情報システム室の進地＠日比谷です。
プロジェクトの最初のお客様との打ち合わせ、まだプロジェクト化していない状態も含めて最初の打ち合わせからエンジニア、そして可能であればテスターを同席させるメリットについて書きたいと思います。会社の体制の都合などから実現が難しいケースもあるかと思いますが、なるべく初期からエンジニア、テスターを打ち合わせに参加させるようにしましょう。
あるプロジェクト、成約はめでたいが・・・
営業の野口さんが帰社して一声。
野口さん: 「◯◯社のAプロジェクト成約しました！！」
一同: 「おめでとうございます！！」
野口さん: 「エンジニアの田中君に作ってもらった見積にちょっとアレンジして無事通りました！ありがとう田中君！！」
田中君: 「は、はい！（アレンジ？）」
野口さん: 「あと、お客様の希望で納期がちょっと短くなっているけど、大丈夫だと思うんで、よろしくお願いするね！ プロマネは佐藤さんになると思うけど、よろしくお願いします！」
佐藤さん: 「え、あ、はい（ちょっと短く？？）」
後日、社内Mtg。
田中君: 「あのー、佐藤さん、僕が出した見積からかなり要件が増えて、複雑化しているんですが・・・」
佐藤さん: 「そうだね。それと納期だけど、2ヶ月も縮まってて、増えた要件と照らし合わせると今日から動いても厳しそうだな。あと、システムの応答時間を最大5秒以内にするという非機能要件も追加されているみたいだ。テスターの上野さんとも連携しておかないとな。野口さん、納期とスコープの調整をお客様としたいのですが」
野口さん: 「あー、ダメです！納期は絶対です。もう約束してきたんですから。先方は納期の直後に新製品の発表があって、これはずらせないんですよ。スコープもどれも必須機能と伺っているんで削れません！」
田中君＆佐藤さん 「・・・」
佐藤さん: 「じゃあ、体制を強化しましょうか。コストはかかるけど仕方ない」
野口さん: 「ダメです！今回はかなり出精値引きもしているんですから、現状の体制を強化したら赤字になっちゃいますよ。この体制でお願いします！」
田中君＆佐藤さん 「・・・」
そして、デスマーチへ。
エンジニアを最初から同席させることで得られるメリット
上述したような展開は、PMすら同席していないのでおとぎ話なので現実にはありえませんが1、分業が進んだ企業などでは似たような事象が起きやすくなります。
- 曖昧な要件で解釈次第では無限にやることが増えかねない状態での受注
- エンジニアが聞いていない追加要件とそれに対する非エンジニアによるざっくり見積が提出されている
- 品質の観点も含んだ実現可能性の考慮がない
- 納期、スコープに関する現実的な調整ができていない
- etc
このような問題が噴出することは稀によくあります。
営業とPM、エンジニア、テスターとはインセンティブ、優先事項が違いますので、個別に動くとどうしてもこのような問題を生じやすいのです。ですので、解決策としては非常にシンプルです。PM、エンジニアを最初から打ち合わせに同席させることです。逆にいうと、営業だけでお客様と打ち合わせをしないことです。PMにエンジニアの素養があれば、営業とPMだけでも良いのですが、やはり実際に手を動かしてモノを作る人間の専門知識や観点、留意事項の気づきのレベルには敵いません。
私は、クライアントワークをしていた時は、営業に無理を言って打ち合わせに同行させてもらっていました。それは、最初に就職した会社のルールで常にエンジニアがお客様との打ち合わせに同席する形になっていたので、それが習い性になっていただけなのですが、非常に理にかなっていたと思います。
エンジニアがいれば、以下のメリットを享受することができます。
- 曖昧な要件の具体化をその場で進められる
- 追加要件に対する精緻な情報をエンジニアにインプットでき、正確な見積が出せる
- 実現可能性に関して早い段階でお客様にフィードバックを返せる
- 納期、スコープに関する現実的な調整が早い段階でできる
- お客様の期待値を適切にコントロールしやすくなる
- お客様が本当に解決したい課題をエンジニアが認識でき、よりよい提案を行える余地が生まれる
- etc
要は、製造責任を負う人間を必ず打ち合わせに最初から参加させましょうということです。
なお、そのプロジェクトを受注した時に実際に担当するエンジニアに同席してもらうようにしてください。実際には担当しない上級エンジニア2は製造に対する責任感にどうしても構造的に欠けますから、営業のインセンティブに対するには弱いです。妥協もしやすくなりますので、注意してください。
テスターにもできれば同席してもらおう
エンジニアが同席していれば、先述したようなメリットを得ることができるのですが、エンジニアだけだと弱い観点があります。
- 期待される品質基準の認識合わせ
- 品質面での要件の実現可能性
- 非機能要件の担保（ユーザビリティ、運用負荷、セキュリティ、パフォーマンス、etc...）
- テスト容易性の判断
- etc
こうした観点を入れるためにはエンジニアにテスターの素養もあればエンジニアだけでもいいのですが、なかなか現実的には難しいでしょう。また、エンジニアは製造することに対して責任感を持ちやすいですが、完成したモノを納品したあとについてはどうしても考慮が弱くなりがちです。それは構造的にそうなのです。その点、テスターはよりお客様やユーザに近い観点からシステムを眺めることが構造的に行いやすい立場になりますので、テスターも最初から打ち合わせに同席するとプロジェクトはより盤石に進めやすくなります。
デメリットもあるけれど、それでもエンジニアが同席した方がお釣りがくる
こうした様々なメリットがある、エンジニア、テスターの同席ですが、デメリットはあるのでしょうか？あります。それは工数（＝コスト）がかかるということです。成約前の案件一つ一つにエンジニアとテスターの工数を割いていたら、エンジニアとテスターがモノづくりをする時間もなくなる、そういう意見も多いでしょう。
それはその通りです。しかしながら、それでも私は同席した方が良いと思っています。
5分気をつけて、1時間で仕事が終わるのと、行き当たりばったりで仕事をはじめて3日かかるのと、どちらがいい？と聞かれたらほとんどの人が前者を選ぶと思います。そういうことです。目先の利益に目を奪われてはいけないのです。
つまり、プロジェクトの初期で曖昧な部分を明確化し、期待値調整をして、顧客との友好な信頼関係を構築して、プロジェクトを安定稼働させる方が、これらを行わずにプロジェクトを走らせて不良債権化3するより、はるかにメリットがあると考えます。なぜなら、前者は結果的に仕事が早く終わり、顧客の期待を満たしやすいので次の受注にも繋がりやすく、何より計画が立てやすいからです。
不良債権化してしまうと、それはいつ終わるか非常に見えにくくなります。それは、社内で空いているリソースが視覚化しづらくなるということであり、先々の計画が立てにくくなるということとイコールです。先々の計画が立てにくくなれば、目先の利益により目を奪われやすくなり、また不良債権化しやすいプロジェクト受注をしてしまうことになります。そんな繰り返しでは人も辞めていきます。悪循環です。
エンジニア、テスターの同席（PMはもちろん同席していますよね？）は、転ばぬ先の杖。お客様により貢献するためにも同席をするようにしてみてください。
11
