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

Developers Summit2012に行った #devsumi

技術

10年後も世界で通じるエンジニアであるために Developers Summit 2012
行ってきた。

今回は開発プロセスや手法(所謂agile系)の話が枠的に多く、自分も何個かそれ系の講演を聞いたのだけど、様々な視点から語られた講演を聞いてる中で、各講演の内容が自分の中でつながっていくような感覚があったので、今回は各セッションのまとめというよりは、その辺をまとめていこうかと思う。
自分なりの解釈の中で内容をつぎはぎにしてしまうので、各セッションの内容を詳細に知りたい場合は他の方が色々とまとめていたり、togetterがあったりしますので、そちらをご覧いただければと。

参加した講演の自分の中でのグループ分け

  • 全体を俯瞰した視点からの講演
    • 【16-A-1】見る前に翔べ 〜ギークの工夫で社会を変えよう〜 及川 卓也 氏
    • 【17-B-5】アジャイルマニフェスト ディケイド 角谷 信太郎 氏
  • 現場の視点からの講演
    • 【16-B-5】アジャイルリーダーシップと組織改革 〜楽天のアジャイル開発というリアル〜 藤原 大 氏
    • 【17-A-4】Scrumで組織改革 貝瀬 岳志 氏
  • 両者をつなぐ視点からの講演
    • 【16-B-3】教科書と現場のあいだ 〜学びを活かすために〜 和智 右桂 氏

そもそも"agile開発"とは何か?

  • 角谷さん
    • Christopher Alexanderが提唱した建築プロセスの特性を、Kent Beckがソフトウェア開発の現場に持ち込もうとしたことが始まり。
      • 少しずつ成長させる (インクリメンタル)
      • 人間の感性に深く基づく(Human Sensibilities)
      • 繰り返し実行される(イテレーティブ)
    • 17人のライダー達により、Agile Manifesto が採択された。
    • "You can't do agile." アジャイルは名詞じゃないから、アジャイルすることはできない。形容詞だよ!!
      • アジャイルさという度合いで測る。どれくらい活き活きと開発できているか!

agile : 活発な、いきいきとした (という意味もある。)

なぜ"agile開発"が必要なのか?

  • 及川さん
    • Launch & Iterateの小さなスパンの繰り返しが今の開発の基本。
      • 昔:パッケージソフトウェア:高い配布コスト。リリースが重要。リコールになったら、、、 Ex.Windows Vistaの開発には5年以上かかってる!
      • 今:クラウド上での開発:低い配布コスト。リリース後が重要。
    • プロダクトアウト と マーケットイン。launchの時はプロダクトアウト、iterateの時はマーケットイン
      • 新しい物を作る時は顧客にヒヤリングをしても有益な意見はなかなか聞き出せないので、素早く市場に投入し、そのフィードバックをもらうことが重要である。市場に出た後においては顧客の意見に耳を傾けることが重要。
      • SONYの盛田さん ウォークマンの誕生について → 企画書を提出して、試作を行ってという通常の手順を踏んでいたら、この商品は生まれなかったかもしれない。
  • 角谷さん
    • ソフトウェアのnature(=本質)として、人が使ってみないと分からない、人の認識やフィードバックが必要という部分がある。そのため、変化を受け入れることの出来る開発が必要。
  • 藤原さん
    • 現場の状況を調べてみると、100h/月 程度がバグ修正や既存の仕様調査にあてられていることが判明。→ 開発スピードの低下。
    • レガシーコード、古い技術、運用のストレス。そして、その状況にいることで時代に取り残されてしまうことへの恐怖(→人材流出?)

どのように導入すればいいのか?

  • 和智さん
    • おしゃれなプロセスを試したいという思いは、大局観を失わせる!! 勉強するリーダーほど気をつけなければならない。
    • 原則を理解して始めて実践に意味が与えられる、実践に幅を持たせることができる。
    • コンテキストに乗せれば、組織の中での言葉が手に入る。勉強会と会社とで言葉の使い分け。
      • 受託開発では常に新しいコンテキストが待っている。お客さんによって方法を変える必要がある。
    • 自分が価値だと信じるものを相手に伝えることはとても大事
  • 藤原さん
    • 見えないなら見に行く。遠くから見てても埒があかない。
  • 貝瀬さん
    • スクラムの理解を深めるためにScrumマスターの研修に参加
    • 自分たち用のローカルルールを共通ルールとチームルールに分けて制定。Arrange Scrume。
      • 突発は受け入れる、Sprint毎にチームを再構成 など

導入にあたっての苦労など

  • 角谷さん
  • 藤原さん
    • 単純にCIを導入しようとした時は八割越えで失敗。
    • みんな忙しい、レポートライン(=成果の求められ方?)が違う。
    • 部署をまたいで色々協力しても、一緒にやってる感が出ず、いつのまにか終わってしまう。
    • 現場に入って導入して上手くいったケースでも、加速するまでには約3ヶ月の時間が必要だった。
    • チームとマネージャー、上司との距離感が超重要。介入があるとチームのモチベーションに影響してしまう。
    • コーチがいなくなったら一回元の状況に戻ってしまった。コーチはいつかいなくなるものなので、人を育てることが凄く重要。
  • 貝瀬さん
    • スクラムの理解が浅いまま実施することは逆効果
      • バックログが増えない
      • 振り返りに否定的なチームが出てきたりしてしまった。

導入の効果

  • 藤原さん
    • 一体感!!!
    • スピード感、楽しかった、みんなで解決
    • タスクの優先度が明確になることによる開発時間の増加。
    • ライブラリの作成などによる開発効率の向上
    • 人が育った。自分がいなくなった後にScrumを復活させてくれた若人の存在。
  • 貝瀬さん
    • マインドの変化。コミュニケーションの改善、メンバーの自発性
    • 自己組織化
    • 新規プロジェクトでの導入も行われている


我ながら上手い具合に講演をチョイスしていたな〜と(笑)。
昨年↓で衝撃を受けて以来、アジャイル系の話をちょいちょい齧ってはいたものの、自分の中でいまいち消化しきれず苦しんでいたのですが、少しつながったように思います。
MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る - 7月3日に生まれて

及川さんと角谷さんの講演から大局を学び、和智さんの講演から大局をいかに現場に落とすかのコツを学び、そして、藤原さんや貝瀬さんの姿からは、及川さんが好きだと言っていたこの言葉を地で行く凄さを感じました。
"みんなきた道ばかり気にする。本当は行き先のほうが大事なんだ。" パブリックエネミー。ジョン•デリンジャー
パブリック・エネミーズ  [DVD]
agileは変化に対応するための開発手法であり、その手法自体も現場の様々な要因によって変化する必要がある。でも、その導入にあたってはリーダーのぶれない志や思いが必要だな〜と思ったりしました。それもまた、"人間の感性に基づく"というアジャイルの特徴につながる所があったりして面白いなと思ったり。

良い締めの言葉は見つかりませんが、とにかく、ありがとうございました!!



以下、公開されているのを見つけた資料のリンクです。