SIerのPMが、ITコンサルに移って最初に戸惑うこと

SIerでPMを務めてきた人が、ITコンサルの仕事に移る。この流れは珍しくありません。大きな開発プロジェクトを回してきた経験は、上流の仕事でも頼りにされます。実際、要件定義やベンダー選定の場面では、開発の現場を知っている人の意見が重く受け止められます。

それでも、移って最初の数か月は、多くの人が戸惑います。会議で何を発言すればよいのか分からない。資料を作っても「それで、どうしたいんですか」と聞き返される。自分の仕事が何で評価されているのか、手応えがつかめない。能力の問題ではなく、仕事の立ち位置が変わったことによる戸惑いです。

この記事では、SIerのPMがITコンサルに移ったときに戸惑いやすい点を順に挙げ、それぞれでSIerの経験がどう生きるのかを考えます。転職を考えている人にも、すでに移って間もない人にも、立ち位置の違いを言葉にする手がかりになればと思います。

「作る側」から「決める側の隣」へ

SIerのPMは、決まったものを作る責任を負う立場です。要件定義書という形で発注者が決めたことを受け取り、それを予算と期間の中で形にする。品質、コスト、納期を守ることが、仕事の中心にあります。

ITコンサルの立ち位置は、ここが変わります。発注者がまだ決めていないことを、決められるように支える。何を作るか、そもそも作るべきかを考える段階に、発注者の側に立って関わります。決めるのは発注者で、コンサルはその隣にいます。

この違いは、会議の場面ではっきり表れます。SIerのPMとして出る会議では、「この仕様でいつまでに作れるか」「この変更でどれだけ影響が出るか」を答えることが求められます。答えには根拠があり、正しいか間違っているかがはっきりしています。

コンサルとして出る会議では、「この業務を変えるべきか」「どちらの方針がよいか」を一緒に考えることが求められます。発注者自身も答えを持っていないことが多い。そこで、議論を前に進めるための材料や問いを出すことが、コンサルの役割になります。

最初の戸惑いは、多くの場合ここから来ます。答えを出すことに慣れている人ほど、答えの出ない会議で何を言えばよいか迷います。まずは、自分の立ち位置が変わったことを、はっきり意識するところから始まります。

立ち位置が変わると、守るものも変わります。SIerのPMは、自社の利益と、契約で約束した範囲を守る立場でもありました。仕様変更の相談が来れば、まず影響と追加の費用を考えるのが仕事でした。コンサルとして発注者の側に立つと、守るべきは発注者の目的です。ベンダーから追加費用の話が来たときに、それが発注者にとって妥当かどうかを一緒に考える側に回ります。かつての自分と向かい合う場面もあり、最初は落ち着かないかもしれません。

成果物ではなく、意思決定の材料を出す

SIerでは、仕事の成果は目に見えます。設計書、ソースコード、テストの結果、稼働したシステム。どれも、できたかできていないかで評価できます。

コンサルの仕事でも資料は作りますが、資料そのものは成果ではありません。成果は、その資料をもとに発注者が判断できたかどうかです。どれだけ丁寧に作った資料でも、読んだ部長が「で、どうすればいいの」と思えば、役目を果たしていないことになります。

たとえば、新しいシステムの方式を検討する場面を考えます。SIerのPMの感覚だと、各方式の特徴、費用、期間を正確に並べた比較資料を作りがちです。抜けのない、よくできた資料です。ところが発注者からは「全部分かったけど、結局どれがいいの」と返ってくる。

コンサルに求められているのは、比較の先です。発注者の目的に照らすと、どの方式がよいと考えるか。その判断を左右する前提は何か。前提が変わったら結論はどう変わるか。ここまで書いて、ようやく意思決定の材料になります。

気をつけたいのは、判断を押しつけないことです。推奨を示すことと、決めてしまうことは違います。「私たちはこう考えます。ただし、この前提が違えば、こちらの方式も十分に考えられます」と、決める余地を発注者に残す。そのさじ加減が、慣れるまで難しいところです。

資料の作り方も変わります。SIerの設計書は、抜けなく、正確に、すべてを書くことが求められました。読む人は開発者で、書かれていないことは作られないからです。意思決定のための資料は、読む人が忙しい管理職や役員であることが多く、最初の一枚で結論と理由が分かることが求められます。詳細は後ろに回し、判断に必要なことだけを前に出す。網羅することに慣れた人ほど、削ることに抵抗を感じますが、ここは意識して変えたいところです。

正解のない論点に、案を持って行く

上流の仕事では、正解のない論点を扱うことが日常です。業務をどこまで標準化するか。どの部署の要望を優先するか。今回の範囲に何を入れ、何を次に回すか。どれも、技術的に正しい答えはありません。

SIerのPMの経験が長い人ほど、こうした論点に「確定してから動きたい」と感じます。開発の現場では、前提が揺れると手戻りが起きるので、決まってから動くのが正しい姿勢でした。しかし上流では、決まるのを待っていると何も進みません。

そこで必要になるのが、仮の案を持って行くことです。「まだ決まっていませんが、たたき台としてこう考えてみました」と、具体的な案を出す。案があると、人はそれに対して意見を言いやすくなります。「ここは違う」「この部分はいい」と反応が返ってくれば、論点が絞られていきます。

たたき台を出すときは、次の三つを添えると議論が進みやすくなります。

• この案で何を決めたいのか。会議のゴール
• 案の前提として置いた仮定
• 意見がほしい点と、すでに固めてよいと考えている点

案は外れてもかまいません。外れた案から、発注者の本当の考えが見えることもあります。大事なのは、空白の議論を具体的な議論に変えることです。SIerで、曖昧な要求を具体的な仕様に落としてきた経験は、ここでそのまま生きます。

発注者の社内調整が、仕事の真ん中にある

SIerのPMにとって、発注者の社内事情は、見えるけれど手を出さないものでした。情シスと業務部門の意見が食い違っていても、それは発注者が整理すべきことで、整理された結果を受け取る立場でした。

コンサルとして発注者の側に立つと、この社内調整が仕事の真ん中に来ます。業務部門が何を望み、情シスが何を懸念し、経営層が何を気にしているのか。それぞれの立場を理解したうえで、合意に向けて話を組み立てることが求められます。

たとえば、ある業務部門の部長が新しい仕組みに消極的だとします。SIerの立場なら、その部長を説得するのは発注者の仕事です。コンサルの立場では、部長がなぜ消極的なのかを聞きに行き、懸念を論点として整理し、どうすれば受け入れられるかを発注者の担当者と一緒に考えます。

ここで気をつけたいのは、外部の人間であることを忘れないことです。社内の力関係に深く入り込みすぎると、どちらかの部署の味方だと見られてしまいます。コンサルの価値は、どの部署からも一歩引いた場所で、論点を公平に整理できることにあります。

この調整の仕事は、成果が見えにくいものです。会議の前に関係者と話をして、論点をそろえておく。その結果、会議が短く終わる。うまくいったときほど、何もなかったように見えます。慣れないうちは手応えのなさに戸惑いますが、上流の仕事の価値の多くは、ここにあります。

提案は「言われる前に、小さく」

SIerでは、提案は営業の仕事として、決まった時期に、決まった形で行うものでした。提案書を作り、見積を添え、受注を目指す。PMはその一部を担うことはあっても、日々の仕事の中で提案することは多くありません。

コンサルの現場では、提案は日常の中にあります。会議の進め方、論点の整理の仕方、次に検討すべきこと。発注者が言い出す前に、「次はこれを決めておくと、後が楽になります」と小さく提案することが、信頼につながります。

たとえば、定例会議で毎回同じ議論が繰り返されている場面です。言われた資料を作るだけなら、それで仕事はしています。しかし、「決定事項を一覧にして、毎回冒頭で確認しませんか」と一言添えれば、会議の質が変わります。こうした小さな提案の積み重ねが、「この人に相談すれば前に進む」という評価になります。

大きな提案を、根回しなしにいきなり会議で出すのは避けます。まず担当者に個別に話し、反応を見てから会議にかける。提案する側にとっても、断られたときの傷が小さくてすみます。

提案の中身にも違いがあります。SIerの提案は、自社が何を作れるか、どう作るかを示すものでした。コンサルの日々の提案は、発注者が何を決めればよいか、どう決めればよいかを示すものです。主語が自分たちから発注者に移ります。「私たちがこれを作ります」ではなく、「次の会議でこれを決めておくと、ベンダーへの依頼が一か月早く出せます」。発注者にとっての得が具体的に見えるように伝えます。

SIerで身につけたことは、そのまま武器になる

ここまで戸惑う点を挙げてきましたが、SIerのPMの経験は、上流の仕事で大きな武器になります。戸惑いは立ち位置の違いから来るもので、経験そのものが役に立たないわけではありません。

まず、実現できるかどうかの勘です。上流の議論は、ときに現実離れした方向に進みます。そのときに、「その要件だと、テストの工数がかなり膨らみます」「既存システムとのつなぎこみで、ここが詰まりやすいです」と、開発の現場から見た指摘ができる。これは、開発を経験していないコンサルには難しいことです。

次に、ベンダーの立場が分かることです。発注者の側に立ってベンダーと向き合うとき、ベンダーが何に困り、どこで無理をしているのかが分かります。見積の背景を読み、無理な要求を避けることで、プロジェクト全体がうまく回ります。

そして、計画と管理の力です。上流の仕事も、最終的には期限のあるプロジェクトです。論点をいつまでに決めるか、誰に何を確認するか、どこで遅れが出そうか。SIerで鍛えた計画と進捗の管理は、上流の仕事の土台になります。

トラブルに向き合ってきた経験も生きます。大きな開発プロジェクトで、障害対応や遅延の立て直しを経験した人は、悪い知らせをどう伝えるか、関係者をどう落ち着かせるかを知っています。上流のプロジェクトでも、想定外のことは起きます。キーパーソンの異動、予算の見直し、経営方針の変更。そうしたときに慌てず、いま決めるべきことを整理できる人は、発注者から頼りにされます。

最初の3か月で意識したいこと

立ち位置の変化に慣れるには、ある程度の時間がかかります。最初から完璧を目指すより、意識する点を絞って、少しずつ慣れていくほうが確かです。

一つだけ挙げるとすれば、資料を作るたびに「この資料を読んだ人は、何を決められるか」を一行で書いてから作り始めることです。比較資料なら「どの方式で進めるかを決める」、論点の整理なら「次の会議で話す三つの論点を決める」。この一行があると、資料の構成も、会議での話し方も変わってきます。

もう一つ、最初のうちは、SIerでの経験を前に出しすぎないことも意識したいところです。「前の現場ではこうしていました」という話は、役に立つ場面もありますが、続くと発注者には自分たちの事情を聞いてもらえていないように映ります。まずは発注者の状況を聞き、そのうえで経験を材料として差し出す。この順番を守るだけで、受け止められ方はずいぶん変わります。

次に資料を作るときは、表紙の裏に、その一行を書くところから始めてみてください。