« インターフェイスとしてのリレーショナル・モデル | トップページ | 認知的不協和論文の確率計算 »

2008年4月12日 (土)

コミュニケーション・コストを減らす方法

だからプログラマが仕様を決めちゃえばいいんだよ。そのほうがいいに決まってる。マネージャはユーザーの立場に立って要件を抽出しそれを固めていくことに邁進すればいい。プログラマはその要件を元に「それならこれで出来ます」という仕様を決めて、後は全部自分が実装までやればいい。本来、システム開発は要員が少ないほうがいいと思う。多すぎるとコミュニケーションコストが高すぎて死ねる。

プログラマが仕様を決めればいい (GoTheDistance)

システム開発を行なうのに、こうしたコミュニケーション・コストの高い方法が使われているのはなぜか、ということを考えますと、本質的には、システム開発に必要な情報量が膨大であるから、ということになるかと思います。この膨大な情報量を持つ”仕様”を、コンピュータに入力するため、”高すぎる”コミュニケーション・コストを支払っているのでしょう。

開発体制

システム開発というのは、典型的には、以下のような階層型の体制で行なわれます。

Article_20080411_01

顧客、SE(システムエンジニア)、PG(プログラマ)の3種類しかありませんが。SEのところは、マネージャーなり、コンサルタントなり、適当に読み替えても変わりません。要は、ドキュメントを書く人: SE、コードを書く人: PG という分け方です。

顧客と開発側の階層トップに位置するSEとが、仕様について打ち合わせ、決定した仕様を、下の中間層SEへと、担当別に分配して流します。さらに、中間層SEがその下のPGへと、各自の担当分に分配して流します。仕様は、上から下へと流れるだけではなく、各階層で概要から詳細へとより具体化され、情報量が増やされていきます。また、そうして各階層で作成された成果物は、階層を下から上へと上り、顧客の手に渡ります。

さて、上の図からSEをすべてはずし、顧客とPGだけを残しますと。

Article_20080411_02

顧客は、膨大なコミュニケーション量の前に押し潰されてしまいますね。このような多数と、コミュニケーションをとり、膨大な情報量を処理していくのは、不可能でありましょう。

結局、膨大な情報量のコミュニケーションを処理するために、間に入る人間が増えてしまうわけでして。SEがPGになったところで、本質は変わらないでしょうね。コーディング作業と、他とのコミュニケーションのための作業(結局はドキュメント書きになりそうですが)を両方やるということにはなりますけど。

仕様の情報量を減らさないことには、根本的な解決にはなりそうもありません。

仕様の抽象度

以下のように、顧客とPGとが、1対1で開発する体制を仮定しまして。

Article_20080411_03_3

要件として、弾道計算を行なうプログラムを考えます。仕様としては、以下の4段階とします。番号の大きなものほど、より具体性のある仕様、ということになります。

  1. 弾道モデルを表す微分方程式
  2. 微分方程式の数値解法(アルゴリズム)
  3. 弾道モデルの微分方程式の数値解を得るロジック
  4. 弾道計算のプログラム・コード

3番目の”ロジック”というのは、日本語で書いた擬似コードのようなものを想像していただければ。この例の微分方程式に対し、アルゴリズムを適用した結果です。

さて、顧客の仕事としては、どこまでの仕様を作れば良いでしょうかね。プログラマは、どのレベルの仕様があれば、そこからプログラム・コードまでの仕事をできるでしょうか。

SI現場の現実から考えますと、最低限、3番目まではやらないと、プログラマは仕事ができないでしょうね。それでもおそらくは不足でして、計算の具体例を何点かと、テスト・データも作成して渡してあげないと駄目でしょう。さもなくば、”わかりません”と言われておしまいです。

また、出来上がったプログラムは、顧客自身で、仕様どおりになっているか、チェックする必要があります。プログラマに渡した例を確認するのはもちろん、渡していない例も確認しないといけませんね。不具合が見つかった場合には、どのようなデータの場合に、どこがどのように間違っているのか、どうなるのが正しいのか、具体的に(”ロジック”のレベルまで落として)プログラマに教えなくてはなりません。さもなくば、”再現できません”と言われておしまいです。

どうすればいい?

結局、プログラマがもっと賢くなればよい、などという結論がでそうです。しかし、それは、人類全体の知的レベルをより引き上げるにはどうすればよいか、と問うようなものでしょうね。ある職業に従事するもの全員の知的レベルを引き上げる、というのは、そういうことかと思います。

できるとすれば、仕様を抽象的記述から具体的記述へと、機械によって変換することくらいでしょう。今のプログラミング言語よりも、より抽象的な言語は実現可能か、ということになりそうです。

|

« インターフェイスとしてのリレーショナル・モデル | トップページ | 認知的不協和論文の確率計算 »

コメント

コメントを書く



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


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/20166376

この記事へのトラックバック一覧です: コミュニケーション・コストを減らす方法:

« インターフェイスとしてのリレーショナル・モデル | トップページ | 認知的不協和論文の確率計算 »