第５回　最初の大規模プロジェクト（その３：本プロジェクトの反省と課題）

筆者は上司と一緒にお客様の役員の方にお詫びに行くことになりました。筆者は、問題発生のお詫び（経緯と原因を含む）と同時に品質の安定化策および性能対策のお願いをしました。現場の関係者は品質ばかりを問題にしていましたが、サービスを開始したセンターは負荷の少ないセンターであり、これから移行する予定の東京や大阪のセンターは負荷が高いので、業務負荷を他のセンターに分散して欲しいと要望しました。お客様の役員の方は問題発生の経緯を聞き、「担当者が要望を聞いてくれない場合は直接私のところに来なさい」と、筆者の要望を全面的に受け止めてかつ勇気付けてくれました。この時、「半年前にこの方に、勇気を持って、要望に行けば良かった」と強く思いました。しかし、当時はこの方とは面識がありませんでしたので、日頃からお客様の上層部の方と面識を持つことの重要性を痛感しました。以来、筆者は日頃から人脈作りをしておいて、難しい問題が発生したら、お客様の上司の方にお願いに行くことにしました。（勿論、現場の担当者の方には、迷惑が及ばないような配慮をしました。）

本システムは、その後、約半年に渡って負荷試験・性能試験および実端末試験を実施して、名古屋センター、大阪センター、東京センター（業務負荷軽減措置を実施後）などの業務負荷の高いセンターを無事に移行しました。そして１～２年後には、本システムは品質の良いシステムの仲間入りを果たしました。

本プロジェクトは、多数の協力会社がプロジェクトに参加しました。この点に関して、試みた項目について触れておきます。

第一は、一括請負契約の能力を向上する手法です。
当時は協力会社も会社を設立して日が浅く、開発力およびマネジメント力が低いので派遣契約が主流でした。しかし、主力の協力会社から「将来のために一括請負を試行したい」という申し出がありました。開発力やマネジメント力が心配だったので「実行責任契約」という手法を試行しました。契約は一括請負ですが、協力会社は現場に全員常駐して当方がＯＪＴで協力会社にマネジメント教育を実施するという方法でした。問題が発生したら協力会社が責任をもって対応しました（対策費用は協力会社で負担）。本プロジェクトの協力会社要員数の約５０％を占めたこの協力会社は、このプロジェクトを実験台にして早期に一括請負の力を蓄えました。当方にとっても信頼できるパートナーが増えたというメリットのあった実験でした。

第二は、協力会社とのパートナーシップを強化する仕組みです。
協力会社の幹部（役員クラス）との定期的情報交換の場を設定したことでした。当時は、本プロジェクトは問題プロジェクトとの悪評が高く、協力会社から嫌われていました。このイメージを払拭するために、協力会社の幹部の方々と相互協力して開発環境の改善をするのが狙いでした。定期的に本音のディスカッションをして問題点の指摘や解決の提案を受け、実現可能なものは早く実現しました。特に、オンライン処理の結合試験の大部分をジョブ・ユニット化（試験専用のオペレータを数名雇ってマシン試験を実行）し、開発者が試験実施に付き合わない方法を考えました。（オンライン試験のクローズ化と呼びました。）

更には、お客様にもお願いして協力会社からの環境面の改善要望を実現しました。逆に、お客様が悩んでいる情報などを提供すると、前向きに協力するようになっていきました。その結果、プロジェクト関係社間相互の意思疎通が図れて団結力のようなものが生まれ、悪い評判も次第に薄れていきました。

本システムの体験を通じての反省点および今後への課題などを以下に整理してみました。

サービス開始後に発生したトラブルの影響の把握が甘かったこと。
（負荷試験や性能試験のお願い時に、発生が想定されたトラブルに対する運用現場の影響をもっと詳細に調べて正確に説明すべきであった）
お客様のご担当、関連部門（購買部門など）および上司（役員クラスまで）に日頃から人脈を作ること。
（出来れば、適度の間隔でお会いすること）
不安な部分はサービス開始後に必ず顕在化するので納得いく対策を実行すること。
（お客様の立場を理解して対策を検討し、説明すること）
お客様の責任者が人事異動で代わることを考慮して、交渉経緯のエビデンスを公式に残しておくこと。
（今回は、たまたま後任者が理解ある方だったので問題にならなかった。本来は、もっとシビアなことになることを想定しておくべきでした））
一方、結果的に予想以上に上手くいったことを以下に示します。

予算（工数）にリスク分を盛り込んで粘り強く実施した結果、目標通りの工数を確保できたこと。
（追加試験のコストもほぼカバーできたのは幸運だった）
品質を向上する基本は「机上レビューの繰返し実行」だと再確認できたこと。
（以後のプロジェクトでもこの手法を使って成功した）
進捗状況はお客様を含めて関係者全員が良く見える状態にすること。
（問題の大きさを誰もが理解できることが重要：全員協力体制の基本）
成功事例を早い段階で示せば、抵抗していた人も自発的に実践するようになること。
（「単体試験の机上レビュー徹底」は協力会社も半信半疑の様子だったので、協力会社の説得に苦労していたが、身近で成功を確認すると積極的になった）
協力会社の幹部の方と本音のコミュニケーションの場を作ると、前向きな提案などの参加意識を高揚できること。（協力会社からも幾つかの有効な提案を頂いた。）
さて、肝心の本プロジェクトの所要工数ですが、６ケ月の追加性能試験の工数を含めて目標の工数（３，０００人月）以内に収まりました。本システムのプロジェクトでは初めてのことでした。サービス開始直後の品質不良問題は大失敗ですが、それ以外の自分で立てた本プロジェクト計画ついては、減点が殆ど無い状態で遂行できたと思いました。このプロジェクトの失点を少なくできた要因は、前のバージョンのリーダーが残してくれたプロジェクト完了報告書でした。この報告書から、本プロジェクトの課題に適応した予防策を立案できたし、負荷試験・実端末試験の波乱はあったにせよ、ほぼその実行計画通りにプロジェクトは進んだのでした。プロジェクトの完了報告書を残すことの重要性を改めて認識しました。

さて、この最初の大規模プロジェクトの物語では管理手法について触れませんでしたが、筆者は予算管理・進捗管理・品質管理に興味があり、それまでの開発経験の中で数値管理をかなり実験していたので、我流ながらも重要な管理項目および報告を鵜呑みにしない手法（自分の目でチェック・評価するポイント）をある程度身に付けていました。本プロジェクトでも存分にこの手法を使い、プロジェクトの状況をかなり的確に把握していたことを付け加えさせて頂きます。この話の詳細は後の章で触れたいと思います。