フォルダ構成から仕様書作成、開発ガイドラインまで、独自ノウハウを披露
「とほほのWWW入門」作者・杜甫々さん “10年先を見据えた”プロジェクト管理術を語る
仕様書作成：フェーズごとの仕様書を統合、“Excel方眼紙”での行単位の進捗管理も
続いては「仕様書作成」における工夫だ。
長期プロジェクトでありがちなのが、仕様書間の不整合である。開発途中で仕様変更があった場合、詳細仕様書から基本仕様書、概要仕様書へと遡り、影響範囲に応じて変更内容を反映する必要がある。「ただみんな、めんどくさがったり、忘れたりして、結局は不整合が生じていた」と杜甫々さん。
そこで、概要・基本・詳細のフェーズごとの仕様書をひとつのファイルにまとめた。一続きの仕様書にして修正の手間を減らすと、不整合はなくなったという。
概要・基本・詳細の各フェーズの仕様書をひとつに
また、文書番号体系（名づけ）も、プロジェクト＋文書の種類（設計仕様書はS、テスト仕様書はT、手順書はMなど）＋連番というシンプルなルールで統一して、検索やリンクをしやすくしたのもポイントだ。年度やモジュールなどは、採番台帳で把握できる。
文書番号体系もシンプル化
一部のプロジェクトで運用していた、“Excel方眼紙”製の仕様書も紹介された。
冒頭の列（A～F）で「作成」「査閲」「承認」「開発」「実装」「評価」のどこまで済んでいるかをチェックして、“行単位”で進捗を把握できる仕組みだ。加えて、コメントはExcelに直接記入し、★をつけることで残課題を集計する。「こうした運用で、仕様変更が漏れなく開発メンバーに伝わり、仕様書の一行一行で管理できる」（杜甫々さん）
Excel方眼紙で運用する仕様書
もうひとつ意識していたのが、「設計仕様書は評価仕様書でもある」という考え方だ。文章の末尾に「～か？」をつけると評価仕様書になるような、“テストファースト”な記述を徹底した。
例えば、「タイムゾーンはアルファベット昇順でソートして表示する」という仕様は、そのまま「タイムゾーンはアルファベット昇順でソートして表示するか？」というテスト項目になる。そして、設計仕様書のシート半分は、実際に評価仕様書として運用し、各行がテストされているかを把握しやすくしている。
そのまま評価仕様書になるよう記載
なお、杜甫々さんがプロジェクト立ち上げ時に最初に行っていたのが「型定義」だ。改行や制御文字、負数、サロゲートペア領域などを許容するかを予め定義して、画面からAPI、デザイン設計に至るまで統一していた。
開発ガイドライン：ノウハウを集約・伝播、そして10年先に伝承する
最後に触れられたのが、「開発ガイドライン」だ。
この開発ガイドラインとは、プロジェクトをまたがり蓄積してきたナレッジをひとつのファイルに集約したものだ。「障害があって、解決して、“なぜ3分析（なぜ？を繰り返す問題解決手法）”をする。喉元を過ぎれば忘れてしまうので、開発ガイドラインに追加して、10年先のメンバーにもノウハウを伝える」と杜甫々さん。
その項目数は500を超え、「管理」「設計」「開発」「評価」「出荷」などのフェーズごとに整理されている。さらに、新規追加の項目にはメンバー向けのチェック欄を設け、理解されているかを確認できるよう工夫している。
開発ガイドラインの例
プログラミングスキルの見える化にも取り組んでいた。それは、「Linuxのcatコマンドの互換コマンドmycatをC言語で作成してください」と投げかけるという内容だ。「これだけのお題だが、完璧に作れる人は少ない。異常時の終了ステータスが0以外になっているか、close()のエラーを確認しているかなど色々なチェック項目を設けていた」と杜甫々さん。
こうしたチェックリストを基に、新メンバーのコーディングスキルを客観的に数値化。チェックリストは、そのまま教育にも用いる。ただし、この見える化を含む施策は「今では生成AIでも出来てしまう」と振り返った。
プログラミングスキルの見える化
ここまで紹介された工夫は、あくまで一部にすぎない。年間で60個ほどの改善策を手掛けた時期もあったという。杜甫々さんは、「大事なのはこうした改善策を整理して、他のプロジェクトと共有していくこと。そして、次のメンバー、次の次のメンバーへと伝承させていくことだ。これはAIでもできない、人間が担っていくべきもの」と締めくくった。