ソフトウェアエンジニアは「詳細設計以降しかやらない」という言説を見つけた。
だからさぁ
— 寺野 克則（ITだけど営業視点のアカ） (@WjgotINrU14Z1fB) March 29, 2023
『ソフトウェアエンジニア＝詳細設計以降』
みたいな感じ、勝手につくるなよ。
別にWeb系さんもそんなひと求めてねぇよ。
外部調達してても『仕方ないから』だよそれ。
40過ぎた詳細マンの扱いなんか、昔から変わってねえよ。なんで変に自信持ってんだよ。意味わかんねえよ。
「詳細設計」という言葉は、SIer を退職してから一度も聞いたことがない。なんだか懐かしい響きだ。ありがとう。
正確には、SIer の新人時代に頑張って「詳細設計書」を作って以来、あまり触れた記憶がない。 もちろん、「詳細設計書」なるものを受領しているプロジェクトもあったが、私が関わったプロジェクトは SIer でさえ、「詳細設計書」なるものは書かなかった。
それはさておき、ソフトウェアエンジニアがいわゆる「詳細設計以降」だけをやっているというのは誤解がある。 しかしながら、V 字モデルの中で開発している方には誤解されても仕方がないともいえる。それが悪いわけでもない。
仕事の進め方が違うだけだ。ユーザーが幸せになればそれでいい。
私や私の執筆仲間、および友人が経験してきた職場の話を総合すると、ソフトウェアエンジニアとして働いている人間で「コーディングだけをやっている人間」は見当たらない。 もちろん開発期間内のコーディングに占める割合は SIer よりも圧倒的に多いが、いわゆる要件定義資料や概要設計資料も残している。
具体的にどのように進めるのか。
スクラムを組んでいるプロジェクトの場合は、プロダクトオーナーと呼ばれる役割の人がいる。 プロダクトをユーザー目線で評価し、製品の方向性を示す人だ。
プロダクトオーナーが「こんな機能を作りたい」という「ストーリー」を作る。 そのストーリーは基本的にはざっくりとしたものなので、要件定義資料を Confluence に書き起こす。
ストーリーの目的は何で、どんなメリットがあるのかまで、ソフトウェアエンジニアが書いた上で、プロダクトオーナーと認識を合わせるのだ。
そして、そのストーリーを実現するための設計資料を作り始める。V 字モデルでいう「概要設計」資料である。
概要設計は開発者間でレビューを行う。必要に応じてテーブルを設計したり、API を設計することもある。
そして、ある程度設計が固まったら、概要設計を「動くもの」に変換するために、コードに落としていく。
設計書の作成に書ける時間は 1〜2 日である。SIer 時代は規模が大きかったのもあるが、同じような機能を作るとしても、要件定義に 2 週間、概要設計に 2 週間かけて、それから詳細設計書を書いてコーディング開始、といった進め方だった。
ウェブ系の設計資料の作成が素早く進むのは、ウェブ系の社員が優秀だとか、ウェブ系の設計書が手抜きであるとかよりも、扱っているソフトウェアの中身を知っている人間が設計資料を書いているから速い、というのが実情といえる。 逆に、プロダクトの中身が何もわからない状態だと、設計書を書く作業は 10 倍以上時間がかかるに違いない。
ただ、SIer の場合は形式的な記載が非常に多く、「テンプレを埋めはするものの、設計の理解にはあまり役に立たない資料」を大量に作らなければならなかった。 SIer では協力会社と呼ばれる外部委託のメンバーが設計書を作り、プロパーの社員が忙しい合間を縫ってレビューを行う。
プロパーの社員は設計をコードレベルで理解しているわけではないので、当然協力会社の人に「概要」を説明してもらう。 そこでプロパーが「OK」を出して初めて、協力会社の人は開発を進めることができる。
この辺のやり取りには無駄が多かったのだが、ウェブ系はそれほど大きくない人数でプロジェクトを回していくため、レビュー地獄のような待ちは発生しづらい。
「詳細以降」という工程を意識する人はウェブ系にはいない
SIer 時代は開発工程を「概要設計」「機能設計」「外部設計」「内部設計」「詳細設計」「実装」「単体テスト」「連結テスト」「総合テスト」「UAT」のように分けていた。
ウェブ系と呼ばれる企業に転職してからは、「外部設計」「内部設計」「詳細設計」という単語を聞いたことはない。 「お前のレベルが低いだけなのでは？」と怒られるかもしれないが、別にそこまで厳密に「工程」を意識しないでもソフトウェア開発はできてしまうのだ。
ざっくり「設計」と「実装」で分けて仕事を進めるイメージである。
テストはユニットテストを書いて、「総合テスト」は「QA」と呼ばれる専門家が担当する。
こんな風に開発を進めているので、「詳細以降しかやらないだろおめーら」と言われると、こちらとしても「うーむ」と首をひねるしかない。
SIer のような Word の「詳細設計書」は作らないが、「詳細に近いレベルの資料」を Confluence に残すこともある。 だがこれが「詳細設計工程」なのかと言われると、別にそうではないと思うんだよなぁ、としか言いようがないのだ。
現在および未来のチームメンバーが意図を理解するために必要な資料は作るし、不要な資料は作らない感じ。
フォーマットは統一されているプロジェクトとそうでないプロジェクトで半々くらいだった。
SIer でゴリゴリと Excel に書いていたような資料は Swagger や StoryBook などで、ブラウザで見ることができるようになっていた点も違いがあるかもしれない。
個人的な経験を言うと、「詳細設計以降」のドキュメントはコードとの乖離が発生しやすく、実態を示さなくなってしまうケースが非常に多い。 API の仕様書などは決められた仕様で、自動生成した方が明らかに品質が高い。そして Excel に色々と書かれるよりも圧倒的に見やすい。
フリーランスや SES の外部委託の方は「詳細設計以降」なのか？
ウェブ系企業と呼ばれる会社でも、「外部委託」と一緒に開発することはある。
SIer では「設計をして外部委託に投げる」という開発のやり方だが、ウェブの方だと「一緒にスクラムを組んで開発する」といったイメージに近いはずだ。 ただ、外部委託の方に関しては、プロダクトオーナーと議論したり、プロダクトの方向性について強く意見することはあまりなかった。
「詳細以降だけをやる人」のイメージにかなり近いように思える。ただ、それも外部委託の方のロール次第で、外部委託のプロジェクトマネージャーとして参画するケースもある。 また、仕様や実装についてももちろん意見したり、議論もする。
「協力会社の意見など許さない」といった、厳密な身分制度のようなものはない。 SIer 時代は、ここまで極端ではないが、「協力会社」と「プロパー」の間には、暗黙の序列があったように思える。
ウェブの方はそこまで明確な序列はない。とはいえ、プロパーの人とは若干の意識の違いはある。
自分たちのプロダクトか、人様のプロダクト開発を支援している立場なのかで、スタンスは変わってくるものなのだろう。