最近スタートアップと言われるような企業に務めている人でもソフトウェア開発で必要になる大体の全工程を把握してないことが多いということに気づきました。こういうのは案外SIで働いていた人とかはしっかり把握していたりします。スタートアップだと深いことは何も考えずに横文字のかっこよさげな単語とかPMFだかPSFだかの略称を連呼することでプロジェクトのヤバさを糊塗しようとする傾向にある気がします。スタートアップだと出資者に対して如何にプロジェクトがいい感じであるかという外観を装うことが重要なのでそのようになるのかもしれませんが、非常に危ういなと思います。
そこで今日は簡単にソフトウェア製品開発（特にWeb）で必要になる全工程をざっくり箇条書きしてみたいと思います。ビジネスサイドではなく、あくまで開発者目線です。
提案
まずはいきなり提案から始まります。ビジネスサイドの人（受託開発の場合は顧客）は、「技術のことはわからんからいい感じの提案をくれ」ということが多いです。提案をするにしても材料がなければ提案できませんので、やりたいことや欲しいもの、困っていることなどを聞き出すことが大事になります。
大体の雰囲気がつかめたら、「こういうのが欲しいんですよね？」といった要求事項をまとめた提案資料をつくります。
要求の聞き出し
提案資料をベースに要求を一つ一つ洗い出していきます。提案資料というたたき台があるとビジネスの人もあれが欲しいこれが欲しいという意見を具体的に述べてくれるようになります。それらの要求を箇条書きにして整理します。
要求から要件を書き起こす（要件定義）
要求を聞きだしたら、それを要件として書き起こします。例えば「日記が書ける機能がほしい」という要求があったら、「日記の作成画面、編集画面、プレビュー画面、一覧画面が必要」といった要件として書き起こせます。要件の段階では画面単位だったり機能のまとまり単位でざっくり書き出すだけでだいたいOKです。
上記は「機能要件」と言われるものですが、「非機能要件」も必要になります。ただ非機能要件はもっと後のフェーズで定義することが多いです。なぜなら作りたいものの解像度がこの段階では低すぎて、非機能要件まで決められないからです。
基本設計
現場によっては論理設計と言ったり外部設計と言ったりして、あまり統一されているわけではありません。またその詳細度も現場によって違います。論理設計の段階でデータの属性やフローチャートまで決めてしまう場合もあります。
ただ、通常はこの段階ではサーバー構成や大まかなデータの流れを決めることが多いです。ミドルウェアに何を使うかとかもこの段階で大体決めます。やりたいことの技術検証などもこの段階で行います。
なのでインフラの人とかは別に優秀な人でなくてもこの段階から割と仕事があって、上流に食い込めたりします。
詳細設計
現場によっては物理設計と言ったり内部設計と言ったりします。いわゆる「仕様書」を作り始めるのがこの段階です。最近のスタートアップ的な開発だと仕様書なんてないのではと思われるかもしれませんが、Figmaとかで作られたモックが仕様書にあたるのではないかと思います。「何を作るべきか」がはっきりしてないと何も作れないという点はウォーターフォールもアジャイルも同じです。ただ「詳細設計→実装」のサイクルの長短が違います。
SIの現場ではこの段階で一番エンジニアの工数を使います。なぜなら仕様書には責任が詰まっているからです。仕様書がマズかったりすると顧客の要求を満たせないソフトウェアを作ったということになり、最悪お金がもらえなくなったりします。にもかかわらず仕様書通りに作ってくれたプログラマにはきちんとお金を払わなくてはなりません。仕様書を作って、顧客やプログラマと一緒にレビューして、みんなが満場一致でOKを出してから（＝みんなの責任）実装に取り掛かります。
現実にはそこまで頑張って合意したにも関わらず仕様は覆ります。そして責任のなすりつけ合いが始まります。
実装
現場によっては開発と言ったり製造と言ったりします。手を動かして実際に動くものを作っていく段階です。並行してインフラの構築や周辺ツールの導入も行います。PMの人はこの期間中にビジネス側の要求がひっくり返ったりしないように気を使わないといけません。それができないPMはPM失格です。PMの仕事はそこに尽きると言っても過言ではありません。できなければプログラマからの信頼を失います。
この段階ではよくスケジュール管理とか工数見積の話が出てきますが、正直言って正確な工数見積もりは不可能です。不可能だと割り切って見積もったほうが建設的なので、直感的に「これくらいかな？」と思った工数の3倍を見積もり工数とするのを心がけるのが良いと思います。盛りに盛った3倍の工数をビジネス側に言うのは案外勇気が必要だったりしますが、結果的にそうなることがほとんどなので理解してもらうしかありません。
テスト
試験と言うことも多いです。テストの中にもいくつか段階があって、代表的なのは
- 単体テスト
- 結合テスト
- 総合テスト
- 受け入れテスト
とかじゃないかなと思います。テストも現場によって何を指すかが大きく違ってたりするので、臨機応変に言葉を使うのがいんじゃないかなと思います。
一般的には単体テストはスプレッドシートに細かく手順と期待値を書いて、「〇〇ボタンを押したら〇〇に遷移」みたいな細かい挙動を確認するやつです。結合テストはクライアント・サーバー間の連携や、外部サーバーとの連携とかを含めて確認します。総合テストはユースケースに則ったシナリオを作成してテストします。受け入れテストは実際のユーザーに使ってもらってテストするやつで業務アプリとかで多いです。
ようやくこの段階で非機能要件が定義できるようになることも多く、同時接続数とかレスポンスタイムとかバックアップとかセキュリティとかの話を詰めていきます。
非機能要件が決まったら、障害時を想定した復旧試験（最低一回はやっといたほうがいい）とか、性能テストをやります。おカネがあるプロジェクトでは外部のWAFとかを入れてセキュリティを担保しますが、そのせいで本番環境だけ機能が動かなくなるなどという椿事が発生するのもあるあるです。
リリース・運用・次のフェーズ
リリース時は夜まで待機みたいなことも結構あると思います。リリース直後の障害は起こるものと考えたほうがよいと思います。そのへんの障害対応の体制は予め組んでおいたほうがチーム内に余計な禍根を残さずに済みます。PMはそのへんをちゃんとやりましょう。
運用に移っていくとチームからどんどん人が抜けます。そこでサクッと抜けてまた新しいプロジェクトに行ければエンジニアとしては飽きなくて良いのですが、運用にある程度長く付き合うのもそれはそれで知見を得られます。特にバッチ処理関連とかパフォーマンスチューニングとか監視とかについての経験は一つの製品に長く付き合うことでしか得られないことが多いです。
次のフェーズが決まってるプロジェクトなら粛々と機能開発を続けていくことになります。新機能単位で「要件定義→仕様作成→実装→テスト」のサイクルを回します。
終わりに
スタートアップで働くことになったはいいが、実は手を動かすプログラマとしての経験しかなく、雰囲気でプロジェクトを進めてるという人もたくさんいると思います。そういう人はCTOだのテックリードだのとかっこいい肩書を考える前に、謙虚になって一度開発工程の全体像を把握しとくと良いのではないかと思いました。