変化のライフサイクル（メカAG）

今回はメカAGさんのブログからご寄稿いただきました。

変化のライフサイクル（メカAG）

最初に新しいことを始める人というのは、自分がどこへ進もうとしているのか自覚がないと思うのだよね。新しいことをしているという認識すらないかもしれない。単に目の前の問題をなんとか解決しようとしているだけ。

Windowsの技術にDDEというのがある。Dynamic Data Exchageの略で、もともとはWindowsアプリケーション間でデータのコピーペーストを便利にしようと開発された技術だ。ユーザは当たり前のようにExcelのデータをWordに貼り付けたりするが、それを実現するには、両者のアプリケーション間でデータをやりとりする共通のフォーマットや手順が定められていなければならない。

ファイルをドラッグ&ドロップすると別なアプリケーションに自然にデータが移動するのも、内部ではかなり複雑な処理だ。「簡単な見た目」を実現するための実装は非常に複雑。だから初期には色々バグもあった。

　　　*　　　*　　　*

DDEというのはそこからさらに発展して、動的なデータをアプリ間で共有できるという仕組み。Wordに貼り付けたExcelのデータが単なる複製ではなく、もとのデータとの関連が継続していて、もとのExcelのデータを書き換えれば、貼り付けたWordのデータも自動的に書き換わる仕組み。この時、Windowsの内部ではWordとExcelが複雑に連携して動いている。

DDEはその後OLE(Object Linking and Embedding)、COM(Component Object Model)、さらにネットワーク越しのアプリケーション通信のDCOM(Distributed COM)、COM+へと発展していった。いわゆる分散オブジェクト技術。オブジェクト(アプリケーション)同士が1台のパソコンを超えてネット越しに連携しあう。

分散オブジェクト技術は1990年代にCORBAとか盛んに研究された。でもDDEは1980年代の技術で、当時DDEを開発していたエンジニアは10年後にそれが分散オブジェクト技術に発展するとは思ってなかったと思う。単にWindows上のコピーペーストを一般化したかっただけで。

　　　*　　　*　　　*

真に新しいものというのは作ってる人間自身が、その意味をまだ自覚できていない。作っている最中は手探りで、それが後から振り返って分かるだけだ。ビル・ゲイツがAltair8800用のBASICインタプリタを作った時、それが世界最大のソフトメーカーの萌芽とは思ってなかっただろう。

先駆者が新しいものを誰かがつくり上げると、第2陣はそれを研究しようとする。先駆者が作ったものを自分なりに理解し真似ようとする人たちが出てくる。これもかなりの難行で、先駆者が迷い回り道をしながらなんとか辿り着いた目的地に、断片的なヒントだけを頼りに進んでいくわけで、簡単にできるものではない。

この過程で道が整地されていく。先駆者が切り開いただけの道はまだ獣道で普通の人が通れるような道ではないのだ。追従者が自分が通るためにそれを一生懸命整地していく。理論を体系化し整理し、邪魔な草を刈り取り、近道を発見し…。そうやって目的地に辿り着けるのは依然として限られた人だけだろう。

コンピュータの世界で言えば、「最近○○で、こんなことを研究している人達がいる」とか言い合ってる頃。でもまだ○○について書かれた本とかなくて、せいぜい論文がある程度。「興味があれば自分で情報収集したら?」みたいな、突き放した感じ(笑)。自分たちが先駆者に追いつくのが精一杯で、とても他人の面倒は見れない。でも「面白そうなことが起きてるよ」と最低限の情報だけは伝えるよ、と。

　　　*　　　*　　　*

第3陣は啓蒙を行う人々。この技術は素晴らしい、もっと広く人々に伝えなければと使命感に燃えた人達が現れ、本が書かれる。概念や考え方をどう説明すればいいか?とかの研究も行われる。一般のエンジニアが目にするのはこの辺りから。

導入方法の解説書が出てくる。それまでは「学びたい人」が自主的に学べばいいというスタンスの本だった。あくまで「学びたい」ならちょっとは手助けするよ、というスタンス。それが自主的に学ばない人に、どうやって技術を教育していくか?という段階になる。組織内でどういう段取りで導入していったかという実例とか。

だいたいは、最初は少人数のチームで始めて、それが成功したら、徐々に導入の範囲を広げていくみたいなことが語られるはず。従来の考え方とのギャップに悩む人をどう説明・説得するかとか、こういう問題は新しい方法ではどう処理するべきかとか。

当然新しい方法も利点だけではなく、欠点もある。従来の方法の方が処理しやすいケースもある。オブジェクト指向なんかもそうだった。オブジェクト指向プログラミングの場合、処理が各オブジェクトのメソッドに分散してしまい、流れがわかりにくくなる傾向がある。むろんトータルではオブジェクト指向の方が分かりやすいのだが、部分部分だけを見れば従来型プログラミングの方が優れていることも少なくない。そういう問題をどう克服していくか、とかのノウハウが蓄積されていく。

いまだとアジャイル開発とかがこの段階かな。アジャイル開発、その先駆であるXP(エクストリームプログラミング)も、発端はデスマーチの中から編み出されたノウハウを体系化したものだ。ウォータフォール型の計画が破綻し、それでもなんとか立て直さなければならない泥沼の中で、多くの人が場当たり的にやってきたこと。それまで誰もが邪道だと考えていたものを「あれ？もしかしてこっちのほう王道じゃね?」と考え方をひっくり返した。発想の転換。言ってみればデスマーチの渦中の開発者たちは自覚がなかっただけで、アジャイル開発を知らずに実践してたわけだ。

　　　*　　　*　　　*

第4陣、残された人たちをどう救済するか。「時代に取り残されないために」みたいな脅しのようなタイトルの本が出てくる。中身はもう子ども向けの本のように図解に継ぐ図解。ちょっと違うけど「2000年問題」の最後の方なんかがそんな感じだった。「最小限の苦労で」「だれでもできる」「いますぐ始めろ」と、なんかダイエット本みたいな(苦笑)。

ということで第3陣ぐらいが、一番ブームとして盛り上がる時期。こうして見ていけばわかるけど、どの段階も先駆者がいる。第1陣は本当の先駆者だし、第2陣も先駆者に追従しようとする人たちの先駆者が先ず始めるわけだ。そして第3陣の一般への導入もやはりそのノウハウを切り開く先駆者がいる。

どの段階の先駆者も前例がないことをやるわけで、試行錯誤の連続。成功する保証はないし、どれだけ時間とコストがかかるかも見通せない。多くの人がそういうことをやった後に、だいたいこれだけ時間がかかると予測がつくようになっていくわけだ。この規模の開発会社に導入するにはこれだけの期間かかる、みたいな。

　　　*　　　*　　　*

新しいことを発見するには、「なにか新しいことをやろう」と考えるのではダメだと思うのだよね。むしろ単に目先の問題をなんとか解決しようとしゃにむにやっていたら、いつの間にか新しいものを創りだしてしまった、というような。

むろん「新しいことをやろう!」と始めることもあるけど、その場合は実はすでに土壌ができているのだ。機が熟していて個々のパーツは揃っている(少なくともそう見える)、あとは組み上げればいいだけだ!と。まあ実際にはそんな甘いものではないけれど、基本的にはこういう構造のはず。

ひらめきは日常の泥沼の中から生まれる。もちろん泥沼に単に浸かっていればいいわけじゃないけどね。でもまずは問題にまみれなければ、発想も生まれない。

執筆： この記事はメカAGさんのブログからご寄稿いただきました。

寄稿いただいた記事は2014年05月23日時点のものです。