■ 1. フリーランス・小規模ソフトハウスが直面する構図
- 元請けが穴だらけの立派な工程表を出してくる
- 大半の人はその穴を見抜けるレベルのレビュー実戦経験がない
- プライムにケチを付けられない立場のため従うしかない
- 末端側はウォーターフォール型工程に従い各工程のみを担当する
- 作るものの全体像が曖昧なまま設計が進む
- 実際に環境を組み上げたタイミングでようやく現実が見える
- 結果として発生する問題:
- 仕様漏れ
- 追加作業と追加料金交渉
- 納期ギリギリ
- ユーザー満足度の低下
■ 2. プロジェクト計画の理想と現実
- 理想:
- プロジェクト計画書がパートナーにも展開される
- 双方でコンセンサスを取りながら進める
- リスク想定とヘッジ案の説明や議論がある
- 現実:
- 小さな会社の社長やフリーランスはプロジェクトキックオフの儀式としてしか見ていない
- 様々な事情からリスク議論が実践できない
■ 3. 元請けの工程表の実態
- PMの願望が強く出たドキュメントと認識すべき
- 通常書かれていないもの:
- 商用環境の構成が固まるタイミング
- 試験環境でどこまで再現するか
- どの段階で何を試すか
- 現場の安全マージンやリスクヘッジ
- 極端な工程表の例:
- 要件定義工程がない
- 各工程での成果物が決まっていない
- 設計工程なしにいきなりパラメータ設計書
- PoCでやったから設計なしでいけるという幻想でいきなり環境構築
- ステージングをそのまま本番にするノリで商用後の保守イメージがない
- 実装期間が妙に短く3週間に環境構築から報告書作成まで全部入り
- セキュリティ設計やセキュアコーディングガイドラインがなく脆弱性試験で炎上
- このまま乗ると後半で燃える
- 外向け工程表とは別に内部で裏プロジェクト計画を持つ発想が重要
■ 4. 技①:基本設計段階でプロト環境を先に作る
- 基本設計フェーズの早い段階で本番と同じ構成イメージの影のプロト環境を自分たち側でこっそり作る
- プロト環境の内容:
- 土台となるOS
- 想定しているミドルウェア(アプリケーションサーバやレポーティング基盤など)
- 知る限り本番構成に近い形で一度組んでみる箱
- あらかじめ作っておくべきもの:
- GitLabなどのソースコード管理とCI/CD基盤
- メリット:
- 早い段階でリバースプロキシ不足や追加DB必要などの設計上の大穴に気づける
- 元請けの基本設計がふわっとしていても動くものの全体像を先に掴める
- 構築メモや設定手順と要件定義があれば基本設計書は後から2〜3日で一気に書ける
- 体裁や細かい部分はLLMを使えば2〜3日で形にできる
- ポイント:
- 工程表通りにドキュメントだけ書くのではなく基本設計の最初にプロト環境をこっそり動かす
- 内部工程を勝手に入れ替える
- 外には言わず自分たちが燃えないための保険として自社努力で行う
- コスト面:
- 自社で新たに大きなコストを捻出する必要はない
- プロジェクト開始早々は要件定義未提出や基本方針未確定などの待ち時間が多い
- 自分に関係ない打ち合わせ中にこっそり進める
- 待ち時間を活用して動くものの断片でも作っておく
- 勝手アジャイルを回す勢い
■ 5. 技②:バージョン釘打ちミーティングをねじ込む
- プロト環境を先に作る際の落とし穴:
- バージョンが後から変わって全部作り直しになる
- 対策として基本設計の初期にバージョン釘打ちミーティングをねじ込む
- 最低限合意しておくべき項目:
- 土台となるOSのバージョン(メジャーとマイナーまで決まれば上出来)
- 主要なミドルウェアとそのバージョン(アプリケーションサーバやレポーティングやバッチ基盤など)
- それぞれのサポート状況(EoL時期やメーカーサポート有無やOSSコミュニティ活動状況)
- 釘打ちは完璧でなくてよい:
- 一生変えないという固定ではない
- ひとまずこの前提で設計見積もりを進めるレベルの合意
- 後から変更が出ても柔軟に対応できるようにしておく
■ 6. 技③:プロト環境の存在は言わず経験値として出す
- 影のプロト環境で性能やリソースを見ておくと後のフェーズで楽になる
- 聞かれる質問の例:
- この構成でCPU何コアぐらい必要か
- 何ユーザーぐらいまで余裕があるか
- どのくらいのマシンサイズを見込めばいいか
- 裏ではプロト環境でちゃんと数字を取っているが自前環境で負荷かけたとストレートに言う必要はない
- 期待値コントロールの領域
- 外向きの言い方サンプル:
- 同等規模の構成での過去案件の経験値ではこのくらいのアクセス数ならCPU使用率は何%前後
- 近い構成のプロジェクト実績をベースにすると初期はこのマシンサイズから始めるのが妥当
- 似たような業務負荷の案件で取った数値を参考にするとこのくらいのスペックで当面余裕がある
- 実際にはその過去案件の1つが今回の影のプロト環境だが外から見れば経験値として扱える
- バランス感覚のポイント:
- 裏側ではしっかり測っている
- 過度に全部やってあげてますと期待値を上げすぎない
- 過去の知見として妥当な範囲を出していますというトーンを守る
■ 7. 技④:LLMに食わせる前提で手順書だけちゃんと残す
- 影のプロト環境を作るときは基本設計書そのものより手順書とメモの残し方をちゃんとしておく
- 理由:
- LLMに食わせるとかなり精度の高い基本設計書ドラフトが一瞬で出てくる
- 流れ:
- 影のプロト環境を作る
- その過程でインストール手順やミドルウェア設定や詰まったポイントと解決策をざっくりテキストで残す
- LLMに渡して基本設計書の構成案出しや顧客向け表現整理や試験項目洗い出しやパラメータシートたたき作成を依頼
- 2〜3日かけて書くレベルの文書が数時間で形になる
- この組み合わせの効果:
- 実装リスクを下げる
- ドキュメント工数も削る
- かなり相性の良い戦略
■ 8. ウォーターフォールを表で守りつつ裏でアジャイルを回す
- 表向きの対応:
- 元請けが出してきた大きな工程表(ウォーターフォール)に従っているように見せる
- マイルストーンや成果物の名称も基本設計や機能設計や結合テストを崩さない
- 裏側での対応:
- 基本設計フェーズのうちにプロト環境を作って動かす
- バージョンを釘打ちする
- 実際に動かしながらこれで行ける構成を先に固めてしまう
- そこで得た知見をもとに性能見積もりやリソース見積もりやリスク洗い出しをスッと出せるようにしておく
- 効果:
- 表面上はウォーターフォールでも内側では小さなアジャイルサイクルをぐるぐる回して後続工程をどんどん楽にできる
- 大線表の納期を遅らせるという話ではない
- 最初に影のプロト環境を作っておくことで大線表を遅らせずに済む確率がかなり上がる
- その構成で実際に動いている環境がすでにあるため
■ 9. 環境をプロジェクトごとに準備する効率化
- ネック:
- 案件ごとにOSやミドルウェアや認証まわりやテスト用クライアントを毎回ゼロから用意するのはフリーランスや小規模ソフトハウスにはheavy
- 対策:
- 案件ごとの箱庭環境を簡単に量産できるテンプレートやツールを少しずつ自分の側に用意しておく
- 具体例:
- 手元のマシン1台に仮想化環境と案件ごとの箱庭を自動で作るスクリプトを置いておく
- 新しい案件が始まったらまず影のプロト環境を30分くらいで立ち上げてから設計に入る
- 使うツールや技術スタックは何でも構わない
- 大事な発想:
- 毎回手作業で環境を組むのではなく案件ごとの箱庭をほぼテンプレートから起こす
- リモートからVPN経由で簡単に入れるようにしてパートナーがすぐに参加できる環境を作っておく
- となりの案件のVMが見えてしまわないようなセキュリティに十分配慮した分離開発環境を構築する
- パブリッククラウドで回してもよいが採算度外視で使うのはかなり危険
■ 10. まとめ
- 元請けの工程表だけを信じて燃えないための要点:
- 外向け工程表とは別に自分たちの内部工程計画を持つ
- 基本設計の初期にプロト環境をこっそり作ってしまう
- OSとミドルウェアのバージョンを早めに釘打ちしておく
- プロト環境で得た数字は自前ラボで測りましたではなく他プロジェクトでの経験値ですとして出す
- 手順書をちゃんと残しておけばLLMに食わせて基本設計書を一気に仕上げることもできる
- 表向きはウォーターフォールでも裏で小さなアジャイルを回して先回りしておくといろんな工程が楽になる
- 正論のセキュリティ記事というより現場で生き残るためのテクニック集
- これらの工夫が積み上がると変わること:
- プロジェクトの燃え具合
- ユーザーの満足度
- 自分たちの消耗度合い