「工数見積」を受け取る側のマインドの話

はじめに

おはようございます。PMグループの神澤です。

今回は、プロジェクトを進める上で欠かせない「工数見積」の受け取り方について語ろうと思います。

今回のテーマ

工数見積は、簡単に言えば「どれくらいの期間でリリースできるか」を考えるための要素です。

プロダクトを販売する企業の人であれば、自社が作るプロダクトがいつ進化してユーザーに提供され始めるかは、誰しもが気になる点だと思います。

ただ、Amazonの配達時刻のような、想定外の事が無ければ予定通り行きます、といった期待感と異なり、多くの人は一度はリリース延期というイベントを経験していると思います。

ここでは、リリース日を決めるための内訳、工数見積に焦点を当てて、どのような要素が含まれるかを説明します。

工数見積に関係する人

プロダクトの開発の流れは、大きくは「要求→設計→開発→リリース」という形です。

この開発の流れに関わる人は、ビジネス、PM、エンジニアが主となり、デザイナー、QA、クライアント、といった関係者がいます。

一つのプロジェクトに対して、関係者が多くなるほど、「専門知識」や「把握情報量」に差が出ます。逆にいうと、開発の仕方を詳しく知らない人、運用を詳しく知らない人も発生します。（そのため関係者全員をチームとして考え、補いながら専門分野の役割分担をして開発を行います）

この「関係者が多くなるほど」という点が重要です。

限りなく少人数なチームであれば、コミュニケーションロスは起きづらく、どこまでどのように分からないのか、という温度感が理解しやすく、結果、工数見積もその内訳に対する期待感がズレにくいです。

逆に、関係者（開発チーム外だけでなく、開発チーム内メンバーも含む）が増えれば増えるほど、把握情報量を全員が100%持つ事が難しくなり、コミュニケーションによる伝達が難しくなります。

では、このコミュニケーションロスの内容にはどのような事例があるかを挙げていきます。

受け取り手の期待ズレ

開発者は、全ての開発を事前に設計できるとは限らない（知識や経験の期待ズレ）
開発者は、自分の技量を正確に把握しているとは限らない（=1日で出来るかという予測の難しさ）
要件を決める人（PM等）は、要求を達成するための項目洗い出しを網羅できているとは限らない
要求する人は、相手に全てを伝え切れているとは限らない

見積側の技量とは異なる問題

要件が漏れているとは、予想する対象が存在していないということ（=見積項目抜け）
要件が期待と異なっていると「訂正」と「再開発」という作業が生まれる
要件が曖昧だと、実際の作業内容も曖昧となる。曖昧な箇所には、予想さえ出来なかった「やるべきだったタスク」が含まれる

じゃあどんなことに気を付ければいいんだろうね

「工数見積」の捉え方には難しさがあり、その内容をコミュニケーションロスの具体例を使って一部書いてみました。

ではどうするか。全ての要件を完璧にすれば問題ない、と言ってしまえば、それも選択肢としてありますが、現実は非常に難しいです。

見積内容の認識齟齬以外にも、テキストの用語が相手に伝わるか、背景理解に差があるか、十分に内容把握する時間的人的余裕があるか、等、懸念すべき事は多くあり、辞書のような仕様書にも、街宣広告のような洗練されたテキストにも、万能な価値はありません。

私が思う重要な点は、関係者同士の「相互理解」です。

ビジネス側にも開発側にも、「専門知識」があり「把握情報量」があります。関係者を各専門家として対等に問題に向き合い、チームとしての調和が必要だと考えます。

業務上のメンバーは、言ってしまえば寄せ集めのメンバーとなる事が多いです。スポーツでいうと近所の人を集めた草野球や、偶然同じ学校にいた部活動のような状態です。プロチームのようにドラフトで人を集める手法もありますが、どの企業でもそれが可能とは限りません。

このような状態で考えるべきは、「このチームで出来る最善の策は何か」を「考え続ける」ことだと思います。

上記の箇条書きは、「あの人なら出来ると思ってた」「自分なら出来ると思ってた」というマインドだと特に起こりやすいと思っています。実際には誰しも不完全な点はあり、得意だから全能ということはなく、だからこそ集団で物事に当たることに、価値があると思っています。

「工数見積」（だけに限る話ではありませんが）でも、工数を計算する上での内訳内容や、どのような人が考えたか、そのシチュエーションや環境はどうだったか、を全員が考慮し、今いる人が出来る最大限のパフォーマンスを出そうというマインドを持っていられると、自然と把握情報量の差異が減り、徐々に信頼できる工数の、算出が可能、もしくは受け取り方が可能となるかなと思います。