Agile Conference Tokyo 2013に行ってきた。
もうね、かっこよくブログにまとめることは無理だと思い知ったので(笑)、
思ったこと感じたことをただつらつらと書くことにする。
[基調講演]
戦略としてのカンバン: ビジネスイノベーション のために
アジャイルを実践するには組織として理解していることが重要である。
ビジネスモデルに適しているか、という点から考えなければいけない。
今までの自分を投げ出せるかどうか。
IT部門を切り離しているのすら時代遅れである。
IT・ビジネス・テクノロジーが一体となっていないといけない。
ごもっともな意見である。
エンジニアリングですら実現方法の一つでしかない。
そこを踏まえて開発会社は自らの存在価値を見出していかなければいけない。
アプローチ
・リーン・スタートアップ
・ビジネスモデル・イノベーション
・継続的デリバリー
の融合へ挑戦する
そこでカンバンですよ。
ユーザストーリーの本質を考える
バックログのマネージメントをしがちになってしまう。
未来のことは書いていないことを意識しましょう。
ユーザストーリーに疑問を持つこと。
なぜ、そのストーリーが必要なのか？
そこに思考をシフトするのだ。
危機感を持っていない人はダメです。
ばらばらのものを組み上げるのがイノベーションではないっ！
［Session 1］
アジャイルな企業のTo Beモデルを提示する
Scaled Agile Framework (SAFe)のご紹介
うーむ。。
アジャイル開発の大きな魅力の一つが、
エンジニア一人ひとりがよりプロダクトの価値に密接に関わることだと思っている。
システマチックに仕上げていくことで開発が楽しくなくなってしまうのであれば、アジャイル開発の魅力そのものが失われてしまうのではないか。
・アジャイルプロセスを取り入れました！
・(生産性とか)成果出しました！
じゃ意味が無い。
少なくともそれは、僕が魅了されたアジャイル開発ではない。
大手企業は皆こんなかんじなのかな。。
［Session 2］
スクラムと品質
若手のいるチームでの成功事例。
面白かったんだけど、やっぱり少しシステマチックな香りがして。。
目指すところはボトムアップ型の自律組織であるはずなのだが、
なんだかそんな感じもしなかったな。
ただし、効率的な教育を行えるという点においてもアジャイル開発が有効だってことの裏付けにはなる講演。
あとね、やっぱりプロダクトの価値向上についてが語られない。
個人的にそこがとても大事なんだと思うんだけどな。
ドキュメントよりソフトウェアに価値を置くという思想は、
そもそもそこから来てるんでしょ？
［特別講演］
エンタープライズ規模におけるカンバンの運用
これが今回一番面白かった！
上司が変わると仕事のやり方が変わるのは嫌だ。
そう、だから現場からボトムアップしていくのだ。
かんばんは改善のためだけの道具ではない。
仕事を整流化する。
滞留する真因は何なのか。
それを明らかにすることに本質がある。
改善の目的とは、
・全社的な人作り
・共通な価値観
・共通な仕事の仕方
所詮組織を形成するのは人なのである。
個人のモチベーションが上がるようにしないといけない。
常にやり方を変えていくんだ。
毎日がイノベートなんだっ！
開発だけでなく営業戦略につながるカンバン。
組織横断なアジャイル。
やっぱり一気通貫の世界は憧れるな。。
導入はやはり上層部とコンセンサスをとっておくのが理想。
そもそも今の組織を変えたいか変えたくないか。
支える人がいないと続かない。
振り返りは業務観点だけじゃない。
ここでも人重視。いいなぁ。
KPTで発言が出てこないなら、それがチームの問題である
改善したいという思いがあるのか？
挨拶、勤務態度など基本的なところから取り組む
種をまけばいつか花が咲くのだ
そのためのファシリテーターだよな、うん。
組織横断のカンバンとか、無理ゲーかもしれないけど、
成功事例を提示されることで夢を描けるのだよ。
［Session 3］
大規模分散アジャイルを支えるプラットフォーム
スクラムオブスクラムの話とか始まっちゃうと、
まぁちょっと待ってくれ、ってなるな(笑)
なんとなくこれまでの経験上、IBM関連の講演は自分にはあってないみたい。。
あ、自分が今仕事で使ってる一人かんばん(笑)にペンディングステータスを作らないと。
優先度高いけど、外部要因で止まってるタスクを今まで放置しちゃってたのよね。
［Session 4］
コンパクトなチームでのアジャイル開発とその実践
開発にだけフォーカス当ててちゃダメ。
サービス全体のアジリティを上げていく。
で、サービスのスコープを広げた時に、
フルスタックエンジニアは見つからない。
育てるのも大変。
テクノロジーの理解×適切なツールで解決しよう。
結構面白そうなツールも紹介されていた。
一番具体的だったかも。
cacoo
名前は知ってたから、結構有名なのかな。
講演では特に触れられなかったけど、今度触ってみよう。
pivotal tracker
電子カンバンかな？
複数のストーリーをエピックとして束ねられるらしい。
bugzilla・githubと連動できるとは言っていたけど、
redmineと連動できないのかなぁ？
ただし付箋かんばんでアナログもやってる。
アナログ大事。
オレもそう思う。
アナログだからこそのメリットは間違い無くある。
つーか、jenkinsに話しかけるとテストしてくれるプラグインとか熱いな
herok
非機能要件のプライオリティーが高いと、
開発チームにとっての負荷は高くなる。
専任エンジニアがいるならAWSはいい選択肢だけど、
小規模チームだとそれは難しいため、herokを導入したそうな。
料金はAWSとくらべてどうなんだろ？
［Session 5］
事例から見るアジャイルの失敗と成功
変更管理が重要。
変更分を考慮したスケジュールをスプリントに組み込んでおく。
作業の詳細化（タスクブレーク）が非常に役立ったとか、
どや顔で言われても。。ウォータフォールだってやんなきゃだめでしょ。
つーかコレができないマネージャーとか、
何をマネージメントしてるのかと問い詰めたい。
＃まぁ実際現場で出来てる人、ほとんどいないのは知ってるけどね。。
開発ワークフローのブラッシュアップっていうところを、
KPTに入れるのはよさげだ。
なぜアジャイルなのかをきちんと考えることが大事。
個人的に強く言いたいのは、ドキュメントは動かないのだよ。
仕様決定者全員が集まって合意を取る場所は必要。
開発チーム以外も含めて、プロジェクト関係者全員に参画・当事者意識を求めるのが
アジャイル開発なのだ！
まぁとどのつまり、
アジャイル開発はやりがいや楽しさを与えてくれるかもしれないけど、
相当な厳しさも連れてくるのだ。
読んで時のごとく「スプリント」。
だけど、ずーっと全力疾走なんて人間はできないのです。
チーム状況を見つつ、その辺の折り合いもちゃんとつけていく技量も求められますね。
