SESのリーダー経験は、ITコンサルでどう生きるか

SESの現場でリーダーを務めてきた人の中には、上流の仕事に関心を持つ人が少なくありません。客先に常駐し、数人から十数人のメンバーをまとめ、日々の進捗と課題を見ながら、顧客の担当者と調整する。そうした経験を積むうちに、「もっと前の段階から関わりたい」と思うようになるのは自然なことです。

一方で、「自分の経験はITコンサルで通用するのか」と迷う人も多いはずです。肩書きはリーダーでも、契約上は客先の指示のもとで作業する立場だった。要件定義の会議には出ていなかった。そう考えると、上流の仕事は遠く見えるかもしれません。

この記事では、SESのリーダーとして積んだ経験が、ITコンサルの仕事でどう生きるのかを整理します。そのうえで、足りないものは何か、それをどう身につけるかを考えます。経験を過大にも過小にも見ないための、一つの見取り図として読んでください。

SESのリーダーがしてきたことを、言葉にしてみる

まず、リーダーとして日々していたことを、具体的に言葉にしてみます。多くの人は、自分の仕事を「現場のとりまとめ」の一言で片づけがちです。しかし、その中身を分けてみると、上流の仕事と重なる部分が見えてきます。

たとえば、次のようなことです。

• メンバーの作業を割り振り、負荷の偏りを調整する
• 毎日の進捗を把握し、遅れの兆しを早めに見つける
• 課題を整理し、自分で解けるものと顧客に上げるものを分ける
• 顧客の担当者と、仕様の確認やスケジュールの調整をする
• 新しく入ったメンバーに、業務とシステムの全体像を伝える

ここに挙げたことは、どれもITコンサルやPMOの仕事の一部と重なります。違うのは、扱う範囲と、話す相手です。リーダーとしては自分のチームの範囲を見ていましたが、上流ではプロジェクト全体や、発注者の組織全体を見ることになります。

経験を言葉にすることは、転職や案件の面談のためだけではありません。自分の強みと足りないところを分けて考えるための、最初の作業です。

言葉にするときは、「何人のチームで、どんな工程を、どれくらいの期間担当したか」に加えて、「そのとき何を判断したか」を書き出すのがおすすめです。メンバーの一人が体調を崩したときに、誰の作業をどう組み替えたか。顧客から急な仕様変更を言われたときに、何を確認してから受けたか。判断の場面を思い出すと、自分が無意識にやっていたことが見えてきます。上流の仕事で問われるのは、作業の量よりも、こうした判断の質です。

現場をまとめる力は、PMOの土台になる

上流のプロジェクトでは、PMOという役割がよく置かれます。プロジェクトの進行を支え、会議を回し、課題を管理し、関係者の情報をそろえる役割です。SESのリーダーとして現場をまとめてきた経験は、この仕事の土台になります。

たとえば、定例会議の運営です。会議の前に議題をそろえ、必要な人に声をかけ、会議のあとに決まったことを共有する。リーダーとして毎週のチーム会議を回してきた人なら、この流れは体に入っています。上流では参加者の立場が上がり、会議の重さも増しますが、基本の動き方は同じです。

人の動きを見る力も生きます。誰が忙しすぎて手が回っていないか。誰が言いたいことを言えずにいるか。リーダーとして現場を見てきた人は、こうした変化に気づきやすいものです。上流のプロジェクトでも、発注者の担当者が抱えている負荷や、部署間の温度差に気づけることは大きな強みです。

気をつけたいのは、まとめる対象が変わることです。SESのリーダーとしてまとめていたのは、主に自分のチームのメンバーでした。PMOとしてまとめるのは、発注者の各部署、複数のベンダー、ときには経営層です。指示を出せる相手ではなく、お願いして動いてもらう相手になります。この違いに慣れるまでは、言い方や頼み方を意識して変える必要があります。

進捗と課題を見る目は、上流でも同じように使える

SESのリーダーは、日々の進捗と課題に向き合っています。どの作業が遅れているか、その原因は何か、どうすれば取り戻せるか。この目は、上流の仕事でもそのまま使えます。

上流の仕事でも、進捗の管理は欠かせません。要件定義には期限があり、決めるべき論点がいくつもあります。どの論点がいつまでに決まる予定で、いまどこまで進んでいるか。決まらない論点は何が原因で止まっているのか。これを把握し、手を打つのは、開発の進捗管理と同じ考え方です。

ただし、上流の課題は、開発の課題より形がはっきりしないことが多いです。開発では「この機能のテストが終わっていない」と言えますが、上流では「業務部門の合意が取れていない」「そもそも何を決めるべきかが共有されていない」といった課題になります。数字で測りにくく、誰の課題なのかも曖昧です。

ここで生きるのが、課題を分ける習慣です。SESのリーダーとして、自分で解ける課題と顧客に上げる課題を分けてきた人は、上流でも「誰が決めれば動く課題か」を考えられます。課題の持ち主をはっきりさせ、期限を置き、追いかける。この基本は、どの段階でも変わりません。

たとえば、課題一覧に「業務部門の合意が取れていない」とだけ書かれている場面です。このままでは誰も動けません。合意が取れていないのは、どの部署の、何についての合意なのか。誰がいつ、どんな場で確認すれば前に進むのか。ここまで分けて書き直すと、課題が動き始めます。SESの現場で、曖昧な障害報告を再現手順と担当に分けてきた人なら、同じ手つきで扱えるはずです。

顧客との調整は、相手が変わる

SESのリーダーは、顧客との調整にも慣れています。仕様の確認、スケジュールの相談、メンバーの増減の相談。顧客の担当者と日々やりとりをしてきた経験は、上流の仕事でも役に立ちます。

変わるのは、調整の相手と中身です。SESの現場で話す相手は、多くの場合、開発や運用の担当者や、そのチームのリーダーです。話の中身も、作業の進め方や技術的な判断が中心でした。

上流の仕事では、業務部門の担当者や管理職、ときには役員と話すことになります。話の中身も、業務をどう変えるか、予算をどう配分するか、どの部署の要望を優先するか、といったことになります。相手はシステムに詳しくないことも多く、技術の言葉は通じません。

たとえば、システムの制約で業務の一部を変えてもらう必要がある場面です。SESの現場なら「この仕様だと処理が重くなるので」と説明すれば通じたかもしれません。業務部門の部長には、「この画面の入力を一か所減らすと、月末の締め作業がこれだけ楽になります」のように、相手の業務の言葉で話す必要があります。

調整の経験があること自体は大きな強みです。ただ、相手の立場と言葉に合わせて話し方を変えることは、意識して練習しないと身につきません。

もう一つ変わるのは、調整の立ち位置です。SESのリーダーは、受託した側の代表として顧客と向き合っていました。上流の仕事では、発注者の側に立って、ベンダーや社内の各部署と調整することが増えます。かつての自分のような立場の人に依頼を出す側になるわけです。現場の苦労が分かるぶん、無理のない頼み方ができるのは強みです。一方で、発注者の目的を守るために、言いにくいことを伝えなければならない場面もあります。

論点を設計する力は、意識しないと育たない

ここからは、SESのリーダーの経験だけでは足りないものを考えます。一つ目は、論点を設計する力です。

SESの現場では、何を作るかは基本的に決まった状態で仕事が来ます。リーダーの仕事は、決まったことをどう進めるかを考えることでした。上流では、何を決めるべきかを考えるところから始まります。

論点を設計するとは、たとえば次のようなことです。この会議で何を決めるのか。その判断のために、どんな選択肢があるのか。選ぶための基準は何か。誰が決めるのか。これらを整理したうえで、会議や資料を組み立てます。

この力は、日々の仕事の中で意識しないと育ちません。身につけるための方法として、次のような練習があります。

1. 出席した会議のあとに、「この会議で本当に決めるべきだったことは何か」を一行で書く
2. 議論が長引いた会議について、どんな論点の立て方をすれば早く決まったかを考える
3. 顧客から相談を受けたとき、答える前に「何を決めたい相談か」を確かめる

SESのリーダーとして出ている会議でも、この練習はできます。顧客側の定例や、仕様を確認する打ち合わせは、論点の立て方を観察するよい教材です。議論がうまく進んだ会議と、同じ話を繰り返した会議では、最初の問いの置き方がどう違ったのか。自分が進行役でなくても、見ているだけで学べることは多くあります。最初は的外れでもかまいません。続けるうちに、会議の構造が見えるようになってきます。

合意を文書に残すことと、業務を知ること

足りないものの二つ目は、文書で合意を残すことです。SESの現場では、仕様の確認や作業の依頼が口頭やチャットですまされることも多いでしょう。上流の仕事では、決まったことを文書に残し、関係者が同じ理解に立っていることを確かめることが、仕事の中心になります。

議事録、課題一覧、決定事項の一覧。どれも地味な文書ですが、上流のプロジェクトでは、これらが後の工程の土台になります。何をいつ誰が決めたのかが残っていないと、後になって「そんな話は聞いていない」という争いが起きます。

身につけるには、まず自分のチームで小さく始めるのがよいでしょう。チームの会議のあとに、決まったことと次にやることを三行でまとめて共有する。顧客との打ち合わせのあとに、確認した内容をメールで送る。この習慣が、上流の仕事の基本動作になります。

文書に残すときは、読み手が後から読んでも分かるかを意識します。その場にいた人には通じる「例の件はA案で」という書き方も、一か月後に読み返すと何のことか分かりません。何を、どの選択肢から、なぜ選んだのか。誰が了承したのか。この四つが書かれていれば、後から参画した人にも経緯が伝わります。

三つ目は、業務の理解です。SESの現場では、システムの仕組みには詳しくなっても、そのシステムを使う業務まで深く知る機会は限られます。上流の仕事では、システムより先に業務を理解することが求められます。受注から出荷までの流れ、月末の締めの処理、部署ごとの役割。業務を知らないと、要件の良し悪しを判断できません。

業務を知るための近道は、いまの現場で、自分が触っているシステムの向こうにいる利用者の仕事を想像してみることです。この画面は誰が、いつ、何のために使うのか。この帳票は誰に渡り、何に使われるのか。機会があれば、利用者の作業を見せてもらう。小さな積み重ねが、業務の理解につながります。

明日からの現場で身につけるために

SESのリーダーとして積んだ経験は、上流の仕事で確かに生きます。現場をまとめる力、進捗と課題を見る目、顧客との調整の経験。これらは、ITコンサルやPMOの仕事の土台になります。足りないのは、論点を設計する力、文書で合意を残す習慣、業務の理解です。どれも、いまの現場で練習を始められるものです。

転職や案件の切り替えを待たずに、できることがあります。大きな変化を一度に起こそうとするより、毎日の仕事の中で、一つずつ習慣を変えていくほうが確かです。

まずは明日の会議のあとに、「この会議で決めるべきだったことは何か」を一行だけ書いてみてください。それを一か月続けると、会議の見え方が変わっているはずです。