超短期開発立ち上げマニュアル

その目次のようなものを書いている。

どのように立ち上げ、どのように進め、どのように管理すれば、コミュニケーション不足にならず、品質がどん底にならず、進捗がスケジュール通りに行くか。

これは去年から実践していて、ようやくノウハウを紙に吐き出し始めた。

「仕様書の読み方」「開発の実手順」「虫食い状態の雛形」など、プログラマ集団を一気に動かして、最初の1歩を加速させて、潤沢なコミュニケーションを取りながら、納期を守る事を目標にしている。設計段階からオフショアにする方法はまた別のマニュアル。今は国内にキーマンを呼ぶ方法を取っているため、本当は入管の手続きから記しておきたかったりする。国内に呼んだキーマンと一緒に設計をし持ち帰ってもらう。そしてその後管理しに現地へ行く。いつ行った方がいいのかパターンあるが、書き出すと止まらないので後で。

実際に成功事例と失敗事例があるので、実践した限りの事と、これから実践してみたい理想論を書き出そうとしている。かなり多岐に渡るため、まとめあげた上、必用な時に見るものと、見ておくべきものに分けて、常時手元にある量を少なくしたい。じゃないと分厚いマニュアルなんて見てられないから。

発注前に準備するものや、仕様を伝達する時に必用なもの、開発中に必要な国内のインフラ、インフラの使い方まで項目を書き出してある。

インフラについては、今回初めて日本と中国からアクセスできる共通のバージョン管理システムを導入(!!)全ての資産を一括管理できるため、今までやきもきしていた事が一気に解決される。ただ、これはほとんどの会社で理想論となる可能性を否定できない。このインフラは用意できない事が多そうなので必須事項ではなく「用意できればすごく良い」ものとして書いている。

無くてもどうにかする方法も書いておきたい。というか今までは全部そうだったからむしろそっちの方が詳しい(笑)

へこたれずにこれを書き上げ、他のブリッジエンジニアと協力していろんなノウハウを書き出し、自分以外の人にも実践してもらって内容を揉む。

たぶん教科書にはならなくて「これが我々のやり方」になるんだと思う。書き出した項目がぶっちゃけてて結構笑える(苦笑)

• 設計書が間に合わない場合→体裁を気にするな→納品用の資料は後で作れ→あれとこれとそれだけあればプログラマはプログラムを作れる→必用なものだけ用意する
• 入出力設計が間に合わない→そんなものより正解のSQLを渡せ

ちなみにこれらは「ありえんやろ状態」のプロジェクトをやり遂げる方法を書いたため、全く美しくない。ありえない状態には、ありえない対処をするしかなくて、ここで理想論を言ってるようじゃ、絶対おさまらん。ということで無駄を省いた体裁を気にしない方法なども書いてある。

さーて、あとどれくらいで書きあがるかな〜♪