« フレームワークはオブジェクト指向を隠蔽する | トップページ | 詳細設計に吸収されるプログラミング »

2009.02.06

ツール開発には変人が必要である

 筆者はSONARというDAWソフト(演奏を録音したりプログラミングして音源を作るためのツール)を使っているのだが、このツールにはミュージシャンが実際にそれを使って制作した作品が添付されている。購入当初、プロが使うとこんなふうになるのかと驚きながら、1曲中に20個もあるトラックを個々に調べてとても勉強になったことを思い出す。

 ひるがえって自分が棲んでいる業界に目を向けるとどうだろう。さまざまなモデリングツールや実装用フレームワークが覇を競っているが、それらに「レファレンス作品」が添付されているケースはまれである。これはおかしい。あらためて申し上げるまでもないことだが、「何かを作るためのツール」の効用は、SONARに添付されていた曲のような「それを用いて作られた本格的な作品」を事前に確認することでおおよそ理解できるからだ。そういうものが手に入らないツールばかりというのはおかしい。

 「このフレームワークは全世界14万8千社で導入されていて、その中にはあのXXや○○が含まれております」なんて宣伝文句も悪くはないだろう。しかし、実際に稼働しているシステムの中身を覗けないのではさみしい。典型的な複雑さと規模を持った「レファレンスシステム」があれば、ユーザは選定の過程でツールの効果を評価できるし、どんなタイプのシステムに適しているかもわかるので無茶な適用も抑止できる。

 そもそもこの業界で「何かを作り出すためのツール」がたくさんあるわりに、実務レベルのレファレンス作品が極端に少ないのはなぜなのだろう。そのように問うとたいてい返ってくる答えが「活用実績はいろいろあるのだが、権利関係の問題があって公開できない」とか「作りたいのはやまやまなのだが、予算がない」というものだ。

 判で押したようなそれらの反応を聞くうちに、私は次のように考えるようになった。「何かを作るためのツール」のアイデアにもとづいて「ツールをプログラミングせずにいられない技術者」は探せばいるのだろう。ところが「そのツールを用いて作業せずにいられない実務者」を見つけ出せないままに開発を進めているのではないか。ゆえに、ツールがあとからあとから生み出されるわりに「レファレンス作品」がいつまでたっても生み出されない。

 だから、たとえそれが難しいことだとしても、「モデリングツール」の開発には「システム設計が趣味であるような物好き」が関わるべきだし、「実装用フレームワーク」の開発には「システム開発が趣味であるような物好き」が関わるべきだ。そうすれば、予算を確保せずとも彼らはとっとと作品を作り出して公開するだろうし、その過程でツールの使い勝手や実用性を向上させるためのアイデアも生まれる。

 オープンソースの世界は「プログラミングが趣味であるような物好き」に支えられつつ発展しているが、オープンソースであろうとなかろうと、ツール開発ではそういう人材が揃っていてもじゅうぶんではない。「ツールを用いた実務そのものを偏愛するキトクな物好き」、ようするに「変人」が必要なのである。

|

« フレームワークはオブジェクト指向を隠蔽する | トップページ | 詳細設計に吸収されるプログラミング »

コメント

 「自分が棲んでいる業界」にも幅が有る訳で、大きくソフトウェアという言い方をするなら、青淳さんの「じゅん」みたいなものも有る訳で、ツールも有れば、リファレンスで済まない部品達が当然の様に公開されている。
 一方、企業の情報処理システムとなると、やっぱり公開できない。
 公開すべきだと思われるのは、パッケージを売っている人達で、我々の製品は、こういうモデルを対象に作っていますと見せて欲しいもんだが、いかんせん、多くのパッケージはどこかの企業向けに作ったシステムに、似たような他の数社に作った機能をちょっと化粧して乗っけてみました的なものが多くて、モデルなんて存在しないのが実情です。
 もう一つ考えられるのは、公共のシステム。自治体なり、公官庁なりのシステムは、本来全てオープン化していてしかるべきだと思います(防衛とかは除けてもね)。
 彼らこそ、同じ業務のはずのものをそれぞれに、過去に機種依存したベンダーに握られたままになって、重複してものが作られているのが実態です。この中には、販売だってあれば、製造なり物流なり、多くのモデルが見れてしかるべきだと思うんですけどね。
 ツールを作るひとより、そっちを根本的になんとかしたいものです。

投稿: Iさん | 2009.02.16 19:58

おや、誰かと思えば。おひさしぶりです(^^)

公共系システムについては、たしかに完成時にモデルを公開すべきだと思います(限定つきでソースも)。それをサボるといつまでたってもシステム開発費を削減できなくなるし、合理化も進まない。住民税も安くならない(--#

投稿: わたなべ | 2009.02.16 23:31

本文と直接の関係はありませんが、質問させてください!
設計を進めていく過程ではタイムチャートの考慮など運用的な分析も必要なことがあると思います。
三要素分析法では、業務/機能/データでモデリング可能とのことですが、タイムチャート的な考察はどのように収まるでしょうか?
まったく別に考える必要があるんですかね?
何か、お考えがあれば教えてください。

投稿: くまきち | 2009.02.19 23:10

くまきちさん

タイムチャート的な考慮というのは、たとえばどんなことでしょうかね。

投稿: わたなべ | 2009.02.20 17:53

お返事、ありがとうございます!

分かりにくいことを書いてしまいすいません。。
たとえば、何時までに処理が終わってなきゃいけないとか、そのために何時までなら受信データの到着を待てるか、などの分析でしょうか?
あとリカバリーが必要な場合でも運用にのるかどうかの確認とかですかね。

三要素分析法のような洗練されたアプローチ法は無いのかなと思ってて、ついコメントしてしまいました。
整理できてなくて、すいません。。

投稿: くまきち | 2009.02.20 19:11

基本設計段階では、とりあえず業務フロー上でサーバーによる業務単位として「規定時刻になった!」のトリガーイベントをともなう「ナントカ受信処理」を定義するなどしてはいかがでしょう。人間の状況判断にもとづく処理であれば、「随時」をイベントにして「なんとか受信処理」を定義する。細かい時刻や前後関係の設定などは、詳細設計段階で扱えばいいのではないでしょうか。いずれにせよ、XEADに登録されるのは、コンピュータの素人であるユーザーが理解できる設計情報が主体なので、あまりテクニカルな内容を登録することは考えないほうがいいと思いますね。

投稿: わたなべ | 2009.02.22 18:08

なるほど。
「何を考える必要があるか」と同じように「いつ考える必要があるか」を意識することが大切なのかな?と思いました。
参考にして日々精進していきます!

投稿: くまきち | 2009.02.22 22:56

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: ツール開発には変人が必要である:

« フレームワークはオブジェクト指向を隠蔽する | トップページ | 詳細設計に吸収されるプログラミング »