Archive for 2011年4月

エリックとリンダと僕らの世界

4月 15, 2011

Not all of a large system will be well designed
(大規模システムのすべての部分がうまく設計されているわけではない)

4月13日、EricEvansのチュートリアルでDomain Driven Design(以下、DDD)を学ぶなかで、この言葉こそがDDDにおける核心の1つだと感じた。

あまりに大きなシステムは、全体的な調和を保つことはできても、全体をつくる個々のすべてのシステムでは、最適な状態を保てないのだ。

DDDにおいて、このシステム観は重要だ。
だからこそ、汎用サブドメイン、支援サブドメイン、コアドメインの3つにシナリオ(といってよいのだろうか)をわける。
そして、ビジネス的に価値が高いコアドメインに注力する。

必要だけれども、コアドメインとは異なり企業の競争力につながらない、ビジネス価値の低い、汎用サブドメインや支援サブドメインは外部調達などによってまかなおうとする。

自分たちのリソースを、コアドメインに自ら注力することこそが重要だと考えているのだ。

僕はさほど多くのシステムを観てきたわけではないが、「すばらしい設計だ」と思わされたシステムは少ない。

ひどいプログラムや設計で作られたシステムに出会うと、先々起こるであろう、システムのバグの改修や変更への対応を考えて気が重たくなる。

そして、そんなシステムを創り上げた誰かに同情しながらも、腹をたてる。

しかし、僕は大きな勘違いをしていたのかもしれない。

そもそも、僕は、自分の関わるすべてのシステムがユーザーに必要とされ、なおかつ重要だと思い込んでいたのだ。

自分が創り上げようとしているシステムは、DDDでいうところのコアドメインに当たるシステムだと思い込んでいたのだ。

僕はもっと疑問をもつべきだった。

いままで僕が携わってきたシステムのどれだけが、顧客にとってのコアドメインとなるシステムだっただろうか。

そして、顧客にとってビジネス価値が高く、競争力の源となるビジネスを可能とするシステムだっただろうか。

システムを外注するユーザー企業からすれば、会社というシステムなかの、さらにプログラムで作られたシステムの一部でしかない。

そんなシステムを僕はつくってきたのかもしれない。

そうであるならば、僕が携わってきたいくつかのシステムの設計が洗練されたものでないとしても、仕方のないことかもしれない。

それは戦略的に選択されたシステムの姿だったのかもしれない。

もちろん、僕が見てきた大抵のシステムのプログラムの汚さやシステムの低品質さは、それを言い訳にはできないものだったけど。

大規模なシステムはすべてを完璧に設計し、維持することはできない。
DDDはそのことを大前提として、重要な部分に集中するのだ。

大きなシステムは、その全体を作り上げている個々のすべてのシステムに注力し、洗練させることは難しいのだ。

チュートリアルを受けたあと、DDDで学んだ大きなシステムを設計し、創り上げることの難しさを改めて考えさせられる話を聞いた。

その話をしてくれたのは、組織を変化させるために利用できるパターンをまとめた『FearLessChange』の著者の1人、Linda Rising だ。

Ericのチュートリアルのすぐあとに、Lindaと出会うという幸運を得たのだ。

その席で、Lindaから、9.11のあとのアメリカで起こった出来事について聞いた。
9.11において、飛行機が高層ビルに飛び込む姿を繰り返しテレビで見ることになったアメリカの人びとは狼狽した。

結果、何が起こったか。
交通事故により死亡する事件が多発したのだ。

飛行機の乗ることを恐れた人びとの多くが車での移動を選んだ結果だ。
そして、アメリカの人びとが恐れたテロリストたちよりも一般の人びとにより、多くの死がもたらされることになった。

個人が最適だと思った方法は、アメリカという全体では、とても大きな問題を引き起こしたのだ。

この現象から、個々の動きが複雑に絡み合う国家という大きなシステムの姿が垣間見える。

翻って、今、大きな地震の被害をうけた日本もおなじだ。
僕も、大きな地震で一部の地域が崩壊したことで、生まれた歪をみたことで、日本が1つの大きなシステムであることを再確認した。

首都圏で使用できる電力は減り、ヨーグルトやタバコは手に入らず、西日本でも電車の本数が減らされている。

日本は大きなシステムであり、一部の地域の崩壊は、日本という大きなシステムを確実に壊したのだ。

EricやLindaの祖国アメリカがそうであるように、日本も3.11以前に戻ることはない。
日本という大きなシステムで壊れた部分は、元通りなることはなく、確実につくり直される。

ならば以前よりも良くしたい。

そのためにも、DDDがビジネス価値に集中するように、日本というシステムにとって価値のあることに集中して、僕らは日本という国を復興、再構築する必要がある。

そして、日本にとって一番、価値があることを発見するためには、今の日本を前向きに見つめ直して、良い点を探し出す必要がある。

Lindaはいっていた。(と思う。英語が苦手ですんません。)
世界をどのように観るか、それが大切だと。

世界を失望のまなざしで見つめていたら、きっと世界を良くすることはできない。
「なにかよいことはないだろうか」という前向きな心で世界を眺めれば、どこかに希望が見いだせる。

ありきたりな認識論かもしれないが、大切なことだ。

いままで、自分の周囲が平和で満たされていたからこそ、世界のうまく設計されていない部分を見過ごしてきた。

それでいて、失敗が分かりやすい、うまくいっていない部分にだけ集中して批判ばかりをしてきた。

経済も、社会保障も、政治も、スポーツも、うまくいっていない部分をあげつらい「日本はダメだ」と言ってきた。

もうそろそろ、世界のすべてがうまく設計されていない、設計されない、という現実に目を向けるときだ。

しかし、その現実に失望するのではなく、前向きで希望をこめた視点で注力すべきところを探す。

すべてにおいて良くあろうとするのではなく、自分たちがより良く生きるために、どこに注力するべきかを戦略的に選択し、注力する。

DDDというシステム設計と『FearLessChange』の著者の考え方から、システム開発の領域を超えて、これから僕が世界とどのように関わってゆくべきか、生きるための知恵を学んだ。

広告

必要かつ重要なデザインを仕事にする

4月 12, 2011

5年後にはシステムデザイナーと呼ばれ、仕事をしているようになりたい。
本日をもって30歳になった僕の夢だ。

もしかしたら、僕がなりたい職業は、アーキテクトという存在なのかもしれない。
でも、僕はシステムの設計を専門として活躍できる存在なりたい。
だからこそ、既存のアーキテクトという言葉ではなく、システムデザイナーと名乗りたい。

3月11日の東北・関東大震災は、自らを振り返る機会になった。
東京ではらたき、千葉に住まう僕も被災者だった。

もちろん、津波に家をのまれ、炎に家を焼かれて、命、家族、帰る場所を失った人たちとの温度差はある。
僕には疲れたり、落ち込んだりすれば逃げ帰れる家がある。
しかし、東北で大きな被害を受けた人びとの多くは、帰る家も、慰めあう家族もない。

ただ、生まれて初めて経験した大きな地震に僕は命の危機を感じた。
そして、人生、とりわけ今の仕事の価値を見つめ直すようになった。

自分の今の仕事に価値はないのではないか。
今後、本当に今のままの仕事をつづけてゆくだろうか。
そもそも仕事という存在は自分のなかでどのような存在感をもつのだろうか。

今でも悩んでいるし、考えている。
自分がいったいなにがしたいのか。

そんなもやもやを抱えて、2011/04/9(土)にDevLOVEのDDD(Domain Driven Design)のイベントに参加した。
そして、印象深い2つの言葉に出会った。

1つは「世界を端的に変えるのは政治家かデザイナーかディベロッパー」
もう1つは「実装は必要。設計は重要」という言葉だ。

僕はこの2つの言葉を聞いて、デザインとそれを専門とするデザイナーの重要性を改めてかみしめた。

デザイナーは世界を変える。
そして、世界を変えるのはデザインという企てだ。

システムの世界において、プログラミングとプログラマは王様だ。
社会的な地位や評価は別として、情報システムの開発に携わる人々にとって、優れたプログラミングのスキルとそれを実践するプログラマは憧れの的だ。

プログラマやプログラマに憧れる人々にとって、いわゆる上流工程にのみ関わり、要求定義や基本設計しか行わない、プログラムに見向きもしないエンジニアは軽蔑の対象だ。

そんな人びとからみれば、デザイン、設計に大きな価値をおいた「実装は必要、設計は重要」という言葉には違和感をもつかもしれない。
しかし、この言葉は事実を表現している。別に実装を軽視しているわけではない。
実装、すなわちプログラミングとは、優れた設計の実現なのだ。
だからこそ、設計が重要なのだ。

そしてまた、設計は実装に制約を受ける。
実現方法によって、デザイン、すなわち理想の姿が制限を受けるのは当然のことだ。
だからこそ、デザインに携わる人だったら、実現方法であるプログラミングを知らない、という状況は許されない。

制約があるなかでいかに目的を達成するか、ということもデザインの1つの要素だからだ。

なにより、優れたプログラマは、実現方法のプログラミングのみならず、実現すべき姿を描くデザインの能力も優れている。
だからそ、優れたプログラマが産み出したプログラムは、価値がある。

僕は優れたプログラマではない。
そう名乗るには圧倒的にプログラミングの経験が少ない。

だから、優れたデザインを生み出すために、僕は歯を食いしばりながらプログラミングを勉強する。
もちろん楽しめればそれに越したことはない。
ただ、今の自分ではプログラミングを楽しむまではないかない。

そしてまた、僕はシステムのデザインについて勉強する。
こちらも歯を食いしばりながら、になるかもしれない。

なにより、協力してくれる人たちを巻き込んだり、お金を集めたり、プログラミングとデザイン以外のさまざまなことをできるようにならなければいけないかもしれない。

イバラの道かもしれない。

ただ、僕には2つの言葉にもらった信念がある。
迷いながらも、信じられる言葉がある。

情報システムは、世界を変える力をもっている。
そして、そのシステムをデザインするとは、世界をかえる企てだ。

システムのデザインを通じて世界を変える。
システムデザイナーという存在に、いま僕はなりたいと思っている。

躓くことを前提とした仕事の仕方を覚えた(ような気がする)

4月 5, 2011

今までのプロジェクトには正解があったのだ、と最近、ふと思った。

僕が経験してきたプロジェクトの大半は、既存システムの改修、もしくは既存システムにつながる新規システム開発だ。
技術はレガシーで、汎用機の上にCOBOLとNATURALという言語でアプリケーションをつくりあげる。

10年以上も続いてきたプロジェクトだから、お客さんとの付き合いもほぼ完成されていた。
もちろん、僕がそうであるようにお客さんにも新人さんが入ってくることもあったようだ。
しかし、10年も続いているプロジェクトでは、新しい風が既存の文化や慣習を吹き飛ばすことはない。
新しい風も、ゆっくりと、10年間で培われた文化と慣習に取り込まれてゆく。

技術も人間関係もレガシー、枯れていたのだ。
技術でも、人間関係でも枯れている良さというものがある。

それは、正解がある、ということだ。
技術にも人間関係にも本来的に、正解はないはずだ。
しかし、長い年月はないはずの正解を作り上げる。

技術にしろ、人間関係にしろ「本質的に正しいか」ということは横においておき、慣れが生まれ、決まりきった手順や方法が確立される。
その手段が最適か否かは横において、とにかくそこに到達することはできる、という意味での正解がある。

僕は今までそうした文化に親しんできた。
こうした文化に親しむ利点はもちろんある。

それは注意深く、テストでもするかのように慎重に行動する習慣が身につく、ということだ。

汎用機の開発をしていると、早く動かして早く間違いを発見して修正する、というアプローチは取りづらい。

むしろ、最初からバグを含めないように、仕様に過剰な誤りがないように、慎重にチェックをするアプローチを取る。
良くも悪くも一発勝負、という感覚があるからだ。

なにかやるにしても「これで間違いはないだろうか」という思考が強くなる。

デバックはかなり手間なので、バグをそもそも含めないように、頭と紙の上でロジックを整えてから、プログラムを書いてゆく。
インテリセンスなど聞かないので、打ち間違えないように慎重に打ち込んでゆく。

また、ロジックもエラーから潰してゆくことを第一にプログラムを書いてゆく。
インプットで予想されるエラーをすべて潰したあとで、業務のロジックを追加してゆく。

便利なデバッガ、ユニットテストツール、構成管理ツールが存在する現在のプログラミングとは真逆なアプローチだ。

ひるがえって、今のプロジェクトは、躓くことを前提として行動することが要求される。
今まで使ったことがないアプリケーション、開発に携わっていないシステム、僕が把握できていないことがたくさんある。

こうした状況では正解、「こうすればたどりつける」という確立された方法はない。

お客さんはそうした状況に僕がいることは知らない。
そして、もし知っていたとしてもそんなことは関係ない。

だから、お客さんが要求を出すペースは変わらないし、僕は可能なかぎり応える必要がある。

お客さんの要求に対処するには、答えにたどり着ける確実な方法をつくってからとりかかろう、今までのアプローチは役に立たない。
確実な方法がわからないからできません、という応答をお客さんは期待していない。

自分としても、やったことがないことをやる前に「正解」を作りあげることは不可能だ、ということに気づく。
とりあえず、ほとんど何もわからないけど、とりあえず着手する。
もちろん、最初は何から手をつけて良いかわからないし、当然、失敗する。

どこでつまずくかわからないけど、自分がつまずくことはわかる。

だから、DBもプログラムもバックアップを取っておく。
もとに戻せることが約束されていばなんとかなる、そう思って先に進む。試してみる。

わからないことは、ネットで調べたり、人に聞いたり、知る方法はいくらでもある。
失敗したり、戸惑ったり、解決まで結論が二転三転したり、というつまずきを前提に行動しないと、結果を出すことはできない。

僕が以前、アジャイル開発の現場に行ったときに戸惑ったのは、実は、この点だったように思う。
周囲の人びとの作業が軽やかに進むのを横目に、僕の作業が進みづらかったことがある。
その原因は、事実、知識も経験も不足していたことにもある。
が、それ以上に、「つまずくことを前提に行動していなかった」点にあると思う。

おそらくあのプロジェクトのなかで、それぞれの人達にとっても、経験したことがないこと、知らないことがたくさんあったはずだ。
あのプロジェクトなかでも、チームに貢献していた人たちは、自分の知らないこと、わらかないことにも、ちゃんと挑戦していた人たちなのだと思う。

現在進行形の技術を用いながら、現在進行形のプロジェクトに携わるというとは、多くの未知な要素に関わるということだ。
そこでは確立された手法、正解をなぞることは、ほとんどできない。

むしろ、そうした方法を手探りで探してゆく、創り上げてゆくという態度と考え方が重要だ。
その根底にあるが、失敗やわからないことによるつまずきがあることを「当たり前」と考える心構えだ。

最近、新しいプロジェクトに携わるなかで、つまずきながらプロジェクトの進める心構えと方法を、僕は学んでいる。