見える化ディスプレイコンテスト 全国各地の見える化大集合 今回の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人。
そうしてできあがったのが・・・
これだ!
右下に見えるのは自己紹介でつくったマインドマップ。
チームメンバーのことをもっとしろう!ということで作ってみましたが、今度、自分のチームでやってみようと思います。
また、イテレーションやふりかえりの重要性を認識したので、継続してチームに注入しようと思います。
変化を受け入れるアジャイルなプロジェクトマネジメントと現場
西村さんのお話はなにかとコメントしづらかったりするのでまたこんど。
グロースエクスパートナーズ株式会社の鈴木 雄介氏の話から。鈴木さんのお仕事は、びっくりするぐらい自分のやっていることに似ていました。
- ユーザ企業にとっての標準化
- ユーザと作り手は違う視点を持っている
- 同じモノがないなら同じコトをしても同じ品質にならない
- 標準化
- プロセス、内部構造
- 大規模と小規模
- 汎用と特殊
- それぞれによって対応する開発は異なってくる
- 標準化とは、新しい仕事のスタイルを考える事
- 開発方法論に縛られた議論はダメ
- ノウハウは様々な視点が必要
- 言うだけでできる人はいない
- 自然にやってもらう=傾向性を考えることが重要
- アセスメントの向上
- プロセス品質の適正化
- 要因流動性の向上
- 人とノウハウの移動
- エンタープライズ要件にマッチするツールかどうかが判断基準
- 新しいツールを使いたいとなったら?
- セキュリティ面などの精査を行う
- そういう情報が入ってくることが重要
- ツールの効果測定は?
- コミットログなど、提供しているものから取得できるもの
鈴木さんの考え方がすごいなと思いました。
的確に適切な言葉、ソリューションを考えている。
自分は直感的なところがあるので、説明が下手くそな部分があるのですが、「これはこうだからこうなのだ」と論理的に話されると、「なるほど、しっくりきた」と思っちゃいます。
考えを言葉にし人に語りかけるスキルをもっと身につけないと!
私も標準化とかをやっている部署で働いているのですが、自分自身が標準化なんて大嫌い!なので、どうしたものかと悩んだりしました(今もたまに悩む)。
そこで考えたのが鈴木さんのおっしゃる「傾向化」というもの。
「こうやってください」といっても人はなかなか動かず、「こっちの水が甘いですよー」というしかないという結論をもとに編み出した作戦です。
最近は成果がではじめちょっと嬉しい感じなのですが、これからも気を抜かず傾向をつかんでいく必要がある。がんばろう。
鈴木さんの話は、資料(公開されれば・・・)そのままチームに話せる内容なので、これもプレゼン練習でコピープレゼンしよう。
- プロダクトとプロセスへの興味が交代している
- ソフトウェア工学でもっとも確かな考え
- 再発明をしちゃう
- 再発見するもの
- 全体観を取り戻せ
- シナリオ化>レビュー
- モデル化
- よいアーキテクチャ > 公共の価値
- テスト&レビュー > アーキテクチャ大切
- プロセス改善 > 要求大切
- 全体を見れなかったらだめ
民俗学者宮本常一さんの話が興味深かった。
「自分の目で見たものを信じる」というのが、Agile Japan2010で一番多く聞いた言葉だったかもしれない。
体験しよう!考えよう!行動しよう!
がテーマになっていたが、体験と考えるはこのイベントや終わってからでもできること。また、できたことかもしれない。しかし、やっぱり行動しないと始まらないんだなきっと。
Agile Japanで得た価値を持ってかえって大きくしよう。
*
以下、参考。会場の雰囲気がわかります。