「業務仕様」を決めるだけでは不十分

さっきと同じ記事ですが、別の事も感じたので違うエントリで書きます。

10年間泥のように働いて花が咲きました - ひがやすを blog

日本のSI業界の重鎮たちの発想が古いのは、C/S以降の開発を知らないからだ。C/S時代は、既に偉い人で、管理業務だけやっていたんだろう。その人たちにC/S以降の開発を知っていますかと聞けば、たぶん知ってるよと答えるだろう。でも、それはきっと日経XXXのような雑誌で読んだ知識に過ぎないと思う。現場にいなかったから、現実を知らないのだ。

これは本当にそうだと思う。この辺の基本的な論旨には納得しています。

で、細かな話だとは思いますが、

汎用機やオフコンの世界は、プログラミングの技術が進化することはほとんどない(と思う)ので、だいたいプログラミングでできることを知っていれば、細かいことを知らなくても業務仕様を決める分には困らない。

そんな変化のないSIの世界もクライアントサーバ(C/S)型の登場で一気に変わった。汎用機やオフコンよりも圧倒的に安くシステムが作れるようになった。それと同時にプログラミングの世界は常に進歩していくようになった。プログラムで何ができるか知らないと、業務の仕様もきちんと決められなくなってきたのだ。

ここで「業務仕様」と言っているところにちょっと違和感を感じた。

「だいたいプログラミングでできることを知っていれば、細かいことを知らなくても業務仕様を決める分には困らない。」というのは、たぶんC/SになろうがWebになろうが、今でもそんなに変わらないのかな、と思うのです。
C/S以降で変わったのは、「業務仕様」を決めるだけでは、プログラムで作る為の仕様として十分ではなくなった、実装に必要な全ての仕様を決めた事にはならなくなった、という事ではないかと。

使い勝手とかUser Experienceの部分でできる事が、C/S以降はとても幅が広がり拡散した。それらはユーザの業務の本質とは違う部分なのだが、ユーザが直接触れるところでもあるので、そこの良し悪しでユーザが受ける印象も相当変わってくる。

昔ながらのウォーターフォールな開発手法においては、この辺の事まで基本設計の段階で決めきれる事が今でもそんなに多くないはず。決めきれていないから、プログラミングをする人のセンスに依存してしまったりする。

だから出来上がってきたシステムに対してユーザからその辺の指摘があると、開発者側は「そんな内容は仕様は盛り込まれていない」と言うしかないし、ユーザ側は現実に出来上がったシステムの振る舞いに対して「これを仕様として決めた覚えはない」と言ってぶつかる事になりがちなのかな、と思う。

もしくは実装で使用する事になるプログラミング言語やツールの事をよく知らないまま設計しているものだから、その辺の動作について無茶な内容が決まっていたりする。それを無理やり実現させる為に開発コストが膨らむ事になる。ユーザ業務の本質とは関係ない、ある意味では「どうでもいい」部分のはずなので、開発も保守もしやすいようにして、必要以上にコストをかけない事が、開発者とユーザ双方にとってよい事のはずなのに。

そんなわけで、やっぱり要件定義からプログラミングまでを同じ人間が通して担当した方が効率的で品質の高いものができると思うし、それを可能にするためにもっとスパイラルな感じの開発手法が必要なんだと思う。

これからは業務もプログラミングも両方わかっている人がもっと増えて、実際にそのような関わり方でプロジェクトが遂行されるようになる事が必要だと思います。