本質的特性と偶発的特性は分けて考える2:仕事の本質的特性と偶発的特性





仕事でよく「枝葉末節にこだわってはいけない」という言い方で、何かの提案が否定されたりする場合があります。私が若いころよくわからなかったのは

 どれが枝葉で、どれが幹なのか

が区別がつかなかったことです。

私はソフトウエアの開発をしていたので、ソフトウェアについて言うと、ある機能(A)をSQLデータベースによって実現したとします。その後、機能(B)を実装するにあたり、SQLデータベースでは実現が難しく、Postgre だと簡単にできることがわかったのですが、いまさら乗り換えるにはコストが掛かり過ぎる…、というような場合。




さて、これをどう判断するかは、もう2000年以上前に答えが出ていたそうです。

ということで本日から数回にわけて、ある過去の資産に対する判断を迫られた時に私が指針にしている方法についてご紹介したいと思います。

本日はその理論的背景



前回は、本質的特性と偶発的特性について概念を説明したので、今回はそれを仕事に対してどのように応用できるかというお話。




■アリストテレスはソフトウエアを考えるか?


ソフトウエアと言うのは、単純なものから複雑なものまで多種多様にあります。
この複雑さもアリストテレス的にいうと

・本質的特性
・偶発的特性

からなっています。

元来ソフトウエアを作る目的は、特定の問題をコンピュータシステムによって解決することであって、そのソフトウエアで解決すべき問題が持つ多様な要望に答えた部分が本質的特性を生んでいます。

一方で、「偶発的特性」は問題の解決には直接かかわりなく生じてしまう複雑性です。たとえば、

ある問題の再発防止策として自動検証システムを導入する

というのは我々が作るシステムの本質的特性ですが、

 自動検証システムを C 言語+MS-SQLでつくる

というのは、その機能の目的である「問題の再発防止」とは全く関係がありません。したがって、これは偶発的特性であるといえるわけです。たまたま、その担当者が使えるツールが C と MS-SQL だったに過ぎないわけです。

これらの本質的特性と偶発的特性が相まって、あらゆるシステム(これはプログラムにかぎらず、人間が関わる全ての活動)がどんどん複雑化していくわけです。

これは会社のルールなどにも見られます。

ある作業ミスをすると、その作業ミスの再発防止としてチェックリストが作られます。他のミスも発見されるとチェックリストに追加されて、やがて紙数枚では収まらなくなります。そうなるとチェックリストを全部やったかという問題が提起されて、チェックリストのチェックリストが作られて、これも膨大になるとチェックリストのチェックリストのチェックリストが…。
それで何年も経つと、意味不明なチェックをしているチェックリストがたくさん生き残るわけです。

たとえば、かつては液晶には信号に反応しない点がひとつやふたつはありました。
顧客からクレームが来るので、いろんな画像パターンを表示させる検査が追加になりました。ところが今の液晶製造技術なら、ppm(100万分の1)レベルまで品質は上がっています。それでも検査は残っています。万が一未満の問題ですよ。

■本質的特性と偶発的特性の複雑性


本来、これらの特性が複合して発生する複雑性は極力排除することが望ましいのですが、間違えて本質的特性を偶発的特性がブロックしてしまったり、本質的特性を排除してしまったりする失敗が少なくありません。

ソフトウエアにかぎらず、その目的達成をより確実に確保するためには、複雑性を排除することが基本思想に必要ですが、本質的複雑性を排除してしまうとそのソフトウエアは役に立ちません。

ですが、「偶発的複雑性」は本来の目的には寄与しないものなので、これを排除することはソフトウエアの品質を高める効果があるわけです。

私が時々やってイライラする経験があるのですが、

1.ある大量のデータを処理しようとして簡単なソフトを作る
2.実際にそのデータを処理させる
3.処理が始まったところで、すごく時間がかかりそうなことに気がつく
4.これをデータをクレンジングしておいてからやればきっと早くなるとかんがえる
5.でも処理を始めてしまったので続けようか一旦止めるか迷う
6.最終的にはやめることにして、強制停止させる
7.データのクレンジングのために新たなソフトを書く
8.クレンジングを始める
9.始めてみるともっと効率のいいアルゴリズムを思いつく
または途中経過のデータを見て、クレンジング処理である特定のデータがフィルタされていないことに気がつく
10.項番 5 に戻るか、そのうちに何をやっていたか忘れて、「綺麗かつ流麗な」ソフトを作ることに熱中する

とやって、最終的には出来上がるのですが、かけた時間と作ったプログラムは当初のものより何倍も大きくなる…、と。
で、さらにまた、それが作りすてのプログラムだったりすると更に腹が立つ………

項番 1 は本質的特性ですが、それ以降やっているのは偶発的複雑性を増加させているだけですね。
ようやく終わった時には、こうつぶやくことになります。

「何をやっているんだか…」

アリストテレスの時代にソフトウエアがあったわけではありませんが、万物(人間?)の持つ特性はソフトウエアも避けられないということですかね?




■関連する記事

ザ・プレゼンテーション

今日は、すごいプレゼンテーションの技術の本。プレゼンの小手先のテクニックを書いたビジネス書はたくさんありますが、これはプレゼンの本質に迫る素晴らしい本です。一つ一つの身振り手振りや、目立つようなアニメーションの技術はさておき、プレゼンにおいて、どのように人を感動させ、どのようにプレゼンターの望む行動を起こさせるか、それが過去の素晴らしいプレゼンテーションを例に解説がしてあります。2007年のMacworldで、90分のうちに80..

本質的特性と偶発的特性は分けて考える3:偶発的特性を回避する

仕事でよく「枝葉末節にこだわってはいけない」という言い方で、何かの提案が否定されたりする場合があります。私が若いころよくわからなかったのはどれが枝葉で、どれが幹なのかが区別がつかなかったことです。私はソフトウエアの開発をしていたので、ソフトウェアについて言うと、ある機能(A)をSQLデータベースによって実現したとします。その後、機能(B)を実装するにあたり、SQLデータベースでは実現が難しく、Postgre だと簡単にできることがわかったのですが、いまさら乗り換える..

本質的特性と偶発的特性は分けて考える1:本質的特性と偶発的特性

仕事でよく「枝葉末節にこだわってはいけない」という言い方で、何かの提案が否定されたりする場合があります。私が若いころよくわからなかったのはどれが枝葉で、どれが幹なのかが区別がつかなかったことです。私はソフトウエアの開発をしていたので、ソフトウェアについて言うと、ある機能(A)をSQLデータベースによって実現したとします。その後、機能(B)を実装するにあたり、SQLデータベースでは実現が難しく、Postgre だと簡単にできることがわかったのですが、いまさら乗り換える..

反論させない技術

部下から「どうしてそんなことをやらなくちゃいけないんですか?」「おかしいでしょう!?」とか詰め寄られることがあります。たとえば、昨今の効率化で、「残業は減らしなさい」というのですが、「仕事は減らしません」というやつ。私も含めて(私はもう残業代はもらえなくなってしまいましたが)、多くのサラリーマンが納得してないのではないでしょうか。でも管理職になれば、それはそれで会社方針として出てくるのでやらないといけない。そんな時に一番困るのが..

本質的特性と偶発的特性は分けて考える2:仕事の本質的特性と偶発的特性

仕事でよく「枝葉末節にこだわってはいけない」という言い方で、何かの提案が否定されたりする場合があります。私が若いころよくわからなかったのはどれが枝葉で、どれが幹なのかが区別がつかなかったことです。私はソフトウエアの開発をしていたので、ソフトウェアについて言うと、ある機能(A)をSQLデータベースによって実現したとします。その後、機能(B)を実装するにあたり、SQLデータベースでは実現が難しく、Postgre だと簡単にできることがわかったのですが、いまさら乗り換える..



■同じテーマの記事

百万ドルの教訓

記憶ほどあてにならないものはありません。多くの場合は、時間が経てば曖昧になるし、最悪(というか普通)消えてなくなります。本当に消えてしまうわけではなく思い出せなくなるだけの場合もおおいですが。百万ドルの教訓過去記事で10万ドルのアイディアというのをご紹介しました。..




posted by 管理人 at 05:00 | Comment(0) | TrackBack(0) | 知的生産術 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:


この記事へのトラックバック
×

この広告は90日以上新しい記事の投稿がないブログに表示されております。