コボラーからITコンサルタントへ(10) 転勤５回目：再びIT業界＆PMへ
エンジニアライフをご覧の皆さま、こんにちは！
本業はITコンサルタント、副業は産業カウンセラー。
TKT48プロデューサー＆SE女子部部長の奥田美和です。
やる気はある。でも、やってもらったらすぐに「できません」と辞められてしまった。
求職者にとっても企業にとっても不運なミスマッチ。マッチングの段階で実技テストが必要なのだろうと、過去の自分を振り返りつつ、最適な方法を探している最中です。
さて、前回の「コボラーからITコンサルタントへ(９) 転勤５回目：IT業界からWeb業界へ」の続きです。
■今度はRuby！のはずが、iPad＆Google Apps＆Google Maps！
１回目の東京転勤の時にお世話になった、派遣先の上司。
２回目の東京転勤でも、起業した上司の会社に、またお世話になることになりました。
上司たちが創業した会社は、当時最先端の国産プログラミング言語「Ruby」での開発を専門にしているIT企業です。
Rubyで業務システムやWebサイトを作っているとのこと。
また業務システムの設計からやれて、最新技術も勉強できるのだから、素晴らしい環境！
そう思っていたら、案件開始のタイミングにより、自社開発の案件ではなく特定派遣で外に出ることになりました。
こちらはこちらで、当時日本で流行し始めた、iPadとGoogle Appsの案件。
社長が、某大企業の経営層のご友人の影響で、iPadを1000台購入したそう。
「営業職員に配布したけれど、メールとインターネットしか活用できていないので、何か営業支援アプリを考えて」
面談の時に、ずいぶんと大まかな指令を出されました。
大学SEの時（「コボラーからITコンサルタントへ(８)」参照）も似たような状況だったので、何とかします、と答えたら採用になりました。
派遣されたのは、親会社の情報システム部が、独立子会社化して半年のIT企業。
生保時代と同様の、久しぶりのユーザー系システム子会社。
親会社から出向してきた派遣先の上司に、業務について色々と教えてもらいました。新しい業界の勉強は楽しい！
それから、iPad、Google Apps、Google Maps、各種SFA（営業支援システム）、イントラマートをはじめとした各種グループウェアの情報収集・検討。
人手不足だから、非正規社員では…協力会社社員の立場ではなかなかやらせてもらえないことまで、超上流工程をあれこれ経験させてもらいました。
ここに来て初めて、企画書と見積書の作り方も教えてもらいました。
旧情報システム部の正社員の方々も今まではメーカーにお任せしていたそうで、みんなで頑張って企画書を作りました。
客先へのプレゼンも初めてなのに、最初から親会社の経営層へプレゼンするという機会を与えてもらえました。PCインストラクターや職員研修を経験していたので、プレゼンは天職だと気が付きました。
――人は、こんなにも、向き不向きがあるんだ。
そう、気が付いた瞬間でした。
■再びPM（プロジェクトマネージャー）に
iPadからでも使えるように、イントラマートとGoogle Mapsで、既存の営業支援システムを作り直すことに決まりました。イントラマートもちょうど最新版にバージョンアップする（それも既存のものとはかなり仕様変更する）ということで、イントラマートの開発に詳しいベンダーを選定しました。
私が４次請けベンダーで働いていた頃（「コボラーからITコンサルタントへ(５)」参照）、「元請けと４次請けの違い。それは、全体像が見えないこと」ということに気が付きました。
生保時代に学んだ「プロパーもベンダーもなく、チームは１つ！」の精神で、キックオフの段階からメンバー全員に顧客向けプレゼン資料を共有（さすがに金額部分は隠しましたが）。顧客へのデモの時は、ベンダーのプログラマーさんも同行してもらい、自分の言葉で自分が作ったシステムの説明をしてもらいました。
私たちにとってもプログラマーさんにとっても、イントラマート最新版もGoogle Maps APIも初体験だったから、プログラマーさんは日々残業して最初のプロトタイプ（土台）を作ってくれました。
PMである私にできることは、
後で仕様変更が出ないように、要件定義の段階でしっかりヒアリングすること。
一字一句、しっかりと議事録に残しておくこと。
顧客に納得してもらえ、できる限り早く社内決裁が下りるような企画書を作ること。
そして、なるべく高値で受注し、高値でベンダーに発注してあげること。
――今までの転職で学んできたことを、全部やってみる。
――PMの立場である私がやれることを、全部やってみる。
■IT業界の長時間労働を無くす！
１．「大切なのはヒアリング」
顧客と直接やり取りする元請けのITコンサルタントやPMが、顧客の話を「カウンセラー並の傾聴モード」で聴き、最初の段階で顧客の潜在ニーズまで引き出す。顧客が１年後に言い出しそうなことを先に提案しておく。
２．「百聞は一見にしかず」
ITコンサルタントやPMが、「こういう結果が欲しいなら、こんな画面が良さそうで、それを作るのに実際にプログラミングするとこんな機能が必要そうだ」と、RFP（ベンダー（IT企業）への提案依頼書）を作る前に基本設計書もどきを作る。顧客も、口で説明されるより絵や一覧を見た方が納得しやすいし、ベンダーも正確な見積りを出しやすい。
３．「議事録はしっかり」
後々顧客が言い出しそうなことを、プロジェクトスタート前に全て確認しておく。後で何か言ってきたら「○月○日の議事録に、○○部長はこの機能は不要と仰ったとの記載がございますので、今回の工程には含まれておりません。次回工程で別途見積り出させて頂きますね」と笑顔でにこやかに言うと、大抵は次回工程に回せる。これで急な仕様変更による無駄な残業は防げる。
私が残業したのは本稼働前１週間だけだったので、後はエンジニアのスキル次第です。
４． ｢受け入れテストで、詳細テストを｣
ベンダーは、スケジュールぎりぎりだと、テストで手を抜く。本稼働してからエラーが見つかり修正するはめになると、元請け側もベンダー側も全てサービス残業になる（顧客から追加予算は出ない）。だから、「ITに詳しくないシニア社員」になりきって滅茶苦茶な操作を行ってみる。いつも100個くらいエラーを見つけ「もらったテスト結果ではエラー無し、となってたけど、エラー見つけちゃったよ♪」と笑顔でにこやかに言う。
ここまでPMがやっていれば、スケジュール通りに本稼働できるのだ、と実感しました。
■そして、ITコンサルタントへ
１次開発が終わり、２次開発も終わるところで、プロジェクトは正社員の担当へ。
私は派遣先を去ることになりました。
同時に、そろそろ夫の転勤辞令が出そうなので、今度は転職せずに、ITコンサルタントとして起業することにしました。
個人事業主として起業する自体は難しいことではありません。
税務署に行って開業届を提出し、HPや名刺を作り、後は営業するだけです。
しかし、とんでもない事態が待ち受けていたのです。
――まさか、NHK「あさイチ」のスタジオ出演するはめになるとは。
次回、「コボラーからITコンサルタントへ(11) 転勤６回目：PMからプロデューサーへ」に続きます。
次回もお楽しみに！
■本日のまとめ：超上流工程（業務分析～要件定義・基本設計）を経験するには
１．アメリカの心理学者・クルンボルツが「計画された偶然（プランド・ハプンスタンス）」理論を唱えています。偶然が積み重なってチャンスがやってくる、と。ご縁があれば、超上流工程も経験できます。