昨日(1/22)MicrosoftのAgile Dayに行ってきた
皆様お疲れ様でした。
イベントレポートって何をかけばいいんだろ？とりあえず、個人的な感想とふりかえりを中心に書きます。
また、勝手な解釈が混じっている事を先にお詫びします。イタリック青字の部分は私の考えなどです。
見た感じ、スーツ率高い、参加している人はプロジェクトリーダ/マネージャが多いみたい。また、実際に現場でアジャイル開発に取り組まれている方が多いような感じがしたけど、実際のところどうだったんだろう。
私の立場
セッションごとに印象に残ったこと
セッション１：アジリティを向上させるためにマイクロソフトが行ったこと〜Visual Studio 開発部門の場合〜
長沢さんのセッション。マイクロソフトでのアジャイルな取り組みについて。
大規模な製品開発（VisualStudioの開発）にアジャイルを取り入れた事例の紹介。
ちょっとまとめきれないので、印象に残ったところだけ書き出したけど、ヒントがいっぱい詰まっていそう。
- VisualStudio2008の開発では新規開発を中断し、既存バグの根絶に集中した。
- 標語は"Get Clean, Stay Clean"
- ジョエルテスト#5「新しいコードを書くまえにバグを修正するか？」に通じる話。
- リスク報告の正直さHonestlyが大事
- 大雪のためスケジュールが遅延するなんて事まで書いてある。
TeamFoundationServerってどんなツールなんだろう。
セッション２：「開発現場でのムダ取り・改善活動」
三井さんのセッション。
アジャイルの成功事例をベースに、どういった改善活動をおこなったのかを紹介。
- 時間が有言実行の障害になる。
- 前に言った事でも、時間がたつと誤解されやすくなる。
- ウォーターフォールは正解主義、アジャイルは適応主義。
- 現時点で分かっている情報を元に仮説を立てる。
- アジャイルでのマネージメントの役割は管理ではない、自律の手助け。
- 数値はとってもいいけど、管理に使うな。
- アーキテクチャ分析は最初にチーム全員でやる。
- ゴールの共有、仕様の理解のため？
- 「初めてのアジャイル開発 ?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方?」でも以下のように述べられている。
最新のIID手法では、開発構想書および「概要レベル要求のトップ10」一覧の作成や、負荷やユーザビリティや多言語化といったアーキテクチャに大きな影響を及ぼすような要因の分析を、早い段階でベースライン化するよう推奨している。
- 問題が起こったとき、「お前なにやってんだよ！」ではなくて、「ちょっと教えてくれる？」で情報を引き出す。
- セッション１で出ていたリスク報告の正直さを保つために必要な態度だろう。
- たとえば、指先に熱いものが触れていて、それが脳に報告されなかったら、大やけどする。
- 神経が正直に情報を伝えるから反射的に手を引っ込めることが出来る。
- リスクを見逃さないために正直さがプロジェクト必要なのかも。
- 怒れるマネージャはもらいが少ない。
セッションの内容ではないけど、懇親会の時に聞いた、受託開発でのアジャイル成功事例はおもしろかった。ドキュメンタリーとして読みたい。
セッション３：「あなたにとって、アジャイルとは何ですか？」
江端さんのワークショップ。
アジャイルは押しつけではうまくいかない。プロジェクトメンバーが自律的に動かないとうまくいかない。
ということで、「自律的に考える」、「改善するにはどうしたらよいかを考える」といったことを体感するワークショップだった。と都合良く解釈する。
「このワークショップの目的＝ゴールは何か」を明らかにした方が、参加者が自律的に考える手助けになって、もっと良くなったかも。
- アジャイルは銀の弾丸ではない
- 分かっているつもりだけど、豆の弾丸しか持ってない自分には、銀の弾丸に見えてしまう。
- 「アジャイルと規律 ?ソフトウエア開発を成功させる２つの鍵のバランス?」では銀の弾丸ではないが、普通のオオカミならば殺せる鉛の弾丸と称していた。
- 最後にで述べられた次の一文はとても良かった。
現場や開発チームにいるのも人。
ソフトウェアを利用するのも人。仕事で開発すべきことも人に繋がっている。
人から目を離し、人を無視しても価値を生むことはできない。
問題の原因はツールや技術ではなく人間に依存する。
-
- 「ソフトウェアを作るほとんどの工程には人間が関わっている。だから、いかにヒューマンエラーを減らすかがムダを削減するために重要になってくるのではないか。」という持論に通じるものがあった。
- ピープルウェアを読み直してみよう。
ワークショップでの「アジャイルとは何か？」という問いのメモを公開してみる。
- 最初の質問「アジャイルとは何か？」
- 自律的
- 適応的
- 早いフィードバック
- ムダを少なく
- ちゃんと計画・設計する。
- ゴールの共有
- アジャイルなソフトウェア開発のためのマニフェストを読んだ後での「アジャイルとは何か？」
- 協調して動く事
- アジャイルソフトウェアの12の原則を読んだあとでの「アジャイルとは何か？」
- ヒューマンエラーを少なくする
- 手作業を行わない
- 会話---誤解を少なくする
- 一定のペース
- 開発プロセスに関する価値観の改革
- 価値を高める、価値を濃縮する。
- IT用語辞典「アジャイル」を読んだあとでの「アジャイルとは何か？」
- 誤解が多い開発手法
- いろいろな解釈をされるもの
- アジャイルの押しつけを読んだあとでの「アジャイルとは何か？」
- 哲学・思想・考え方
- 型になれるまではそれに従う、その後は自分で発展させていく。
ライトニングトーク
C#のコードは初めてだけど、内容は分かった。VisualStudio2010のベータ版もらってきたので、試してみよう。実際の開発だとコードが先に書いてしまいがちなんだけど、それを予防するにはどうしたらいいんだろう。
現時点で日本国内では、アジャイルに対する誤解が少なからずある事、そしてその対処が必須であることを実感。そのために、お客さんや監査部門に対して「アジャイル」という言葉を使わない、なんて対策が必要になってしまっている業界の現状がとても残念。これまでのプロセスを定義して、マネージャが管理するっていうやり方の反対側にあるやり方なので、なかなか浸透しにくいのかも。
次は上司同伴のイベントがいいんじゃないかという話が出ていたけど、上司だけでなくお客さんも同伴して、アジャイルとは何か、アジャイルに対しての誤解を解く、アジャイルに対しての共通認識を作るみたいなイベントにしたらいいんじゃないだろうか。まずはアジャイルについて持っているイメージを列挙してもらって、みたいな。
懇親会
おもしろそうな話しているところに近づいて、こっそり会話している内容を聞いて回った。
名刺を作っておけば良かった。
懇親会が終わった後の片づけ
「机の移動を手伝っていただけませんか」というお願いで、残っていた参加者で適当に片づけを始める。
ゴールは会場の復元、床にある白い目印に机の位置を合せる。
という感じでみんな勝手に机やいすを移動し始める。うーん自律的だ。
