AgileJapan2018に参加してきました。

www.agilejapan.org

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

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

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

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

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

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

Agile Japan 2018

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

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

スクラムを補う２つのフレームワーク
SAFe,DtoD
SAFeについての日本語訳の本が出版された。藤井さん翻訳。

基調講演その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も１種のMob。専門性の高い知識を持つ人が１箇所に集まる
システムは一つ一つを集めてもできない。それぞれの
効率性（正しくやっているか？）、生産性（Outputがでているか？）、効果的かどうか（正しいことをやっているか？間違ったことを早くやるのではなく、遅くてもよいから正しいことをやりたい）
５人で生産性があがるか？　質問が誤り。５人で効果的(effectivity)か？を知るべき。
効果的なものを破壊するものは何か？いろいろあり、人によって異なる
Mob Programmingをやり始めると、これが消える。効果的に働くということにフォーカスした結果。
Question Queue Time。VSMを整理すると、質問して待っている時間が無駄。
普通は、待っている間に他のことをやる。そうすると、在庫を抱える、コンテキストスイッチが入る
One Peace Flow 日本語でいうと一個流し。１つのタスクにしかかったら終わるまでやりきる
心理的なFlow、物理的なFlow
前者は没入状態、自分と相手の区別がつかない。Zoneに入っている。時間の感覚もなくなる
Team Flow.仕掛かり状態なく、待ち状態もない
ソフトウェア開発は、ideaがソフトウェアでデリバリーされる。それがキューなく、待ちなく、割り込みなく、リラックスした状態でできるか？
Mob Programming は一人一人を最大限引き出すのではなく、みんなから一番いいところ引き出す。
モブプログラミングは、仕事のフローに対して最適化されている (一人一人のアウトプットへの最適化はしていない)
製品開発でもっとも大きな問題はキューとされている。Mobはソフトウェア開発におけるキューの問題を解決する
個人のFlow、チームのFlow、LeanのFlow
大事なのは、アートを作ることではなく、自然にアートを作れる素晴らしい状態にいること、環境になっていること
参加者のBlog： https://hackmd.io/kbddZClZRzyAhRnMkFgiCA#

JapanTaxiの挑戦

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

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

エンタープライズもこの２−３年でアジャイル導入追加
エンタープライズ特有の悩み（乖離統制、社内ルール、標準化、契約、委託会社との関係、、）
金融企業向けサブイベントを開催（2018/4/26)FISCの人、セブン銀行のアジャイル事例の共有

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

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

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

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

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

ビジネス競争力強化、働き方改革などの目的に組織を今年1月に大体的に改革
Agile Coachを会社でやっている３名。
アジャイルオーケストラと呼ぶ。
why　agile？
- 要件定義が大変。横軸でのコラボレーションが無い（サイロ化）。紙＆サイン文化。複数アサインメント。プロジェクト期間の長さ
組織構造：それぞれBP部門に対して、トライブ（縦）、横（ギルド）で組織化。
トライブ：何をするか、ビジネスパートナーとの関係維持
ギルド：どのように実現するか？
トランスバーサル：適切なコントロール、ガバナンス
自立的なチーム：End to Endで自立的にプロダクトを開発できるチーム
T-Skillのメンバー：スペシャリスト＋ジェネラリスト
新しいロールと新しい働き方でAgilityをあげた
POはミニCEOのマインドセット。
Aglityを高めるために内製率をあげている。エンジニアが重要なロール
Business Proximimity ITとビジネスとのコラボレーションが成功の鍵- ４段階のコラボレーションレベル
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立ち上げ）を潰してしまったら、組織がアップデートする芽を数年単位で摘むことになる
仮説キャンパスによる仮説立案 -> インタビューや観察を通じた状況の把握（エスノグラフィー）-> 行動フローペースで必要な仕組みの設計 -> プロトタイプ検証
必要にして最小限の要求詳細化作戦
- 要求仕様の粒度は、結成するチームと関係者の練度でもって決める（詳しければよいわけではない）
- 過去のポストポーテムを活かす
  - キックオフの前に、メンバーそれぞれの過去のプロジェクトでの学びを棚卸しする
  - インセプションデッキ「やらないことリスト」でやり方、あり方でやりたくないことを共有
- 常にチームビルディング
  - 単純接触効果：接触回数が警戒心を解く
- 間違ってもすぐに正解に取り戻せる力（レジリエンス力）を身につけておくのが大事
- 間違っても即、直せる開発
  - 間違うなら、早めに間違っておく：１週間スプリント
  - 最初から何をもって完成なのかをあわせる
  - POが受け入れ条件をかけない問題
    - 仮説検証のフェーズで開発から逆に学ぶ。ともにつくるという案も。
    - 内製＋傭兵チーム（ギルドワークス）
  - 越境：内製チームが。内製チームが自分が何をしたいのか
  - ゴールデンワークルは書くX ２
  - 最初はこれまでの延長でしかない。その上でむきなおりをすることで本当のゴールデンワークルをかける
- 大企業の新規事業は２回戦う。
  - 最初の関門はプロダクトの方向性を見定めること
  - 最大の問題は、コンセプトをまとめたあとにくる。
    - 大企業ならではの、社内関係者の調整という関門
    - チームで乗り越えるしか無い
- 逆境からのアジャイルをエナジャイズする（元気付ける、勇気付ける、後押しする）
- 逆境だからこそ起きた変化が影響が大きい！

Deep agile people

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

20181120Eclipse 最新事情セミナー

20180911 Cloud Native Meetup Tokyo #4

所感

istioとEnvoy

Open Policy Agent is 何？

20180907 第2回enPiT-Proスマートエスイーセミナー: アジャイル品質保証と組織変革

所感

アジャイル品質保証パターン: Quality Assurance から Agile Quality へ

OODAと品質保証:アジャイル開発に置ける品質管理のアプローチ

高生産性と信頼性におけるアジャイル形式工学手法

ソフトウェア工学の観点から見たアジャイル(

“アジャイル組織への変革”と“アジャイル開発の成功・定着”のポイント

【東京】JJUG ナイトセミナー 「Java: Today and Tomorrow by Simon Ritter!

所感

以下それぞれのセッション中にとっていたメモ

Java Platform Module System (JPMS)

OpenJDK;New Release Model

JDK10

JDK11

Futures

Building A Better JVM

JSUG勉強会 2018年その5 Spring IO 報告会

全体所管

Reactor, Reactive Data Access, REST beyond the obvious

Flight of the Flux: A look at Reactor execution model

Under the Hood of Reactive Data Access

REST beyond the obvious

Spring REST Docs RAML, Spring Cloud Contract

Spring Cloud Gateway, Spring Cloud Pipeline

Spring Cloud Gateway

Spring Cloud Pipeline