ユーザーとの積極的なコミュニケーションで価値提供により貢献できるエンジニアになる

2023-10-26

はじめに

こんにちは。株式会社 Belong の Backend Engineer の noguchi です。

先日弊社のオペレーションセンターで運用している業務自動化アプリケーションの既存課題の解決のためにユーザーインタビューを実施してきました。

そこでエンジニアサイドが想像していた課題に対する温度感のギャップ、業務マニュアルからは読み取れなかった業務内容の詳細を知ることができ、有意義な内容となりました。

現在その情報をもとに開発ロードマップの修正や設計に役立てています。

また、私は前職では受託系の企業に勤めていたのですが、そこでもプロジェクト成功の命運を分けたのはやはり顧客とのコミュニケーションにあったなと感じました。

今回はそれらの具体的なエピソードを紹介しながらユーザーと積極的にコミュニケーションをとることで価値提供により貢献できるエンジニアを目指そう、というお話をしようと思います。

失敗エピソード: 要件定義後に一切コミュニケーションを取らなった結果、検収で大幅な修正が発生。

前職で初期の頃に参画した実装フェーズから参画したプロジェクトでの話です。

要件定義、設計通りに実装、テストを完了させほっとしたところ、検収時に顧客から「思っていたものと全然違う」というフィードバックが返ってきました。

私が初めて顧客と会って言われた言葉がこれだったので大変驚いたことを覚えています。

最大の原因は当時のプロジェクトマネージャーの考えとしては「要件定義で合意が取れた」 = 「顧客と受託側での完成イメージが合致した」といった解釈となっており、その後検収まで一才経過報告等行っていなかったことでした。

上記解釈は理想的ですが、実際問題、要件定義 1 発勝負で完成イメージが合致することはかなり難しいことだと思います。

実際、開発途中で都度考慮漏れが発覚してプロジェクトマネージャーに相談していましたし、都度内々で仕様を決めていたのでこれでは顧客と認識のギャップが発生するのは当然のことでした。

結局その後大規模な修正が発生して丸々 1 ヶ月納品が遅れてしまい、顧客に迷惑をかけてしまう事態となってしまいました。

成功エピソード 1: プロトタイプフィードバック形式で顧客が期待するアプリケーションを納品

上記エピソードの反省を生かし、前職で要件定義から参画させていただいたプロジェクトの話となります。

顧客と協力して要件をまとめたとしてもドキュメントベースでは認識の齟齬が発生しうることの反省を活かし、要件定義前半ではワイヤーフレームを作成して全体感のイメージを共有することにしました。

また、要件定義の後半に入りある程度仕様が定まった段階ではプロトタイプ(API は実装していないがフロントエンドのみで実際の動作感のイメージができるレベル)を作成してフィードバックをいただくようにしました。

各フェーズで画面イメージを通して解像度が上がっていくことで見逃していた要件が浮かび上がり、そのフィードバックを次週の要件定義前に反映させることを繰り返した結果、確度の高い要件定義をすることができました。

その結果、検収では認識違いによる指摘は発生せず少ない微修正のみで済みました。

このプロジェクトで作成したのは業務自動化アプリケーションだったのですが、納品後は効率が大きく改善したと喜びの声をいただけました。

成功エピソード 2: ユーザーインタビューで現場の課題や温度感を解像度高く把握し、開発ロードマップの修正

「はじめに」で少し触れた内容になります。

現職で私が所属するチームで今月から始まった複数プロジェクトの中の 1 つを担当することとなりました。

プロジェクト開始時には本プロジェクトの優先度は大中小のうち、中と設定されていました。

ですが、本プロジェクトの要件決めのためにユーザーインタビューを実施して現場の課題やその温度感をヒアリングした結果、本プロジェクトで追加する機能に対する要望の温度感が高いことを知りました。

その結果を受けて今季の開発ロードマップを変更し、チーム全体で適切な優先度の設定の元でプロジェクトを開始することができています。

もしユーザーインタビューで現場が感じている課題の温度感を把握できず、エンジニア内のみでプロジェクトが進行していたとしたら、本来必要とされる機能は後回しになったが内部的には目標を達成して満足するという、本来の仕事の目的からズレた本末転倒な結果になってしまう可能性が生じていました。

そもそもエンジニアの仕事の目的は何か。

エンジニアは業務の内訳として、個人間の差はあれどコードを書くことにある程度の時間を割きますが、それ自体は仕事の目的ではありません。

コードを書くことの目的は課題の解決、価値提供です。

そのためにはユーザーが抱えている課題、市場が求めていることを正確に把握する必要があります。

そして、そのためにはユーザーとのコミュニケーションが必須であるため、ユーザーとのコミュニケーションはエンジニアにとって重要な業務の 1 つであると私は考えています。

最後に

今までの業務経験から、ユーザーとのコミュニケーションで価値を生み出した事例について紹介してきました。

今回紹介した事例以外にも生み出せる価値はありますので、この記事がユーザーとのコミュニケーションを増やしていく機会になれば幸いです。

弊社は「Make a Contribution/チームや社会に貢献」の価値観のもとに、ユーザーとエンジニアリングチームが日々積極的にコミュニケーションをとって価値創出に取り組んでいます。

もし弊社に興味を持っていただけたら エンジニアリングチーム紹介ページ をご覧いただけたら幸いです。