#19 - 未経験者で実施したプロジェクト

　とあるお客様を担当したときの話です。そのお客様はこれまでプロジェクトを計画通りにサービスインした経験がありませんでした。しかも、それは当然なので仕方ないという考えまで定着していました。

　そんなお客様でプロジェクトが立ち上がり、私がPMとしてリードすることになりました。そこでまず考えたのは、このお客様の若手社員に、プロジェクトを計画通りにサービスインさせる成功体験をしてもらいたいということ。プロジェクト終了後からは若手社員が中心になって保守していくことになるので、自分たちが参加したプロジェクトが計画通りに本番に移行できたとなればその後の自信につながるだろうと考えました。

　そんな中、大きな問題が立ちはだかりました。構築するのは、お客様のアプリケーションでリアルタイムで処理するためのシステムです。主として資材調達の担当の方々が利用される仕組みでした。そのシステムを開発するための要員として集められたのは、お客様から3名、協力会社から4名という人数です。人数に不足はありませんでしたが、問題なのは、協力会社のSEさん1人をのぞいて、当時のシステム構築の前提であるCICSというプロダクトを使ったことがなかったのです。これから学び始めるには期間が不足していました。

　CICSというプロダクトは、画面定義や画面間のメッセージの受け渡し方法などは、知らないとコーディングすらできません。そこで、どうすべきかと悩んだ挙句、唯一スキルを持っている協力会社のSEさんと私で、いくつかのパターンのスケルトンプログラムを作成することにしました。それは、ビジネスロジックが記述されていない、CICS独自のコーディング部分、つまり画面遷移のための制御ロジックなどを標準化したのです。そのスケルトンプログラムを利用して、他の協力会社のSEさんやお客様は、業務用のロジックを埋め込んでいくという開発手法を採用したのです。これでCICSを知らなくてもコーディングができるようになりました。

　コーディングしていたメンバーは、何本かプログラムを作成し、テストを実施するようになると、CICS独自のコーディング部分がどのような動きをしているのかが徐々に理解できるようになりました。そうすると一気に生産性が上がり始めましたのです。なんとか、スケジュール的にも間に合う目処が立ち始めました。

　それでも本番が近づいてくると、テストデータが足りなかったり、データを移行するためのプログラムが不足したりすることもあり、私も進捗管理だけでなく、プログラムを作ったりデータ移行を実施したりして本番予定日の明け方に作業が終了するというギリギリの対応でした。本来であれば、数日前にサービスインできるかどうかの判断を実施して計画を変更するのが正しい対応ですが、そうすると100%サービスインを遅らせることになるため、成功体験ができなくなります。お客様のリーダーとも話をして、ギリギリまで粘るということで合意し、サービスイン当日の朝まで対応を続けました。最後のデータ移行が終わったのが、明け方6:00でした。

　この時は、スキルを持っていないプロジェクトメンバーとともに、計画通りのサービスインを実現して、お客様に成功体験をしてもらうというとても無謀なゴールを設定したわけですが、協力会社のSEさんもお客様の若手社員も諦めることなく賢明な対応をしてくれたため、なんとか間に合うこともできましたし、それ以上に全員が大幅なスキル向上が実現できました。こんな無謀な試みができたのも、お客様のユーザー部門である資材調達部門のリーダーの方に話を通していたからでした。

　お客様の中でいざという時に力を発揮できる人との信頼関係が築けているかということが大きな成功要因となります。この時も、システム部の部長さんと資材調達部の課長さんに事前に話を通し、最悪は当日の9:00前に延期のお願いをする可能性がゼロではないと言うことを理解してもらっていました。もちろん、成功体験をしてもらいたいと言うことが最も大きい目的であるとも伝えていました。お陰で、PMとしても動きやすく報告もしやすい環境で仕事ができたのです。

　開発プロジェクトはシステムを組み上げることが目的ではありますが、一方で育成の場でもあります。その時のプロジェクトを通して何を学んでもらうか、どんなスキルを向上させることができるのかをリーダーはよく考え、計画すべきだと再認識しました。そうすることで美味しいお酒も飲めるようになりますね。