最近よく思います。
システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。
ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。
- この言葉はプロジェクトで使われていない
- 書き方が統一されていない
- 誤字脱字が多いので直せ。
- この文章ではこのように解釈される恐れがある
- ここではこのような話になっていたがどうなのか
こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。
で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部パァになる。重要なのはドキュメントをいじくり回すことではなくて実装工程にシームレスにつなげていくことなのだが、工程が分断されている日本のシステム開発スキームにおいては「この書類は自分たちが言いたい事を一語一句間違えなく伝えているのである」というのが大切らしい。
設計に対していくらPDCAをまわしてみても、せいぜい誤字脱字、書式が正しくない、更新日付が間違ってる、と言ったことしか見つからないし、こいつらは、プログラムに対してまったく関係がない。まったく関係がないミスをいっぱい見つけて、はい、これで完璧です。次のフェースに行きましょう。って言ってるのが現状。
で、開発になってこの設計ではうまく行かない点が見つかって大騒ぎになっている。何でだ設計書は完璧なんだろう？はい完璧に誤字脱字はありません。ギャグですかと。
本当にこんな感じだから笑えない。
工程が分かれてしまっていることの弊害は計り知れなくて色んな問題を引き起こしていると思うのだが、特に思うのが上流工程だけでも下流工程だけでもつまらないんだけど、上流から下流を全部担当するとこれほど面白いものはないということ。ドキュメントだけ作ってチェックするのもつまらなすぎる。他人様の言われた通りの実装をするだけ、テストをするだけ、というのもつまらなすぎる。でも自分で要件→仕様決定→設計→実装→テストを垂直に行うと、すげー面白い。色んなことが身につくし、何よりもこれが「システムを作る」ことの醍醐味だと思う。結果としてとても品質の高いシステムができると思う。
だからプログラマが仕様を決めちゃえばいいんだよ。そのほうがいいに決まってる。マネージャはユーザーの立場に立って要件を抽出しそれを固めていくことに邁進すればいい。プログラマはその要件を元に「それならこれで出来ます」という仕様を決めて、後は全部自分が実装までやればいい。本来、システム開発は要員が少ないほうがいいと思う。多すぎるとコミュニケーションコストが高すぎて死ねる。
要件を決めるのは技術力以外のことが求められることが多いし政治的な領域であるため、要件定義は実装に強い人をアサインしても何にも生まれない。「御社の事業において今回このシステムをどう使わせるのですか」というのが要件定義。そこでは実装の話は不要。ちょっとでも出来なさそうな要件を聞くと「それはできません」と答えてしまう技術者が出てくる。出来ることだけやっても何にもならないじゃないか、と僕は思う。
遅かれ早かれ今のシステム開発スキームは破綻する時が来ると思うし、むしろ早く来てしまえと思っているぐらいなんだけど、大きな会社はどこも「誰がやっても同じものを作れる」ことを目指しているように思う。そんなの無理でしょ。誰がやっても同じ結果を作ることは出来ても、誰がやっても同じロジックになるとは到底思えない。それはあたかも、あるテーマに沿った文章を一語一句同じで書いて来いと言っているようなもの。無理に決まっている。同じものを作らせたいと言う願いの裏側にあるのは、誰がいじっても変なバグが起きないようにするということだと思っていて、改修が簡単になって品質も落としたくないということが目的だと思う。それが満たせるなら別に同じやり方である必要はないじゃん。必然性が無い。
こういうことを考えていると、やっぱり内製回帰すべきじゃないかと思います。
