不況の中、利益を上げる方法は…(・・？

既に多くの皆さんが語りつくしていることですが、その意見を踏まえて自分の状況にあった開発スタイルについて考えてみました。

ここ１年近く、開発・保守生産性向上について考えてきましたが、ここにきてボンヤリと実態が見えてきました。

色々模索していたら、あったのですよ。その方法が…気付いたときには”ゾクっ”としましたね。
歓喜に震えました本当に…皆さん心して聞いてください。。。ゴクｯ

その答えは「開発プロセル」にありました！
開発前(中)は、顧客様に提出する資料以外は、軽減化しろということ。。。 ！Σ（￣ロ￣lll) ｵｾｰﾖ！
あっ!イッパイ突込みの声が、聞こえましたが無視します…(_ _;)

ビジネスにおいては、スピードが最も重要です。もう今までの様な「お大名」のような仕事は出来ないのです。
お客様の要件を、いかに「早く・安く・満足させる」かが重要なのです。。（○牛方式が大事！）
だから、開発プロセスは、軽量化したい。当たり前です。

でっ、軽量化する上で目をつけたのが、設計書。
設計書のかわりに、外部仕様のテストシナリオを書く。DDTTDDですね。
テストシナリオが設計書のかわりになる。なんて奇麗事はいいませんが、プログラムを無理やり自然語にするよりは、まともです。
このメリットは、(無理やりの自然後の)設計書を書かないことで、かなり開発のスピードが上がる。

っで、設計書を軽くした時間で、コードレビューをする時間を設ける。
もちろん、チームでなんて大げさな規模じゃない。
出来る人が、不安な人のコードを見てあげる。。。ただし、そのスパンは短いほど良い…かつ作成者の説明は最小化にする。

恐らく、こんなことを言うと、設計書LOVEの方からは、「バカいってんじゃねーヨ」とか「お前一回４ね」って言う突っ込みが聞こえましたが、やっぱり無視します…(_ _;)
その(突っ込みの)理由は、詳細な設計書を作らない(レビューしない)で、開発したら破綻する…ってね。

でもね、経験上ですが、プログラム開発後に「設計書」を書き直さないプロジェクトにかかわったことが無い！
設計書が細かければ細かいほど、大量の手直しが発生していたもの。。。

本当は最近はあった。。。（実際に見たわけではなく、協力会社の人に聞いた話）

それはすばらしく出来の設計書ではなく、ちょーアバウトな設計書（作っても作らなくても良い程度のもの）。。

開発者も頭を使ったのですね…どうせレビュー相手は理解できてないのだから、フォーマットをあわせて書けばＯＫだろーって。。。

悲しいけど、これは見事に正解だったようです。指摘があったのは、誤字と(日本語の)文法のみ…(T^T)

やっぱしな〜っと思ったことでしょう。

只、開発終了後に、別資料を作ったそうです。

少し極端な書き方をしたかもしれませんが、これ位の変化は必要な時期なのだと思います（少なくとも私の現状では）。