アリスです。
日本のソフトウェア開発は生産性が低いといわれます。
欧米人はそんなに賢いのでしょうか？
ちがいます。
実は多くの日本人が行っている開発方法に問題があるのです。
生産性が高いといわれているドイツでは、
ドキュメントは最低限のみで、
ほとんどかかないのです。
いかに日本人が無駄なことをしているか！
ということですね。
あなたも、無駄なドキュメントにたくさんの工数を使っていませんか？
きっと身に覚えがあると思います。
ソフトウェア開発は、
分析→設計→実装→試験の流れで作業を行います。
一般論ですね。
しかし、この手順通りにキチッと実施しているがために、
多くのプロジェクトはデスマーチを歩んでいる。
デスマーチとは、死への進行と略すけど、
その名の通り、プロジェクトが納期までに終わらない、
納期になってもバグだらけ
といった悲惨なプロジェクトのことである。
この原因の多くは、分析、設計フェーズに問題があると、
私のこれまでの経験上、断言できる。
分析、設計フェーズで、
想定していなかったことや考えきれていなかったことが
実装時に判明し、手戻りや再設計を行う。
その結果ソースコードも当初の設計思想を逸脱していき、
読みにくい汚いコードができあがる。
設計というのは机上の空想なので、
どうしても抜けがでたり、考慮漏れがあるものなのだ。
いくら紙にしっかり書いたところで、所詮絵空事である。
そこで、私は実装から進める開発を提案する。
ソフトウェア業界の人間であれば、
実装から行う開発がいかに非常識であるかわかると思う。
私はこれまで様々な書籍をみたが、
そんなことを提案している書籍は一冊もなかった。
だからこそ、提案したい。
私はこの方法に変えてから、飛躍的に生産性があがった。
また、失敗したことがない。
プログラミングをするということは
とてもクリエィティブな作業のため、
脳みそが活性化し、
どんどんよいアイディアが浮かんでくる。
また、技術的にもできないこととできることが
すぐにわかるため、
すぐに別の方法に切り替えることができる。
具体的な手順を記載する。
１．仕様書を読み込む。
２．仕様書を読み込んだら、具体的に何をすべきかを、箇条書きでいいのでとりあえずまとめる。
３．実装を開始する。まずは枠組みから作る。関数など。
４．箇条書きにした内容をみつつ、できるところから作っていく。
５．できるところがひと通り終わったら、一旦終了。
６．この段階で、できないところがなぜできないのかを分析する。最もよくあるのが、仕様があいまいでどうすべきかがわからない。この場合は、仕様を書いた人に質問して明確にする。技術的に難しいのであれば、どうすればできるのかをネットなどで調べる。
７．６で技術的な課題や、あいまいな点はすべてスッキリさせることができれば、プロジェクトは成功したようなもの。
８．７まででプロトタイプはできあがっており、実装も７割近く終わっているはず。そこまできてから、やっと設計書を書き始める。
設計書がすらすらとかけるはずだ。
９．後は、一般的にいわれているソフトウェア開発の手順通りに進める。
この方法のメリットは簡単。
まず、プロトタイプをつくることで、
はやく動くものを提供できる。
また、プロトタイプと言っても、
一般的にいわれているプロトタイプではなくて、
ある程度作りこんだプロトタイプなので、
技術的な不明点や仕様の曖昧な箇所は明確になっている。
これがとても重要。
そうはいっても、結局頭のかたい人によって、
通常のプロジェクトでは
絶対こんなやり方は認められないだろう。
だから、このやり方は絶対に提案してはいけない。
個人で仕事をする場合に、密かにこのやり方で進めるのだ。
自分は、仕事でアプリ開発の際には
このやり方を実践している。
アプリ開発は一人でやることが多いからである。（^^）
例えば、ドイツではソフトウェアの設計書というものは
ほとんどかかないみたいである。