Seeing is believing

いちエンジニアの日々の興味のあるところ、イベント参加記録、学びの共有を取止めなく※このblogは個人の見解であり所属する組織の見解ではありません

Agile Japan 2018 に参加してきました!

AgileJapan2018に参加してきました。

www.agilejapan.org

全体の印象としては、アジャイルやってみよう!という人よりは今やっている、もしくはやり始めたところの人たちが多かった印象。

他の会社ではどうやっているの?とか、自分がアジャイルをやっていてぶつかった課題に関するヒントを得に来ている感じ。

JapanTaxiの川鍋社長のプレゼンがとても引き込まれるもので良かった。

資料が公開されたら、参加できなかった裏番組セッションも含めてじっくり見直したい。

以下は参加中にとっていたメモです。

運営の方、登壇者の方、お疲れ様でした!!

Agile Japan 2018

  • 今年で10周年
  • 今年の参加者は542名の参加者(登録者数)
  • うち今年初参加388名
  • Agileキャズム(深い淵)を超えた。今後のはさらに広がっていく見込み。
  • Agileはわかりづらい? Do Agile? Be Agile?
    • 常にWHYを意識することが成功へのカギ
      • 変えることが大事になってしまうと、本来の目的を見失ってしまう
  • event hubのスペースが用意されており、Mob Programmingブースもあり。去年から初めて大盛況。第一人者のWoody Zuill 氏による

株式会社オージス総研 藤井 拓 氏

基調講演その1:Woody Zuill 氏

  • 楽天川口さんのつてで登壇。企業向けに英語の公用化の支援。アプリ、塾など。
    • モブプロを取り入れて1年ほどたっている
    • きっかけは、Woodyさんの1dayのトレーニングを受けたこと
    • ペアプロの延長ではなく、働き方そのものを変える何かかだと感じた
    • イベントでMobに対する講演もしている。Mobの見学会も。モブをやることでビジネスサイドの人がプログラマがどうやって開発しているのかが知れた。などの感想も。
    • no estimate:見積もりしない。 延期をする権利。ハンターインダストリ社?

Woddyさんセッション

  • 平鍋さんによる通訳!
  • Mob Programming and tho Power of Flow
  • 同じことを同じ時間に同じ場所で、同じコンピュータでやる
  • 知識がバラバラの人を集めてやる。なぜかうまくいく。
  • Driver(チームからInputを受けて、チームの考えをoutputするだけ) / Navigator
  • イデアをシェアする。簡単ではないが、練習すると出来るようになる
  • リモートによるVirtualMobでやっている事例も。
  • NASA Mission Controlも1種のMob。専門性の高い知識を持つ人が1箇所に集まる
  • システムは一つ一つを集めてもできない。それぞれの
  • 効率性(正しくやっているか?)、生産性(Outputがでているか?)、効果的かどうか(正しいことをやっているか?間違ったことを早くやるのではなく、遅くてもよいから正しいことをやりたい)
  • 5人で生産性があがるか? 質問が誤り。5人で効果的(effectivity)か?を知るべき。
  • 効果的なものを破壊するものは何か?いろいろあり、人によって異なる
  • Mob Programmingをやり始めると、これが消える。効果的に働くということにフォーカスした結果。
  • Question Queue Time。VSMを整理すると、質問して待っている時間が無駄。
  • 普通は、待っている間に他のことをやる。そうすると、在庫を抱える、コンテキストスイッチが入る
  • One Peace Flow 日本語でいうと一個流し。1つのタスクにしかかったら終わるまでやりきる
  • 心理的なFlow、物理的なFlow
  • 前者は没入状態、自分と相手の区別がつかない。Zoneに入っている。時間の感覚もなくなる
  • Team Flow.仕掛かり状態なく、待ち状態もない
  • ソフトウェア開発は、ideaがソフトウェアでデリバリーされる。それがキューなく、待ちなく、割り込みなく、リラックスした状態でできるか?
  • Mob Programming は一人一人を最大限引き出すのではなく、みんなから一番いいところ引き出す。
  • モブプログラミングは、仕事のフローに対して最適化されている (一人一人のアウトプットへの最適化はしていない)
  • 製品開発でもっとも大きな問題はキューとされている。Mobはソフトウェア開発におけるキューの問題を解決する
  • 個人のFlow、チームのFlow、LeanのFlow
  • 大事なのは、アートを作ることではなく、自然にアートを作れる素晴らしい状態にいること、環境になっていること
  • 参加者のBlog: https://hackmd.io/kbddZClZRzyAhRnMkFgiCA#

JapanTaxiの挑戦

  • 川鍋さん。日本交通の3代目。
  • 全国タクシーApp
  • GPSスマホ で急にITが必要になってきた
  • 全産業IT化の状況。経営者は全員気づいている。
  • JapanTaxiは90名体制でうち50名は内製。日々状況が変わってついていくため。
  • リアルのビジネスがあってそれにITを足す方やさしい(Japan Taxi)。ITから初めてリアルを後付けするのは難しい(Google)。
  • コラボレーティブモビリティ。タクシーと道路舗装会社、など
  • 社長自身もtech campに1週間参加し、Rubyもやった。
  • エンジニア採用はCTOに任せた
  • ハードウェア(シンセンで数千円単位)や、SIMが安くなってきたことが大きい。
  • 最近VPOE(Vice president enginieer)の役職を作った

エンタープライズ企業におけるアジャイル開発の取組み

東京電力;WF文化の企業でSoRにアジャイルを導入してみて起きたこと

  • 2016年にHD制に移行。2020年の電力完全自由化に向けての組織変更
  • 生産性の倍増と、新ビジネスの創造を目的としている
  • Open Speed Co-Operation(共創)をテーマに
  • デザイン思考と高速PoC
  • 3年で1000のアイディア創造、100のPoCを実施。今後確率をあげたい。
  • 6/22にインキュベーションセンターを開設。既存の門前仲町のビルの1フロア。tepsys labs。
  • 東京電力が持つファリシティのデータを生で触ることができる
  • 福島原発廃炉プロジェクトを遂行中。30-40年がかり
  • 原発放射線管理に関する業務支援システム
    • 人、作業、場に関すること
  • 1997年リリースのホストシステム(COBOL 100万Step)
  • 24/365、個人情報あり
  • 関連法務多数(ステークホルダー多数)
  • 作業員の安全確保が最優先。法令や業務設計と並行して、早急なシステム対応が必要。
  • スピードをあげた結果、あとからAgileと名付けたのが実際
  • なぜWF文化の会社でアジャイルが導入できたのか?
  • 非常事態と2つの偶然。:「風土・文化」「ヒト」
  • 非常事態:標準を崩してでもスピードをあげてもよい
  • ヒト:高いスキルと意欲を持ったチームの確保
  • ヒト:業務精通し意思決定が行えるPOが確保できた
  • 内の変化:システムプロジェクト規模が拡大、ステークホルダーも増大
  • プロジェクトの停滞;ステークホルダーが多く、利害関係が増大。POがボトルネック
  • プロダクトバックログを目的別に分割し、チームも分割
  • POに業務部門かた代表者を招集
  • 各業務部門長でステアリングチームを構成。POはこのチームとだけ話をすることで負担減
  • ホスト統合案件
    • パフォーマンス、コスト、リスクのバランス
    • チームの維持、割り込み要件対応に応えるためアジャイルで進めた
    • アジャイルの中で品質保証をどう取り組むかを検討
    • 改良ベースであることはアジャイルに不向きだった
    • 開発工程の工夫
      • 開発期間は1年半
      • 要件定義フェーズでプロダクトバックログが361個
      • スプリントを6つに分割
      • 各スプリントごとに請負契約にした(スプリントバックログが契約の元)
      • 改良の色が濃くなると、触っていない機能への不具合が多発してきた
        • 既存機能への影響分析に時間が必要であった
      • 1スプリント内を2週間の子スプリントに分割。2週間ごとのスプリントレビューのレビュー実施記録が納品物の扱い。=検収
      • プロダクトバップログ内案件の入れ替えルールを定めた
      • 要件膨らみに伴う、稼働率をあげると、不良発生率が上がる因果関係があることが社内で事実としてあった
    • 開発体制の工夫
      • 40名ぐらいの体制
      • PO部門が3つに別れていたので、それぞれで開発チームを組成
      • 大規模、会議エリアはオープンエリア(声が聞こえる)
    • プロジェクト運営の工夫
      • スプリント計画
        • 案件の内容により、開発チーム編成を変える
        • テスト体制は他チームを含めて混成編成とする。(品質、体力面)
    • 開発手法の工夫
      • 単純構造:ソフトウェアメトリクスが小さなプログラムを書く(モジュール数、分岐数、定義数を最低限に)
      • 簡単理解:日本語でプログラムを書く。ドキュメントの簡略化が可能になる。
      • 共同所有:ソースコードリポジトリを使って、個人が自由に気軽に無申請でコミット可とする。途中でもOK。他のヒトに積極的に見てもらう
        • みんなでソースを見る会
          • コードをプロジェクタで東映
          • コードに対して意見交換
    • 計画QCDの達成。業務部門の満足度が高かった
    • 課題:属人的、契約の整理が必要

三菱UFJ銀行におけるアジャイルの取り組み~ これまで、今、これから ~

  • アジャイルの取り組みのスタートは、不確実への対応
  • 方向付けフェーズを儲ける、リリース準備期間(移行フェーズ)を設け、標準化 > DaD同様
  • リリース準備期間で他システム連携テスト、トレーニング期間
  • 2015年からのLCP開発の体制もアジャイル。一定予算内で継続的な開発。優先度に応じてバックログを見直し。
    • 50以上の小規模なアプリケーションを提供
  • EFXの事例。モデル開発が変化が激しく終わりがないのでアジャイル向き
  • デジタラでは、システム駆動ではなく、会社としてやっている
  • カルチャー改革としてのAgile:Culture of Failure
  • 課題と取り組み
    • 知識、経験不足 : ガイドの充実、アジャイルコーチ支援、スクラムサイズとして7名でスタート
    • 見積もり、稟議:機能別な精緻な見積もりを求めず。一定規模以上のPBIの集合体でりん議。優先度見直しで開発内容の変更可(予算内)
    • BPとの関係:請負契約に拘らず(準委任契約を推奨)。経験者の参画や受託者マインド脱却を要請。請負適正化観点でのコミュニケーション留意
      • 従来型の品質の積み上げ方、品質担保、リリースチェック項目の見直し
  • 業務部門の関与:個別勉強会やワークショップでの理解促進。ユーザータスク管理手続のアジャイル対応
  • 業務部門との物理的な距離;専用のコロケーションルーム、可視性を心がけTV会議等の有効活用、開発PO(Proxy)を通じたコミュニケーション
  • 意思決定の遅延:POを組織責任者から実務責任者へ。複数の業務部門が関与する場合は、代表部署のPO(リードPO)を明確化
  • アジャイルをよりやりやすく、よりメリットを享受するために

保険会社でAgile? アクサ生命Agileトランスフォーメーション

  • ビジネス競争力強化、働き方改革などの目的に組織を今年1月に大体的に改革
  • Agile Coachを会社でやっている3名。
  • アジャイルオーケストラと呼ぶ。
  • why agile
    • 要件定義が大変。横軸でのコラボレーションが無い(サイロ化)。紙&サイン文化。複数アサインメント。プロジェクト期間の長さ
  • 組織構造:それぞれBP部門に対して、トライブ(縦)、横(ギルド)で組織化。
  • トライブ:何をするか、ビジネスパートナーとの関係維持
  • ギルド:どのように実現するか?
  • トランスバーサル:適切なコントロール、ガバナンス
  • 自立的なチーム:End to Endで自立的にプロダクトを開発できるチーム
  • T-Skillのメンバー:スペシャリスト+ジェネラリスト
  • 新しいロールと新しい働き方でAgilityをあげた
  • POはミニCEOのマインドセット
  • Aglityを高めるために内製率をあげている。エンジニアが重要なロール
  • Business Proximimity ITとビジネスとのコラボレーションが成功の鍵- 4段階のコラボレーションレベル
  • Community of Practice : 知識を共有、プラクティスのアライン、スタンダード、新しいサイロを防ぐ
  • Tool from Management 3.0:Management3.0組織を目指す。システムではなく組織をマネージメントする。権限の委譲、コンピテンシーの開発(マトリックス化)
  • Agile Coach:チームやリーダーをリード・ガイドする

ギルドワークス:カイゼンジャーニー執筆者。市谷さん

  • 仮説検証とアジャイル開発
  • ギルドワークス:正しいものを正しく作る。スタートアップや事業会社でに新事業の支援
  • 保険会社、水回り製品メーカ、家電など
  • 大企業で新規事業をスタートアプする仮設型仮説検証
  • Golden Circle:Why -> How -> What
  • Start with why
  • なぜ、私はここにいるのか?
  • 日本におけるアジャイルとは、挑戦と、敗北の歴史
    • XPへの憧れと、その遠さ:すごくいいけどプロジェクトではどうしたらいいのか?問題
    • 2006年ごろの顧客との強調と不調、灰色の時代
    • 2010年アジャイル侍という突破口、超えられない壁
  • 二極化する現場
    • 前進していく現場は、アジャイルという言葉さえ不要
      • 進化、発達の最前線には、若く少数の組織
    • 歴史深い組織でも、アジャイルに踏み出す
    • 二極化は進んでいるが、一方で越境しようと思っている人も少なく無い(本の反応から)
  • 基本はリーン製品開発
    • リーン製品開発では、セットベースという考え方が基本。
    • 正解を誰も持っていない、不確実
  • ベンチャーの場合=セットが多すぎる。基準がゆるく、なんでもありになりがちで後半で思いつきで変更される
  • 大企業の場合=ポイントベース。却下の失敗(選択肢採用の基準が厳しすぎる。不確実なことでもあらかじめの検討を詳細に求められる)
  • 求められるのは、採用の失敗を抑えながら、製品開発を行う手段。仮説の確からしさを検証しながら、漸進する開発:仮説検証型アジャイル開発
  • 精度と頻度のマネジメント。バランスが重要。
  • 日本食品の事例
    • 新しい事業展開を牽引するサービスの開発
      • SoR中心からSoEへの越境
      • 何を作るべきか?=仮説検証
      • どのようにしてかたちにしていくか?=アジャイル開発
    • 歴史深い組織が、アジャイルに踏み出す
  • 最初の一歩(SoE立ち上げ)を潰してしまったら、組織がアップデートする芽を数年単位で摘むことになる
  • 仮説キャンパスによる仮説立案 -> インタビューや観察を通じた状況の把握(エスノグラフィー)-> 行動フローペースで必要な仕組みの設計 -> プロトタイプ検証
  • 必要にして最小限の要求詳細化作戦
    • 要求仕様の粒度は、結成するチームと関係者の練度でもって決める(詳しければよいわけではない)
    • 過去のポストポーテムを活かす
      • キックオフの前に、メンバーそれぞれの過去のプロジェクトでの学びを棚卸しする
      • インセプションデッキ「やらないことリスト」でやり方、あり方でやりたくないことを共有
    • 常にチームビルディング
      • 単純接触効果:接触回数が警戒心を解く
    • 間違ってもすぐに正解に取り戻せる力(レジリエンス力)を身につけておくのが大事
    • 間違っても即、直せる開発
      • 間違うなら、早めに間違っておく:1週間スプリント
      • 最初から何をもって完成なのかをあわせる
      • POが受け入れ条件をかけない問題
        • 仮説検証のフェーズで開発から逆に学ぶ。ともにつくるという案も。
        • 内製+傭兵チーム(ギルドワークス)
      • 越境:内製チームが。内製チームが自分が何をしたいのか
      • ゴールデンワークルは書くX 2
      • 最初はこれまでの延長でしかない。その上でむきなおりをすることで本当のゴールデンワークルをかける
    • 大企業の新規事業は2回戦う。
      • 最初の関門はプロダクトの方向性を見定めること
      • 最大の問題は、コンセプトをまとめたあとにくる。
        • 大企業ならではの、社内関係者の調整という関門
        • チームで乗り越えるしか無い
    • 逆境からのアジャイルをエナジャイズする(元気付ける、勇気付ける、後押しする)
    • 逆境だからこそ起きた変化が影響が大きい!

Deep agile people

  • 受託開発をずっとやっている会社だと、立ち止まってアジャイルを考える時間、余裕がない
  • メンバーからアジャイルやりたいと言ってくれるといいが、やらされだとあまり、、。だがみんながアジャイルやっていきたいというケースなんて実際はない
  • アジャイル事業部は全てアジャイルアジャイル好きな人が集まったわけでは無い。新しく来た人は、そこにあるものとして当たり前に受け入れる
  • 顧客側からアジャイルをやりたいというニーズは実感として増えている。
  • パナソニックにいたときは最後は100人でスクラムしていた。サブグループわけして進めていた
  • 30-40名でやっている現場にアジャイルコーチで入っていった時は、大変だった
  • アジャイルコーチはそのScrumが自己組織化してきたら、卒業していく。単価は通常SIより高い
  • アジャイルを広めるために、アジャイルという言葉を使わないことで広げるテクニックがある(マインド面)
  • 請負で普通にやって、現場のやり方としてアジャイルでやっている。短期でリリースしていきますよというだけ。
  • 1週間ずつ区切って、わかりやすくなっているだけ、とか
  • 最近なぜアジャイルをやりたいか?を聞いても出てこないことが多くなっている。(上の人が、、とか、流行ってるからとか)
  • 海外の人と仕事する時に相手がアジャイルだから、日本も合わせて始めるというケースも
  • アジャイル、前のXPは開発者のモチベーションを高めるためだった
  • 最初はなぜプログラマーが散々ドキュメントかかないといけないのか?無駄では?という疑問がスタート。承認が多いとか
  • アジャイルのきっかけは、XPの白本、実践編はピンクの川端さんが訳した本もあった。達人プログラマーも。
  • 今おすすめするのであれば、アジャイルサムライ
  • アジャイルを広めようとしている人が高齢化してきてしまっているのでは?
  • AgileJapanは初参加の人が多い。もともとはスーツの人も呼びたいという背景があったから。
  • スクラムギャザリングの方が濃い人が多い
  • 既存ルールや規制がある場合でAgileをやろうとするとうまくいかないケースがおおい
  • PMBOKとかは変わって来ているので外堀は埋まってきている
  • 最後は企業内ルールの変更などに壁がある。最初は目的があってルールを決めたはずなのに、今目的が変わってルールを変更するとなると、ちょっと時間がかかる
  • アジャイルの品質。QA部門が開発チームの外にいて、そこと一緒にScrumのタイムボックスに入ってもらってやる人は会場で3割ぐらい。
  • 品質管理部門はWFベースでのメトリクスを要求すると辛い。POもあまり品質わかってないく、最初に握っても。。どうするか?
  • 製造業(車、医療機器)はやはり品質気にする。チーム組成からQA担当メンバーも入り、インセプションデッキして、チームごとに決める
  • メトリクスのトラッキング項目はWFとあまり変わらない。カバレッジとか。
  • TDDだとバグがでない、そうするとこれまでのソースコード量単位の目標バグがでない
  • やりかたも含めてQAと一緒に決めるしかない
  • ルールで縛る。テストコードが無いプルリクは受け付けない。もしくはペアプロ必須とする。それにプラスしてテスターがいる。
  • 品質保証部門に品質だけに責任を負わせると、イマイチになる。QCDを考えさせる。例えば経験としてPOになってもらうとかはうまくいった事例あり
  • アジャイルの場合はプロセス品質を重視するというが多い。スプリント内でこなしたプロダクトバックログ数。多すぎても少なすぎてもよくない。
  • CIが1週間に何回落ちているかなど。それもプロセス品質。
  • V字モデルがわかっていないと、アジャイルも回せないよね?という議論もあり
  • リモートワークが当たり前になっていくと、対話できないから、ドキュメントかかないといけないというものに逆にいっている流れも。チケットやチャットというものも結局文字伝達