2014年3月16日
当社は、ソフトウェアの受託開発の仕事で、様々なお客様と付き合いさせて頂いています。
その中に、それほど難しくないのにズルズルと終わらないプロジェクトもあるが、内容も納期も無理に近かったのに綺麗に成し遂げされたプロジェクトもあります。
受注側のチームを的確にリードし、困難なプロジェクトを見事に完成させたお客様の何人かに恵まれました。（本当にわずかの数ですが。）その方々にいくつか共通点があります。
1. 決断力がある
仕様が未確定の部分について、「○○さんの確認を待たないとわからない」のような他人への依存思考でなく、「xx日までに決めます。」のようなコミット姿勢を示します。
その日になっても不確定要素がまだある場合、自分のベストの判断で責任を持って決めてくれます。
受注側から見ると、発注担当者の方の判断が間違って多少やり直してがあっても、いつまでも判断を遅らせるより結果的に仕事の効率が良く頑張りやすいのです。
2. 判断基準を強く意識している
その方々との会話の中に、次のようなセリフがよく聞こえます。
「画面設計書には、何が求められるのか」
「何をもって、実装完了と言えるのか」
「何をもって、結合テストに合格したと言えるのか」
このような合格基準を開発チームとしっかりと打ち合わせ、箇条書きの形まで落としてくれます。
しかも、理想ばかりを言うのではなく、品質・期間・リソースを考慮した現実的な基準を作ってくれます。
明確な合格基準があるおかげで、開発チームが作業量を計算しやすく、頑張れるのです。
逆に、合格基準が事前に定められると、次ような状況になってしまいます。
・予定より遥かに早いタイミングで途中の成果物の提出を求める。
（「出来た物を見ないと、作るべき物のイメージができない」から）
・リリースされる度に、違うことを言い出し、また修正を求める。
・開発チームが永遠のように繰り返されている修正要求に覆われ、次のタスクに進めらる時期が予測できず、スケジュールが破綻してしまう。
3. リスク対処のシミュレーションをやっている
プロジェクトがうまくいかないリスクは、おそらく誰でも意識できます。
但し、そのリスクに対する対処方法は、担当者の方によって異なります。
「既存のシステムとすぐ結合できるかどうか分からないから、とにかく早く物を頂戴」と催促してくることが対処方法だと考える担当者の方々もいらっしゃいます。
（対処方法にならないが。。。）
逆に、できる担当者の方々は、次のような会話をしてくれます。
・「結合する時に、どんな問題が起こると思う？」
・「今何をすれば、それらを防げるのか？」
そして、
「このようなデータを出します」や
「このようなテストプログラムを作って」
などの具体的な対策まで導きます。
4. 会議の終わり時間が明確
できる担当者の方々は、打ち合わせに入る前からアジェンダを持ち、そのアジェンダが終わったらすぐ会議を終わらせます。
打ち合わせを設定する際、「今回は３０分で終わる」とか「２時間を確保してください」など、正確に会議に必要な時間を予測してくれます。
解決すべき全体の課題の数と複雑さを常に把握しているからこそ、会議に必要な時間を正確に予測できたと思います。
逆に、話が拡散して、時間切れのため話の途中で会議が終わってしまうことが多ければ、そのプロジェクトには危険信号ですね。