公開日くらいに映画『Michael/マイケル』を観にいきました。キングオブポップの半生はすごいなと思いつつ、映画を見た後にさらに曲も聴くようなっていました。その矢先に、マイケルジャクソンについて調べていたらソフトウェア工学界 マイケル・A・ジャクソン(Michael Anthony Jackson) という方がいて、IT業界にもマイケルジャクソンがいることを知りました。今回はその方について書いた記事です。
はじめに
先日、マイケル・ジャクソンの伝記映画『Michael/マイケル』を観てきました。
冒頭にも少し書きましたが、キング・オブ・ポップはやっぱりすごい。マイケルジャクソンの曲はもともと聞いていて、今回の映画でさらに好きになりました（笑）
そして、余韻に浸りながらマイケル・ジャクソンについて調べていたら、ある人物について知りました。
ソフトウェア業界にもマイケル・ジャクソンがおるやん。
Michael Jackson (not the singer) — Consultancy & Research in Software Development
しかも「歌手じゃない方のマイケル・ジャクソンです」って自分で書かれていました。何回「Thrillerの人ですか?」とか聞かれたんやろな…と思い調べていくと、この方、ソフトウェア工学界のキング と呼びたくなるほどすごい方でした。
この記事でわかること
- マイケル・A・ジャクソンがどんな人物か
- 「3つの奇跡」= JSP・JSD・問題フレームのざっくり概要
- 名論文「The World and the Machine」(ICSE '95)のエッセンス
まず結論(要点だけ)
- マイケル・A・ジャクソンは、JSP(ジャクソン構造化プログラミング)・JSD(ジャクソンシステム開発法)・問題フレーム を生み出した英国のソフトウェア工学者
- 彼の仕事は「プログラム → システム → 問題」と、コンピュータの外側へ外側へ と射程を広げていった
- 代表論文のメッセージは「問題は世界にあり、機械は解決である」
マイケル・A・ジャクソンってどんな人?
| 項目 | 内容 |
|---|---|
| 生まれ | 1936年、英国バーミンガム |
| 高校 | ハロー校。 Christopher Strachey(計算機科学者) に最初のプログラムを教わる |
| 大学 | オックスフォード大学で 古典学 を専攻。 |
| キャリア | 1961年からロンドンでプログラマ・コンサルタント。後に自身の会社を設立 |
| 受賞 | Stevens Award(1997)、英国計算機学会 Lovelace Medal(1998)、ACM SIGSOFT Outstanding Research Award(2001) |
| 家族 | 息子の Daniel Jackson も MIT の計算機科学者(モデリング言語 Alloy の人) |
大学の専攻、コンピュータサイエンスちゃうんかい!とツッコみたくなりますが、当時のオックスフォードの古典学には論理学が含まれていたそうで、それが彼にとっての関心だったそうです。
日本での評価も紹介しておきます。ソフトウェア・シンポジウム2009のモデリングWGの資料では、こう紹介されています。
間違いなく、ソフトウェアエンジニアリング領域の奇才、というか巨匠。哲学的な深さ、本質に迫る叡智、ただし、凡人にはかなり判りにくい。
「ただし、凡人にはかなり判りにくい」ということですが、実際、著作は難解なことで有名らしいので、この記事では雰囲気だけでも掴んで帰ってください。
3つの奇跡:JSP → JSD → 問題フレーム
先ほどの資料では、先生の業績が 「3つの奇跡」 と紹介されています。面白いのは、それぞれ扱う範囲が どんどんコンピュータの外側に広がっていく ところです。
| 奇跡 | 出版年 | 扱う範囲 | ざっくり一言 |
|---|---|---|---|
| 奇跡1:JSP(Jackson Structured Programming) | 1975 | プログラム1本 | 制御フローじゃなく データ構造 からプログラムを導出する設計法 |
| 奇跡2:JSD(Jackson System Development) | 1983 | システム全体 | 機能より先に 実世界のモデル を作る開発法 |
| 奇跡3:問題フレーム(Problem Frames) | 1995 / 2001 | 実世界の問題そのもの | 問題を基本パターンで 分析 する方法 |
3つの奇跡の射程。プログラム→システム→問題と、どんどんコンピュータの外側へ広がっていく(AIで作成)
奇跡1:JSP — フローチャートを書くな、データ構造を見ろ
1970年代、「フローチャートを構造化してプログラムに翻訳する」のが主流だった時代に、ジャクソン先生は「フローチャートは制御の流れの記述であって、設計ちゃうやろ」と真っ向から異を唱えます。
代わりに提案したのが、入力と出力の データ構造 を「順次・選択・反復」の3基本構造で図示(ジャクソン構造図)して、その対応関係からプログラム構造を 導出する アプローチ。「プログラムの形はデータの形に従う」という発想です。
ちなみに先生自身、アセンブラ時代に丁寧にフローチャートを書いてからコーディングしていたのに「こんなに注意深くやっても間違う」と痛感したのが方法論探求の原点だったそうです。先生も最初は「設計というものはむずい」と思っていたそうです。
奇跡2:JSD — ユーザは要求を知らない
JSDはさらに一歩引いて、システム開発全体の方法論です。前提となる思想がもう痺れます。
ユーザは要求を知らない。機能より実世界モデル
機能一覧をヒアリングして積み上げるんじゃなく、まず実世界の実体(書籍とか利用者とか)とその振る舞いを記述して、システム内に実世界をシミュレートするモデルプロセスを作る。機能はそのモデルに後から接続するもの、という順番です。
例えば図書館システムで説明します。実世界で「書籍」が貸し出されたら、システム内のプロセスが同じ動作をする。そのために実世界とシステムを「どう接続するか」を決める——という考え方。ドメイン駆動設計(DDD)が現在ありますが、「あれ、これ1983年の話…?」と驚きました。
もうひとつ、JSDで面白いのが 共有事象(common action) という概念です。
「人が時計のボタンを押す」と「時計が人にボタンを押される」は、人の生涯と時計の生涯が交差する 同一のイベント を両側から見たもの。この共有事象の抽出こそがシステム設計の第一歩、とされています。この「両側から見る」感覚が、次の問題フレームと代表論文に繋がっていきます。
奇跡3:問題フレーム — 問題は「問題」にある
そして集大成が問題フレーム。もはやシステムの作り方ですらなく、そもそも解くべき問題をどう分析・構造化するか の話です。
実世界の問題を「機械・ドメイン(適用領域)・要求」の関係で捉え、いくつかの基本パターン(問題フレーム)に当てはめて分析します。
要求とは、機械が及ぼす効果によって適用領域において達成されるべき条件
要求は機械の機能一覧ではなく、世界側で達成されるべき条件 である、という定義です。
ここまで来ると、もう完全に「コンピュータの外側」の話をしています。
「要求」と「要件」について
この記事では原文の requirement を「要求」と訳しています。日本では「ユーザーの 要求 をヒアリングして、システムの 要件 として定義する(要件定義)」のように使い分けることが多いですよね。ジャクソン先生の言う requirement は「顧客が世界側で実現したいと望む条件」のことなので、システム側の条件として固めた「要件」よりも手前にある「要求」がニュアンスとして近いです。
論文「The World and the Machine」(ICSE '95)
3つの奇跡を貫く思想が一番ギュッと詰まっているのが、ICSE '95の論文「The World and the Machine」です。冒頭からいきなり核心を突いてきます。
要求 — すなわち問題 — は世界の側にある。機械は我々が構築する解決である。
ワープロの価値はコードの美しさではなく、できあがる文書の質で決まる。
航空管制システムの要求は、飛行機と空域と滑走路と管制塔の中にある。
ソフトウェアの価値は常にコンピュータの外側(=世界)で決まる、という話です。
航空管制システムとは
飛行機同士がぶつからないように、管制官が空の交通整理をするためのシステムです。レーダーなどで飛行機の位置・高度・速度を把握し、離着陸の順番や飛行ルートの指示を出すのを支えています。つまりこのシステムの「要求」は、コードの中ではなく、実際の飛行機・空域・滑走路・管制塔といった 現実世界側 に存在する、というのがジャクソン先生の指摘です。
世界と機械の関係。要求(問題)は世界側に、プログラム(解決)は機械側にあり、仕様は2つが重なる境界に書く(AIで作成)
逆噴射の悲劇
論文中の例が強烈なので紹介します。ある航空機システムには、こんな要求がありました。
「飛行機が滑走路に接地しているときだけ、逆噴射を使えるようにしたい」
逆噴射とは
着陸した飛行機がエンジンの噴射の向きを切り替えて、強力なブレーキとして使う仕組みです。まだ空を飛んでいる状態で作動したら大事故なので、「接地しているとき だけ」という条件が何よりも重要になります。
「飛行機が接地している」というのは 世界側の事実 であって、制御ソフトウェア(機械)はそれを直接知ることができません。機械が知れるのは、あくまでセンサーから届く信号だけです。
そこで開発者は、世界と機械の橋渡しをするために、世界についての2つの仮定 を置きました。
- 仮定1:車輪が回転しているなら、車輪のセンサーからパルス信号が出る(逆もまた然り)
- 仮定2:車輪が回転しているなら、飛行機は滑走路の上にいる(逆もまた然り)
この2つの仮定を認めると、「接地しているとき」を機械にもわかる言葉に翻訳できます。
要求: 接地しているときだけ、逆噴射を許可したい(世界の言葉)
↓ 仮定2:車輪が回っている = 滑走路上にいる
↓ 仮定1:車輪が回っている = パルスが出る
仕様: パルス信号が来ているときだけ、逆噴射を許可する(機械の言葉)
開発者は「仮定1と仮定2が正しければ、この仕様は要求を満たす」ことを証明しました。ロジックとしては完璧です。
ところが、ある大雨の日。滑走路に張った水の膜でタイヤが浮いてしまう ハイドロプレーニング現象(雨の日に車がスリップするやつです)が起き、飛行機は 接地しているのに車輪が回らない 状態になりました。仮定2の崩壊です。
晴れの日と大雨の日で機械の判断はこう変わる(AIで作成)
車輪が回らない → パルスが出ない → 機械は「まだ着陸していない」と判断 → パイロットは逆噴射を使えない。結果、飛行機は止まりきれず滑走路をオーバーランしました。
ここで大事なのは、機械は仕様通り完璧に動いていた ということです。バグっていたのはコードではなく、世界についての仮定 の方でした。要件定義で頭を悩ませたことがある人には刺さると思います。
エンジニアは世界から目を背けがち(4つの否認)
ここまでの話で「世界を理解するの大事やな」となるわけですが、この論文の面白いところは、それでも僕らエンジニアは世界から目を背けて機械に閉じこもってしまう と指摘してくるところです。その言い訳のパターンが「4つの否認」として列挙されています。この4つの中身は、AI時代の話と絡めて後編でじっくり紹介します。
まとめ
- ソフトウェア業界のマイケル・ジャクソンは、自ら「not the singer」と名乗る英国の巨匠
- JSP → JSD → 問題フレームと、キャリアを通じて「コンピュータの外側」へ向かい続けた
- 代表論文のメッセージは「問題は世界にあり、機械は解決である」
後編に続く
ここまで書きましたが、
「問題は世界にあり、機械は解決である」——この30年前の言葉、AIがコードを書く2026年の今こそ一番刺さるのでは…?
AIが安くしたのは「機械」を作るコストであって、「世界」を理解するコストは1円も安くなっていないはずです。逆噴射の悲劇みたいなものは、プロンプトの問題として今も毎日再生産されている。そしてvibe codingというAIからの誘惑は、実は30年前に「否認」として予言されてのではないか、、。
後編のリンク
https://qiita.com/kaichan_dot/items/d21010b66725119be25a
参考
- Michael Jackson, "The World and the Machine", Proceedings of ICSE '95
- 飯泉純子「問題は『問題』にある — An Overview of Problem Frames」ソフトウェア・シンポジウム2009 モデリングWG
- Michael A. Jackson (computer scientist) - Wikipedia
- ジャクソンの構造化プログラミング - Wikipedia
- 映画『Michael/マイケル』公式サイト
- 邦訳書:『構造的プログラム設計の原理』(1980)、『システム開発 —JSD法—』(1989)、『ソフトウェア博物誌 —世界と機械の記述—』(1997)