IT系の仕事や、オペレーションマネジメントの支援の仕事をしている際に、時に壁にぶつかることの一つに、「記録が無い」「明文化していない」ということ。
「文章として記録に残す」というのは、役所系の仕事ではごく当然に行われているが、一般企業では、結構、軽視されていることが多い。
「契約書」ベースの欧米に比べて、日本は「曖昧」なまま進めてしまう社会風土が起因しているのだろうか。
特に、インターネット系のシステムでは、「仕様書」が無いということが多々ある。
その多くが、「予算を軽減する」という理由で作成されていないことが一般的。
しかし、その後のシステムの改修をする際に、その「予算を軽減」したことがあだになってしまうことがある。
また、企業側の担当者が入れ替わり、システムに関する情報が、誰もわからないということさえある。前回の開発担当者でなければ分からないようなことは、ブラックボックス化されてしまうのだ。
開発業者は、現状の仕様が分からなければ、改修をするにしても、その現状の把握からしなければならない。当然、その分の作業コストが嵩み、それは当然請求金額として跳ね返ってくる。
基幹系システムと比較して、インターネット系システムは、技術の変化も早く、スクラッチ＆ビルドも当然、そのサイクルは早い。また、「アジャイルソフトウェア開発」の手法を取っているからといって、そうした明文化は行わないというスタンスの会社もある。
確かに、アジャイルソフトウェア開発は、短い単位での開発を繰り返し、機能開発を行う。プロジェクト関係者の間で、必要な時に即座に直接顔を合わせて意思疎通を行うから良いという主張もある。
しかし、これは自社のソフトウェアパッケージ開発ならともかく、受託型の場合はそうはいかないと私は思う。
システム開発も、以前に比べて価格競争が激しくなった。
こうした流れで、開発会社側も如何に効率よくプロジェクトを進めるかを試行錯誤する。そういう意味でも、「明文化」は後回しされやすい。
発注する企業側にとって、どうしてもシステムそのものに目が奪われやすいが、こうしたシステムの設計書の重要性を、見積もりベースの予算化の時点から意識しながら対応する必要があると私は思う。
目先の費用対効果と、長い目で見た場合の費用対効果。
そして、目に見えない部分を抱えることによる「リスク」。
総合的に考えると、その重要性もはっきり見えてくるだろう。
