成功するプロジェクトに変えるために

4352 ワード
単体テスト プログラム設計 ソフトウェア開発 ドキュメンテーションコスト 単体テスト テキストリンク

成功するプロジェクトに変えるために　今までに書いてきた記事の中から役立ちそうな視点の記事へのリンクをまとめてみます。

開発したい目的を、どのようにして実現していこうとするのかは、よく考えてから開発方針を決めてください。
どう失敗しやすいのかを考えることで、うまくいきやすい技術を選択することにつながればと思って書いています。
　開発の方式を選択するには、何でもかんでもきちんと評価するのは無理です。ZnSeとGaNではどちらがいいのかについて、何でもかんでもきちんと評価することができると思いますか。開発者の直感というものが重要だと思います。直感をはたらかせれば、無駄な作業をしなくて済むので、開発速度を上げることができます。

　いくつかの可能性から、どの方式を選ぶか考えるときも、「開発は、有限の時間で有限のリソースで行うものです。
少ない差し手で勝負を決めなければならないものです。」と主張して、通常の論点とは異なり、「全ての項目をきちんと評価して」、「最適な選択を」、などと言わない視点を提案しています。

自分たちの頭で考えて、自分たちの頭を信用するしか方法はありません。他人の言うことを鵜呑みにしていると「ろばを売りに行く親子」になるだけです。そもそも自分たちの頭を信用できない人は、新規の開発などすべきじゃないとさえ思います。

　さらに、次の記事では、ものごとを簡単に単純にすることの大切さを主張しています。

　開発が成功しやすくなるように、最終製品の仕様とは別に、開発段階での仕様を設定することを主張しています。

開発仕様の大枠ができてきたら、どのように設計すべきかを述べています。「実験してみなきゃ分からない」は最小限にする指導原理がある場合があること、設計の一貫性を貫くことが、成功へのキーとなりうること述べています。

現実のシステムでは、ノイズなどの影響を受けて思ったようにいかない場合が多いこと、ノイズの影響を受けにくい方式（ロバストな方式）があることを述べています。開発では「動くようにする、正しくする、速くする。」の順序の重要性を述べています。

開発に専念する時間を十分にとることが重要なので、開発者の開発時間を減らすドキュメンテーションコストを抑えることが大事です。

ひとつ一つの実験結果を成功させるためには、品質を作りこむための作業を怠ってはいけません。

マネージャーの皆さんは、どうやってプロジェクトを成功に導くのか本気で考えることです。だれか1人の力で全てが解決されることは期待できません。メンバーの力を発揮させやすくすることが大切だと主張します。

また、開発メンバーがともにスキルを上げていくことが、プロジェクトの成功には必要です。どこでも食っていけるレベルに開発メンバーのスキルをあげていくことが、結局は開発をスムーズに進むようにしていきます。（そうであっても、メンバーが自分で能力を高めようと思っていない分野について、一方的にその分野のライブラリなり手法などを紹介しても迷惑なだけで、技術の押し売りをしないように注意しておきましょう。）

まだ、ここに書いていないこととしては、プロジェクトを成功させるためには、チームの人間関係の重要性があります。
ともに同じプロジェクトを成功させようと思っているメンバーだということが、重要なポイントです。技術者が一緒にいるだけではチームとして機能しません。同じプロジェクトを成功させようと思っているということは、お互いの困っていることを助け合う関係でなくてはないません。信頼関係は、最初からあるものではなく、お互いの行動を結果作られていくものです。次の本は、メンバーの心の動きにも着目している本ですので、そういったチームを作り上げていくためのヒントが多く含まれています。

「アジャイルコーチング」

これらの視点を持つことで、開発内容が成功しやすいものに変えることができるのではないかと、私は考えています。

追記
何をどうすればうまくいくのかに気づいてもらうには、時間がかかります。
どうすればうまくいくと考えているのかを、他のメンバーや将来の参加者が、必要な情報が取り出せる環境を作っておきましょう。
将来の参加者がどのように課題を引継いだらよいのかが分かるように、課題管理システム（Redmineなど）に記録を残しておきたいものです。