組織やチームの話を追いかけると、プログラミングは基礎教養なんだって話に辿り着いてしまう件

まさにそんな感じの話がInfoQで紹介されていた。

自律的なチームを「管理」するという矛盾にどう立ち向かうか

シュレーディンガーの猫
シュレーディンガーの猫

組織とはそもそもピラミッド(階層構造)なのだということを、筆者の中で今流行りのハーバート・サイモン先生は主張して目出度くノーベル賞を獲得したのだが、時代は変わってチーミングの本では、そのピラミッド型組織が親の仇のように扱われていた。

21世紀になって、それまではどちらかと言えば個人の才能に頼っていたイノベーションという難題に、組織として取り組む企業が出現し始め、それに成功した企業が高い競争力を持つようになったため、チーミングやらボトムアップ組織のようなものが脚光を浴びるようになったというのがその背景だ。

しかし、組織とはそもそもピラミッドなのである。その中では、上位の人間の役目は下位の人間を「コントロール」して成果を出す事だと信じる人間が圧倒的なマジョリティを占めるだろう。

このような環境の中で、自律的に考えて動くチームを組織の中心に据えるというのは、相当な難題である事は想像に難くない。

この「自律的なチームを組織の中でどう育てるか?」という、一見矛盾するかのように思える問題を、量子力学の「シュレーディンガーの猫」に喩えて解説したのが、Instagram で技術責任者を務める James Everingham 氏だ。

観測という行為自体が観測対象に影響を与えてしまうという「観察者効果」のメタファーは、自律的なチームを管理するという矛盾(難題)をうまく表現していると思う。管理者は常に、自分が介入する事でチームの自律性(シュレーディンガーの猫)を殺してしまう可能性があることに注意を払う必要がある。

Everingham氏が提案する、量子力学的チームマネジメントの5つの法則はこちら。

  1. 成功のパターンを出来るだけ沢山想定すること。
  2. 観察者効果を常に意識すること。
  3. 箱を開ける(観測する)タイミングを心得ること。
  4. 自律性を壊さずにチームに良い影響を与える方法を心得ること。
    • 背中を見せる
    • 共感による動機付け
    • インセンティブ
    • 連帯感
  5. チームが正しい方向に向かっているか、外部からのフィードバックに常に気を配ること。

この新しいマネジメント手法のエッセンスは、当該記事の最後の言葉に集約出来るかもしれない。

By not suggesting a destination, we all ended up somewhere extraordinary — a place I didn’t even know we were going.

「あえて行き先を押し付けない事で、想像もしなかったような、すごいところに到達できる。」

受託開発でアジャイルというのはほとんど語義矛盾ではないだろうか

ここ最近、立て続けにアジャイル絡みの事を書きながらこぼれ落ちた考えをここに書き留めておく。

筆者にとってアジャイルというのは、かなりの程度、個人的な問題だということはまず認めておかなければならない。

個人的だと思う背景には、(自分にとっての)アジャイルというものを、それを知らない人に伝達する事の難しさをつくづく痛感しているからである。

アジャイルはそもそも道具ではない。すでに書いたように、アジャイルというのは価値観であるし、もっと言えば文化だと言っても差し支えないだろう。

人間の集団の中で理屈抜きで共有出来る何らかの価値観があれば、それを文化と呼ぶ。

例えば、一つの組織の中で、ある事が組織の利益になるから同意するというのは、基本的に契約の問題であって文化ではない。つまり、組織にとって利益になるからアジャイルを導入しようという(ベタな)言明はそもそも成り立たない。

アジャイルが結果的に組織にとって利益になるという事は当然あり得るが、利益になるからやるという順番だとそれはもはやアジャイルではない(それが「道具ではない」ということの意味だ)。このようなジレンマが文化というものには必ず付いて回る。

文化を築くのには気が遠くなるほどの時間と幸運が必要になるが壊れるのは一瞬である。特に営利組織の中で働いていて、その利益以外の事で価値観を共有するというのは基本的に至難の業である。

アジャイルはもう終わったという話が度々出てくるが、そのほとんどはハイプ・サイクル絡みの話だった。そもそも無理筋なことをやろうとしていた、というだけのことではないだろうか。

アジャイルはそもそも「無理」から出発した方が良いのだろう。

アジャイルはソフトウェア開発にクリエイションを持ち込もうとしたが、ほとんどの現場ではそんなものを求めていなかった。

日本ではソフトウェア開発の多くが受託開発だと言われている。

受託開発というものがそもそも「アイデアを他者によって実現してもらう」という考えで成り立っている以上、開発側にクリエイション(アイデアをいかに発見するか)が入り込む余地がない。

文化という側面で言えば、人に頼まれて何かをやるという仕事の方式そのものが減点ベースの評価にならざるを得ず、アジャイルとそもそも相容れないと言う事も出来る。

これは受託開発だったらウォーターフォールという選択の問題ではない。人に頼まれて何かをやるときは「交渉」が最重要事案になるというだけだ。

自分達で発見したものを世に問うという仕事に就きたいというのは完全に価値観の問題であって、多くの人にとっては「人に頼まれて何かをやる」のがそもそも仕事の定義であり、その上で生活が成り立っている。社会全体としては価値を生み出していなくても「交渉」によってお金を回す事は出来る(それが持続可能なのかは別にして)。

アジャイル最大の難点は、当たり前だが、そこで価値の発見が保証されているわけではないというところだろうか。以前、スティーヴン・キング氏の自伝「On Writing: A Memoir of the Craft」を紹介したが、それを読めば誰もが小説が書けるわけではないのと同じように。

何が見つかるか分からない状況で旅に出ることをこの上ない喜びと感じるか、そんな博打を打っていたら生活が成り立たないと嘆くか、そこが文化の分かれ道かもしれない。

アジャイルはプログラマーに万能を求める。

アジャイルの問題意識がそもそも役割の分断にあるので、必然的に分断された役割を小さな範囲に集約していくことになる。そこを突き詰めると、それは単にフルスタックエンジニアになるというレベルを超えて、各人が自律したマーケターになることも要求されるようになる。

興味深い事に、これはマーケティング分野の側でも同じような事が言われているようだ。

アジャイルにおいて創造のエンジンを担っているのはプログラマーの側である。その外側にいてアイデアや舵取りの責任を持つ人間の存在はアジャイルにとっては単なる非効率に過ぎない。技術がイノベーションの源泉になっている、あるいはそのような組織を目指しているのなら尚更、外側の人間がアジャイルのエンジンに噛み合って仕事ができるという幻想を捨てなければならない。

しかし、冷静に考えてみよう。こんなことが可能な環境や組織が果たしてどのぐらい存在するだろうか? あるいはそれこそがクリエーションの希少性と呼べるものなのかもしれないが。

#noprojects: もう「プロジェクト」というアプローチでは価値を生み出せない

ちょっと前に InfoQ から「#noprojects」という電子書籍が出ていた。

cover-noprojects-emag

この書籍には、それぞれ別の論者によって書かれた6つの記事が掲載されている。「No projects」というそのタイトルの通り、これまで当たり前のように採用されて来た「プロジェクト」というアプローチは既に有効ではない、というのがこれらの記事に共通する主張である。

一見、過激で論争を呼びそうな主張であるが、内容を仔細に検討してみると、アジャイルというものを追求して行けば自然にこの形に到達するだろうなと腑に落ちる内容だった。アイデアとしては、アジャイルがより多くの領域に援用されるきっかけとなった、リーン、あるいはリーン・スタートアップや、このゆびてくでも紹介したインパクトマッピングなどのアイデアをミックスしてより一般的な形で展開させたものである。

そもそも「プロジェクト」とは何だろうか?

プロジェクトには始まりと終わりがある。プロジェクトはあるタイミングで開始されて、そして終了するタイミングは予め決定されている(実際にその通り終了するかどうかは別にして)。プロジェクトの最大の目的は「プロジェクトを終了させる」ことである。プロジェクトには固定の期間と人員、そしてそれに合わせた固定の予算、そして固定のアウトプットが想定されている。つまり、プロジェクトとは、予算を持ってそれを計画する人の都合に合わせる事を目的にしたアプローチなのである。言って見れば、予算と青写真を入れてボタンを押せば、決まった期日にアウトプットが出てくる魔法の箱である。

そんな魔法の箱は存在しない、そして、たとえ青写真通りのアウトプットが出てきたとしても、その時にはすっかり価値がなくなっている、というのが #noprojects の主張である。

プロジェクトというのは、ウォータフォール型開発の最後の遺産だと言えるかもしれない。これまでその存在があまりにも自明過ぎたためにアジャイルの時代になっても生き延びてきた。しかし、アジャイルでは既に、どの段階でもプロダクトをリリース出来るという継続的デリバリー(Continuous Delivery)が普及しつつあり、そのような現場においてプロジェクトというアプローチは形骸化しつつある。

最初に計画を行い、そしてその通りに物事が進んで、予定の期日にものが出来上がってくるという想定は間違っている、必ず想定外の事象が発生して変更を迫られることになるのだから、予め変更に強い体制を整えておかなければならない、というのがアジャイルの考え方であり、自然に #noprojects に繋がるものであるが、実際には多くの管理者がガントチャートを作りたがるし、物事が想定通り進まないのはどこかに原因があって、それを個別に対処して行けばプロジェクトを元のレールに乗せる事が出来ると信じている。頭の中では変化を想定しなければと思う反面、行動としてはどうしてもウォータフォールの影を引きずってしまう。プロジェクトという形態を取る限り、失敗の原因を計画に求める他なく、故により多くの事を予め想定しておこうという考えから脱する事ができない。

あるいは「変化に対応しよう」というアジャイルのスローガンに問題があるのかもしれない。変化があるかないかで言えば、変化がなく想定通りに進むプロジェクトだってあるだろうと主張する人も出てくる。よって、アジャイルかウォータフォールなのかは適材適所なのだという主張も成り立つ。しかし、本当の問題はそこにはない。ソフトウェア開発が開発の中途で想定外の変化を遂げるのは、その中でより価値のあるものを「発見」しようとするからである。ほら、想定通り物事が進んだじゃないか、そういうことだってあるんだ、と言っても、そのようにして出てきたものには既に価値はない、というのがソフトウェアの世界である。よって、スローガンとしては「発見を主眼におかないソフトウェア開発にはもはや価値を産み出せない」と言った方が良いのかもしれない。

継続性

プロジェクトに代わって、新たなモデルとして提案されているのが「継続的な変更の流れ(Continuous stream of change)」あるいは「流れ作業生産(Flow production)」と呼ばれるものだ。「流れ作業」というと、アジャイルが目の敵にしていたテイラリズムを想像してしまうが、ここでのフォーカスは顧客価値に基づく小さな変更を継続的に行うことにある。リーンの「かんばん」などはこのモデルに近い。

そして、ここでのキーワードは「継続性」である。プロジェクトは基本的に large-batch なアプローチであり、リスクも高いしオーバーヘッドコストも馬鹿にならない。これまではプロダクト(アウトプット)ごとにプロジェクトを組むのが一般的であったが、この方法だと新しいプロダクトを計画する度にチームを編成してプロジェクトを立ち上げなければならない。同じプロダクトでもバージョンアップや改修があるときに別のプロジェクトを立ち上げるのはよく見かける光景だ。#noprojects が提案するのは、アウトプットではなく「成果(Outcome)」にコミットするチームを編成し、その成果を実現するために継続的な変更をリリースしていくモデルである。成果とは、組織にとってどのぐらいの「価値(Value)」があるかという尺度で評価される何らかの「変化(Change)」のことだ。

このようなモデルにおいて、プロジェクトに代わって重要な存在になるのは「チーム」である。チームは結果的な価値にコミットするため、同じチームが複数のプロダクトに関わることは自然なことであり、そこに継続性が生まれる。このようなチームを「価値提供チーム(Value-delivery team)」と呼ぶ。これまでのプロジェクトモデルの問題は、プロジェクトごとにチームが編成・解散されることが多く、せっかく蓄積した知識やノウハウの連続性がそこで失われる事であった。

これまでのプロダクトにフォーカスするプロジェクトベースの開発では、開発者、営業、マーケティング、サポートといった、組織内の機能ごとにチームを分けるのが一般的だった。そして、このように役割で組織が分断されるという問題が、このゆびてくでも繰り返し取り上げてきた、アジャイルやDevOps、インパクトマッピングといった考え方が繰り返し指摘する、現代のソフトウェア開発における最大の障害なのである。チームが価値にコミットするためには、そのために必要な全ての機能をチームの中に備えておかなければならない。これを「機能横断型チーム(Cross-functional team)」と呼び、たとえれば、チームがミニチュアなベンチャー企業となるようなイメージである。実際に、#noprojects の記事の中では、ベンチャーキャピタルの組織内バージョンだと指摘されている。

このような機能横断型チームが、小さなサイクルで実験と学習を繰り返しながら価値を発見しようと継続的な努力を続ける、これが #noprojects が提案するソフトウェア開発のあり方である。

#noprojectsの重要なコンセプト

#noprojects では、その手法を構成する重要な要素として、以下の5つのコンセプトを挙げている:

  • 価値(Value)
  • 成果(Outcome)
  • アクティビティ(Activity)
  • ルール(Principle)
  • 継続的デリバリー(Continuous delivery)

チームは「成果」を生み出すために「ルール」に基づいて「アクティビティ」に従事し、その「成果」は「価値」によって測定される。そして、その継続性とサイクルの短さは「継続的デリバリー」によって担保される。

価値(Value)

価値というのはなかなかに厄介な概念である。ほとんど「主観」と同義だと言っていいぐらいに不確かなものであるし、多くの賢人が指摘しているように、数字に置き換えて理解しようとすると途端に落とし穴にハマる危険性が高くなる。#noprojects では、その不確かさはそもそもビジネスをする際には付き物であり、そこが正確に予測出来るのであればマーケットも簡単に予測可能になるはずだが実際にはそうなっていないと、価値問題に深入りする事は避けている。しかしながら、組織が成功するかどうかのファクターのほとんどはこの価値に関わっていて、仮に #noprojects を実現したとしても、それは単にスタート地点に立っただけに過ぎない。

この価値の問題については、以前「我々は何のためにソフトウェアを開発するのか?」という記事の中でも取り上げた。その中で、Ron Jeffries氏による価値の定義「Value is what you want(価値とはあなたが欲しいもの)」を紹介した。価値を突き詰めれば、経済の問題だと考える人も多いだろうし、あるいは文学の問題だと思う人もいるかもしれない。

#noprojects によれば、一度成果として実現された価値というものは、変更を継続しなければ、時間が経つにつれて減衰していくと言う。これが、プロジェクトモデルに代えて継続的手法を取るべきだという主張の直接的な根拠になっている。

成果(Outcome)

成果とは、具体的なプロダクトやアウトプットではなく、価値によって計測可能な変化の集積である。このように表現するとなかなかイメージを掴みづらいが、記事の中では「アクティブユーザーの獲得」や「スタッフ満足度の向上」などが例として挙げられている。

Agile India 2016 - Leadership Day Summary より
Agile India 2016 – Leadership Day Summary より

この「成果」は、以前ゆびてくで紹介したインパクトマッピングの「ゴール(Why?)」に相当する。つまり、インパクトマッピングを利用すれば、成果を実現するためにはどのようなアクティビティを行えば良いかを考える際の助けになるし、かつチーム内での情報共有においても効果的である。

map

im_example

アクティビティ(Activity)

アクティビティとは、成果を生むための必要な個別のタスクのことである。#noprojects では、個々のアクティビティを事前に評価するための手法として「アクティビティ・キャンバス(Activity canvas)」というものを提案している。以下のように、アクティビティにかかる手間をX軸、実現できる価値をY軸とするキャンバスを用意し、そこに個々のアクティビティをマッピングして行く。

Agile India 2016 - Leadership Day Summary より
Agile India 2016 – Leadership Day Summary より

上のようにアクティビティをマッピングして行くと、どのような順番でアクティビティを実施したら良いかという優先順位が自然に現れてくる。#noprojects に限らず、アジャイルで重要なのは、タスクを「高」「中」「低」のような役に立たない優先順位に分ける事ではなく、実施の順序を決めることである(次に何をやればよいか?)。タスクを順序付けることによって同時並行で処理するタスクの数を減らせば、チーム全体のスループットを向上させることができる。

ルール(Principle)

アクティビティの実施方法は完全に自由というわけではなく、多少をコストをかけてでも若干のルールを作っておくことによって、アクティビティとプロセス全体の親和性、あるいはアウトプットの品質を保つ。アジャイルで言えばプラクティスに相当するが、プログラミング、コミュニケーション、セキュリティ、ブランディングなど、共有するルールはプラクティスよりも多岐に渡る。ルールでチームを縛るというよりも、最低限守らなければならない作法を明確にしておくことによって、その他はメンバーの裁量に任せるという意味合いが強い。

ルールの導入にはコストがかかるため、「MoSCoW」という優先度割当の方法が紹介されている。MoSCoWではルールごとに以下の4つのカテゴリーから選んで優先順位を割り当てる。

  • M (Must have) – 必ず従わなければならない
  • S (Should have) – 正当な理由がない限りは従う
  • C (Could have) – 個人の裁量に任せる
  • W (Won’t have) – 出来るだけ避けるべき

継続的デリバリー(Continuous delivery)

#noprojects のような考え方が提唱されたり、あるいは現実的になってきたのは、インフラ技術の進歩によって継続的なデリバリーが実現出来るようになってきたからだと言っても過言ではないだろう。継続的デリバリーを、アジャイル以後のDevOps時代に生み出された最も重要な技術的達成だと位置付ける人も多く、より具体的で分かりやすい継続的デリバリーという考え方をアジャイルの後継とすべきだという主張も見かけた。

まとめ

以上、#noprojects の考え方を概観してみた。

プロジェクトは計画の別名だと言ってもよく、計画を軸にビジネスを進めると本当に重要な価値の追求よりも計画の履行を優先してしまうことになる。#noprojects の問題意識をひと言で言えば、そんな感じになるだろうか。計画・施行のモデルは、同じようなプロダクトを作り続ける事に意味があった20世紀型のビジネスモデルであり、21世紀の今では発見的な手法に移行しなければ新たな価値を生み出す事は出来ない。その意味で、本来は技術者よりも、経営者やマネジメントがアジャイルや #noprojects のような手法を理解しなければならないはずである。しかしながら、マネジメントの利害を考えると #noprojects が世の中の大勢を占めるトップダウン型の企業に浸透するとは到底思えない。これまでプロジェクトマネジャーが担当していた責任をチームに委任することになり、マネジメントの役割は大きく変わる事になるからである。

プロダクト開発とアイデア信仰

先週の記事で紹介したスティーブ・ジョブズ氏のインタビュー。その中で彼は、パーソナルコンピューティングやオブジェクト指向開発だけでなく、ジョブズ哲学を総括するかのように実に様々な話題について自説を展開している。その中でも特に興味深いのが、プロダクト開発における「アイデア」の位置付けについての話だ。

この中で、インタビュアーはジョブズ氏に対して「プロダクト開発において重要なことは何か?」と聞く。ジョブズ氏はしばらく考えた後、そのインタビューの10年前、1985年に彼をアップルから追い出したジョン・スカリー(John Sculley)氏の話をする。

ジョブズ氏によれば、彼がアップルを去った後、スカリー氏は深刻な病に冒されていた。その病とは「素晴らしいアイデアを手に入れたら、それで90%の仕事が完了したと思い込む」ことだと言う。

しかし実際には、素晴らしいアイデアと素晴らしいプロダクトの間には気が遠くなるような craftmanship(職人芸)の集積がある。そのような集積を経て実現したプロダクトは、スタート地点のアイデアとはかなり異なるものになっている。その変化(発見)を可能とする数限りない試行錯誤、トレードオフにまつわる決断、このようなプロセスこそがプロダクト開発の魔法なのだとジョブズ氏は言う。

この気づきの有無は、この話の前に出てくる、marketing (or sales) people と product people の話題にも関係している。ジョン・スカリー氏はペプシコーラのプロモーションで大成功を納めた人物だ。この分野の人物が craftmanship やプロダクト開発の魔法を理解するのはなかなか難しいのではないかと想像できる。これら職能間の断絶は深く、2016年の今でも、プロダクト開発におけるアイデアの重要性について疑う人はそれほど多くないように見える。

ジョブズ氏のインタビューから15年以上経った2012年、似たようなことを主張している記事を見かけた。アメリカを拠点とするコンピュータ科学分野の国際学会 ACM(Association for Computing Machinery)の機関誌「Communications of the ACM」に掲載された「The idea idea」という記事である。

著者は、高名なコンピュータ科学者であるピーター・J・デニング(Peter J. Denning)氏。

デニング氏の問題意識は、現代の我々はアイデアの重要性を信じて努力を継続しているため、アイデアの獲得には苦労していないが、それを実際のイノベーションに繋げる段階になると極端に成功率が下がるのは何故なのか? ということであった。実際の成功率は4%ぐらいに過ぎないのだと言う。

彼は、イーサネットを発明したロバート・メトカーフ(Bob Metcalfe)氏が、コンセプトの発明にかけた労力よりも、それを普及させるのに費やした労力の方がはるかに大きかった経験を「花と雑草」にたとえた話を紹介し、重要なのはアイデアよりも実践の方なのではないかという仮説を展開している。

アイデアよりも前に、まず誰かによる実践があり、その実践に効果があると見た他の人たちがそれを真似する。しばらくするとその実践をより容易にするようなツールが開発され、その実践は更なる広がりを見せる。このようなプロセスを前提に考えると、「アイデアとは既に起こったイノベーションを説明するための後付けの理由」に過ぎなくなる。

デニング氏は記事の中で「氷山の一角」というアナロジーを紹介している。プロジェクト全体の中でアイデアというのは氷山の一角に過ぎず、海中に沈んでいる多くの部分がイノベーションにとって重要な実践の部分に当たる。そして、実践を継続することでアイデアの部分が氷山として浮き続けることが出来る。一方、盲目的にアイデアの重要性を信じてアイデアの獲得にコストを費やすと、このバランスが崩れてイノベーションの実現は難しくなる。

この記事が出てきた文脈には、ソフトウェア開発の世界で第一段階目の成熟を迎えつつあったアジャイルの影響があったと思われる。スティーブ・ジョブズ氏は、1995年の段階でその核心に到達していた数少ないビジネス界の人物だったと言えるのかもしれない。

このような考え方は、さらにクリエイティブな領域に行くとそれほど珍しい話ではなくなる。世界的な小説家であるスティーヴン・キング(Stephen King)氏は、彼の作家人生を記した自伝的著書「On Writing: A Memoir of the Craft」の中で、自身の興味深い小説技法について説明している。

on-writing

彼は「プロット」を信じていないという。プロットは小説における設計書のようなものだ。

I distrust plot for two reasons: first, because our lives are largely plotless, even when you add in all our reasonable precautions and careful planning; and second, because I believe plotting and the spontaneity of real creation aren’t compatible … I want you to understand that my basic belief about the making of stories is that they pretty much make themselves. The job of the writer is to give them a place to grow (and to transcribe them, of course). (p.159)

我々の人生にはそもそもプロットがないこと、そして真のクリエイションに備わっている spontaneity(自発性)とプロット(計画)はそもそも相性が悪いこと。そして、キング氏によれば、ストーリーは、適切な場を与えさえすれば自然発生的に育つものだと言う。

I told the interviewer (Mark Singer) that I believed stories are found things, like fossils in the ground, he said that he didn’t believe me. I replied that that was fine, as long as he believed that I believe it. And I do. … Stories are relics, part of an undiscovered preexisting world. The writer’s job is to use the tools in his or her toolbox to get as much of each one out of the ground intact as possible. (p.160)

キング氏は、ストーリーは発見するものだと考えている。地中に埋まっている化石のように。それは遠い昔に存在した、未だ発見されてない世界の遺品のようなものである。そして作家の仕事は、自分が持てる道具を駆使してそれらの遺品を出来るだけ無傷で掘り起こすことだと言う。

オブジェクト指向とは何だったのか?

このブログでも何度か取り上げているように、プログラミングにおけるここ数年間のトレンドで最も大きなものは、関数型プログラミングの隆盛だと言って良いだろう。そのトレンドと共に相対的に存在感を失いつつあるのが、それまで長らく主流を占めていた「オブジェクト指向」という考え方である。関数型プログラミングの観点から眺めると、オブジェクト指向プログラミングではシステムの状態を暗黙に扱う(情報隠蔽)ために実行時の挙動が予測しづらくなり、高度な並行性が求められる現在の環境では、信頼性を確保する際の大きな障害となるように見える。

しかし、筆者も含めて、オブジェクト指向という考え方にあれだけ熱狂した立場から考えると、昨今のオブジェクト指向に対する評価に対して若干の違和感を感じざるを得ないのも事実である。というわけで今回は、オブジェクト指向の発案者による発言を参照しながら、改めて「そもそもオブジェクト指向とは何だったのか?」ということについて考えてみたい。

まず始めに「オブジェクト指向」という言葉の意味については、どこかに正式な定義が存在する、というわけではないようだ。これは「関数型」についても同様のようである。なので、このブログで書かれていることはある種の解釈や立場表明をしているに過ぎないということに注意して頂きたい。

メッセージング

「オブジェクト指向(object-oriented)」という言葉を最初に提唱したのは、Smalltalkというオブジェクト指向環境を発明したアラン・ケイ氏だと言われている(これは本人も認めている)。

When and where was the term “object-oriented” used first?

At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me what I was doing, and I said: “It’s object-oriented programming“. – Dr. Alan Kay on the Meaning of “Object-Oriented Programming” (強調は筆者)

そのアラン・ケイ氏によれば、オブジェクト指向で最も重要なのは「メッセージング」なのだと言う。

Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea.

The big idea is “messaging” – that is what the kernal of Smalltalk/Squeak is all about – Alan Kay On Messaging (強調は筆者)

上記引用にもあるように、ケイ氏は「オブジェクト(指向)」という言葉を持ち出したことに後悔さえしていると言う。メッセージングの観点から言えば、クラスやオブジェクトさえも重要ではないということから、本来は「メッセージ指向」と呼ぶべきだったのかもしれない。

さて、このメッセージングであるが、オブジェクト指向の発案者によってその重要性が強調されているのにも関わらず、職業プログラミングの主流を占めていた C++ や Java でオブジェクト指向を実践してきた多くのプログラマにとっては、むしろ馴染みの薄いものではないだろうか。

ケイ氏は、オブジェクトを、ネットワークを形成してメッセージを送り合うコンピュータのメタファーとして捉えており、インターネット上のサーバーのように、リクエストをメッセージとして受け取り、そのメッセージをサーバー側で解釈して何らかの処理を行うというモデルを想定していた。オブジェクトへのリクエストという意味では、C++ や Java のメソッド呼び出しがメッセージングに相当するように思われるかもしれないが厳密には異なる。ケイ氏の開発した Smalltalk では、このメッセージを非同期にやり取りするという、今まさに広がりを見せつつある並行処理のモデルを70年代の段階で実現していた(後にアクターモデルと呼ばれる)。しかし、その Smalltalk においても、ある段階から現在主流になっている(メソッド呼び出しと同等な)同期的な呼び出しに移行し、その後も「メッセージ」のような用語が維持されたためにメッセージングにまつわる誤解と混乱が生じた、という経緯があったようだ(参考: Alan Kays Definition Of Object Oriented)。


[2016/05/09追記]
この部分に事実誤認があるとの指摘をコメント欄にて頂いた

「ケイ氏の開発した Smalltalk では、このメッセージを非同期にやり取り」については、

Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as “messages” for what essentially are procedure calls rather than one-way notifications). – Alan Kays Definition Of Object Oriented

この言及だけを参考にして書いてしまっていたのだが、

アラン・ケイらの Smalltalk-72 が大きな影響を与えてはいますが(https://www.cypherpunks.to/erights/history/actors/actor-induction.pdf の Acknowledgements 等)、アクターモデル自体はカール・ヒューイットの考案であり、Smalltalk や ケイのメッセージングとはまた別物です。念のため、ケイの関わった Smalltalk(-72、-74、-76、-78)は非同期のメッセージングベースで実装されたことはありません。 – コメント欄(sumimさん)より

とのこと。ご指摘感謝!

[2016/05/10追記]

さらに別の方からコメントを頂く。

Actor Model自体がCarl Hewittの考案であり、Kayのメッセージングとは「別物」ということですが、歴史はしばしばもうちょっとややこしいものです。私が見聞きしたか限りにおいては、KayがMITに行ってSmalltalk-72に関する講演を行った時に、実際の実装とは別に元々のアイディアとして「ネットワークで接続されたオブジェクト群がメッセージを交換しながら計算を行う」という話をし、その時に聴衆にいたHewittがActor Modelの着想を得た、という経緯もあります。Actorの当初の論文には謝辞としてAlan Kayの名前があるもの、それ以上のクレジットがなかったために、Carlが「コミュニティー」からもうちょっとアイディアの出典を正直に述べなくてはならないという批判を受けることになったという話もあります。 – コメント欄(よしきさん)より

Smalltalk に興味がわいた方は、sumim氏による Smalltalk-72 入門も是非ご参考あれ。


messaging

このメッセージングに関係して、最近タイムリーなブログ記事を見かけた。メッセージングを実現している環境として、実は Erlang/Elixir が最もアラン・ケイ氏のオブジェクト指向を体現している言語環境なのではないかという考察である。ちなみに、この二つの言語は一般的には関数型プログラミング言語として認識されているはずである。

この記事の中で紹介されているように、Erlang の開発者である Joe Armstrong 氏が「Erlang が最もオブジェクト指向に近い言語である」という趣旨の発言をしているようだ。

しかし、何故メッセージングが最も重要なのだろうか? それは、メッセージングという仕組みの内に、ケイ氏が考えるオブジェクト指向の要点が全て含まれているからである。ケイ氏は、メッセージングの位置づけを日本語の「間」という言葉で説明しているが、氏によれば、システムの「間」つまりコミュニケーションに着目することによって、システムにとって重大な目的(ゴール)だけを表現し、その他の詳細については二次的に決定すれば良い、そしてそのような決定の先送りがシステムの寿命を延ばす鍵になるのだと言う。メッセージがどのように解釈されるのか、クラスから作られたオブジェクトによって処理されるのか、そのクラスは継承によって構造を共有しているのか、あるいはプロトタイプベースなのかという問題は全て二次的な問題である。

出来るだけ多くのことを「work in progress」として扱うことによって進化してきた Smalltalk は、ある段階からあらゆることを決定し固定化したがる人たちによって不毛な議論が繰り返され、その結果、進歩が停滞しているとケイ氏は苛立ちを見せていた。この「work in progress」の考え方は、21世紀になってから普及したアジャイルの考え方そのものである。アジャイルはオブジェクト指向のコミュニティが生み出したものであるが、その考え方の源流はオブジェクト指向の始まりから既に埋め込まれていた。

抽象データ型

ここまでの話で、オブジェクト指向の発案者であるアラン・ケイ氏の、メッセージングという真意が明らかになった。しかし、これだけでは職業プログラマの多くが実践してきたオブジェクト指向らしきものは一体何だったのかという疑問が残る。

One of the things I should have mentioned is that there were two main paths that were catalysed by Simula. The early one (just by accident) was the bio/net non-data-procedure route that I took. The other one, which came a little later as an object of study was abstract data types, and this got much more play. – Dr. Alan Kay on the Meaning of “Object-Oriented Programming”

上記引用のように、ケイ氏は、オブジェクト指向の起源となった Simula という言語からは、ケイ氏の主張する「the bio/net non-data-procedure route」の他に、「抽象データ型」を中心に据える流れも起こり、こちらの方がむしろその後主流になったと説明している。抽象データ型の流れは、C++ や Java に引き継がれ、最近では Scala など、いわゆる静的型付け(static typing)として職業プログラマの間では主流になった。

ケイ氏の考えとしては、抽象データ型系列の C++ はオブジェクト指向としては認識していないようであるが(「”I invented the term object-oriented, and I can tell you that C++ wasn’t what I had in mind”」)、型システムそのものについて否定的に見ているわけではないようである。

I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing. – Dr. Alan Kay on the Meaning of “Object-Oriented Programming”

クリエイティビティ

さて、結果的に抽象データ型が主流になったのあれば、それがいわゆる多くの人が認識するところのオブジェクト指向なのだから、今更「アラン・ケイ氏のオブジェクト指向」についてわざわざ考慮する必要があるのかと考える人もいるかもしれない。しかし、筆者にとってこの二つの立場の違いは、単にプログラミング言語の差異に留まらず、コンピューティングというものに対する立場を二分する大きな断絶を象徴する分岐であるように思えるのである。

抽象データ型というのは、単にプログラミング言語の問題である。あるいは、システム開発者側の問題だと言っても良いかもしれない。例えば、開発側の観点から仕事上のトラブルを少なくするといった、よりプラグマティックな理由から型システムという仕組みを評価できるだろう。職業プログラマの間で型システムが普及した理由にはこのような側面もあったのではないだろうか。

しかし、アラン・ケイ氏による1993年の論文、オブジェクト指向が生まれる過程が仔細に書かれた「The Early History Of Smalltalk」を読むと、オブジェクト指向は単にプログラミングだけの問題ではなく、もっと壮大な理想を追求するために考案されたのだということが分かる。

オブジェクト指向が生まれる直前の60年代という時代は、コンピュータが、予め計画された計算を行うだけというイメージの、一つの部屋を専有する巨大な機械から、もっと人間の力を高める形でインタラクションを提供する新しいメディアへと生まれ変わろうとする、いわゆるパーソナルコンピューティングの黎明期に当たる。そして、そのような運動の中心にあったのが、ARPA(Advanced Research Projects Agency)というアメリカ国防総省管轄の研究機関である。ARPA はインターネットの原型となった ARPANET を開発したことでも知られる。

このパーソナルコンピューティングを模索する流れの中で、アラン・ケイ氏が立ち上げたのが Dynabook 構想であり、この構想には今日では当たり前になっているパーソナルコンピュータやネットワーク、GUI(ウィンドウシステム)など、パーソナルコンピューティングにとって重要なあらゆる要素が詰め込まれていた。

パーソナルコンピューティングの主題は、コンピュータを使っていかに人間の能力を高めるか(「Amplify human reach」)ということであったが、これは言い換えれば「クリエイティビティ(創造性)」の追求である。ケイ氏が最も熱心に取り組んでいたのはコンピュータを使った子供の教育であった。オブジェクト指向プログラミングを子供に教えることによって、ソフトウェアを自身の問題に合わせて自在に変更出来るようにし、より高い問題解決能力を獲得させることを目指した。

この教育プロジェクトの試行錯誤によって得られた知見には大変興味深いものが多い。例えば、Smalltalk がクリエイティビティに寄与する一つの根拠として、より少ない原則で多くを表現できるというものがある。有名な「Everything is an object」というやつである。後のケイ氏であれば「Everything is a message」と言ったかもしれない(そのようなプログラミング言語が実際に存在する)。この全てがオブジェクトであるという原則と、大きなシステム(オブジェクト)は小さなシステム(オブジェクト)の組み合わせで作られるという「再帰的デザイン」によって、どんな複雑なシステムをデザインするときでも、覚えなくてはならない原則は少なくて済むようになる。さらに Smalltalk において重要なのは、システムを使うという行為と作るという行為が全く同じになるということである。システムを使うときと全く同じ操作で、その延長線上でシステム自体を変更することができる。このように、導入において覚えることが少なくて済む、そしてその少ない道具立ててであらゆることが表現できるという枠組みが、子供の教育にとって重要であることは想像に難くない。しかし、実際に試してみて分かったことは、あるオブジェクトにメッセージを送るという1ステップの変更については小さな子供でも理解することが出来るが、複数ステップの変更を組み合わせないと解決できないような問題になると、それがほんの2、3ステップだったとしても極めて難しくなってしまうということだった。これは子供だけでなく、プログラミング経験のない大人でも似たような現象が見られたようである。初歩の問題は容易にクリアできるが、問題が複雑化すると、それがプログラマから見たら些細だと思われる問題でも全く歯が立たなくなる。これは今で言うプログラムデザインの問題である。このデザインの教育に対応するためにケイ氏の同僚である Adele Goldberg 氏が「design templates」という仕組みを考案した。これはぼんやりとしたデザインのアイデアとプログラムによる実例の中間に位置する道具立ててで、今で言うところのデザインパターンやフレームワークに相当するものである。

ケイ氏は、このような大きなビジョンを掲げることの重要性について、そして出来るだけ多くを「work in progress」にすることの重要性について繰り返し語っているが、それはいかに多くの技術者や専門家が手段に埋没し、そして宗教論争に明け暮れているかということに対しての警鐘にもなっている。

スティーブ・ジョブズ

「The Early History Of Smalltalk」の一つのハイライトは、1979年、ケイ氏の勤めるパロアルト研究所(PARC)に、あのスティーブ・ジョブズ氏が訪れる場面である。当時のジョブズ氏は77年にアップルコンピュータを設立したばかりで、次世代のパーソナルコンピュータを生み出そうと Lisa プロジェクトを立ち上げていたが、決定的なアイデアがなく模索中の段階であった。ケイ氏は、PARCに訪れたアップルの面々に対して、ALTOというパーソナルコンピュータ試作機のデモを行う。ALTO には Smalltalk による OS が搭載されており、その上ではウィンドウベースのGUIが動いていた。

Xerox Alto Computer
Xerox Alto Computer

そのデモの最中、ジョブズ氏は、試作機で動いていたウィンドウシステムのスクロールをもっと滑らかな方式に変更出来ないかと指摘し、開発者の一人である Dan Ingalls 氏がその場で修正して訪問者を驚かせたという場面が紹介されている。Smalltalk 環境の強力さが垣間見えるエピソードである。

この邂逅の後の歴史は多くの人の知るところなのでここでは深追いしないが、1995年に行われたインタビューにおいて、ジョブズ氏がパロアルト研究所で見たデモについて、そしてその当時は理解出来なかったというオブジェクト指向の重要性について語っているので、その動画を紹介しておきたい。

この映像は放送後に一度紛失したと思われたマスターテープがジョブズ氏の死後に偶然見つかったということで、95年の放送時はカットされた部分も含めて全編放送されたものであるが、その内容にはただひたすら圧倒されるのみである。

このインタビューの中で、1995年当時、今後10年間で最も重要だと思われるテクノロジーとして、ジョブズ氏はオブジェクト(指向)と Web の二つを挙げている。

そして現在

オブジェクト指向についてその起源から検討してみたが、この歴史を前提に改めて考えてみると、昨今言われる「オブジェクト指向から関数型へ」という話が大分狭い領域の話であることに気づかされる。モジュールシステムの進化という観点から言えば、関数型プログラミングが有効である場面が増えているのは疑いようがない。しかし、より大きなスコープで考えるとオブジェクト指向の考え方は依然として重要であり、将来的には、以前紹介した「Functional in the small, OO in the large」という形で適材適所に住み分けることになるのではないだろうか。

そして、アラン・ケイ氏のオブジェクト指向という観点からより視野を広げて考えると、その枠組みにおいてオブジェクトはプログラミング言語とは切り離されたメタファーあるいはコンセプトに過ぎず、メッセージや遅延束縛(late binding)と言ったコンセプトは形を変えてあらゆる場面で見かけるようになった。その代表的なものの一つが、アジャイルという考え方である。オブジェクト指向はその出自から考えても分かるように、より上流の考えを重視する目的指向のパラダイムである。アジャイルはその後、経営やデザインなど、ソフトウェア開発の枠組みを超えて、クリエイション一般に適用出来るような普遍的な考え方として普及しつつある。

プロダクト開発とアイデア信仰 | ゆびてく

ビジョンを曇らせる誘惑: 技術偏重、一貫性

James Hague (@dadgumjames) 氏は、少年時代に一世を風靡した『パックマン』などのゲームに影響を受けてプログラミングを始めた。高校時代にはコンピュータ雑誌の常連投稿者として活躍、大学卒業後もゲームプログラマーとしてSNES(海外版のスーパーファミコン)向けのゲームを開発した。当時はアセンブリ言語で開発していた彼も、次第にマンネリを感じて高級言語を物色し始め、丁度その頃オープンソース化された Erlang で関数型プログラミングの門戸を叩いて今に至る。

パックマン from Wikipedia

そのようなキャリアを持つ彼が、長らくプログラマとして活動する内に気がついた事があると言う。それは、いつの頃からか新しいアプリケーションをデザインする時には、技術的・実装的な見地から逆算的に物事を考えるようになり、ユーザーやプレイヤーの観点から完成品を想定することが少なくなっていたということだった。

技術者は長くその専門領域に棲息するうちに、その領域の尺度だけで物事の良し悪しを判断するようになる。技術者のコミュニティでは、そのような尺度の元に序列付けが行われて、個々の技術者にプレッシャーを与え続ける。その結果として、何のためにそのアプリケーションを開発するのかということは脇に置かれ、パフォーマンスやプログラムデザインのような技術的達成が優先的に考慮されるようになる。

Hague 氏がプログラミングを始めた頃、プログラミングは彼のビジョンを実現するための道具に過ぎなかった。しかしそれが、プログラミング自体にのめり込むにつれて次第に自己目的化してしまった。そのねじれを解消するために、もう一度原点に戻ろうという思いがこの The Recovering Programmer というタイトルに込められている。

前回の記事「TDD再考 (8) – 凝集性(cohesion)とは何なのか?」で紹介した論理的凝集と機能的凝集の対立もこの問題と密接に関係している。アプリケーションの目的から考えれば機能的凝集を目指すべきところでも、油断すれば技術偏重に陥り、論理的凝集を優先してしまうことになる。そしてこの問題は Hague 氏だけでなく、このブログでも紹介してきたように、ビジネスと技術の対立を解消すべく現れたアジャイルムーブメントによってもフォーカスされてきた。特にその流れの中で提案されたドメイン駆動設計(Domain-driven design, DDD)は、機能的凝集に集中するための方法論だと考えると分かりやすいかもしれない。

アジャイルが指摘したのは、機能的凝集は動くターゲットであるということであった。それまでのソフトウェア開発で念頭に置かれていたような静止したゴールは存在しない。継続的に効果を得るためには、ユーザーとのインタラクションを重ねて、ユーザーにとって意味のある「文脈」を構築していかなければならない。

デジタルマーケティングの世界で長年活躍してきた Joanna Lord (@JoannaLord) 氏は、ブランドマーケティングの観点から、一貫性への過剰な執着がブランドの機能的凝集(coherence)を損なう要因になり得ると指摘する。

彼女によれば、ブランドの一貫性とは、裏を返せばそのブランドが変化せず、(環境が変わっても)常に同じ体験を提供し続けるときに実現されるものだと言う。コメント欄で指摘されているように、コカコーラのような長い歴史の中でブランドが確立しているようなケースではその一貫性を維持する理由があるが、現代の状況の中で新しいブランドを構築していかなければならない場合、一貫性より機能的凝集を目指さなければ生き残りは難しい。

一貫性というのは分かりやすい価値であるが故に過剰に追求されやすい。そして、一貫性を保とうとすれば、新しいアイデアを試したり、大胆な変更を行う事に対して臆病になってしまう。その結果としてユーザーにとっての価値、つまり機能的凝集が時間とともに失われてしまうことになる。