プログラミンガリスティング
| 分野 | ソフトウェア工学（架空の開発手法） |
|---|---|
| 主な対象 | 高可用性アプリケーションと仕様駆動の開発 |
| 成立の背景 | 手戻り削減と変更追跡の極端化 |
| 標準的な成果物 | プログラム同定表（Listing Index） |
| 関連概念 | 仕様差分台帳、実装予言器 |
| 流行時期（推定） | 1998年から2006年 |
| 実施組織（伝聞） | 内閣府 技術監査局（旧）ほか |
| 批判の焦点 | 列挙の肥大化と「仕様の宗教化」 |
（ぷろぐらみんがりすてぃんぐ）は、コードを「書く」のではなく「列挙し続ける」ことで挙動を確定するという発想に基づく、架空のソフトウェア開発慣行である[1]。表向きは設計・保守性の向上を目的とし、実務者のあいだでは一種の職人芸として語られている[2]。
概要[編集]
は、プログラムの実装を単体で完成させるのではなく、変更が起こりうる状況を「列挙（リスティング）」しておき、その列挙結果から実行パスを導くとする手法である[1]。特に、入力・環境・例外の組合せを事前に表に落とす点が特徴で、表を更新できない限り“仕様は変えられない”という統制が敷かれたとされる[3]。
成立の経緯としては、1990年代末にの大規模システムで障害対応が「ログはあるが原因が曖昧」という状態になり、対応現場が“原因候補をリスト化するしかない”と結論づけたことが起点であると説明される[4]。のちにこの発想は、仕様策定やテスト設計の領域を越え、「実装そのもの」を列挙へ従属させる思想として拡張された[2]。
用語と仕組み[編集]
中核概念はと呼ばれる台帳であり、機能単位ごとに「条件→挙動→検証」を行ごとに紐づけるとされる[5]。同定表には、少なくとも(1)入力の型、(2)タイムゾーン、(3)同時実行度、(4)例外種別、(5)サーバの負荷帯の5軸が含まれるとされ、運用上は“5軸が揃わない行は列挙できない”というルールがあったとされる[6]。
さらに、列挙の粒度を管理するために「許容爆発係数」（Allowed Explosion Coefficient）が導入されたという記録がある[7]。この係数は、同定表の行数が指数関数的に増えるのを抑えるための指標で、当時の社内文書では「行数Lに対し、爆発係数E = ceil(log2(L+1))」のように定義されたと伝えられている[7]。ただし、運用が進むにつれ“係数が高いほど品質が高い”と誤解され、結果として行数が先に肥大化したともされる[8]。
また、列挙結果から挙動を導く段階ではと称される補助ツールが使われたとされる。予言器は、同定表の空白行を検出すると自動で「候補行」を補完する仕組みであり、補完された行に対しては必ず担当者の手書き承認が必要だったと語られる[9]。ここでの“承認”が、プログラミンガリスティングが単なるドキュメント作成ではなく、組織統治に近づいた理由であると説明されている[2]。
歴史[編集]
起源：障害対応ノートの暴走[編集]
起源は、のデータセンターで発生したとされる1997年の障害に求められることが多い。現場の技術者が“原因のメモ”を時系列ではなく条件別に書き直したところ、復旧手順が驚くほど再現できたという逸話が残っている[4]。その後、同様の障害がでも起きた際、同じ条件表現に揃えることが復旧時間を短縮したとして、条件列挙の価値が周知されたとされる[10]。
この時期には「障害は“列挙の不足”として扱える」という信念が生まれ、同定表が“再発防止の道具”から“開発の手段”へ置き換わっていったと説明される[3]。なお、社内資料には“1997年12月、1週間で同定表が13版に達した”という記述があり、版管理の熱量がうかがえるとされる[11]。もっとも、当時の第3版以降に記録上の空白が見つかるという指摘もあり、実態は現場の工夫が先行した可能性があるとされる[12]。
拡張：監査と規格化の時代[編集]
2000年前後に、列挙された表に基づいて仕様変更を監査する動きが加速した。伝聞によれば、配下の（旧）が「表の差分が監査の主語になる」として、同定表の様式統一を求めたことが転機だったという[13]。統一様式では、行IDが必ず“機能コード+三桁通番+環境ビット”で構成される必要があるとされ、例として『FT-217-104-011』のような形式が推奨されたとされる[14]。
規格化が進むと、同定表の更新頻度が開発の進捗そのものとして数値化され、週次会議では「今週の新規行が何行か」「差分の承認待ちが何件か」が進捗指標になったとされる[6]。結果として、開発者は“実装の完成”よりも“列挙の完全性”を優先するようになり、プログラミンガリスティングはテスト主導から仕様主導へ移行したと語られている[1]。
一方で、列挙が制度化されるにつれ、仕様を守るための形式が増え、表作成に時間が吸い取られたという反省も出た。特に2004年頃から「許容爆発係数」が形骸化し、“係数が高いほど良い”とする悪癖が広まったという[8]。この誤解が原因で、ある企業では同定表が2か月で約48万行に達し、レビューが終わらずリリースが延期されたという苦い経験が語り継がれている[15]。
衰退：自動補完の倫理問題[編集]
衰退は、自動補完機能が強化された後に訪れたとされる。予言器が空白行を補う精度が上がると、開発者は“承認のための理解”を省略しがちになったという指摘があった[9]。さらに、補完アルゴリズムが内部で参照する“過去事例の列挙パターン”が、暗黙のうちに業界慣行を上書きしてしまうという問題が持ち上がった[16]。
2005年にの某企業で発生したとされる「補完行事故」は、列挙が正しそうに見えて実は条件軸が1つずれていた事例として語られる[17]。事故報告書では、ずれは“タイムゾーン軸のビット反転”であり、影響範囲は「障害受付画面の表示時刻」だけだったとされたが、その後の追跡で決済処理の再試行回数にまで波及したとされる[18]。このように、列挙の自動化がもたらす責任の所在が問われ、プログラミンガリスティングは“便利だが怖い”という評価へと変化していったとされる[2]。
社会的影響[編集]
プログラミンガリスティングが広がったことで、ソフトウェア開発組織には“仕様の可視化”が求められるようになった。列挙された同定表は、非エンジニアにも共有可能な形式であったとされ、結果としてやの現場が技術判断に関与しやすくなったと説明されている[13]。また、表の差分が会話の中心になったことで、仕様議論は「言った・言わない」から「表のどこが変わったか」へ移ったともされる[6]。
他方で、表が“正しさ”の中心になることで、仕様は交渉可能な合意ではなく、更新できる時にのみ成立するものになったとされる[1]。この変化は、スピードを求める現場と、統制を求める現場の緊張を増幅させた。たとえばある企業では、リリース判定会議で「新規行が週あたり1500行未満なら未完了」とする内規があり、行数至上主義が生まれたと報告されている[15]。
さらに、表の作成が職人的な能力として認識されるようになり、同定表のレビュー技法が“資格”に近い形で教えられたという。資格講座は全国で開かれ、修了者には「行間読解者」という称号が与えられたとされる[19]。このような文化は開発コミュニティの価値観を変えた一方、学習コストが高く、結果として導入企業が局地的になったとされる[2]。
批判と論争[編集]
批判として最も多いのは、プログラミンガリスティングが「列挙の肥大化」に陥る点である。理屈上は条件の網羅が品質向上につながるはずだが、実務では“列挙のための列挙”が増え、表の更新が目的化したという[8]。実際、あるレビュー会議の議事録では「表が増えたのは改善ではなく、疑問が増えたからだ」と記されており、自己矛盾が露呈したとされる[12]。
また、監査が強く関与するほど、開発者はリスクを下げるより“監査で説明できる形”に寄せる傾向が強まったとされる[13]。この結果、設計の本質よりも、表の体裁（行ID形式や軸の並び）の遵守が優先される場面が生まれたという指摘がある[14]。
さらに、予言器の自動補完が“責任の所在を曖昧にする”という論点でも争われた。自動で補完された行を誰が正当化したのかが追跡不能になることがあり、監査側では「承認者は誰でもいい」と誤解された時期があったとされる[16]。このような論争の中で、プログラミンガリスティングは一時期「正しさの儀式化」という批判を受けたと記録されている[2]。
脚注[編集]
関連項目[編集]
脚注
- ^ 田中悠馬『列挙がすべてを決める夜：プログラミンガリスティング再考』情報処理学会, 2004年.
- ^ Margaret A. Thornton『Specification Governance Through Listings』Springer, 2003年.
- ^ 佐藤政輝『同定表の版管理と障害短縮効果』日本ソフトウェア監査学会誌, 第12巻第3号, pp.45-68, 2001年.
- ^ Kenji Nakamura, “Allowed Explosion Coefficient and Review Bottlenecks,” *Journal of Imagined Software Engineering*, Vol.7 No.2, pp.101-129, 2005.
- ^ 李静安『差分が会話を支配する—監査と開発のインターフェース』技術出版, 2006年.
- ^ 山本光樹『行ID設計の人間工学』ソフトウェア品質研究, 第19巻第1号, pp.9-27, 2002年.
- ^ Robert H. Kim, “Automated Completion and the Ethics of Approval,” *International Review of Spec Methods*, Vol.3 No.4, pp.210-244, 2004.
- ^ 内閣府 技術監査局『同定表統一様式（暫定版）FT-Model』内閣府資料室, 2000年.
- ^ 高橋沙織『列挙肥大化の統計的兆候と対処』ソフトウェア工学年報, 第8巻第2号, pp.77-95, 2005年.
- ^ Chloe Winters『The Rituals of Correctness: Listing-Based Systems in Practice』MIT Press（誤記多め）, 2002年.
外部リンク
- プログラミンガリスティング研究会
- 同定表フォーマット倉庫
- 行間読解者アーカイブ
- 仕様差分台帳シミュレータ
- 内閣府技術監査局（資料検索ミラー）