■ 1. 登壇者の背景
- Webに関する技術サイト「とほほのWWW入門」を30年間ひとりで運営してきた杜甫々さんによるセッションである
- 同サイトは個人活動だが本職であるソフトウェア開発でも複数の長期プロジェクトに携わってきた
- Backlogのユーザーグループ・JBUGは2025年11月29日にプロジェクトマネジメントの祭典「Backlog World 2025」を開催した
- 杜甫々さんの招待セッションでは彼がソフトウェア会社で実践してきたプロジェクト管理における数々の工夫が披露された
■ 2. とほほのWWW入門と杜甫々さんの経歴
- 1996年に開設された「とほほのWWW入門」はプログラミング言語やフレームワークなどWeb技術の入門情報を網羅的に発信し続けている
- 最近では陶磁器や洋楽・中国語・韓国語・タイ料理にまでコンテンツを広げている
- 2025年は尻を叩かれてAIの記事も載せている
- インターネット黎明期には同サイトでHTMLコーディングやCGIプログラミングを学んだ古参の読者も多い
- 杜甫々さんもインターネット歴38年でありインターネット老人会の会長を目指している
- 杜甫々はハンドルネームで本名ではない
- 大学卒業後1988年にメーカー系ソフトウェア会社に入社した
- 入社後はさっそくUNIXにTCP/IPを移植するプロジェクトに参加した
- その後ネットワーク管理システム(1990年から現在)・セキュリティ管理システム(2002年から現在)・クラウド管理システム(2013年から現在)と今なお続く長期プロジェクトの数々に携わってきた
- 会社自体は2025年10月に定年退職を迎えたばかりである
■ 3. 長期プロジェクトの課題
- プロジェクトが長期化すると仕様書だけでも1000枚を越えメンバーの入れ替わりで知識の断絶も発生する
- 杜甫々さんは「得意分野ではない」「細かで古い話」との前置きの上でプロジェクト管理で実践してきた工夫を披露した
■ 4. フォルダ構成の工夫:10年フォルダ
- まずは「フォルダ構成」における工夫である
- 長期プロジェクトではファイルのバージョンアップ(v1.1・v1.2)やバグフィックス(v1.1.1・v1.1.2)を重ねるうちに「どこに何があるかわからなくなる」問題が発生する
- そこで杜甫々さんが推進してきたのが10年経っても乱れない「10年フォルダ」と呼ぶフォルダ構成である
- 具体的には「バージョンに依存するファイル群」と「依存しないファイル群」を完全に分離させるのがポイントである
- 例えば「v3.2」に関連する仕様書はバージョン依存ファイルを管理するフォルダにあるv3.2フォルダ直下にのみ保存する
- そして最新の仕様書はバージョンに依存しないファイルとして別フォルダで管理する
- これを徹底することで新メンバーでも目当てのファイルにすぐに辿り着ける
- ただしこの運用ではバージョン依存と非依存の両方の仕様書を書く必要がある
- それに対し「v3.2の仕様書では2行ほどしか記載せず詳細は最新仕様書にリンクで飛ばし同じことを複数の仕様書で書かないようにしていた」
- さらに「リリースが終わればバージョン依存のフォルダは捨てるくらいの気持ち」で運用するのがよい
- 結局のところ重要なのは「最新の仕様」であり10年後に保守しているメンバーは古いバージョンの仕様など読まないからである
- 細かな工夫としては大本のフォルダ名に2桁の固有数字を付与している
- マウス嫌い派である杜甫々さんはこの数字を利用してキーボードのみでエクスプローラーを移動していた
■ 5. 仕様書作成の工夫
- 続いては「仕様書作成」における工夫である
- 長期プロジェクトでありがちなのが仕様書間の不整合である
- 開発途中で仕様変更があった場合詳細仕様書から基本仕様書・概要仕様書へと遡り影響範囲に応じて変更内容を反映する必要がある
- ただみんなめんどくさがったり忘れたりして結局は不整合が生じていた
- そこで概要・基本・詳細のフェーズごとの仕様書をひとつのファイルにまとめた
- 一続きの仕様書にして修正の手間を減らすと不整合はなくなった
- また文書番号体系(名づけ)もプロジェクト+文書の種類(設計仕様書はS・テスト仕様書はT・手順書はMなど)+連番というシンプルなルールで統一して検索やリンクをしやすくしたのもポイントである
- 年度やモジュールなどは採番台帳で把握できる
■ 6. Excel方眼紙による進捗管理
- 一部のプロジェクトで運用していたExcel方眼紙製の仕様書も紹介された
- 冒頭の列(A~F)で「作成」「査閲」「承認」「開発」「実装」「評価」のどこまで済んでいるかをチェックして行単位で進捗を把握できる仕組みである
- 加えてコメントはExcelに直接記入し★をつけることで残課題を集計する
- こうした運用で仕様変更が漏れなく開発メンバーに伝わり仕様書の一行一行で管理できる
■ 7. テストファーストな記述
- もうひとつ意識していたのが「設計仕様書は評価仕様書でもある」という考え方である
- 文章の末尾に「~か」をつけると評価仕様書になるようなテストファーストな記述を徹底した
- 例えば「タイムゾーンはアルファベット昇順でソートして表示する」という仕様はそのまま「タイムゾーンはアルファベット昇順でソートして表示するか」というテスト項目になる
- そして設計仕様書のシート半分は実際に評価仕様書として運用し各行がテストされているかを把握しやすくしている
- なお杜甫々さんがプロジェクト立ち上げ時に最初に行っていたのが「型定義」である
- 改行や制御文字・負数・サロゲートペア領域などを許容するかを予め定義して画面からAPI・デザイン設計に至るまで統一していた
■ 8. 開発ガイドラインによるナレッジ伝承
- 最後に触れられたのが「開発ガイドライン」である
- この開発ガイドラインとはプロジェクトをまたがり蓄積してきたナレッジをひとつのファイルに集約したものである
- 「障害があって解決してなぜ3分析(なぜを繰り返す問題解決手法)をする喉元を過ぎれば忘れてしまうので開発ガイドラインに追加して10年先のメンバーにもノウハウを伝える」
- その項目数は500を超え「管理」「設計」「開発」「評価」「出荷」などのフェーズごとに整理されている
- さらに新規追加の項目にはメンバー向けのチェック欄を設け理解されているかを確認できるよう工夫している
■ 9. プログラミングスキルの見える化
- プログラミングスキルの見える化にも取り組んでいた
- それは「Linuxのcatコマンドの互換コマンドmycatをC言語で作成してください」と投げかけるという内容である
- これだけのお題だが完璧に作れる人は少ない
- 異常時の終了ステータスが0以外になっているか・close()のエラーを確認しているかなど色々なチェック項目を設けていた
- こうしたチェックリストを基に新メンバーのコーディングスキルを客観的に数値化する
- チェックリストはそのまま教育にも用いる
- ただしこの見える化を含む施策は「今では生成AIでも出来てしまう」と振り返った
■ 10. 結論
- ここまで紹介された工夫はあくまで一部にすぎない
- 年間で60個ほどの改善策を手掛けた時期もあった
- 杜甫々さんは「大事なのはこうした改善策を整理して他のプロジェクトと共有していくこと」と述べた
- 「そして次のメンバー・次の次のメンバーへと伝承させていくことだこれはAIでもできない人間が担っていくべきもの」と締めくくった