プログラマにコミュニケーションが足りないと言われる時

IT業界で働く技術者は営業マンでないのに、コミュニケーション能力が必要とよく言われる。
特に、プログラマのプログラミング能力が優れていても、実力を発揮できないとき、君はコミュニケーション能力が足りない、とよく言われる。
その理由について考えたことをラフなメモ書き。

【1】営業マンにコミュニケーション能力が必要と言われるのは、初対面の顧客へモノを売りつける必要があるから。
いかに信頼して買ってもらえるか、人間関係の構築作りに力を入れる。

だが、IT技術者に必要とされるコミュニケーション能力は、営業マンのそれとは全く違うと経験的に思う。
自分よりも上位職の人へ働きかける政治力をすごく要求されるのだ。

特にプロジェクトリーダー、そしてプロジェクトマネージャのように上位の管理職になるほど、自分よりも上位職の力を借りて組織を動かす能力が必要とされる。
以下、どんな状況でそのようなコミュニケーション能力が必要とされるのか、あげてみる。

【2】課題や仕様の不明点をプロジェクトリーダーに解決してもらえない

プログラマが仕様書に従って実装すると、必ず仕様書で不明点が出てくる。
細かな仕様の部分を自分たちで勝手に決めていいのか、プロジェクトリーダーを通じて顧客へ仕様確認すべきか、判断に迷う時がある。

また、仕様書の品質が低い場合、実装してみたらあちこちに穴があり、仕様の整合性が取れておらず矛盾している点があったりする。
そんな時は、プロジェクトリーダーを通じて、本来あるべき仕様に修正してもらわなくてはならない。

すると、プログラマがプロジェクトリーダーに、課題を解決してもらうように働きかけないといけないのだが、信頼関係がなければ、プログラマの思い通りにプロジェクトリーダーは動いてくれるとは限らない。

例えば、開発チームが元請けのリーダーと下請けのプログラマのように風通しが悪かったり、開発者や設計者同士でも信頼関係がなったりする時もある。
すると、プログラマが見つけた課題を報告したのに伝わっていなかったり、課題の重要性や緊急性を認識しないまま放置してしまう時もある。

そして、課題が解決されないまま、開発の進捗が遅れたり、テスト工程の後半になって大きなリスクとなって判明するパターンに陥る。

【3】要員の動員や予算増額をプロジェクトオーナーに承認してもらえない

プロジェクトリーダーが要件定義や外部設計で要件を詰めている時、システムの経験者を早めに入れたいとか、工数見積もりしたら開発工数が大幅に増えるので人員を増やすために予算を増額したい、などの状況が出てくる。
すると、プロジェクトリーダーの上司に当たるプロジェクトオーナー(実際は部長クラス)へ働きかけて、開発チームを円滑に回すような仕組みを整備してもらいたいのだが、プロジェクトリーダーの思い通りにプロジェクトオーナーが動いてくれるとは限らない。

プロジェクトオーナーにとって、組織の人員を一プロジェクトの都合で決めるわけにはいかないし、何故人員を増やしたいのか、その理由に正当性がなければ、そもそも予算を増額してくれはしない。
プロジェクトリーダーは見積り工数の正当性をプロジェクトオーナーへ分かりやすく説明しなければならない責任があるのだが、要件定義における工数見積りは正直正確さに欠けるので説得しづらい。

結局、本来のシステム規模とアンバランスな開発チームで体制を作らざるを得ず、開発やテスト工程で火を噴くパターンに陥る。

【4】変更要求のスコープや優先順位をプロダクトオーナーに調整してもらえない

受託開発の開発チームのマネージャ(又はリーダー)が、要件定義や外部設計で要件を詰めている時、顧客の情報システム部門の窓口に当たるプロダクトオーナーへ、納期やビジネス要件の制約から、工数見積りが大きい機能の開発を後回しにしたり、故意に2段階リリースを選択して段階的に機能拡張していく戦略を提示したりする状況がある。
しかし、顧客にしてみれば、ITのプロに任せているのに何故それぐらいの機能でそんなに工数がかかるのか分からない、とか、やはりこの機能が最優先だ、と言われて、こちらの提案通りにいかない時がある。

あるいは、開発工程に入って、ユーザ部門から度重なる変更要求がやってきて変更管理の手順を守らない場合、変更要求を受け入れて開発する手順を守ってもらうように、プロダクトオーナーへユーザ部門の取りまとめや周知徹底を依頼する時がある。
しかし、肝心のプロダクトオーナーが自分の会社の数多くのユーザ部門を取りまとめる権限がなかったり、その責任を果たせない場合、仕様変更が五月雨式に落ちてきて開発チームが混乱する状況をマネージャすらも制御できなくなる時がある。

特にアジャイル開発では、顧客にプロダクトオーナーの役割を強いる。
プロダクトオーナーは本来自分の会社の業務をモデル化でき、その優先順位を付けることができるくらい業務に詳しくないといけない。
つまり、プロダクトオーナーはアーキテクトの役割も担っている。
だが、全ての顧客がアーキテクトであると自覚しているわけでもなく、受託開発であればアーキテクトの役割すらもSIへ押し付ける。
結局、顧客が本来求めているシステムとかけ離れたシステムが出来上がったり、そもそも納期に間に合わずプロジェクトが失敗したりする。

【5】いずれの3パターンともに、自分よりも上位職又は権限の及ばない人達へ働きかけて状況を変えてもらう能力を必要とする。
特に経験のあるプロジェクトマネージャは、この辺りの事情を深く知っている人が多く、組織を動かす能力に長けているように思う。
ファシリテーションがこの辺りに必要なスキルの一つ。
「ザ・ファシリテーター」では、ファシリテーションとはプロセス設計の技術だ、と主張する一文があり、なるほどと思った時がある。

個人的には工数見積もりの正当性を説明できるスキルも必要と思っている。
上位の意思決定者へ説明する時、この課題をクリアしないとこれだけのコストがかかりますよ、と論理的に話せるならば、納得してくれやすい。上位の意思決定者ほどコスト意識が強いし、その権限を持っているからだ。
IT特有の技術の一つである工数見積もりを使う場面は、多分上記の状況がとても多いように思う。

【6】WF型開発では、上記のようにたくさんの役割を持つ人が多く、その分複雑な階層構造になる。
オフショア開発していれば尚更だ。
レイヤが多くなるほど、上記のような無駄なコミュニケーションを必要とする。

レイヤの多い組織は無駄に複雑なシステムを作る～Conwayの法則: プログラマの思索

プロダクトオーナーやプロジェクトオーナーが開発チームの外にいると、常にお伺いを立てる必要があり、コミュニケーションを取る時間が開発コストへ響く。
XPのオンサイト顧客の概念はその問題にメスを入れたが、Scrumはその役割をプロダクトオーナーという概念で明確化した点がとても有意義だと考える。

最近のアジャイル開発の具体例を聞く時、SNSやゲーム業界の事例が多い。
彼らの話を聞くと、開発チーム自身がプロジェクトオーナーでありプロダクトオーナーであり、全員がアーキテクトでもある。
開発チームの内部で要件の変更、タスクの優先順位、課題の解決を実施できる。
チーム内のコミュニケーションが取りやすい分、開発速度も速い。
本来のアジャイルな開発チームとは、そういう状況を指すのかもしれない。