プログラマとプロマネのあいだ

プログラマもやるし、プロマネもやるし、たまに似非アーキとか営業っぽいこともやる

ソース読む気がない人はSIerには向かない

概要

画面上のアノ項目が、登録するとデータベースのどこに反映されるのか分からない、という話があった。
その人いわく、画面設計書やデータベース定義書をひっくり返してみたのだけど、どうも分からなかったとのこと。
でもそれって、ソース読めば分かるよね、という話。
(ああ、なんて低レベルな話。。そう、これは単なる愚痴エントリです。。。)

なんでソース読まないの?

ソースを読めないから(ソースを読むスキルがないから)


設計書が中途半端にしかメンテナンスされてないから、設計書に書かれていないことは、ソース読むなり、動かしてみるなり、時としてデバッグしてみて、理解する必要がある。
そういう環境が与えられているのに、なぜこの人達は、できる方法を取らないのだろう。
あるいは、できないことをできるようになるために、なぜスキルを身につけようとしないのだろう。

なんで設計書が中途半端にしかメンテナンスされないのか

いやいや、設計書がきちんとメンテナンスされていれば、ソースなんか読む必要はない、と思う人がいるかも知れません。
ここで、「設計書が完璧にメンテナンスされている状態」=「設計書とソースが完全一致している状態」と定義すると、
設計書を完璧にメンテナンスするには、

  • 設計工程:設計書を書いているところ。まだ開発してないのでソースは存在しない。
  • 実装工程:設計書を元に実装する(ソースを作る)。この時点では、設計書とソースが完全一致している。
  • テスト工程:発生したバグや仕様変更を元に、設計書とソースの両方を修正する。

のようにする必要がありますが、たぶん、テスト工程で「設計書とソースの両方を修正する」余力がなくて、ソースだけが先行してしまうのではないでしょうか。(僕が体験したケースは大体これ)
じゃあなんで、ソースだけが先行してしまうかというと、ソースは修正しないとバグは直らないけど、設計書は修正しなくてもシステムは動く。という事実があるからなんだと思います。

それでもちゃんと設計書をメンテナンスしろよ

かつて厳密にやっていたプロジェクトもありました。
そのぶん工数もかかるわけですが、設計書を完璧にメンテナンスすることにこだわっていたプロジェクトでした。
が、まあ、どこも低予算・短納期を強いられている関係上、こういうのはまれです。(いいわけ)

というわけで

ソース読む気がない人(ソース読むスキルを身につけるスキルがない人)は、SIerには向かないと思います。
(なのに、こういう人がいっぱいいるという矛盾した事実はなんとも受け入れがたい。。)