シス開発：システム開発に役立つ様々な視点 |
今まで、いくつものシステム構築を見てきた。かなり成功したものもあれば、悲惨なほど失敗した例もある。では、成功と失敗を比べて、どんな点がどのように違うのだろうか。ここでいう成功とは、システム本来の目的に照らし合わせて、どれだけの成果を上げたかである。期待した以上の成果を上げたシステムが、もっとも大きな成功といえる。
そうした視点で過去のシステム開発を評価すると、ピンからキリまである。そして、成功した開発には共通の特徴が見付かる。システムが実現する機能を、かなり深く検討している点だ。システム設計者が問題領域（業務など）を深く分析し、その結果として、システムに必要な機能を設計する。この部分の設計が上手なほど、良いシステムに仕上がる。
こうしたシステムの機能は、次のような手順で求める。最初にシステムの目的を規定し、次に目的を達成するのに必要な条件や要素を洗い出し、条件や要素を満たすための機能を考える。また、目的以外にも、使い勝手や信頼性の向上など、システムとして満たさなければならない条件がある。さらには、将来に新しい要望が出たとき、機能を追加しなくても運用で何とか逃げられるような、システムとしての柔軟性も高めた方がよい。以上の点を総合的に考えて、システムの機能を細かく規定していくのが、レベルの高い設計だ。
優秀なシステム設計者は、自らの開発経験から、「利用者の要望をそのまま実現したのでは、良いシステムにならないこと」を知っている。要望をそのまま満たすだけでは、良いシステムには仕上がらないのだ。優秀でない設計者は、この点に気付かない。
システムの利用者なら、問題領域に詳しいと誰もが思いがちである。しかし実際には、それほど詳しいわけではない。たいていの利用者は、目の前の作業には詳しくても、その分野のことを、総合的に把握しているわけではない。ただ、自分が普段行っている目の前の作業を、自動化したいと願っていて、広い視点は持っていない。そういう利用者が多くを占めているの現状だ。
しかし、システムを構築する場合は、もっと総合的に考えるだけでなく、あまり手直しせずに何年か使える点も考慮する。そのため、対象分野を総合的に把握し、本来の目的を強く意識して設計しなければならない。こうした点まで理解している利用者は、多くても１割程度（自分の経験から推測すると、おそらく５％以下）しかいない。逆に見ると、少なくとも９割以上は、対象分野を総合的に理解してはいないと言うことだ。もちろん、手作業を自動化するとともに、他から独立したシステム（つまり簡単なシステム）なら、９割側の利用者に聞くだけでも構わない。
では、対象分野を総合的に捉えるには、どうするのであろうか。成功したシステム開発では、どれもシステム設計者が行っていた。その分野をかなり勉強して、必要なレベルまで深く理解するのだ。全部を深く理解するのは大変なため、その分野で何が大事なのか最初に見極め、大事な部分だけ深く勉強するという方法を用いる。こうして理解した上で、システムの機能を設計している。
では、対象分野を総合的に把握した利用者がいる場合はどうなるだろうか。その場合でも、良いシステムに仕上げるためには、後述する別な面を考慮して設計しなければならない。それができるのは、優秀なシステム設計者だけなので、一緒に設計すれば最良のシステム仕様が得られる。システム設計時に考慮する点とは次のようなもので、システム設計者の知識や経験を総動員して、設計結果を得る。
利用者がシステムの目的を的確に把握していても、どのような機能を作れるかまでは知らない。目的や狙いが分かり、対象分野の知識を理解した設計者ならば、目的に最適な機能を提案できる。これがシステム設計者の最大の貢献だ。
どんなシステムでも、問題領域の例外を見極めて対処しなければならないが、一般的な利用者から得られる情報は限りがある。たいていの利用者は、例外が発生したとき何とかする癖が付いていて、それを網羅する形で挙げてもらうのは極めて難しい。仕方がないので、システム設計者が、自分の能力で例外を予測する。対象分野の知識、システムの目的、システムに関係する利用者作業の中身、扱うデータの特徴などから、起こりうる例外を挙げるわけだ。その中から、システムでサポートすべき例外を選んで、システムの機能に組み込む。
将来の拡張なども、対象分野の今後の動向を調べて、大まかに予測する。関係する法律が変わるとか、重視すべき要素が変化するとか、業界の雑誌を過去２年分ぐらい丹念に調べれば、大まかになら推測できるものだ。それをもとにして、最低限の準備をシステムに組み込んでおく。
システムを使っているうちに、新しい要望も出てくるだろう。出るたびに変更はできないので、利用者だけで何とか対処できる機能を入れておく。ある程度の手作業が生じたとしても、手も足も出ないよりは、比べものにならないほど助かるからだ。全部の要望に対処するのは無理だが、重要な箇所で少し準備しておくと、何とかなりやすい。
他にも、利用者が作業しやすく運用しやすい機能を整える。間違った操作でデータを壊さないとか、人間がミスしやすい箇所で手助けするとか、一連の作業を最小の手間で済ませるとか、一定期間ごとに入力件数を確認できるとか、エラーの可能性があるデータを集中的に調べられるといった配慮だ。当然だが、システム部門が運用しやすい機能も盛り込む。このように、様々な点を考慮して設計して、システムの機能を総合的に良くする。もちろん、システムの目的に照らし合わせながら。
以上のような点まで含めて検討すれば、システムの機能の設計内容が、相当に良いものになる。良いシステムの構築にとって不可欠な作業で、システム設計者の力量によって可能になっている面が非常に大きい。
上記のように、システムを上手に設計するためには、いろいろな能力が求められる。では、システムを設計している人は、こうした能力を身に付けているだろうか。
たいていは、プログラマーとして何年か経験した後で、設計を少しずつやり始める。先輩の書いた仕様書を真似しながら、システムの機能を決めていく。いろいろな面を検討して設計しているというより、何となく決めているという感じに近い。利用者に言われた機能を整理して、そのまま実現するのが一般的となっている。
システムの目的から検討し、目的に適した機能を求めている人となると、非常に少ない。このような形で設計すればよいこと自体を、知らない人が多いのではないだろうか。こんな状態でシステムの仕様を決めると、その内容はどうしても悪くなりやすい。
そこから生じる当然の結果は、途中での手直しが大量に発生する現象だ。プログラミング段階では、機能に整合性がない点を指摘される。利用者に見せた段階では、機能が正しくないとか、必要な機能が揃ってないとか、このままだと運用できないとか、言われてしまう。当然、修正しなければならないが、この段階での修正は大きな負荷となる。あまりにも大変だと、本当に重要な部分だけで勘弁してもらったりする。
システムを運用し始めた後でも、改善要望が多く発生する。使いにくい、機能が足りないなどの形で。また、問題領域で例外が発生すると、それへの対応も要望として挙がる。あまりにも多くの要望が発生して、急いで対応するのは難しい。運用開始後も、非常に困った状態に陥りやすい。
こんな現象は、１つのシステムだけで終わらない。必要な能力を身に付けていないので、作ったシステムのほとんどが、こういった状態に陥る。根本的な原因を直さないため、いつまでも同じことが繰り返されるし、改善の見込みはまったくない。
上記の問題は、システム開発の業界で昔から指摘されてきた。「要求仕様を適切に確定することが重要だ」などと。何度も言われ続けているが、改善する気配はほとんどない。その最大の理由は、単に指摘するだけで、具体的な解決方法を提示できてないからだ。
もしかしたら、「要求仕様」という言葉が悪いのかも知れない。ここまで説明したように、システムの仕様を設計する際には、要求を鵜呑みにするのではなく、本来の目的に照らし合わせて、要求の内容を再構築する。さらには、良いシステムに必要な要素を盛り込んで、システムの機能を確定させる。要求された内容を、そのまま仕様にするわけではない。
実際の要求の内容は、仕様とはほど遠いレベルであり、「要求事項」や「要求内容」と表現するのが適する。それを出発点にして「システム仕様」を設計するわけだが、要求をそのまま採用しないし、別な要素も盛り込むので、「要求仕様」と呼ぶに相応しい内容にはならない。「要求仕様」と言うのなら、「要求された中身だけで、仕様レベルの内容を作る」ような感じがするからだ。また、「要求されたことだけ実現すればよい」という安易な考えに陥りやすく、良いシステムを構築できない。こう考えると、「要求仕様」ではなく「システム仕様」と呼んだ方が適している。
話を、システム仕様の設計に戻そう。いくら大事だと指摘されても、具体的な方法を提示しなければ、問題点が解消するはずはない。そんな状態が長く続いたため、目立った改善成果を得られずにいる。よく考えてみれば、当然の結果である。
システム開発方法論が提示されているではないかと、反論する人がいるかも知れない。しかし、どの開発方法論も、開発の手順を示しているだけであって、システムの機能を良く仕上げる方法を提供してはいない。要求仕様を作るという工程が入っているだけだ。そのため、開発方法論をいくら詳しく習得しても、良いシステムの構築には期待したほど役に立たない。
現実の開発現場では、役に立たないと嘆いているだけでは済まない。何とか改善したいと考え、苦肉の策として、試行錯誤的に開発する手法が登場してきた。代表格は、XP（Extreme Programming）だ。少しずつ作っては利用者に使わせ、指摘された点を改善しながら、開発を進めるという手法である。
では、この手法を用いれば、システム設計能力が低くても、良いシステムを構築できるのだろうか。残念ながら、そうならない。ここまで解説してきた内容と照らし合わせると、どれだけの効果があるか分かるだろう。
XPでは、利用者の中から１人を選んで常駐させる。その利用者が、１割に属する優秀な人あれば、まあまあのレベルを達成できる可能性はある（システム設計者の能力に依存しない部分に限ってだが）。しかし、１割に属する利用者は優秀なので、本来の仕事で非常に忙しく、多くの時間を割くことなどできない。結果として、あまり忙しくない人が割り当てられ、その人が優秀な１割に属する可能性は、極めて低い。
そうした利用者の意見を聞きながら開発すると、目の前の作業をシステム化するのは大丈夫だが、良く作れるのは常に使う部分に限られる。また、その利用者の個人的な趣味が反映されやすく、他の利用者にとって良いとは限らない。
もっと重大なのは、問題領域の例外への対処が良く作られない点だ。試作中のシステムを使うだけなので、遭遇する例外は限られてしまう。対応しなかった例外は、システムが稼働してから起こり、機能不足として指摘される。
さらに、利用者が使っていくと、例外の他にも要望が生じる。それへの対応は、事前に考慮して設計していないと、改善しなければならない点として挙げられる。事前にどれだけ対応できるかは、システム設計者の能力に依存し、開発手法には関係ない（システムの構造が格段に進歩して、開発が不要になれば別だが）。
こうした問題に対処するためには、システムの運用を開始した後も、開発者が常にいて、出された要望に対処するしかない。つまり、試行錯誤の開発をシステム稼働後も続け、システムを使わなくなるまで終わらせないことだ。もちろん、機能の変更時には、本番データの移行作業などが含まれる。いくら何でも非現実的だろう。
他にも、使い勝手の良さ、問題領域での作業や運用のしやすさなどが、良いシステムには必要だ。これらの点は、開発手法に関係なく、システム設計者の能力で決まる。試行錯誤の開発手法でも、改善できない点である。
このように分析してみると、試行錯誤の限界が見えてくる。良いシステムを構築するのが難しいと理解できるだろう。一部の人は、試行錯誤によって良いシステムが構築できるように宣伝しているが、だまされてはいけない。
厳しい表現を用いるなら、「試行錯誤による開発手法は、システム設計能力の低い人を、最大限に有効活用する方法」である。能力が低い分を、試行錯誤によって補おうとしている。どの部分なら試行錯誤で補えるのか、よく考えて評価すべきだ。
最近では、データベースなどを用いたウェブサイトの開発が、数多く行われている。たいていに共通するのは“開発のスピード”で、短期間での構築が求められている。ここでも、試行錯誤型の開発を採用する人が増えている。
開発の対象となるウェブサイトだが、９割以上が期待した成果を出せてないと言われている。つまり、成功したのは１割以下なのだ。こうなったのは、当然の結果かも知れない。サイトの機能（システムの機能）が悪ければ、どんなに急いで開発したとしても、良い結果をもたらすことはない。もっとも重要なのは、サイトの機能を決める段階であり、その部分の設計を省略しては、成功などほど遠い。また、試行錯誤で何とかなるわけでもない。
ウェブサイトの構築でも、サイトの目的を明確に規定し、それに必要な機能や情報を求めることが極めて大切だ。目的に該当するのはどんな利用者層か、その層は何を喜ぶのか、そのためにどんな機能が必要か、同業他社との差別化をどうするのか、どこで利益または成果を上げるのか、成功させるために何を高めることが必要なのか、その高める点をどの順番で良くすればよいのか、といった点を明らかにしなければならない。
こうした検討の結果、どんなに良い形で構築しても成果が得られないという結論になることもある。その場合は、構築を中止するか、目的を変えて再検討するのが、賢明な判断だ。該当するサイトが、非常に多いのではないかと思う。
こうした点を深く検討せず、ただただ急いで開発していると、期待した成果は得られない。何度変更しても、成果が上がらないまま開発費だけが膨らんでいく。自分たちの行動を冷静に評価すれば気付くのだが、“開発のスピード”という流行語に惑わされている。言われてみれば当たり前の「悪い機能は、いくら急いで開発してもダメ」に気付かない。また、試行錯誤的な開発手法を適切に評価できず、かなり期待をかけて待ち続け、いつまでも成果を上げれない状態が続く。現実は厳しく、実際に動かしたときの結果として現れる。
システム設計を中心に解説したため、取りあげなかった能力もある。それは、利用者に対する態度や行為だ。できるだけ正確な内容で話を進めないと、システムの評価や運用が適切に行われにくい。たとえば、過度な期待を持たせるような話を最初にするのは最悪。また、論理的な内容でないと、システム化できないことを強調し、利用者が出した内容を論理的に整えて提示する能力も必要となる。加えて、利用者が正しく把握していない箇所があれば、上手に指摘して理解させる能力も求められる。こうした点も、信頼を得るためには欠かすことができない。
実は、現実問題として、もう１つ重大な要素がある。利用者側の責任者の思考能力や態度だ。責任者が論理的でないことを通そうとしたり、設計者の提示した内容を信頼しないと、いくら優秀なシステム設計者がいたとしても、成功しない状況に陥る。マトモな検討ができないので、良いシステム仕様に決めることができずに、どうしても失敗へ近づいてしまう。こうした外部要因は、論理的な話が通じない相手だけに、いくら説得しても改善できない。
ここまで何種類かの話題や能力を取りあげたが、良いシステムの構築に必要な要素に関して、大まかに理解してもらえたと思う。一番必要なのは、システム設計に役立つ能力の習得である。こうした必要性が正しく認識されていないので、提供できる組織や仕組みがほとんどない。そのため、習得しようと思っても習得できない悲しい現実が、目の前に立ちはだかっている。この点を何とかしないと、現状を大きくは改善できない。
個人で対処するのは非常に難しいため、影響力の強いどこかの組織が中心となって、改善策を実施するしかないだろう。そうした動きが始まるのは、いつになるのだろうか。
余談として、優秀なシステム設計者の特徴も少し紹介しよう。システム設計を主な仕事としているが、幅広い能力を身に付けたことで、いろいろな仕事を高いレベルでこなせる点だ。
その代表例に、プログラミングを挙げることができる。優秀なシステム設計者も、最初はプログラマーとして働いていて、少なくとも数年はのめり込んだ経験がある。プログラミングの適性も高いので、プログラマーとしても優秀なことが多い。さらに、システム設計の能力を高めたことで、より広い視点を考慮したプログラムが作れる能力を持っている。その結果、やろうと思えば、優秀なプログラマーに負けないレベルのプログラムを作れる。ただし、できたプログラムの特徴は少し違っていて、システム設計寄りの視点で良いと判断できる形に仕上がる。
テストなどに関しても、システム設計能力を生かせる。テストシステムの設計でも、テストケースの設計でも、システム設計と捉えて作れるからだ。テストの進捗管理、テスト結果のまとめなどの書類も、システム設計の対象となる。もちろん、テスト以外の作業での同様だ。
実は、システム以外にも利用できる。問題点を整理したり、何かを提案したりするとき、作成する書類の中身をシステムとして設計すれば、中身の質がかなり良くなる。また、問題領域の設計ができるようになると、業務の改善内容を設計したり、作業の検査工程を設計したりもできる。システム構築は問題解決でもあるため、たいていのことに応用できるというわけだ。その結果、活躍の場が大幅に広がって、スーパーパースン（スーパーマンまたはスーパーウーマン）的な人材となり得る。
こうしたチャンスを、システム設計者は持っている。それだけに、大事な能力を身に付けないなんて、大きな損だと思うのだが。
（2001年12月10日）
良いシステムを構築するための条件 |
