最近,製造業を中心に「見える化」の話題が大きく取り上げられています。

 ソフトウェアはハードウェアよりも開発の工程が見えにくいため,開発やメンテナンスにおいて,より一層の「見える化」の努力が必要となります。さらにソフトウェアのオフショア開発においては,海外側の開発状況や担当技術者の顔や表情が見えにくいため,特に大小いろいろなトラブルが数多く発生します。

 筆者はオフショア開発におけるトラブルを出来る限り防ぎ,そして発生するトラブルの影響を最小化するためのいろいろな取組みをやってきました。その結果,よい最終プロダクツ(成果物)を生み出すためには,途中のプロセスが重要であるという,ごく当り前のことに気付きました。ソフトウェアの開発プロセス,オフショア状況,そして海外技術者の表情などが「見える」と,適切な対応がとれるので,結果としてプロジェクトがうまく進むという点です。

 オフショアをうまく進めるための改善ポイントとして,(1)日本側組織の変革マネジメント,(2)調達・契約等のビジネスのマネジメント,(3)開発および品質に関するマネジメント,(4)知的労働の要となる人材のマネジメント,(5)日本側とオフショア側をうまくつなぐコミュニケーションのマネジメント,(6)思いもよらないときに発生するリスクのマネジメントなどがあります。これらが「見える」ようにマネジメントすると,よい結果が出るようになります。

 今回は,日本側とオフショア側を含めたプロジェクト全体のマネジメントの「見える化」ついて感じている点をお話します。

オフショア側に報告書を作成させ,考えを「見える化」する

 人間の考えや意識は状況に応じて無意識のうちに刻々と変化します。そこで,その時点での記録を残そうと,オフショアの当初から,打合せやレビューの都度,日本側が議事録を書き,オフショア側で確認してもらうやり方をやっていました。しかし,思ったほどうまくいきませんでした。オフショアメンバが頭の中で考えていることがよく見えないのです。

 そこで考えついたのが,オフショア側に議事録や報告書を書いてもらい,日本側が確認するというやり方です。日本の標準フォームを渡してもなかなかうまく書いてもらえないので,書くべき点のみをオフショア側に説明し,オフショア側で使いやすいフォームを作成してもらいました。そうすると,自分で考えて作ったフォームのせいか,遵守の意識も強くなり,また書きやすいためか,よく書くようになりました。記述が抜けている事項を指摘したときも,よく修正対応してもらえるようになりました。

 オフショア側で書いたドキュメントや話の中に,彼らが何を考えているか暗黙知となっている部分が垣間見えます。これにより,当初日本側が書いてオフショア側で確認していた場合と比べて,格段にオフショア側の考えや意識がわかるようになりました。

 こうしてオフショア側で書いてもらうことに成功した文書の中には,技術ドキュメント,報告書(週報/日報/都度),議事録,バグリスク(Code Review Sheet),レビュー記録,テストケース結果/進捗報告書,SE作業分析などがあります。

 これらをうまく書いてもらうためには,オフショア側メンバのモチベーションが重要になります。時間がかかりますが,定着させれば間違いなく効果が出てくるでしょう。なぜなら彼ら自身がそれがよいと考え,自分自身で実行するからです。
 

当初計画,進捗,実行結果のデータを分析する

 当り前のことですが,最初にタスク/要素に分解した開発及びテスト・スケジュールを作成し,それに基づいて実行し,実績を記入してもらいます。タスクごとに,計画の下に実績が塗りつぶされるのを定期的に見ていると進捗が見えます。計画どおりに進んでいると全体が最初の読みの範囲内に入っていることがわかります。この場合心配はあまりありません。

 反対に計画の一部が遅れると,当初の読みが甘いか予期していないことが発生していることがわかります。その場合スケジュールの辻褄は合わせたとしても,何か隠れた問題点があり,それが後日大きな問題を引き起こすことが予想されます。そのことがわからず,高圧的,指示的に対応した場合は悲惨な結末となりました。これは先の寄稿でお話ししたとおりです。それ以降は,オフショア側と目線を合わせたオープンなディスカッションをするようにしています。

 これまでの経験によると,うまく進んだプロジェクトでは,スケジュール予定と実績を見ると両方がほぼバランスしていることがわかっています。レビュー指摘の内容や件数,テストケースの内容や件数,バグの内容や件数そして重要度などを分析すると状況がよくわかります。

 筆者は以前,担当の技術者から概要報告だけを受けるようにしていました。しかし最近では,必ずそれらの元データを見るようにしています。データを見る経験を積むと,データを元にある程度の状況が読み取れるようになります。オフショア組織は日本国内とは状況が異なるため,詳細な開発指標データをとることはできないケースが場合が多々あります。しかし,最低限のデータをとることにより,状況が客観的に読め,判断にとても参考になるのです。

 このように,ドキュメントやデータの形式知は,状況判断に大変参考になります。しかしさらに注意すべきことは,現在隠れていて後で顕在化する問題点です。

 これらは暗黙知となっているため,他人や外部にはわからないケースが多くあります。筆者はドキュメントの形式知となっている内容に必ず目を通すと同時に,オープンでフランクなコミュニケーションの場をもち,それを聞き出し,見えるようにする努力をしています。

 「報告書を拝見しました。開発は予定どおり進んでいるようで感謝しています。ところで,何か心配なところはありませんか?どのようなことでもよいので気になっているところがあれば言って下さい」。常日頃,このように自然な対応をしていると,海外技術者の方から,「実は,この辺りがわからず困っています」とか,「お客様からこの点について最終確認が届いていないので弱っています」──などの話しが出ます。そうした問題点が見えると,素早くアクションを起こし,問題の芽が小さいうちにつぶすように対応します。これは極めて効果的です。

 また毎週のプロジェクト定例会にて,客先責任者,プロジェクトリーダ,そしてブリッジSE人材とも直接対話し,暗黙知をつかむようにしています。