オフショアプロジェクトマネジメント

「標準テキスト オフショアプロジェクトマネジメント 【PM編】」を読んだ。
こまごまとした文章よりも、コラムや経験に基づく具体例の方が面白い。
オフショア開発に携わった経験がある人ならば、うんうんあるよ、と頷く箇所が多いのではないだろうか？
一部のコラムを抜き出して、感想をラフなメモ書き。

【1】自社のオフショア子会社よりも外部の協力会社の方が安いとしたら、どちらを選択するか

あなたはオフショアPMOで海外発注数量の数値目標を持つ責任者とする。
ある日、顔なじみの協力会社の営業マンがやってきて、自社の３年前に設立したオフショア会社よりもはるかに安い人月単価を提案してきた。
そもそも、あなたの会社のオフショア社内単価は随分高めに設定されている。

あなたは、勝手を知る協力会社の提案を受け入れるか？
それとも、オフショア発注数量を数値目標を達成するために、赤字覚悟で自社のオフショア会社を社内プロジェクトへ展開し続けるか？
あなたはどちらを選択するか？

このコラムでは、日本のSIですらも「赤字なら自社のオフショア会社を使わない」人が過半数を超えたらしい。
つまり、人月単価の高い自社オフショアよりも、外部の協力会社を使う方が合理的だ、という判断を下している、と。
同じ質問を米国人マネージャにしたらどうなるか？
おそらく、「グループ企業とはいえ、赤字なら絶対使ってはいけない。コスト競争力のある外部の協力会社を積極的に使うべきだ」という回答になるだろう、と。

このコラムで言いたいことは、企業統治における経営指針に従って判断すべき、ということ。
経営方針として、オフショア子会社を育てるために最初は我慢して使うべきなら、それに従うし、取引基準は経済合理性に基づいて判断すべきなら、品質が同じなら安い方を選択することに従う。

個人的には、この質問では、日本のSIではオフショアPMOと現場のプロジェクトマネージャの間で緊張関係が発生し、一つ上の階層のプロジェクトオーナーがトップダウンで判断する事例が多いのではないかと思う。

オフショアPMOが数値目標を持たされた責任者であるがゆえに、赤字であろうとも、彼は自分の職務を果たそうとするだろう。
逆に、高い単価の技術者を押し付けられる現場のプロジェクトマネージャは、赤字にならないようにするために、品質が同じで単価の安い外部の協力会社を選択肢したいだろう。
つまり、社内では、それぞれの現場責任者が個別最適の選択をするうちに、会社全体としては全体最適とならない事例が多発する時が多いだろうと思う。

【2】アジャイル開発とは名ばかりで、実態は手戻り多発の反復作業

オフショアとアジャイル開発の親和性を調べてみると、実はアジャイルとイテレーション(反復)の意味を誤解していた事も少なくないらしい。
つまり、見切り発車と手戻り多発が慢性化した状態をアジャイル開発と呼んでいただけだ、と。

個人的には、地理的にチームが分断されたオフショア開発では、上流工程が自社の社員、下流工程が海外オフショアのように工程ごとにさらに分断されるために、工程を一体化して小規模リリースしながら作っていくアジャイル開発とは、水と油だと思う。

【3】オフショア拠点では品質保証スタッフは不人気

多くの海外オフショア会社では、プロジェクト実行部隊から独立した監査チームが計画的にプロジェクトを監査する。
CMMI導入に熱心な企業ほど、SQAを設置して品質管理を実践している。
しかし、中国の開発現場では、品質保証業務に人気がなく、プロジェクト監査が弊害化しやすい、と。

理由は、中国人IT技術者にとって品質保証業務は、キャリアとして確立されておらず、仕事ができない人が配属されるイメージがあるから、と。
実際、品質保証業務では、プログラミングよりもひたすら定量化したデータをまとめて報告書を作るドキュメント作成作業がメインだろうから。
すると、オフショア会社へ発注するSIにとっては、海外オフショア会社のCMMIのアセスメント(評価)認定が本当に保証されているのか、見極める必要がある、と。

品質管理は日本のお家芸。
その理由は、日本では製造業をモデルとしてソフトウェア工場を目指していたからとも言える。
しかし、日本のソフトウェア工場の実態は、開発プロセスの一部が標準化された部分最適化の状態に過ぎない、と。
すると、そのやり方が海外のオフショア発注で通用するとは限らない。

【4】「日本人プログラマ」は不要と公言してはばからない日本人上司の自己矛盾

大手SIの金属30年の部長は「付加価値の低い下流工程は全て外注するから我社にプログラマはいらない」と公言する。
しかし、ベテラン日本人管理職のキャリアをヒヤリングすると、彼らはかつては泥臭いプログラミングで技術を鍛え、OJTをこなしながらマネジメントスキルも身に付けていった人が多い。
しかも一部の達人は、今なお現場でコーディング作業に従事し、誇りを持って仕事をしている、と。

でも、彼らが管理職につくと、若い従業員にはプログラミング技術よりも上流設計や顧客との折衝能力を期待するようになってしまう、と。
自分たちは泥臭いプログラミングでキャリを築いた事実を棚に上げて、若手技術者にはプログラマ不要論を説教する矛盾がある、と。
大手SIの管理職にいるベテラン社員は、おそらく会社で育てられた最後の情報技術者だからこそ、若手技術者はオフショア開発に消極的になり、抵抗勢力になる、と。

個人的には、技術者がマネジメント技術を身につけることは重要と思うけれども、ライン管理職になって、プログラミング技術に疎くなり、現場のプロジェクトを回す技術すら忘れてしまうのは危険だと思う。
昔にCobolとメインフラームで腕を鳴らした経験があっても、スマートフォンやタブレット上でアプリを作る開発や、JavaやRubyを使った業務系Webシステム開発では、設計のボトルネックの目利きすらできないだろう。

また、現在の日本のSIの主流の開発アプローチは、「日本人による日本語で書かれた日本人顧客のための」プロジェクト運営に最適化されている垂直統合型モデルだ、と。
この手法は、「大手SIは上流工程のみ担当し、付加価値の低い下流工程は協力会社や海外オフショアに任せる」水平型モデルと、そもそも水と油だ。

日本のSIのオフショア開発で成功例が少ない理由は、従来の日本の製造業をモデルにした「職人のすり合わせ」という垂直統合型モデルに、オフショア会社の社員を取り込めていないからだろうと推測する。

【5】オフショアでいきなりプロセス改善は難しいから、まずは整理整頓から

あるオフショア会社へトヨタ生産方式の５Sを導入しようとして失敗した。
失敗の原因は「ISO導入の失敗」と同じ。
そこで、中国製造業の事情に明るい専門家から、中国の職場でいきなり躾(プロセス改善)の展開は難しいので、まず整理・整頓から着手してはどうか、と提案した、と。
整理整頓を持続させるには、改善前(Before)と改善後(After)を記録し、PDCAサイクルを回していくことが大事だ、と。

プロセス改善の導入は、オフショアだろうが日本国内だろうが、経験上難しいと思う。
今までの価値観を否定し、新しいやり方に慣れようという気持ちが皆になければ、そもそも続かない。
そして、少しずつであっても成果がでなければ、モチベーションも維持できない。

日本で生み出されたプロセス改善の技法は基本的にはPDCAサイクルと職人のすり合わせが中心にある。
従業員の価値観を平準化し、価値観を揃えることで、垂直統合型モデルで成功してきた。
でも、そのやり方で果たしてうまくいくのだろうか？
３年先のマーケットすらも見えない現代で、多様性を認めない職場でやっていけるのか？