上流に移っても技術は手放さない。開発経験の生かし方と保ち方

SIerやSESで設計・開発を長くやってきた人が、要件定義や構想の仕事に移ろうとするとき、よく口にする迷いがあります。「上流に行ったら、技術がわからなくなるのではないか」というものです。手を動かす時間が減ります。コードや設定画面から離れます。数年たつと、若いエンジニアの話についていけなくなるかもしれない。そう考えて、一歩を踏み出せずにいる人もいます。

この記事は、そうした迷いを持つ人に向けて書きます。上流の仕事で、技術の経験はどこで効くのか。どこまで踏み込み、どこで止まるのか。日々の仕事で手を動かさなくなっても、技術の勘をどう保つのか。現場の場面に沿って整理します。

先に考えを書いておきます。技術の経験は、上流に移るときに捨てるものではありません。使う場所と使い方が変わるだけです。

技術から離れる不安は、半分だけ当たっている

まず、不安のうち当たっている部分から見ます。上流に移ると、手を動かす時間は確かに減ります。新しいフレームワークの細かい書き方や、ツールのバージョンごとの違いは追いきれなくなります。ここは受け入れたほうが楽です。細部まで自分で書ける状態を保とうとすると、上流の仕事との両立がむずかしくなります。

一方で、外れている部分もあります。上流で求められるのは、細部を書ける力ではありません。話を聞いたときに「それは重い」「それは後で困る」と気づける力です。この感覚は、手を動かした経験の中で育ったものです。数年で消えるものではありません。

たとえば、業務担当者が会議で「月末に全件を集計して、翌朝には画面で見られるようにしたい」と言った場面です。開発の経験がある人は、すぐにいくつかのことが頭に浮かびます。対象の件数はどのくらいか。夜間の処理時間に収まるか。ほかのバッチと時間帯がぶつからないか。集計の途中で失敗したら、朝の画面はどうなるか。経験がない人は、この一言をそのまま要件として書いてしまうことがあります。

気をつけたいのは、「技術がわかる」ことに安心しすぎないことです。古い前提のまま判断すると、かえって議論を誤った方向に進めます。たとえば、以前の現場では自前で組むしかなかった仕組みが、いまは標準の機能やサービスで済むこともあります。勘を保つやり方は、後の見出しで書きます。

上流で技術の経験が効くのは「決める前」の場面

上流の仕事の中心は、発注者に決めてもらうための材料をそろえることです。技術の経験は、決める前の段階で特によく効きます。決まってから気づいても、手戻りになるだけだからです。

現場でよくあるのは、次のような場面です。

• 業務側の要望を聞きながら、実現の重さをおおまかに当たりをつける場面
• ベンダーの見積や提案を読み、前提の置き方に違和感を持つ場面
• 性能・可用性・運用など、業務側からは出てこない要件に気づく場面
• 既存システムとのつなぎやデータの持ち方で、後から困りそうな点を先に挙げる場面

たとえば、ベンダーの提案資料に「既存の仕組みを流用し、開発量を抑える」と一行だけ書かれていたとします。開発の経験がある人なら、流用できる範囲をどう確かめたのか、流用元の改修履歴や品質はどうか、と聞けます。この問いが出るかどうかで、後の工程の見通しが変わります。

会議の中のひと言でも効きます。画面の要望を聞いているときに「この画面は、ほかの部署の方も同時に更新しますか」と確かめる。帳票の話なら「この帳票は、締めのあとに訂正が入ることはありますか」と聞く。どれも短い質問ですが、業務側は聞かれて初めて考えることが多いものです。

ここで気をつけたいのは、当たりはあくまで当たりだということです。会議の場で「それは無理です」と言い切ると、業務側は要望そのものを引っ込めてしまうことがあります。本当は別のやり方で実現できたかもしれません。「重くなりそうなので、ベンダーに実現方法と影響を確認します」と、確かめる行動につなげて止めるのが安全です。

深入りしすぎると、役割がずれる

技術がわかる人ほど陥りやすい落とし穴があります。上流の立場なのに、設計まで自分でやってしまうことです。ベンダーより先に方式を答える。テーブルの持ち方まで資料に書く。気づけば、ベンダーの仕事を肩代わりしている。そういう状態です。

一見すると親切で、プロジェクトが速く進むように見えます。しかし、あとで困ることがいくつか出てきます。ベンダーの責任の範囲があいまいになります。発注者は「あの人に聞けばいい」と考えるようになり、判断が一人に寄ります。そして、上流で本来やるべき論点の整理や合意づくりに手が回らなくなります。準委任で参画しているなら、自分が担う範囲は契約で決まっているはずです。その外に出ていないかも意識しておきたいところです。

たとえば、設計レビューの場で、ベンダーの方式に違和感を持ったとします。「自分ならこう作らない」と感じた場面です。このときに伝えるのは「こう作るべきです」ではありません。「この方式だと、データが増えたときに何が起きますか」「障害で処理が止まったら、どこから再開しますか」と、条件と結果を問う形にします。判断するのはベンダーと発注者です。自分は、判断に必要な問いを出す側に立ちます。

線を引く目安を一つ持っておくと迷いが減ります。上流の担当が見るのは、何を、どの条件で満たすかまでです。どう作るかはベンダーが考えます。ただし、作り方が要件・費用・スケジュールに大きく響くなら、それは論点として表に出します。黙って自分で直すのでも、黙って見送るのでもありません。

逆に、遠慮しすぎて気づいたことを言わないのも違います。上流に移ったばかりの人は、「もう技術の人ではないのだから」と口をつぐむことがあります。言うべきことは言う。ただし、判断は奪わない。この二つを両立させるのが、技術のわかる上流の担当の役目です。

技術の話を、業務の言葉に置き換える

上流では、技術の判断を業務側に説明し、決めてもらう場面がたくさんあります。ここで専門用語のまま話すと、相手は「よくわからないので、お任せします」と言います。任されたように見えて、実は何も決まっていません。後で問題が起きたとき、「聞いていなかった」となります。

たとえば「排他制御が必要です」と伝えても、業務側には何を決めればいいのかが伝わりません。言い換えるなら、こうなります。「お二人が同じ注文を同時に開いて直すと、後から保存した方の内容で上書きされます。そのとき、先に開いた方にお知らせするか、後の方の保存を止めるか、どちらにするか決めていただけますか」。これなら、業務の担当者が自分の仕事に引き寄せて考えられます。

置き換えるときは、次の順で組み立てると話がまとまりやすくなります。

1. 業務の中で、何が起きるか（画面や帳票で見える形で）
2. 誰が、いつ困るか
3. 選べる道と、それぞれで何を引き受けることになるか
4. いつまでに決めてほしいか

この順で話すと、相手は「自分が決めること」として受け取れます。会議で話すときも、メールで確認を取るときも同じ型が使えます。メールなら、件名に「ご判断のお願い」と入れ、本文の最初に決めてほしいことを一文で書くと、返事が早くなります。

気をつけたいのは、わかりやすくしすぎて制約を軽く見せないことです。費用や期間に響くものは、響くとはっきり書きます。「少し手間がかかります」ではなく、「この案を選ぶと、テストの範囲が広がり、期間に影響が出ます」と伝えます。やさしい言葉と、甘い言葉は別のものです。

現場を離れても、技術の勘を保つやり方

手を動かす時間が減っても、技術の勘は保てます。特別な勉強の時間をたくさん取らなくても、仕事の中でできることがあります。

1. ベンダーの成果物を、読む側としてていねいに読む。方式設計書、テスト計画、障害の報告。知らない言葉が出てきたら、そのままにしない。
2. 新しい領域は、細部より仕組みの前提をつかむ。クラウドやSaaSなら、何を自分たちで持ち、何を任せるのか。どこで料金や制約がかかるのか。
3. 小さく触ってみる。無料の範囲や個人の環境で、画面や設定を一度見ておく。触ったことがあるだけで、質問の具体さが変わる。
4. 若いエンジニアに聞くことをためらわない。会議のあとに「さっきの話、もう少し教えてください」と声をかける。

一つ目は、上流の担当だからこそできる学び方です。開発をしていたころは、自分の担当範囲の資料しか読まなかった人も多いはずです。上流に立つと、システム全体の資料に目を通す立場になります。全体を読む経験は、むしろ技術の見通しを広げてくれます。

四つ目は、少し勇気がいるかもしれません。年次が上の立場で「教えてください」と言うのは、慣れないうちは抵抗があります。ただ、知ったふりをして古い前提で話すほうが、信頼をずっと早く失います。素直に聞く人は、技術の人からも話しやすい相手として見てもらえます。

気をつけたいことが二つあります。一つは、全部を追おうとしないことです。担当している業界やプロジェクトで実際に出てくる技術に絞ります。もう一つは、客先の資料やデータを個人の環境に持ち込まないことです。小さく触ってみるのは、公開されている情報と自分で用意した題材だけにします。

職務経歴や面談で、技術の経験をどう語るか

上流の仕事を探すとき、技術の経験の書き方で読まれ方が変わります。使った言語やツールを一覧で並べると、開発の担当として読まれます。それ自体は悪いことではありません。ただ、上流の入口に立ちたいなら、技術の経験が判断にどう効いたかで書くほうが伝わります。

たとえば「方式設計を担当」と書くだけでは、何をした人なのかがぼんやりします。「要件の段階で夜間処理の時間に収まらないことに気づき、業務側と締め時間の見直しを調整した」と書けば、技術の知識を使って決める前に動いた人だとわかります。同じ経験でも、書き方で上流の経験として読んでもらえます。

面談で「技術から離れることに抵抗はありませんか」と聞かれることもあります。このときは、離れるのではなく使い方が変わる、と答えるのがよいでしょう。抽象的に言うより、先ほどのような具体的な場面を一つ添えます。聞き手は、その人が上流でどう動くかを想像しやすくなります。

気をつけたいのは、やっていないことを上流の経験として盛らないことです。要件定義の一部を担ったなら、一部と書きます。業務側との調整に同席しただけなら、同席したと書きます。参画してから「思っていた経験と違う」と見られるほうが、ずっと苦しくなります。正直に書いたうえで、何ができて何をこれから伸ばしたいかを示すほうが、長く続く仕事につながります。

次の一歩のために

最後に、読み終えたあとに一つだけやってみてほしいことがあります。直近のプロジェクトを一つ選び、技術の知識があったから決める前に気づけた場面を三つ書き出してみることです。会議でのひと言、資料に入れた一行、ベンダーへの一つの質問。小さなことで構いません。

書き出したものは、上流での強みの原形です。職務経歴を書き直すときの材料にもなります。もし一つも思い浮かばないなら、次の会議で試してみてください。業務側の要望を聞きながら、どこが重くなりそうかを心の中で当ててみる。その当たりを、会議のあとにベンダーへの質問として書いてみる。それだけで、上流の仕事の動き方に一歩近づきます。

技術を知っている上流の担当は、発注者からもベンダーからも頼られます。両方の言葉がわかる人は、どの現場でも多くありません。手を動かしてきた年月は、上流に移っても、形を変えて生き続けます。