読者です 読者をやめる 読者になる 読者になる

Natural Software

KinectなどのDepthセンサーを中心に活動しています

Tech Fielders セミナー 東京 [Agile Day] に行ってきました #msagile

勉強会 scrum

Tech Fielders セミナー 東京 [Agile Day] に行ってきました。
1/22(金) Agile Day | これから知りたい、きっかけを作りたい、取り組みたい方に参加いただきたい! - 長沢智治のライフサイクルブログ - Site Home - MSDN Blogs
#サイトが期限切れで表示できないので長沢さんのblogにリンク。


まずは長沢さん、三井さん、江端さんそしてLT登壇者の皆さん、素晴らしいイベントをありがとうございます。
本当に楽しかったです:)

アジェンダ

  1. 『アジリティを向上させるためにマイクロソフトが行ったこと 〜 Visual Studio 開発部門の場合 〜』 @長沢さん
  2. 『開発現場でのムダ取り・改善活動』 @三井さん
  3. 『あなたにとって、アジャイルとは何ですか?』 @ id:ebacky さん
  4. LT1・アジャイル開発 まずは社内の誤解に立ち向かえ @ id:ryuzee さん
  5. LT2・TDD ってどんな感じ? @ biac さん
  6. LT3・「アジャイル開発現在進行形」 @ 永瀬さん
  7. 懇親会(本番)

『アジリティを向上させるためにマイクロソフトが行ったこと 〜 Visual Studio 開発部門の場合 〜』 @長沢さん

マイクロソフトVisual Studio 開発を例にする。

マイクロソフトの取り組みとして、Engineering Excellence がある。これはエンジニアの取り組みの中で良いものを共有することで、専門の部隊が用意されている。この部隊がいることによってマイクロソフト社内では常に改善活動がなされている。

バリューアップ

またマイクロソフトではアジリティを向上させるために、トップダウンボトムアップといった開発者視点ではなく「バリューアップ」として「顧客に対する価値の向上」を目指している。
バリューアップとは(アジャイルプロジェクトマネージメント宣言)

  • タスク達成率ではなく、価値を測定
  • 価値を基準にした組織運営、意思決定
  • 価値=投資収益率、信頼関係、透明性、個人力、責任の共有、状況に応じた戦略

情報リソースとして「Visual Studio Team Systemで実践するソフトウェアエンジニアリング ― 成功する開発プロジェクト運営のために」がある。

VISUAL STUDIO TEAM SYSTEMで実践するソフトウェアエンジニアリンク

VISUAL STUDIO TEAM SYSTEMで実践するソフトウェアエンジニアリンク

マイクロソフトの階層構造

マイクロソフトではライフサイクルを計画と実行で段階的に分けている

  • 計画
    • Value Pro:ビジョンや主要なテーマ
    • Feature Group:投資効果や顧客価値の大きい領域
    • Feature:シナリオの実現方法
  • 実装
    • Deliverable:コード単位の実装方法
    • Task & Bugs:実行するための個別の作業単位

これを基準に、WindowsやOffice、SQLServer ごと、製品に合った階層構造を作り上げている。
このプロセスは閉じたものではなく、MPT(Microsoft Process Template)としてTFSのプロセステンプレートとして公開されている。
TFSのプロセステンプレートには先のMTPのほかにもScrumを実装する Agile Software Development もある。

TFS(Team Foundation Server) の意義

タスク管理、バージョン管理、バク管理など、個別のツールを使用するとそれぞれの学習コストと、連携のコストがかかる。これをオールインワンパッケージとすることで、学習コストの低減を狙う。
実際にマイクロソフト社内での TFS 使用実績は年々右肩上がりである、多くのプロジェクトで利用されている。
また、自社の製品を自社で使用するドックフードと呼ばれる方法をとっており、TFS の最大のユーザー企業はマイクロソフト自身。

Visual Studio 2005 と 2008 の開発期間、バグの比較

Visual Studio 2005 ではたび重なる延期と(計画24カ月、実績39カ月)、多くのバグが負債となった。
Visual Studio 2008 では、"Get Clean, Stay Clean(キレイにする、キレイを保つ)"を目標に、新規開発を4カ月中断しバグの根絶を図った。
同時にアジャイル開発や、透明性の維持など新しいスタイルへのチャンレンジも行い、その結果 Visual Studio 2005 から2年以内のリリースを達成することができた。
Visual Studio 2008 での計画レベルの Feature 数は 1,200 にのぼる

まとめ
  • リスクは正直に
  • 成功へ実現可能なものを少しずつ
  • レポート可能な状況を作る

『開発現場でのムダ取り・改善活動』 @三井さん

作成されたソフトウェアの機能のうち65% は使用されていない。
TPS(トヨタ生産方式)を参考に。TPS とアジャイルとの比較を載せたので後で見ておいて。


ムダの排除には、誤解を生まないこと。
一人での作業は思考のムダを生むので、二人一組での作業を行う。
タイムボックスと呼ばれる日々の時間記録を行うのもよい。

改善とは

改善とは不断の努力。決して止めることはしない。


改善の例として

  • 大きな企業で模造紙を出しっぱなしにできないような場合、日中は模造紙を壁にはっておき帰るときにカギのついたところにしまう。そのうちに上司が理解を示してくれれば社内のルールを変えることもできる。
  • 毎週の振り返り。KPTを行うことで改善する
  • 管理者は芸能人のようなマネージャー(引っ張るのではなく、後押しする)を目指す
提案型のソフトウェア開発

開発者がリズムをつかみ日々改善していくことで、顧客に対して受け身ではなく、提案型の開発に変えることができる

継続して成功するために

成功例をそのままもっていてはだめ。チームを考え、チームにあったやり方で開発する。

アジャイルの誤解

アジャイルCMMIやISO9001 といったプロセスが合わない?

『あなたにとって、アジャイルとは何ですか?』 @ id:ebacky さん

ebacky way
アジャイル銀の弾丸ではない、今日の話も銀の弾丸ではない
アジャイルとはなんですか?×5
id:cnaos さんがこの問いに対する答えを書いていたのでマネっこ:)

  1. 最初の質問「アジャイルとは何か?」
  2. アジャイルなソフトウェア開発のためのマニフェストを読んだ後での「アジャイルとは何か?」
  3. アジャイルソフトウェアの12の原則を読んだあとでの「アジャイルとは何か?」
  4. IT用語辞典「アジャイル」を読んだあとでの「アジャイルとは何か?」
  5. アジャイルの押しつけを読んだあとでの「アジャイルとは何か?」
アジャイルの押しつけ(Martin Fowler's Bliki in Japanese - アジャイルの押し付け

普段アジャイルの押し付けは良くないが、時と場合によってはそれが良い場合がある。
それは学習段階、すなわち「守破離」の「守」の状態のとき。このときは押しつけが良いがほかの場合では良くない。


われわれにできることはアジャイルとは何かを説明できること。
説得ではなく説明できること。

LT1・アジャイル開発 まずは社内の誤解に立ち向かえ @ id:ryuzee さん

Agile Day参加レポート(1/22 マイクロソフト) | Ryuzee.com

  1. アジャイルだから計画立てないんだよね
    • んなこたぁない
  2. アジャイルだからドキュメント作らないよね
    • んなこたぁない
  3. ウォーターフォールより早く終わるよね
    • 「終わる」の定義次第
  4. ウォーターフォールより安くできるよね
    • 「終わる」の定義次第
  5. アジャイルだから仕様変更は自由だよね
    • 完全に自由ではない
  6. アジャイルだから画面から決めるんだよね
    • ちがうよー!
  7. 同時並行で複数の案件ができるよね
    • んなこたぁない
  8. 全部一人でやるんでしょ
    • チームだよ!
  9. たまに朝会行くから状況教えてね
    • いいけど発言権はないよー

LT2・TDD ってどんな感じ? @ biac さん

[お知らせ] Tech Fielders セミナーの資料を掲載しました: TDD.NET
FuzzBizz を TDD でやってみる。

LT3・「アジャイル開発現在進行形」 @ 永瀬さん

アジャイル開発を自社に導入する際にやったこと

  1. 自分自身は猛勉強
  2. 上司を見方に
  3. 上司にはアジャイルと言わない
  4. お客様にはアジャイルと言わない
  5. 社内(特に若手) に見せびらかす

まとめ

どのセッションも素晴らしく有意義な時間を過ごすことができました。
特に ebacky さんおワークショップでは、意地悪な顧客役に悩まされ頭がうにうにの状態になりました。
ゴールも見えず、意図もやることも分からず、もやもやしながらワークショップを行っていた方もいるでしょう。


それでもきっと終わったころには皆さんそれぞれに気づきがあったのではないでしょうか?
それがたとえ主催者が意図したものではなかったとしても、気付きがあったことが一つの成功なんだと思います。


僕が得た気づきは上記のことです。

そうそう

懇親会で ebacky さんから聞いたこと(意訳)
「今日はプロセスの話をしたけど、技術が大事ではないとは一言も言ってない。技術とプロセスは車輪の両輪で、両方そろわないと幸せにはなれない」

あと

なんとなくアジャイルを叫ぶ人が哲学っぽくなるのがわかった気がする。
人もいいけど、作成すべきはソフトウェア。これを忘れないようにしないと。。。
人とソフトも車輪の両輪ですね。