上流工程はつまらないのか?僕は全体としては面白いと思っています
「上流工程はつまらない」と言われることがあります。
たしかに、その気持ちがまったく分からないわけではありません。実際、僕も上流工程の仕事をしていて「これはつまらないな」と思うタスクはあります。やりたくない作業もありますし、正直めんどうだなと思いながらやっていることもあります。
でも、全体として見ると、僕は上流工程を面白いと思ってやっています。つまらなくはないです。むしろ、けっこう楽しんでいます。
もちろん、これはかなり人によると思います。性格にもよりますし、何を面白いと感じるかにもよります。会社や案件によっても全然変わるはずです。
この記事では、僕が上流工程の中で個人的に面白いと思っている部分と、逆につまらないと思っている部分を紹介します。
これから上流工程に行きそうな人や、今まさに上流工程にいて「なんかつまらないな」と感じている人にとって、何かしらのヒントになればうれしいです。
前提:僕は中小企業向けの一次受け受託開発で上流工程をやっています
先に前提を書いておくと、僕は中小企業向けの受託開発で、一次受けの立場で上流工程をやっています。
要件定義をしたり、設計をしたり、プロジェクト全体を見ながらお客さんと話したりすることが多いです。
なので、この記事で書く「上流工程」は、あくまで僕がいる環境での話です。
たとえば、二次請けや三次請けの上流工程だと、お客さんとの距離感も違うと思います。大企業向けの大規模開発だと、役割分担ももっと細かいかもしれません。自社開発でもまた感覚は違うはずです。
なので、この記事は上流工程の一般論というより、一次受けの受託開発で上流工程をやっている僕の実感として読んでもらえるといいかなと思います。
僕が上流工程で特に面白いと思う部分
上流工程の中で、僕が特に面白いと思っている部分は大きく3つあります。
- まだ何もない状態からシステムを考えるものづくり感
- 要望や課題を聞いて、必要な機能を考えること
- 設計をロジカルに詰めていく感じ
ひとつずつ書いていきます。
まだ何もない状態からシステムを考えるものづくり感
上流工程の面白さとして、まず大きいのが「ものづくり感」だと思っています。
こう言うと、「ものづくり感って、コードを書いて実装しているときの方があるんじゃないの?」と思う人もいるかもしれません。
それはそれで分かります。実際にコードを書いて、画面が動いて、機能が形になるのはかなりものづくりっぽいです。
でも、個人的には上流工程にもかなり強いものづくり感があると思っています。
なぜなら、上流工程の段階って、まだ本当に何もないからです。
コードを書く段階では、すでに要件定義が終わっていたり、設計書があったりして、だいたいどんなシステムができるのか想像できる状態になっていることが多いです。
でも、上流工程はその前です。
まだシステムの形がありません。画面もありません。機能の整理もできていません。お客さんの頭の中にある困りごとや要望が、ふわっと存在しているだけだったりします。
その状態から、お客さんの話を聞いて、「じゃあこういうシステムにしたらいいんじゃないか」「こういうアプリにすれば課題が解決できるんじゃないか」と構想していきます。
僕はこの時間がかなり好きです。
まだ実物は作っていません。コードも書いていません。だから厳密には作成ではないかもしれません。
でも、何もないところから形を想像していく創造の感覚があります。
僕にとっては、ここが上流工程の大きな面白さです。
要望や課題を聞いて、必要な機能を考えるのが面白いです
次に面白いのが、お客さんの要望や課題を聞いて、それを叶えたり解決したりするために必要な機能を考えることです。
ちょっと誤解を招くかもしれませんが、僕の感覚としては謎解きに近いです。
お客さんが最初から完璧に整理された要件を話してくれることは、そんなに多くありません。
「こういうことがしたい」「ここが困っている」「今はこうやっているけど大変」「この作業を楽にしたい」みたいな話を聞きます。
その中には、要件のヒントが散らばっています。
そのヒントを自分の手で探りながら、「本当に必要なのは何か」「どういう機能があれば解決できるのか」「逆にこれは機能として作らなくてもいいんじゃないか」と考えていきます。
お客さんの話を聞いたその瞬間に答えが出るとは限りません。
むしろ、打ち合わせ中はなんとなく方向性だけ見えていて、打ち合わせが終わったあとに「どうしたらいいかな」と考えることも多いです。
そのあとで、「これだ」と思える形が見えたときがかなり気持ちいいです。
考えている過程も好きですが、バラバラだった話がひとつの機能や仕様としてつながった瞬間は、やっぱり楽しいです。
上流工程の面白さは、ただ言われたものを作ることではなく、相手の課題を自分なりに理解して、解決策の形に変換するところにあると思っています。
設計をロジカルに詰めていく感じが面白いです
もうひとつ面白いのが、設計をロジカルに詰めていく感じです。
ここで言っているのは、特に詳細設計のあたりです。
設計といっても、会社によってどこまで細かく書くかはかなり違うと思います。僕の会社では、かなり細かく書きます。
たとえば、次のようなことを設計書に書いていきます。
- どのテーブルからデータを取得するのか
- どの条件で絞り込むのか
- 取得したデータを画面のどこに表示するのか
- ボタンがクリックされたら何をするのか
- 処理が成功したらどう表示するのか
- エラーになったらどう制御するのか
個人的には、自然言語でコーディングしているような感覚に近いです。
もちろん実際にコードを書いているわけではありません。でも、処理の流れをかなり細かく言葉で組み立てていきます。
「これをやるためには、このデータが必要ですよね」
「このデータを取得するには、この条件が必要ですよね」
「でも、この画面の仕様を考えると、こっちの条件も必要ですよね」
「ここをクリックしたらこうなる。そうすると次はこういう表示になる」
こういうことを、ひとつずつ論理的に詰めていきます。
僕はこの作業がけっこう好きです。パズルみたいな感じがあります。
隙間があると、あとで実装者が困ります。仕様の抜けがあると、テストや本番で問題になります。だから、できるだけ矛盾なく、漏れなく、処理を書いていく必要があります。
このロジカルに隙間を埋めていく感じが、上流工程の中でもかなり面白い部分だと思っています。
僕が上流工程で特につまらないと思う部分
逆に、上流工程の中でつまらないと思う部分もあります。
ただ、書き出してみると、僕の場合はそこまで多くありませんでした。
一番大きいのは、設計レビューです。
設計レビューは正直つまらないです
僕の会社では、開発者が実装してくれた部分を、設計者が設計レビューします。
ここで言う設計レビューは、設計書のレビューというより、実装された画面や機能が設計通りに動いているかを確認する作業です。
実際に画面を触りながら、「設計通りに動くか」「想定した条件で正しく表示されるか」「処理が抜けていないか」を確認していきます。
普通に画面をポチポチ触るくらいなら、別にそこまで嫌ではありません。
でも、設計レビューでやる必要があるのは、考えられる全パターンのデータで正しく動作するかを見ることです。
これがめんどくさすぎます。
同じような操作を何回もします。条件を変えて確認します。データを変えて確認します。表示を見て、処理を見て、エラーケースも見ます。
しかも、ここで誤動作を見逃したら、本番で動かしたときにお客さんに迷惑がかかる可能性があります。
だから、適当に流すわけにはいきません。
つまらないけど、見落とせない。めんどうだけど、ちゃんとやらないといけない。
このプレッシャーもあります。
僕の性格として、一度作ったものや、作られたものを確認する作業があまり好きではないというのも大きいと思います。
何かを考えたり、構想したり、設計したりするのは好きです。でも、できあがったものをひたすら確認する作業は、かなり苦手です。
だから僕にとって、設計レビューは上流工程の中でかなりめんどうでつまらない部分です。
面白い部分とつまらない部分を整理するとこんな感じです
分類 | 内容 | 僕の感覚 |
|---|---|---|
面白い部分 | 何もない状態からシステムを構想する | ものづくり感があって楽しいです |
面白い部分 | 要望や課題から必要な機能を考える | 謎解きみたいで楽しいです |
面白い部分 | 詳細設計をロジカルに詰める | 自然言語でコーディングしている感じがあります |
つまらない部分 | 設計レビューで全パターンを確認する | めんどうですし、見落とせないプレッシャーがあります |
こうやって見ると、僕の場合は面白いと思う部分の方が多いです。
だから、上流工程全体としては楽しんでやれているんだと思います。
ただし、上流工程が面白いかどうかはかなり人によります
ここまで書いておいてなんですが、この記事はあまり参考にならない部分もあるかもしれません。
というのも、上流工程が面白いかどうかは、会社によっても案件によってもかなり変わるからです。
一次受けかどうかでも変わると思います。お客さんと直接話せるかどうかでも変わります。どこまで設計を書くかでも変わります。どれくらい裁量があるかでも変わります。
それに何より、性格の影響がめちゃくちゃ大きいです。
たとえば、僕はまだ形がないものを考えるのが好きです。お客さんの話から必要な機能を考えるのも好きですし、設計を論理的に詰めるのも好きです。
だから上流工程を面白いと思いやすいのだと思います。
でも、手を動かしてコードを書いている時間が一番楽しい人にとっては、上流工程は遠回りに感じるかもしれません。
打ち合わせが多いのが苦手な人もいると思います。ドキュメントを書くのが嫌いな人もいると思います。曖昧な話を整理するのがストレスになる人もいると思います。
だから、上流工程がつまらないと感じること自体は、全然おかしなことではありません。
ただ、個人的には上流工程そのものがつまらないというより、どの部分に面白さを感じるかの問題だと思っています。
上流工程が自分に合うかは、やってみないと分かりません
正直、上流工程が自分に合うかどうかは、やってみないと分かりません。
僕も今の仕事に就く前は、本を読んだり、YouTubeで動画を見たりしていました。
もちろん、それで得られる知識もあります。要件定義とは何か、設計とは何か、プロジェクトマネジメントでは何を見るのか、みたいな基礎を知るには役に立ちます。
でも、実際にやってみて思ったことは、事前に本や動画で得た知識とはだいぶ違いました。
特に、「何を面白いと思うか」「何をつまらないと思うか」は、知識として学んでもあまり分かりません。
これは本当に、やってみないと分からないと思います。
会社で上流工程に行ける機会があるなら、実際にやってみるのが一番いいです。
もし会社で上流工程に行けないとしても、自分で勝手にプロダクトを作る前提で、上流工程っぽいことをやってみるのでも十分いいと思います。
たとえば、こんな感じです。
- 身近な困りごとをひとつ選ぶ
- 誰が何に困っているのかを書き出す
- その課題を解決するための機能を考える
- 画面に必要な項目を考える
- ボタンを押したときの処理を自然言語で書く
- エラーや例外パターンも考えてみる
これだけでも、上流工程の感覚は少し分かると思います。
関連記事としては、要件定義の進め方や設計書の書き方について整理した記事もあるので、合わせて読んでもらえると理解しやすいと思います。
ただ、最終的には読んだり見たりするより、自分で一回やってみるのが一番早いです。
まとめ:僕にとって上流工程はつまらなくないです
僕にとって、上流工程はつまらなくないです。
もちろん、つまらないタスクはあります。特に設計レビューは、正直かなりめんどうですし、あまり好きではありません。
でも、全体として見ると、上流工程は面白いです。
まだ何もない状態からシステムを考えるのは楽しいです。お客さんの要望や課題を聞いて、それを解決する機能を考えるのも楽しいです。設計をロジカルに詰めていくのも楽しいです。
僕みたいに、こういう部分を面白いと思える人は、上流工程をけっこう楽しんでやれるんじゃないかと思います。
上流工程がつまらないかどうかは、仕事内容だけで決まるわけではありません。自分が何に面白さを感じるかで、かなり変わると思います。
今、上流工程がつまらないと感じている人も、全部が嫌なのか、一部の作業が嫌なのかを分けて考えてみるといいかもしれません。
これから上流工程に行く人は、まずは実際にやってみて、自分がどこを面白いと思うのかを見てみるのがいいと思います。
何かの参考になれば幸いです。