#14 - 新組織創設への挑戦と読み違い
2000年問題が何事もなかったかのように過ぎ去り、世の中も平穏な時間を過ごせるようになった頃、社内では主流となり始めたSIの仕事の効率化を迫られていました。よくある話ではありますが、年間のSI件数をみると約70-80%は、3000万円以下の小規模案件で占められていました。特にインフラの構築案件はほとんどが小規模案件でした。ただし、金額でみると、全体の約70-80%の売り上げは、大規模SI案件の20-30%で押さえられていました。これ自体はよくある話で、現在も構造はあまり変わっていないと思います。
そのような背景を受け、当時、製造業のお客様を担当していたラインの私としては、大規模案件に関しては経験豊富な統括PMを中心に組閣すれば問題ありませんが、多くの小規模案件を効率よく実施するための特化した部門を創設した方が標準化も進めやすいし、大規模案件のPMになる前の段階としてスキルアップするのには適しているのではないかと考え、社内で小規模案件のみを推進するチームの創設を提案し承認され、翌年新しい組織が創設されることとなり、結果「お前がやれ」ということで最初のラインとして私が着任することになりました。ほとんどの場合、案を出した人がリードすることになるということはよくある話ですね。
最初に検討したことは、小規模案件のアプリケーション開発とインフラ構築のプロジェクトの進め方をある程度標準化してテンプレート化できれば、個人のスキル差によるプロジェクト品質のばらつきを最小化できるはずだということでした。アプリケーションに関しては、社内にもガイドや事例が多くあり、経験者も多いことからWBSテンプレートや見積もりの標準、進捗管理方法など全般的に準備できましたが、インフラに関しては、なかなか情報が集まりませんでした。インフラは、お客様環境を考慮しなければならないことと導入するHWやSWバージョンによって、作業が変化してしまうので、共通のWBSテンプレートを作成しても非常に荒いものになり、結局、経験者がガイドしないとなかなか理解できないということが判明しました。これは、今でも同じかもしれませんね。
インフラの案件に関しては、標準化を強力に押し進めるのは労力に対する効果が高くないと判断しました。もちろん、荒いレベルでの標準化は必要なので、HW選定に始まり手配、導入、カスタマイズ、稼働確認、アプリとの連携確認などは共通テンプレートやガイドとしてまとめる意味は高いと思います。
当時は、基本となるOSの導入や、データベースを主とするミドルウェアの導入など、ミッドレンジサーバーへの導入などの案件の発生が継続的に発生していたので、まずはミッドレンジをターゲットとして活動を開始し始めました。ミッドレンジサーバーとはユニックス系列のサーバーと考えてください。
小規模案件の場合は、効率化や提供コストのミニマイズを考慮すると2-3プロジェクトを一人のPMがリードできるようにすることが重要となります。大規模案件と違い、PMがSEの仕事を兼務することも多くありましたが、そうすると問題が発生した場合、プロジェクト管理が疎かになるリスクを孕んでいました。したがって、PMを目指しているSEへのアサインとしては、複数のプロジェクトを管理するスキルをつけさせるためのPMをアサインするというのも育成として考慮すると必要であり、プロジェクトにとっては小規模でもPM専門職をアサインできてリスク回避にもつながるだろうと考えました。
実際に組織として運用を開始しましたが、描いていた計画通りには全く進みませんでした。メンバーはどうしてもリーダーに頼ることになり、リーダーの負荷が下がりません。よって、リーダーによる標準化の推進やリーダー間連携を進めようにも、お客様サイトに行きっぱなしとなることが多く進められません。お客様の案件を止めるわけにはいかないので、どうしても継続した流れの中で新しいことを実施する時間を捻出する方法を最初に計画すべきだと反省したのですが、その時、それをも凌駕するような時代の流れに飲み込まれている事に全く気付きませんでした。当時は経済が上向きとなり小規模案件の数が激減していったのです。案件がなくなったわけではなく、大規模案件が増加し、小規模案件を包括したような案件になって行ったのでした。複数のアプリケーション開発とインフラ構築が一つのプロジェクトとして案件化され始めました。結果、小規模案件推進の専門組織は残念ではありましたが、一年で解散してしまいした。
しかしながら、複数の小規模案件を一人のPMが管轄するという考え方自体はその後も生き続け、大規模案件の統括PMの元で仕事を実施するSub PMは、異なるプロジェクトでのSub PMを兼務するというような形態で生かすことができ、大規模PMへの登竜門的な考えにつながりました。