上流工程にプログラミング経験は必要なのか

上流工程の話をしていると、よく議論になるテーマがあります。

それが「上流工程をやる人にプログラミング経験は必要なのか」という話です。

これについては、人によって意見が分かれると思います。上流工程は要件定義や設計、プロジェクトマネジメントが中心なので、「コードを書けなくてもできる」という意見もありますし、「いや、実装を知らないと厳しい」という意見もあります。

僕の意見としては、今プログラミング経験がないなら、独学でいいので多少は勉強して、軽く何かを作る経験はしておいた方がいいと思っています。

もちろん、すでに実務で開発経験があるならそれで十分です。ただ、まったく経験がない状態で上流工程をやるよりは、少しでも自分でコードを書いて、何かを実装した経験がある方が、かなり仕事がしやすくなると思います。

まず僕自身のプログラミング経験について

最初に、僕がどのくらいプログラミングをやっていたのかを書いておきます。

僕は上流工程の職につく前に、プログラミング経験はありました。ただし、エンジニアとしてがっつり開発していたわけではありません。

どちらかというと、独学で勉強していたレベルです。仕事で本格的にプロダクト開発をしていたというより、自分で調べながら手を動かしていた感じです。

ちなみに僕が独学していた時期は、今みたいに生成AIが当たり前にある時代ではありませんでした。なので、検索して、記事を読んで、コピペして、自分でも書いて、エラーが出たらまた調べて、というやり方で学んでいました。

具体的には、次のようなものを触っていました。

  • Railsのチュートリアルを一通りやる
  • JavaScript、TypeScriptを学ぶ
  • GASを書く
  • Pythonを少しだけ触る
  • Next.jsを少しだけ触る
  • SQLを仕事で使う

プログラミング言語ではないですが、SQLの経験もありました。これは仕事でちゃんと使っていました。

なので、僕自身は「バリバリのエンジニア出身です」とは言えません。ただ、自分でコードを書いて、動かして、エラーにぶつかって、直すという経験はありました。

その状態で上流工程の職についたわけですが、振り返ると、この経験はかなり役に立っていると思います。

僕の結論：独学レベルでもプログラミング経験はあった方がいい

僕の結論はシンプルです。

上流工程をやるなら、プログラミング経験は必須とまでは言わない。でも、ないなら独学でいいから多少はやっておいた方がいい。

この「多少」というのがポイントです。

上流工程の人が、全員エンジニアレベルでコードを書ける必要はないと思っています。複雑な設計パターンを理解しているとか、大規模なリファクタリングができるとか、そこまでは求めなくていいと思います。

ただ、自分で簡単なWebアプリを作ってみる。フォームを作る。DBに保存する。保存したデータを一覧で表示する。編集する。削除する。このくらいの経験があるだけでも、かなり見える世界が変わります。

個人的には、比較的少しの努力で、かなり大きなプラスが得られる領域だと考えています。

プログラミング経験が上流工程で役立つ理由

僕がプログラミング経験をおすすめする理由は、大きく3つあります。

  1. 実装で何が簡単で何が大変かをなんとなく把握できる
  2. 設計書を詳しく書けるようになる
  3. 最悪コードを読んで「これ違う」と言える

それぞれ詳しく書いていきます。

理由1：実装で何ができて、何が大変かを判断しやすくなる

上流工程では、お客さんから要望を聞く場面が多いです。

そのときに「これはできそう」「これはちょっと大変そう」「これはやるほどの効果があるのか微妙だな」といった感覚を持てるかどうかは、かなり大事です。

もちろん、最終的な見積もりや技術判断は開発者と相談すべきです。ただ、会話の場でざっくりと実装難易度を想像できるだけでも、かなり進め方が変わります。

たとえば、お客さんからある機能の相談を受けたとします。業務課題としては理解できるし、その機能があれば解決できそうに見える。でも実装を考えると、実はかなり大変そうだと感じることがあります。

そのときに、プログラミングや実装の感覚が少しでもあると、こう考えられます。

  • この機能は実装コストが高そう
  • そこまでして今すぐ解決する課題ではないかもしれない
  • まずは別の簡単な方法で運用回避できるかもしれない
  • 今回のスコープからは外して、次フェーズに回す判断もありそう

逆に、この感覚がないと、お客さんとの会話でつい「いいですね、できますよ」と言ってしまうことがあります。

でも、実際に開発に入ったタイミングで、開発側から「これ、めちゃくちゃ面倒です」「かなり工数かかります」と言われる。そこで初めて、思ったより大変だったと気づく。そうなると、かなりあわわとなります。

上流工程では、要望をそのまま受けるだけではなく、実装コストと業務価値のバランスを見ながら判断することが大事だと思っています。

複数の解決策から、実装しやすい案を選びやすくなる

もうひとつ大きいのが、複数の機能案があるときです。

同じ課題を解決するにしても、実現方法はいくつかあります。

観点

プログラミング経験がない場合

プログラミング経験がある場合

機能案の検討

業務的に良さそうかで判断しがち

業務価値と実装難易度の両方で判断しやすい

お客さんとの会話

実装面の懸念をその場で出しにくい

「この案の方が軽そうです」と話しやすい

開発への影響

後から工数が膨らむことがある

早い段階で現実的な案に寄せやすい

実装しやすい選択肢がわかっていると、お客さんとの会話中にも「たぶんこの方向が良さそうだな」と思いながら進められます。

これは上流工程をやるうえで、かなり実用的な強みになると思います。

理由2：設計書を詳しく書けるようになる

次に、設計書の話です。

設計書をどの粒度で書くかは、会社やプロジェクトによってかなり違うと思います。ざっくり書く現場もあれば、かなり細かく書く現場もあります。

僕の場合は、設計書をかなり細かく書く方です。

どのくらいかというと、AIに渡したらほぼ思った通りに実装されるくらい。あるいは、どのレベルの開発者が見ても、同じような動作になる実装ができるくらいを目指しています。

もちろん、完全にそこまでできているとは言いません。ただ、少なくともそのレベルを目指して書いています。

ここでプログラミング経験がかなり役に立ちます。

なぜなら、自分でコードを書いた経験があると、どこを書いておかないと実装者によって解釈が分かれるかがわかりやすくなるからです。

コーディング中に起こる解釈の余地を減らす

設計書が曖昧だと、実装者は自分なりに解釈して作ります。

それ自体は悪いことではありません。むしろ、設計書に書いていないことを補いながら実装してくれる開発者はありがたい存在です。

ただ、上流工程の立場からすると、意図していない動作になるのは困ります。

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

  • 入力値が空だったときにどうするか
  • エラー時にどんなメッセージを出すか
  • 検索条件を未指定にしたときに全件表示するのか、検索させないのか
  • 更新時に確認ダイアログを出すのか
  • 削除済みデータを一覧に出すのか
  • 権限がないユーザーにはボタンを非表示にするのか、押せない状態にするのか

こういう細かいところは、設計書に書いていないと人によって解釈が変わります。

実装経験があると、「ここは何も書かないとたぶん人によって動作が変わるな」と気づきやすくなります。

僕の感覚としては、設計書を書くというより、コーディングの中で起こりそうな解釈の余地を先回りして潰していく感じです。

もちろん、完全になくせているわけではありません。でも、減らすことはできます。

そして、自分が思っているものが出来上がってこないなら、設計の意味はかなり薄くなってしまいます。だからこそ、設計の段階で具体的に書くことは大事だと思っています。

理由3：最悪コードを読んで「これ違う」と言える

3つ目は、実装後のレビューやテストの話です。

基本的には、上流工程の人がコードを細かくレビューする必要はないと思います。まず見るべきなのは、画面を触って設計通りに動いているかどうかです。

ただ、実際にレビューやテストをしていると、こういう場面があります。

  • なんでこの動きになっているのかわからない
  • 設計書ではこう書いたのに、画面の動きが違う
  • どういう実装をしているのか気になる
  • 開発者にどう指摘すればいいのか迷う

このとき、開発者に「ここ、設計書通りじゃないっぽいです」と伝えて調査してもらうのが、プロセスとしては正しいのかもしれません。

ただ、個人的には、そのやり取りが無駄に感じることがあります。

なので僕は、必要であれば自分でコードを見ます。

コードを見ると、そこには基本的にすべてが書かれています。もちろん、ネットワークの問題やDB側の問題など、コードだけでは判断できないこともあります。ただ、画面の動きや処理の分岐がおかしい場合は、コードを見れば「あ、これ違うじゃん」とわかることが多いです。

そして、違っている箇所がわかれば、GitHubの該当コードの行リンクをつけて具体的に指摘できます。

これはかなり大きいです。

曖昧に「なんか違います」と言うより、この行のこの条件分岐が設計書と違いますと言えた方が、確実に直りやすいです。

開発者側も調査の手間が減りますし、認識ズレも起きにくくなります。個人的には、これもプログラミング経験があることのかなり大きなメリットだと思っています。

上流工程の人はどこまでプログラミングを学べばいいのか

では、上流工程の人はどこまでプログラミングを学べばいいのでしょうか。

僕は、エンジニアとして即戦力になるレベルまでやる必要はないと思っています。

まずは、基本の書き方を学んで、超簡単なものでいいので、DBを使うWebアプリっぽいものを作っておくと良いと思います。

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

  • ユーザー登録ができる
  • ログインできる
  • データを登録できる
  • 登録したデータを一覧表示できる
  • 詳細画面を見られる
  • 編集できる
  • 削除できる
  • 検索できる

これだけでも、Webアプリの基本的な流れがかなり見えてきます。

画面、入力、バリデーション、API、DB、一覧表示、更新、削除。このあたりを一度でも自分で触っておくと、設計書を書くときの解像度が上がります。

言語は正直なんでもいいと思います。

ただ、無難にいくならTypeScriptが良いんじゃないかなと思っています。Next.jsで何か作ると、画面側とサーバー側、DB連携の雰囲気をまとめて掴みやすいです。

大事なのは、DBも使うものを作ることです。

画面だけ作るのも勉強にはなりますが、上流工程で特に役立つのは、データがどう保存されて、どう取得されて、どう画面に出てくるのかを理解することだと思います。

余談：SQLもやっておいた方がいい

最後に少し余談ですが、SQLもやっておいた方がいいと思っています。

DBの基本知識は、上流工程ではかなり大事です。特に業務システムだと、基本的にはRDB、つまりリレーショナルデータベースを使うことが多いと思います。

画面にデータを表示するとき、裏側では基本的にSQLが動いています。もちろん、実装ではORMを使うことも多いです。直接SQLを書かないケースもあります。

それでも、裏側でどんなクエリが動いているのか、それぞれの句がどんな意味を持っているのか、データがどんなふうに取得されるのかを知っておくと、かなりイメージしやすくなります。

たとえば、設計書を書いているときに「この画面ではこのテーブルとこのテーブルを紐づけて、この条件で絞り込んで、この順番で表示するんだな」と想像できるようになります。

この想像ができると、画面設計や機能設計の書き方が変わります。

SQLについては、最初は全部を深くやる必要はないと思います。

  • SELECT
  • WHERE
  • ORDER BY
  • GROUP BY
  • JOIN

とりあえず、このあたりまでで良いと思います。特にJOINくらいまでわかっていると、データ取得時のイメージの解像度はかなり上がります。

個人的には、上流工程の人ほどSQLの基礎は知っておいた方がいいと考えています。

プログラミング経験は、上流工程の判断力を上げてくれる

上流工程の人がプログラミングを学ぶ目的は、開発者になることではないと思います。

目的は、実装の感覚を持つことです。

お客さんの要望を聞いたときに、どれが現実的なのかを判断する。設計書を書くときに、実装者の解釈が分かれそうなところを潰す。実装後に動作が違ったとき、必要であればコードを見て具体的に指摘する。

こういう場面で、少しでもプログラミング経験があるとかなり役に立ちます。

もちろん、プログラミング経験がないと上流工程ができないとは思いません。業務理解、調整力、言語化力、資料作成力、合意形成力など、上流工程に必要な力は他にもたくさんあります。

ただ、実装をまったく知らないまま進めるよりは、少しでもコードを書いたことがある方が、判断の精度は上がると思います。

だから僕は、これから上流工程に関わる人や、すでに上流工程をやっているけどプログラミング経験がない人には、独学でいいから一度やってみることをおすすめしたいです。

基本の書き方を学んで、DBを使う簡単なWebアプリを作る。言語に迷ったらTypeScriptとNext.jsあたりで始めてみる。SQLもJOINくらいまで触ってみる。

それだけでも、要件定義や設計の見え方はかなり変わると思います。

関連記事としては、要件定義の進め方や設計書の粒度についての記事でも近い話を書いていますが、結局のところ上流工程では、業務と実装のあいだをどれだけ具体的につなげられるかが大事だと思っています。