30画面ほどのシステム開発を考える時は、稼働希望日から画面ごとの予定を置き、機能を見ながら日数を見積もり直してWBSへ落としています。大きな仕事は、次に何をするかと、どこで相談が必要かが見えるまで分ける。今はそう考えています。
『SOFT SKILLS ソフトウェア開発者の人生マニュアル』を読んだ時、大きな仕事ほど失敗しやすいという話に納得しました。実装だけでなく、予定やバックログも、大きいままでは扱いにくいと感じています。
30画面の開発なら、稼働希望日から逆算する
30画面ほどのシステム開発を考える時は、まずいつ稼働させたいのかを確認します。希望日に収まるよう、画面ごとの作業を粗く予定へ置きます。その後、1画面ずつ機能を見て何日かかるかを見積もり直します。ここは機能数を見ながら経験と勘に頼る部分が、まだ大きいです。
例えば「予定管理画面を作る」だけでは規模が分かりません。予定をどんなふうに管理するか、UIはどうするか、扱うデータ量や利用人数はどのくらいか。画面の中身を深掘りして作業と見積もりをWBSに並べます。希望日までに難しそうなら増員を相談し、少しはみ出すなら日程を調整できないか話す。マイルストーンを置いて、ゴールまでに必要なことを見えるようにします。
タスクの分解は、実装作業を列挙するだけではありません。最初に聞くこと、後から詳しく見積もること、規模が見えた時点で相談することを明らかにする作業でもあります。
大きなタスクは、次の一手が見えにくい
「詳細検索機能を追加する」と言われても、画面、検索条件、API、DB、既存機能への影響、テストなど、最初に考えることが多くて手を付けにくい。作業量が多いだけでなく、何をすれば終わるかが見えないのが重さの一因です。
そこで、要件、既存処理の調査、APIとDBへの影響確認、バックエンド、UI、テスト、リリース準備のように分けます。必要なら、さらに小さくする。分解の目的はタスクの数を増やすことではなく、「次に何をすればよいか」が分かるところまで具体化することです。
バックログも大きな塊になりやすい
未着手のIssueが並び、「いつかやるもの」が増えてくると、どれから取り掛かるか、どこまでで一区切りかが分からなくなります。バックログ全体も巨大なタスクと同じで、存在は分かっていても大きすぎて扱えず、だんだん見なくなります。
タスクを分けると、進捗も具体的になります。10項目のうち7項目が終わっていても、項目ごとの大きさが違えば作業量の7割が終わったとは限りません。完了した数と、残っている作業の大きさは分けて見る必要があります。それでも、残作業が具体的になれば「あと何をすれば終わるか」は伝えやすくなります。
小さくしすぎると管理が面倒になるが、そこはAIでかなり楽になった
一方で、「ファイルを開く」「クラスを作る」レベルまで細かくしすぎると、作業より管理の手間が増えます。必要なのは、次に何をするか迷わず手を動かせ、ある程度まとまった成果が出るサイズです。
とはいえ、そのちょうどいい粒度でバックログを1件ずつIssueに起票するのも、手でやると面倒くさい。最近はAIに任せて、バックログを細かく分け、Issueに登録させています。
不具合なら、起きたこととログをAIに渡して、現状を調べて分析し、修正案をまとめてもらう。その詳細をIssueへ登録するところまで頼んでいます。このやり方にしてから、Issueに登録する作業自体は手間に感じなくなりました。
先に修正を進めていて、思ったより重くなった時には、後からIssueに登録することもできます。
2026年10月にIssueへ登録した仕事は80件ほど。全部を終えられているわけではないので、処理済み、レビュー中、処理中、未対応に分けて、残っている仕事を見ています。
以前は大きな仕事を見ると「気合で終わらせよう」と構えがちでした。今はまず「何に分ければ次の一手が分かるか」を考え、AIも使いながらプロジェクトやバックログをパッと手を動かせる単位まで割って進めています。
関連記事
- 本書の全体像・書評: 『SOFT SKILLS』を読んで4年。残った考え方と、続かなかった実践
- 実践・ポモドーロ: ポモドーロは仕事で続かなかった｜それでも残った作業量を測る考え方
確認した公式情報
- 書籍: SOFT SKILLS ソフトウェア開発者の人生マニュアル 第2版 – 日経BOOKプラス（著者: ジョン・ソンメズ / 訳者: 長尾 高弘 / 解説: まつもとゆきひろ、日経BP、2022年2月発行、2026年9月22日確認）
コメント