 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||
|
||||||||||||||
| 美しい設計 | ||||||||||||||
|
特殊な書式をサポートさせた結果、美しかったシステムの設計は汚くなっていった。しかし実は設計が「美しい」であるとか「汚い」というのは、きわめて主観的な価値観であり、さしたる意味はない。 予算内で必要な性能と機能を提供し、維持や修正も低コストかつ短期間で可能となるシステムこそが良いシステムといえる。そして、美しいシステムなるものは、往々にして完成度が高すぎて修正を入れにくくメンテナンス性の低い難物になることがある。 つまり貴方は「美しい設計」を素晴らしいものと思ってはいけなかったのである。 |
||||||||||||||
| 誰も予見できなかったトラブル | ||||||||||||||
|
誰もが上手く動作すると確信していたシステムが、実際に運用してみると上手く動作しないというのはよくある事例といえる。なぜ事前にわからないのかといえば、いくつかの理由がある。
表1：トラブルを予見できない理由
いずれにしても実際に稼働させてみるまでは、本当に業務で使用できるという確信を持つべきではない。 |
||||||||||||||
| 未来は予見できない | ||||||||||||||
|
設計時にはまだ使用されていなかった例外的書式がシステム稼働日には使用されていた。これは単なる連絡不足という問題ではない。例え新しい書式が必要だという連絡が適切に行われていたとしても、この例で見ているようなシステムの場合、設計変更やプログラムの変更など、多くの手順を踏まねばその書式を使用可能にできない。つまり新しい書式に即座に対応することができないかもしれない。 更にいえば、システム稼働開始日以降であっても、新しい書式が業務で必要とされる可能性がある。つまり未来は予見できない。当然、後から必要とされる書式をあらかじめ設計に組み込むことはできない。言い換えれば、たいていのシステムは常に「予見不能の未来」という脅威にさらされているといえる。 このドラマでは、貴方、ユーザ、技術者のいずれもが「予見不能の未来」に対する備えを一切考えていない。 |
||||||||||||||
| どこで誤ったのか・問題の根源を探る | ||||||||||||||
|
これらの問題について、より深く問題の本質を探ってみよう。 「業務ルールの細部は常に揺れている」あるいは「人によって細部が違う」というのは人間が行う作業である以上、避けることができない。これに対処するには2つの選択があり得る。 1つは、システム側でルールを規定してしまい、揺れを許さないという選択である。もう1つは、揺れを許さないといってしまうと業務が滞るため、硬直的なシステムによって業務を支援することができない場合である。つまり柔軟なシステムが必要とされる。 未知の未来に備えることはできないという問題は、未来を見ることができるタイムマシンが発明されていない現在では避けることができない。しかし、対策が存在しないわけではなく、いくつかの方法が考えられる。 まず、ワープロや表計算ソフトなどの汎用性の高いソフトを使い、業務専用のソフトを使わない方法。効率は良くないがどのような変化にもすぐ対応できる。別の選択は、常に変化にさらされるという前提となるシステムの開発スタイルを取る方法である。 本当の業務を誰も知らない、という問題も実は回避できない。知るための努力を払えば正しい業務の厳密な知識を得られるのではないか、と思うかもしれないが、これは努力だけで解決できる問題ではない。 業務というのは、例え零細企業であっても、様々な専門分野のスキルが相互に絡み合って運営されているものであり、自分の業務に関係する情報をたぐっていくと、どうしても他の専門分野に入り込み、情報量が一人の人間に把握できる量を超えてしまう。 またそれらの情報を学んでいる間にも、徐々に変化は続いている。仮にすべてを学ぶことができたとしても、その時点での持っている情報はすでに古いということである。この問題に対処するためには、すべてを知ろうとするのではなく、システムをテスト稼働させつつ実際に業務にすりあわせていく方が良い。 |
||||||||||||||
| 「変化を抱擁する」という解決 | ||||||||||||||
|
これらの問題に対処する方法は、一言で要約すれば「変化を抱擁する」ということになる。 システムを常に柔軟に変化させつつ、実際に行われている業務にすりあわせ続ければ十分に実用性の高いシステムが運用できるだろう。実際、開発方法論の1つであるエクストリームプログラミングは「変化ヲ抱擁セヨ」とスローガンに掲げ、このような開発スタイルを積極的に肯定している。 それにも関わらず、柔軟に変化し続けるシステムで成功したという話はあまり聞かれない。それはいったいなぜだろうか。 |
||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
