シス開発：システム開発に役立つ様々な視点 |
システムの開発では、システムを使いたい人が自分では作れないので、作れる専門家に依頼することがほどんどだ。どのようなシステムにするかを依頼主が規定し、それに合わせる形で開発者が設計する。このような形態なので、開発が失敗する原因としては、開発者の能力が低い以外に、依頼主のレベルが低いことを挙げられる。
依頼主が要望を出す形態では、要望をきちんと規定するのが、開発を成功させる大前提だ。要望に含める内容は、何でも良いというわけではない。実際に実現可能なのはもちろん、決められたコストや期間内に作れる必要がある。さらに、企業の戦略との整合性を確保し、情報システムの特徴を生かした形で、戦略を支援できる要望に仕上げることも求められる。依頼主が出す要望は、システム設計の基礎となるため、きちんとした内容でなければならない。
出された要望があいまいだと、システムの仕様が適切に決まらず、本当に役立つ姿にはならない。たいていは開発の最後のほうで変更が発生し、システムの内部構造はだんだんとボロボロになり、質が大幅に低下する。最悪の場合には、まったく使えないシステムが出来上がる。要望が途中でコロコロ変わる場合も同様だ。
情報システムの特徴を生かすような要望でない場合も、何とか開発は終わるが、システムが生む効果は小さい。これもコスト対効果を考えると失敗といえる。正常に動作しないだけが失敗ではないのだ。
これだけの説明でも分かるように、要望を出す依頼主のレベルは非常に重要である。その中身を、もう少し詳しく解説しよう。
依頼主が失敗の原因にならないためには、コンピュータ・システムに関する基本的な知識を、依頼主も理解する必要がある。知っておくべき内容には、システム自体の特徴と開発での制約の２種類が含まれる。
１番目のシステム自体の特徴とは、コンピュータ・システムを利用した仕事のやり方が、人間の手作業と比べて異なることだ。人間が行うときは、１つの１つのデータを見て臨機応変に処理できる。もし問題のあるデータを見付けたら、その場で適切な対処ができる。しかし、システムで自動的に実行する場合は、あらかじめ組み込んだ検査や対処の内容でしか、データを処理できない。起こりうる全部の状況を洗い出し、それぞれにどうするかを事前に規定する必要がある。つまり、決められたこと以外はできないのだ。この結果、システムが処理する部分と人間が処理する部分を、上手に分担することが求められる。
コンピュータで処理するため、要望として規定する内容は、すべて論理的でなければならない。また、全部の例外を組み込むのは無理なので、対象業務を標準化する必要もある。その代わりに、多くのデータを低コストで処理できるし、人間のように処理をミスする心配もない。もちろん、バグを出さないような作り方が求められるが。
システムの変更も、人間の手作業とは大きく異なる。手作業ならば、たいていは簡単に切り替えられる。しかし、情報システムでは開発やテストが必ず発生する。データ構造を大きく変える変更では、データの変換が必要だ。また、切り替えの作業には、既存データのバックアップや動作確認など、大きな工数が必要となる。
２番目のシステム開発が持つ制約は、開発の方法やコストに関する部分だ。現状での開発では、システムの機能を途中で大きく変更するのが難しい。そのため、最初の段階でシステムの機能を明確に規定する必要がある。また、システムの複雑さが増すと、コストと期間の両方が加速度的に増し、開発を難しくする。そのため、最初の段階で要望をきちんと規定しなければならない。
システムが運用し始めた後でも、開発面での制約が関わってくる。一部の機能を少し変えるだけでも、システムの関係箇所を調べたり、システム全体でテストするなど、かなりの工数が必要だ。気軽に変更するのは不可能ではないが、コストと安全性の面で現実的ではない。
プログラミングは知らなくても構わないものの、最低でも以上のような内容の理解が求められる。それが分かっていれば、無茶な要求を出して開発を失敗させることは少ない。
依頼主のレベルが低いのには、大きく分けて２つの場合がある。情報システムに関しての経験不足と、要望を論理的にまとめられない点だ。
情報システムに関しての経験不足は、前述のような知識を知らないことが原因となる。システムに過度な期待を抱き、何でも簡単にできると考えがちだ。そのため、思い付くまま要望を出してしまう。また、途中での変更が難しいことを知らず、後から変えればいいやと最初はいい加減に要望をまとめ、後でどんどんと変更を出してくる。さらに、現状の作業をそのままシステム化する傾向が強く、コンピュータの特徴を生かした業務形態に仕上げることができない。
この種の相手には、一番最初に、情報システムおよびシステム開発の特徴を説明することで、失敗を少しは防げる。しかし、情報システムを実際に使っていないと、コンピュータの特徴を生かした業務形態を考えることができない。やはり、ある程度の使用経験は必須だろう。依頼主が別なシステムを事前に使うことで、この問題は解消できる。
ただし、コンピュータがこれだけ普及した現状では、ある程度以上の役職なのに情報システムの経験が不足するというのは、必要な能力を持っていないことに等しい。組織にとっても本人にとっても大問題で、早急に解消する必要がある。もし逃げてばかりいるようだと、役職を外れてもらうしかない。
もう１つの、要望を論理的にまとめられない場合が、より厄介だ。言っていることに矛盾があったり、細かな部分まで考えていない抽象的な内容だったりして、そのまま実現するのは難しい。深く考えないので、思いつきだけで変更を依頼することもある。このような発言をするのは、論理的に考えるのが苦手な人に多い。残念ながら、たとえ依頼するだけの役割であっても、システム構築の仕事には向かない人なのだ。知識を増やすことで解消する種類の問題ではなく、別な人に入れ替えるしか解決方法はない。
以上のように、レベルの低い２つの場合は、原因がまったく異なっている。それぞれ対処方法が異なるので、依頼主をきちんと調べて、どちらに属するのか判定しなければならない。
依頼主の組織の中で争いが発生する場合も、開発を邪魔しやすい。業務の情報システム化とは、今まで手作業で行ってきた仕事を、コンピュータ中心に切り替えることである。手作業の間は、情報を独占するなどの方法で、年輩者が自分の地位を確保してきた。ところがシステム化すれば、個人で情報を独占することができない。また、業務自体を標準化して、誰もが同じレベルでできるようにするので、先輩の優位が失われやすい。さらに、コンピュータを使いこなす能力は、若い人ほど高い傾向がある。
以上のことを知った年輩者は、開発を邪魔するようになる。表だって邪魔するというのではなく、まったく協力しない形の場合が多い。業務上の情報やノウハウを何も教えず、使いものにならないシステムになることを願う。
こんな状況は、専門性の低い仕事ほど発生しやすい。逆に、業務の専門性が高いと、システム化できる割合が低くなり、人間の専門的な能力が仕事の質を左右する。専門性の高い仕事では、人間である専門家が中心で、システムはあくまで補助なのだ。
組織内の争いの発生は、システム開発の成功を難しくする。だからといって、システムの開発者が解決すべき問題ではない。外部の人が首を突っ込むと、本来の仕事とは異なる余計な負荷を背負うことになるからだ。それよりも、依頼主の責任者に事情を話し、依頼主側で解決してもらう。助言はするが、解決してもらうのが基本である。
ここまで述べたように、依頼主のレベルは、システム開発の成功に大きく関係する。実際の開発でも、依頼主のレベルが低いために遅れたり失敗したりしている。日本の役職者はコンピュータを避ける傾向が強いため、ごく一部の現象ではなく、かなり多く起こっていると思われる。
以上のことが理解できたら、システム開発を請け負うときには、相手のレベルを調べたほうがよい。今まで使ってきたシステムの範囲はもちろん、これから作るシステムで実現したい内容、例外処理の扱い方、人間とコンピュータでの作業の切り分けなど、相手のレベルを知るための質問をしてみる。システムで実現したい内容が、抽象的だったり非論理的だったりしたら、レベルはかなり低い。また、システムに過度の期待を持っていたら、システムの経験が浅い可能性が高い。どちらも、仕事をする相手としては良くない。
論理的でない依頼主の場合は、特別な理由がない限り避けたほうがよい。それがベストな選択だ。経験の浅い依頼主には、優秀な開発者なら教育してあげられる。しかし、その分だけ余分なコストが発生するので、採算性は低くなる。残念ながら、その分を明示的に相手が出してくれる可能性はほとんどない。たとえば「おたくはレベルが低いので、２割増で請求させていただきます」とは言えないだろう。現実には、通常の見積りの中に割増分を隠して加算し、その金額で相手が納得したら、開発を請け負うことにするしかない。こうして割増分をもらっても、生産的でない苦労を背負い込むので、できれば避けたほうが無難だ。
良いシステムを構築するためには、開発者の技術レベルを高めるだけでなく、要望を出す依頼主も情報システムの特徴を理解しなければならない。その両輪が揃わないと、開発するシステムのレベルを高めることは難しい。
（1998年11月18日）
依頼主のレベルが低いほど開発は失敗しやすい |
