先発完投型から継投型への変化
プロ野球もオフシーズンとなり，来期の契約について国内/海外ともにポストシーズンを賑わしています。先日，筆者の家に届く新聞でも，中継ぎ専門のピッチャーが契約更改で評価が低く，来年度は先発としてがんばりたいといった主旨の記事を目にしました。プロ野球は，過去に比べて分業化が進み，ピッチャーで言えば「先発」「セットアッパー」「抑え」「敗戦処理」と明確に役割分担が進んでいるようです。
同様にシステムエンジニアの世界でも，情報処理技術者試験の多様化（※1）から分かるように，分業化は進んでいるように思います。「システムを提案する人」「受注後にプロジェクトを取り纏める人」「ネットワークを専門に扱う人」「開発に責任を持つ人」「稼動後にシステムを運用する人」といった具合です。システムが複雑化する中で，先発完投型では専門性をなかなか発揮できないためでしょう。しかし，実務では，システムの提案を行った人がプロジェクトマネージャ（リーダー）となることが圧倒的に多いと思います。
主な理由は，お客様との信頼関係，業務面での精通度合い等により仕事内容を上手く引き継ぐことができないためと想定されます。お客様の中に，体制引き継ぎを申し入れすると「受注を取ったら，逃げるのか」とネガティブにとられた経験をお持ちの方もいるでしょう。
また，引き継いだ場合でも「はめられた」「勝手に前任者が約束した事だから，自分の責任ではない」といった揉めごとになるときがあり，途中段階でプロジェクト担当者を交代していくのは，なかなか難しいものです。
しかし，複数のお客様を担当していると，この案件は受注が取れたら他のエンジニアに任せたいといった場面もしばしば発生します。
今回は，システムエンジニアの分業化について考えてみたいと思います。
プレーイングマネージャの限界
数年前の筆者は，プロジェクトが始まると，提案からシステム構築までのほぼすべての取りまとめを担当していました（当時，筆者はシステムマネージャになったばかりで，自分ですべてをやろうとする傾向がありました）。また，マネージャとしては失格なのですが，限界レベルで忙しく動き回っている自分が好きでもあり，忙しくないと不安にさえ思うこともありました。
そんな忙しくバタバタと動き回っている中，筆者が担当しているお客様より，大規模なシステム導入に関するお話を頂きました。規模が大きく，システム構築期間は，最低でも1～2年が想定され，プロジェクトに専念しないと対応できそうもない内容でした。
プロジェクトを人に任せる決断
この受注をとれば，仕事量は確保できますが，他の仕事は手薄になる事は明白です。注文は頂きたいけど，筆者が専任で張り付くわけにはいかない。新米マネージャの筆者が，最初にぶつかった壁（ジレンマ）でした。早速，筆者は上位上長や他のマネージャに相談し，次のような話をしました。
- 受注決定までは，お客様の現状に精通している筆者が中心となって行う。
- 受注後，プロジェクトが開始したら，プロジェクトマネージャを筆者以外に設定する。
自分が提案したシステムを他の人に任せるのは心苦しく思いました（※2）が，システム構築は他のエンジニアに任せることにしたのです。「提案活動も他の人に任せたらいいんじゃないの？」と思われた方もいるでしょうが，時間的な余裕がありませんでした。
プレゼンテーションでのやりとり
プレゼンテーションは，1時間で提案内容を説明した後，1時間で質疑応答を行う形式でした。最初の1時間で提案内容を十分に説明ができた実感を持った筆者は，質疑応答についても自信を持って答えていきました。
例えば，「提案範囲にこの機能は入っているの？」という質問に対して，「それは今回の提案範囲外となりますが，後で拡張できるように考えています」といった具合です。大きな手ごたえを感じたまま，プレゼンテーションも終わりの雰囲気になったころ，これまで黙って聞いていたお客様の管掌役員から，「提案よりも数ヶ月以上早くシステムを稼動したいが可能ですか？」と質問がありました（※3）。筆者は納期には若干の余裕があると判断していたため，その場で「はい，かしこまりました。納期は（ご要望に沿えるように）前向きに検討します。」と答えました。「是非宜しく頼みますね」と管掌役員からも依頼され，プレゼンテーションは無事に終了しました。
継投（引継ぎ）の失敗
社内に戻り，早速，プロジェクトマネージャになる方と納期短縮について話しをしました。今思えば，筆者は楽天的な部分がありますが，プロジェクトマネージャは筆者より悲観的な方でした。納期を短縮したいという筆者の依頼に対しても，「当初の提案通りでないと受けられない」とどうしても譲りません。期待を持たせるような発言をしている筆者は，内心「困った事になった」と思いました。任せられたプロジェクトマネージャから見た「任せられるからにはプロジェクト計画に口出しをしないで欲しい」という相手の気持ちと，「そこまで言うなら，貴方が担当してください」と言われる恐怖から，これ以上は説得できなかったのです。
関係者を巻き込む重要性
このプロジェクトでは，関係者の巻き込み方を失敗したのは明らかです。また，プレゼンテーターとプロジェクトマネージャが異なったため，「お客様と会話する（約束する）人」と「プロジェクトを実行する人」が別々なのも問題を大きくしました。このようなケースは多くあります。「残業してでも，納期に間に合わして欲しい」という上司と，「急に言われても無理なものは無理」と思う部下の関係は典型的な例でしょう。「このぐらいは，やってくれる（やって欲しい）」は，相手には伝わらないものです。
幸いなことに，本事例では，お客様先で納期の打合せをプロジェクトマネージャと一緒に行った結果，あれ程かたくなだったプロジェクトマネージャが歩み寄ってくれましたが，いつも上手くいくとは限らないでしょう。一方，あまりにも巻き込み過ぎると，お客様から見て滑稽に見えてしまいます（※4）。
人に任せるという行為は，ラストマンとしての自覚と反すると思われるかも知れませんが，そうではありません。エンジニアは，プロジェクトの場面に応じて，必要最低限の関係者を上手く巻き込む戦略を持つことが必要だと思います。意識的に関係者を上手く巻き込めたとき，プロジェクトは成功に大きく前進するでしょう。関係者の性格と状況に合わせた巻き込み方を研究することをお勧めします。
