システム開発の工程
システム開発をしていて、
| 工程 | 割合 |
|---|---|
| 基本設計 | 30% |
| 詳細設計 | 30% |
| プログラミング工程 | 30% |
| テスト | 10% |
という工程を耳にすることが多い。
cf.http://www.newspt.co.jp/contents/manual/yes/2_mi/3a02_1.html
Excel方眼紙の落書きが設計だっていわれても
ウォーターフォールを標榜している開発現場では、この基本設計がExcel方眼紙とほぼ一致しているというのが悩ましいところだ。
これまでざっくり25くらいのシステム開発をしてきた。
| 方式 | 累積 | 件数 |
|---|---|---|
| アジャイル | ●●●●〇●●●●〇●●●●〇 | 15 |
| 調査 | ●●● | 3 |
| テスト駆動 | ● | 1 |
| ウォーターフォール(Excel) | ●●● | 3 |
| ウォーターフォール(md,doc+Excel) | ●●● | 3 |
意図的にアジャイル開発を選んでいるので、アジャイル開発の比重は高い。
システムとしては、Database(各種SQL)とView(html, Xaml, JavaScript, css, etc.)、コントロール部分(C#)という構成。WPF, ASP.NETとか。
CodeFirstでコードからすべて作る
わたしがアジャイル開発をする場合、CodeFirstでModelのクラスを作り、その作業自体がテーブル設計を兼ねている。
Modelを作るとその瞬間に動作するDatabaseのテーブルとテーブル定義書とER図(クラス図)を手にすることができる。Model2TableDefinitionは自作ずみで、ER図(クラス図)はVisual Studioにその機能がある。
Modelを変更すると、ER図(クラス図)、Databaseのテーブル、テーブル定義書はほぼ手間なく連動するので、これらのドキュメントはほぼ常に最新の状態に苦もなく保てる。
やっぱりExcel方眼紙を理解できない
この方法に慣れていると、ウォーターフォールでExcel方眼紙を使ってテーブル定義書とER図(クラス図)を書くことを「設計」と呼ぶ考え方を理解できない。
Excel方眼紙の結合セルにコピー&ペーストを駆使して書いたテーブル定義書は、そのままではコードに流用しにくく、しばしばtypoがあり、Databaseのtypeにミスがあり、すんなり動かすことはできない。そもそも動かすためのコードへの置き換えのところで相当な試行錯誤が必要なことがある。2度手間なのである。
CodeFirstなら常に動く
CodeFirstではtypoはあるかもしれないが、typeのミスは開発環境が防いでくれるので発生しない。
さらにコーディングでテーブルを修正した場合、コードとExcel方眼紙のテーブル定義書を2重に保守し続ける必要があり、しばしば途中でバージョン管理できなくなり、メンバーとの間で深刻な精神的な対立を引き起こす。
Excel職人
クラス図をExcelで描くのはほとんど職人芸で、見とれるが、同様にそのままではコードに流用しにくく、しばしばtypoがあり、typeにミスがある。そもそも職人芸なので、作った本人以外は保守できない。共有していても同時に複数人の編集は不可能ではないがまずしないし、パーミッションによってはExcelファイルが消失するというバグもある。
cf. https://support.microsoft.com/ja-jp/help/271513/troubleshoot-problems-when-you-save-excel-workbooks
cf. https://hebikuzure.wordpress.com/2009/04/12/サーバー上の共有フォルダで-excel-ファイルを上書き/
実際にこのトラブルには、Windows7 + Excel2013で2019年1月ごろに遭遇した。
こんなシステムは使えないよと真実思った。
感覚的な工数割合
それはまあそれとして、いちばん違うと感じるのは、工程の割合だ。
| 工程 | 割合 |
|---|---|
| 調査・試作 | 50% |
| アジャイルプログラミング | 10% |
| デバッグ | 20% |
| テスト | 10% |
| 設計書作成 | 10% |
というのが感覚的なイメージ。調査ももちろんプログラミング要素を含むので、プログラミングしているのが60%くらいある。
あとはそもそも調査とデバッグという重要な工程が工程にないことに、認識の差を感じる。
調査を工数に含めるか
そもそもわからないことを調べる調査にはきりがなくて時間もかかる。それをぜんたいのなかにイメージできていないとしたら、いったいいつ調査するのだろうか。
調査なしでできるということは、すべて既知の範囲で作るということか。それっておもしろいのだろうか?
デバッグはコーディング以上に重要だけれど、それを工程にしていないのはどういう理由なのか。
さっぱりわからない。
「未定」「調査中」「検討中」ばかりの設計書
調査firstで、アジャイル開発する場合、ドキュメントを作るのは最後の工程になる。最後の最後とは言わないまでも、ある程度システム全体を把握した最後だ。
この場合、ドキュメントを作るのは、わかっていることを書くだけでよいので、スムーズに進む。
初期に穴だらけの設計書を書いて保守し続けるのに較べて、ずっと容易だ。そもそも「未定」「調査中」「検討中」ばかりの設計書なんて、単なるたたき台にすぎないと思うのである。それをほしがる気持ちがわからない。