日本のアジャイルはここにあった！Agile Japan 2010レポート2日目

見える化ディスプレイコンテスト全国各地の見える化大集合
今回のAgile Japanで話題をさらった佐賀県の事例がディスプレイされていました。
こういう工夫をされているとうれしいですね。
佐賀県職員採用ページも一読する価値あります。地方から変わっていくのか！？

アジャイルの現状と未来、次に来るもの。?リーン開発への展望? Alan Shalloway氏

これまでのアジャイル開発をふりかえり、これからのアジャイル開発を語るキーノートでした。
以下、響いた言葉。

アジャイル開発は、プロセス改善とマネジメント改善が交互に主流になっていた
しかし、アジャイルはgoodでも、構造がないため長く続かなかったのが現状
我々はバリューストリームマップを早く回さなければならない
これまでのアジャイル開発では、マネジメントが弱かったのだ

バリューストリームのフロー
まずは見える化
障害物を考える
ワークフローをプロセスとして表す
価値と時間を考える
無駄というよりもdelay（遅れ）を除去する
その中で、人は交換可能な部品ではない
これまでの手続き重視のやり方は、交換可能な人を生み出すための仕組みが多い
それでは組織はうまく動かない

スクラムはマネジメント的なプラクティス
スクラムはBusiness＆Developer
XPは技術的なプラクティス
XPはCustomer＆Developer
マネジメントが抜けている
チームのアジリティを上げるだけでは足りない
ビジネスアジリティが必要なのだ
ビジネスアジリティには何が必要か？
明確なルールが必要なのではないか？

リーン開発
delayをなくすために無駄なものを作らない
delayはdelayを生み出す
生産性を高めるのではなくdelayを潰す
生産性に焦点をあてると逆に遅れが生じる
忙しいといわれるのは生産的ではない
タスクをうまく詰め込んでも効率的にはならない
delayが生まれるためチームに負荷をかけすぎてはいけない
リスクは常に生まれるもの
現場がリスクを回避するためのプラクティスを作り改善していくべき
delayを取り除くことで品質を高めるべき
早くするはdelayをなくすこととは違う
どうやったら早くなるか？
バリューストリームマップがdelayを見つけ出すいいプラクティスの一つである
フロー全てを俯瞰的に見ていくべき

自社でも生産性の話題はつきないのだが、いつまでたっても生産性の指標が出てこない。個人的にはFPでもLOCでもなんでもいいからやってみればいいのに、結局、お金をものさしにしようとする。
そんな難しいことは考える必要もなく、自分たちは価値をお客様に提供する仕事なのだから、バリューストリームマップのような手法は、自分たちのスピードを表すもっともわかりやすい方法に思える。
しかし、それは開発だけでなく、起案からリリースまでの全体を眺めなければ、開発だけもりあがってしまい、結果、ビジネスアジリティが上昇しない。

中でも、Shalloway氏は「無駄」という言葉ではなくdelayという言葉を多用しているところが印象に残った。
無駄といわれると怒る人も出てくると思うが、「遅れをなくそう」という掛け声はとてもわかりやすい。

知識が足りないのでアジャイル開発の本を最近読みあさっているが、最近読み終えたリーン開発の本質にはソフトウェア開発のヒントがたくさん詰まっていた。アジャイル開発の次としてリーンを紹介されていたが、Webサービスを提供する企業はアジャイル開発がやりやすいのだから、できるところから初めていけばいいはず。

SIerがやっている手法を取り入れるだけでは、アジリティは落ちる。
また、プラクティスにしばられてもアジリティは落ちる。

昨日の野中先生の話といい、Shalloway氏の話といい、会社でプロセスを整備する人たちにはぜひ聞いて感じて欲しかったので、資料が公開されたら自分が話せるように練習をしようと思う。

Agile on プロジェクトファシリテーションでイテレーション体験ワークショップ

職場の先輩が「俺、8F行く！」とおっしゃるので、僕は7Fに行ってきました。8FのFBしてくださいね！

机にレゴが置いてあったので、アジャイル on プロジェクトファシリテーションに参加。
ここでは2回のイテレーションをくりかえし、レゴを使って飛行機を完成させます。

テーマを決めて、グループ名を決めて、タスク分割をしてかんばんを作ってみて作業開始。その後、KPTで振り返って次のイテレーションに行くのですが、なによりもびっくりしたのが、2回目のイテレーションのほうがびっくりするぐらいいいものができあがるのです。

まず、チームメンバーにめぐまれたのかもしれませんが、KPTででてきてKeepは維持し、ProblemとTryを実現しようとやっきになる大人4人。
そうしてできあがったのが・・・

これだ！

右下に見えるのは自己紹介でつくったマインドマップ。
チームメンバーのことをもっとしろう！ということで作ってみましたが、今度、自分のチームでやってみようと思います。

また、イテレーションやふりかえりの重要性を認識したので、継続してチームに注入しようと思います。

変化を受け入れるアジャイルなプロジェクトマネジメントと現場
西村さんのお話はなにかとコメントしづらかったりするのでまたこんど。
グロースエクスパートナーズ株式会社の鈴木雄介氏の話から。鈴木さんのお仕事は、びっくりするぐらい自分のやっていることに似ていました。

ユーザ企業にとっての標準化
ユーザと作り手は違う視点を持っている
同じモノがないなら同じコトをしても同じ品質にならない

標準化
プロセス、内部構造
大規模と小規模
汎用と特殊
それぞれによって対応する開発は異なってくる
標準化とは、新しい仕事のスタイルを考える事

開発方法論に縛られた議論はダメ
ノウハウは様々な視点が必要
言うだけでできる人はいない
自然にやってもらう＝傾向性を考えることが重要

アセスメントの向上
プロセス品質の適正化
要因流動性の向上
人とノウハウの移動
エンタープライズ要件にマッチするツールかどうかが判断基準

新しいツールを使いたいとなったら？
セキュリティ面などの精査を行う
そういう情報が入ってくることが重要

ツールの効果測定は？
コミットログなど、提供しているものから取得できるもの

鈴木さんの考え方がすごいなと思いました。
的確に適切な言葉、ソリューションを考えている。
自分は直感的なところがあるので、説明が下手くそな部分があるのですが、「これはこうだからこうなのだ」と論理的に話されると、「なるほど、しっくりきた」と思っちゃいます。
考えを言葉にし人に語りかけるスキルをもっと身につけないと！

私も標準化とかをやっている部署で働いているのですが、自分自身が標準化なんて大嫌い！なので、どうしたものかと悩んだりしました（今もたまに悩む）。
そこで考えたのが鈴木さんのおっしゃる「傾向化」というもの。

「こうやってください」といっても人はなかなか動かず、「こっちの水が甘いですよー」というしかないという結論をもとに編み出した作戦です。
最近は成果がではじめちょっと嬉しい感じなのですが、これからも気を抜かず傾向をつかんでいく必要がある。がんばろう。

鈴木さんの話は、資料（公開されれば・・・）そのままチームに話せる内容なので、これもプレゼン練習でコピープレゼンしよう。

新時代の開発プロセスに向けて