設計書がエンジニアを殺す

設計書は必要だが、、、

　金融システムのエンジニアをしていて、つくづく思うのは設計書の作成に時間をかけるのは悪だということだ。確かに設計書を作成することは開発を行う上で重要だが、必要以上にこだわっても意味がないと考えている。
　例えば、画面であれば、画面遷移図、画面レイアウト定義書や画面項目定義書を作成するよりも、モック作成して要件を詰めた方が、設計書修正と言う手間を削減できるし、業務ロジックの設計書を作成しても、テスト段階で必要な業務ロジックや各サブシステムとの整合性が誤っていることに気づくと言うのは日常茶飯事的に起きうるので、そうなると設計書修正からやり直しとなる。
　ご存知の方もいると思うが、ソフトウェア開発では、目に見えるものを作成している訳ではないので、設計書を完璧に作成したところで後々、修正することになるケースが多く、この設計書の修正作業に多大なロードを取られることが本当に多い。
　こういったことを防ぎ、開発スピードを上げるために旧来のウォーターフォール開発ではなく、アジャイル開発が取り入れられている業界も増えているが、私が従事している金融業界においては、いまだにウォーターフォール開発が主流となっている。システム開発に携わったことのない方もいるかもしれないので、軽く説明すると、ウォーターフォール開発とは要件定義->外部設計->内部設計->開発->単体テスト->結合テスト->総合テスト->ユーザーテスト->本番リリースという手順を段階を追って踏んでいく開発手法となる。一方、アジャイル開発はウォーターフォールの一連の開発工程を２週間ぐらいの短期間で行い、それを何度か繰り返す開発手法だ。アジャイルは私自身があまり詳しくないので記載はしないが、ウォーターフォールの欠点を補う開発手法と言える。
　ウォーターフォールは開発工程を上から下に水が流れるごとく行うため、基本的に「手戻りは発生しない」前提で開発を行うが、これがソフトウェア開発と相性が悪い。他業界の人によっては、アジャイル開発にすればいいじゃん。。と思う人もいるようだが、金融業界はシステム投資規模の大きさに加え、ベンダーに丸投げ体質・新しいプロセスに消極的といった業界であるため、アジャイル開発はごく一部の採用に留まっている。
　さて、話を設計書に戻すが、開発に着手しても、手戻りは発生するので、設計書もその都度修正することになり、この作業にロードがかかってしまっており、個人的には非常に勿体無いと思う。
　個人的な考えとしてはプログラム修正やテストをやってみて、一通り問題なければ、設計書を修正するといった逆の流れにした方が生産性は高い。（この場合、内製開発で自社に開発エンジニアを確保する必要性が出てくるが。）
　では、なぜこうできないのか？
答えはいくつか考えられるが、マインド視点で回答をすると設計書は「誰がみてもわかるように細かく、正確に記載するもの」という固定概念がユーザー側、Sler側双方にあるように思う。そのせいもあるが、設計書の文章の「てにをは」を異様に気にするのに加え、資料の体裁（フォントや文字ポイントなど）に異様に細かくこだわる文化がある。（特に金融はその傾向が強い。）
　ここ数年はどこの会社も生産性を向上させろ！と言われることが多いがだったら、こんな生産性の低いことはなるべくやらないようにするべきだと個人的に思う。

いいかげんGit使おうぜ。

　そして、設計書関連でもう一つ時間を取られることがある。
それがバージョン管理だ。世の中ではGitがバージョン管理のデフォルトスタンダードになっているが、金融業界ではほとんど使われていない。
　これは本当に謎で、私もなぜ使わないのか理由がわからないが、おそらくセキュリティ上の漠然とした懸念があるのではないかと思う。ただ、このご時世でGitを使用しないのは従業員のスキルが上昇しない原因になることに加え、バージョン管理のための管理表をいちいち作成したり、別案件開発で同じ設計書を修正することを考慮して、フォルダを分けて管理するなど煩雑な管理方法を考慮しなくてはならない。
　そして、これらの煩雑な作業を行うのに、またかなりの時間を消費することになる。こんなことにロードを取られるぐらいならGit使わせて欲しいが、現場の声は届かず、部長クラスからすると、「セキュリティ上のリスクが否めない」という理由で原始時代のような管理方法を取らされるオチなのだが、それなら生産性の向上や業務効率化を現場に強要しないで欲しい。
　まあ、個人的には「いいかげんGit使おうぜ」と言いたいのが本音だが、果たしていつまでこんなことが続けられるだろうか？と思う日々である。