オブジェクト倶楽部2006(冬)

オブジェクト倶楽部2006(冬)

• 1.
  プロマネが TDD と上手に付き合う方法～技術は管理できない～ オブジェクト倶楽部 2006 冬 永和システムマネジメント 岡島 幸男
• 2.
  いきなり宣伝です テーマは今思えば、「プロジェクトと人間」
• 3.
  問題意識 今日のテーマは「プロジェクトと技術」
• 4.
  プロジェクトは文化である オープンソースコミュニティ プロジェクトには、全てそれ固有の「文化」が根付いている。会社組織 A プロジェクト B プロジェクト C プロジェクト D プロジェクト
• 5.
  人・モノ・金は環境である オープンソースコミュニティ 「プロジェクト文化」は、様々な環境要因によって特徴化される。会社組織 A プロジェクト B プロジェクト C プロジェクト D プロジェクト 事業部長 お客さま エンジニア リーダー プロマネ 予算 予算 予算 ビジネス 要求 ビジネス 要求 ユーザー 開発者 予算
• 6.
  代表的なプロジェクト文化 同じ技術を使っているが、プロジェクトの性質はかなり異なる。 「いかに優秀なエンジニアを確保するか」（サービス業的） 「いかにコストをかけずに開発をすますか」（製造業的） スポンサーの関心ごと 少数精鋭の個人 安定したチーム 開発者（社）に求められるもの 「いかにスポンサーのビジネスに貢献するか」（サービス業的） 「いかにコストをかけずに開発をすますか」（製造業的） 開発者（社）の関心ごと 生み出されたビジネスの価値 削減された経費 スポンサーにもたらされる価値 スピード・目新しさ 品質・確実さ 成果物に重視される要素 ビジネス価値の一部 受注金額 － かかった経費 開発者（社）にもたらされる価値 漸次改善型 低い ビジネスに対する投資 （新しい「作業」を生み出す） IT 業界文化 事前計画型 マネジメント （比較的）高い 見積可能性 経費削減 （手作業の自動化） スポンサー（エンドユーザー）の目的 SI 業界文化 私の属する文化
• 7.
  技術トレンドはミームである オープンソースコミュニティ ミームは「概念の遺伝子」で、人の心を媒介にして進化し、互いに融合したり競合したりする。会社組織 A プロジェクト B プロジェクト C プロジェクト D プロジェクト 「 TDD 命」 「 PF は必要だ」 「アジャイル最高」 ミーム (meme) とは、いわゆる文化的遺伝子で文化内の「変異」が「遺伝 ( 伝達 ) 」的に承継され、「自然選択 ( 淘汰 ) 」される様子を進化になぞらえたとき、遺伝子に相当する仮想の主体である。例として災害時に飛び交うデマ、流行語、ファッション、言語など、すべてミームという仮想の主体を用いて説明できるとする。 (Wikipedia) 「ウォーターフォールありき」 「オープンソースの業務利用」 技術は人が広めるのでなく、「人を利用して広まる」。という逆転した視点が大事。
• 8.
  ミームとの付き合い方 ミームの進化や、生き残りの可否は、その文化の環境要因によって決まる 「プロジェクトにはリーダーが必要」は、ほとんどの文化に適応する強いミームであるたとえプロマネであっても、作用できない環境要因がある お客さまは変えられない 一度決まった予算はなかなか変えられない 文化に技術が根付くには、その技術を含むミームそれ自身が環境に適応し、競合するミームに勝たなくてはならない 例えば「 TDD は必要」というミームと、「 TDD は時間の無駄である」というミームは競合する どちらが勝ち残るかは、そのプロジェクト文化固有の環境により決まる ただし、プロマネは、その文化の中で特に強い影響力を持つある種の環境要因である だから、ある特定のミームに肩入れしたり、進化を誘導することは可能 プロマネにできることは、 操作可能な環境要因をチューニングすること 予算・工数を多少多めに見積もる メンバーを教育する・入れ替える ミームの持つ技術を正しく評価し、より広まりやすくすること 自分が良いと信じる（感染された）ミームを見つけること ミームは完全には管理できない。より有用で強いミームに進化するのをサポートせよ。
• 9.
  「 TDD は必要」ミームとの付き合い方ミームの本質を理解し、強みを分析せよ TDD はエンジニアにとっては「設計行為」であり、良い設計を促す 繰り返し実施可能なテストは、品質を担保し、無駄なドキュメントを省く効果もある。 ミームの感染源（あるいは感染先）である現場のエンジニアに相談せよ 「テストは当たり前！」 「テストがないと安心できない」 「でも、切羽詰ると省略しちゃうこともある」 「納品用にテストを書くのはむなしい」 自分のプロジェクトに取り込んだときの影響をよく考えよ テストを書く分、見かけ上の工数は増えるんでは？（契約前の見積時には想定してない工数だよ） ドキュメント ( 紙のテスト仕様書や設計書）って、納品対象では？ 競合するミーム（「 TDD は時間の無駄」）のことも意識し、弱らせる手をうて テストを書くのにかかった時間を実績としてきっちり記録する 工数が増える分は、「保守フェーズへの投資」だとみなす戦略をとる 成果・効果を計測し、評価する 見積と実績を比較・分析し、次のフェーズ、次のプロジェクト用の基礎データとする
• 10.
  現時点での気付きと今後の課題
• 11.
  計画時点で TDD を前提とする必要があるとあるプロジェクトの実績データの一部 プロジェクト計画時には、それを前提に余裕を持った計画を行う必要がありそうだ。 具体的には、見積工数の最大 1.2 倍で考える。例えば、 10 人月（ 2 名 X5 ヶ月）と見積もったなら、 12 人月分の人間を用意する。（期間は変わらないので、約 2.5 名 X5 人月） この分の工数は、 今後の保守コスト（保守担当の心理的な面も考えて）を考えればペイできるはず また、推敲フェーズ時の予算は多めにみておく。（残業が増える可能性高し） ハマリ時間は除外する この時間が、見た目上増える工数
• 12.
  テストの費用（工数）は、保守フェーズへの投資と考える テストの費用（工数）は、保守フェーズへの投資と考えればうまくいきそうだ。 カバレッジの高いテスト（UI 自動テストも含む）は、保守担当にとっては、とてもありがたい。 加えて、きっちりとメンテナンスされたドキュメントもありがたい。テスト資産と設計ドキュメント資産のバランスを取る。 ドキュメントの記述粒度は、 「保守担当者が読んだだけで理解できるかどうか」 を判断基準とする。 Selenium ちなみに、「 Selenium を使う」ミームは、現在勢力を強め、進化している最中。 最初は、単純な入力チェックに利用 次第に、ロジックのチェックにも利用 ユーザーエクステンションの活用が流行 -> さらに、チーム内に感染している
• 13.
  記録された実績は、いろいろと役に立つ 実績を記録するのはとても役に立つ コラボレーション感のある管理ツール、および「壁」を活用し、「管理されている」感を軽減 実績データがあれば、見積に対する信頼感がとても強くなる プロジェクトを通じて実績値を蓄積することで、次の類似プロジェクトでは、かなり精緻に見積もれるはず dotProject ちなみに、「 dotProject を使う」ミームは、現在勢力を弱めている 仕様変更、追加などによる頻繁にスケジュールの調整を行った 割り込みタスクが増え、実績の記録が難しくなった -> プロマネが指示することによりなんとか生きながらえている
• 14.
  （参考）「ペースメーカー」を壁に貼る 実績をベースに、工程（基本設計・実装・テスト他）ごとに必要な時間が割り出せる -> これを開発メンバーに「ペースメーカー」として公開することで、過剰な前倒しを防げる
• 15.
  よい文化を継承する プロジェクトという文化は、開発メンバーが去った後でも残っている 成果物（TDD の優れたテスト資産）は、「遺伝子」として、プロジェクト文化に残る 保守メンバーには、このテスト資産を通じてそのプロジェクトの文化が継承される そして、このプロジェクト文化は、さらに上位の文化にミームを通じて継承される プロジェクトから他のプロジェクト、あるいは会社組織へ