I attended Agile Japan 2016 on May 31.
I want readers to see the materials of the sessions, many of which are uploaded on
http://www.agilejapan.org/program.html
(though written in Japanese).
I would like to write what I thought, although it may be biased.
What you can do and what you cannot / what you should do and what you shouldn't
If an individual or a team can be anything you want, how to introduce agile development is not a problem. Just "Introduce it" is sufficient. On the other hand, if you cannot change, we do not have any hope.
I took the presentations in Agile Japan as a quest for solution to the problem of what is the entry point of agile development and what kind of agile development is possible as a result.
"The strange path of a new scrum master and a QA guy" is a case in which Mr. Toyoda, the scrum master became a QA (Quality Assurance) and showed a model of a QA in agile development. He did not have experience as a QA and other QA members only had experience in waterfall (WF) process. They learned from each other and communicate with developers and product owners (PO).
As the QA sees software from customers' point of view, they can feedback to PO what they recognize during the process of test analysis and design. They can make an effective test plan if they incorporate developer's viewpoint. While the focus of attention was on the QA, the solution here was to make an agile expert join in the project.
"Break the wall of culture! A genuine DevOps journey that is possible in Japan" was a session with enthusiasm. "Installation of culture" was a keyword here. As an ex-anthropology student, I don't think it is possible to do it easily. It reminded me of Pierre Bourdieu's argument of habitus, its formation through daily activities and reproduction of social hierarchy.
The presenters were fully aware of the difficulty and showed the process to install "culture" focusing on one element of the culture of agile development, "Be lazy". In short, it means how to avoid doing needless things. In the next session, they held a workshop to try value stream mapping (VSM) to eliminate them. VSM shows operation time, lead time (LT) and produced value of processes and its relationship with each other. The point is that we can shorten the LT by locating processes that does not provide values and remove it, and by automating processes if there is a large gap between operation time and the LT.
Review processes were major foci of attention in many teams including mine. Shortening the time from the end of the previous processes to reviews, reducing the repetition of suggestion and fixation, and abolition of review itself (although not always) were what we can do to eliminate wasteful practices. VSM is a method to make what we aren't usually conscious the focus of attention but we cannot make every problem to the fore. Here also an agile coach joins in the team to improve processes (and culture).
From social scientists' or philosophers' eyes, there is infinite information in our daily activities and we select some of them, interpret them and present as "facts". In this sense, VSM itself may depend on expertise of its users and the expertise means how to define stream of events to processes. It may be interesting to see the process further.
Mr. Ushio, one of the presenters of the DevOps session, listed "breaking of 'should'" among elements of agile culture, which derives from Western one. He said it is not good to think that we should do this by that day whatever happens. (Japanese often think that we must do something at any rate. "Breaking of 'should'" is an antithesis of this mindset.)
Presenters of the session "Making agile more agile: Agile mystery analysis makes you find something" also thought that consuming "buffer" days itself is inevitable even if it exceeds the original expectation and what is important is that the management helps teams with less buffers. While agile development usually tries to satisfy deadline and quality by postponing features (functions), in this case the solution was to make other teams help the teams in critical conditions.
The famous "The Mythical Man-Month" suggests that adding work forces to late software projects is not a good solution so I think the scope of this solution is not universal but it seems to work well on the project.
---
5/31(火)に行われたAgile Japan 2016に参加してきた。多くのセッションの資料は
http://www.agilejapan.org/program.html
にアップロードされており、またレポートも出ているので、バイアスはかかっているが思ったことを書いてみる。
私が出席したセッションは以下のとおり（午前中は不参加）。品質や組織、文化に関係したものを中心に回った。
* 「新米スクラムマスタとQAおじさんのアジャイル珍道中」
* 「日本型ハイブリッドアジャイルの導入と実践」
* 「アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～ 」
* 「文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！」
* 「効果的な自働化を目指す！ Value Stream Mapping 実践ワークショップ」
できること、できないこと/すべきこと、すべきでないこと
もし個人が、あるいはチームが望むような何者にもなることができるのであれば、アジャイル開発の導入が問題になることはない。「導入せよ」の一言で済む。一方変わりようがないのであれば、アジャイルを導入は成功するはずがない。両者の間にあって、何を突破口とすれば、どのようなアジャイルが導入できるか、という問題に対する答えをそれぞれが模索していた、というのが全体を通しての感想である。
最初に聞いた「新米スクラムマスタとQAおじさんのアジャイル珍道中」ではスクラムマスタである豊田氏が自ら（経験がない）QAになってアジャイル開発におけるQAのあり方を示す、という事例である。QAとしては未経験な発表者と、ウォーターフォール(WF)での経験のみがあったQAメンバーが互いから学びながら、開発やプロダクトオーナーとコミュニケーションしていく、という過程を紹介していた。QAは顧客の視点に立てるので、テスト分析、設計の過程で気づいたことをプロダクトオーナー（=要求・仕様）に対してフィードバックできる。また開発視点も取り入れることで効果の高いテストを計画できる。QAに焦点が当たっていたが、ここでの解決策はアジャイルの経験者を外から人を入れるということだった。
「文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！」の発表者の一人である牛尾氏はde:codeにも登壇していたようだし、何度かブログも読んだことがあるので全く初めてではなかったが、このセッションは非常にテンションが高かった。ここでは「文化のインストール」がキーになっていた。（1年前に人類学を学んでいた者としても）文化がそんなに簡単に習得できるものとは思えないが、それは承知の上で、アジャイル開発の文化の中でも特に"Be lazy"にフォーカスして、どのように導入するかを紹介していた。簡単に言えば、無駄なこと、必要がないことをいかにやらないかである。そのための手法として次のセッション（牛尾氏は引き続き登壇）ではVSM(Value Stream Mapping)をワークショップ形式で試してみた。VSMは各工程がどれだけの工数、リードタイムでどのような価値を生み出しているかと、工程間のつながりを示したものである。価値がはっきりしないものがあればなくす、工数とリードタイムに大きな差があれば自動化などで差をなくすことでリリースまでのLTを短くできる、というものである。私のチームもそうだったが、レビューに焦点が当たり、前工程終了からレビューまでの時間を減らすことと、指摘事項⇒修正の繰り返しを少なくすること、そして必要ない場合はレビュープロセス自体をなくすこと、などが無駄をなくすためにできることとして挙がった。VSMは普段意識したいないものを意識させるための手法であり、時間が短かったということはあるが、自分たちで考えるだけで問題がすべて明るみに出るわけではない。ここでも導入にあたってはアジャイルコーチが入っている。
DevOpsのセッションで、アジャイル（西洋）の文化として挙げられていたものの中に「"should"の破壊」というものもあり、アジャイル導入にあたっても、いつまでにこれをやらなければならない、と考えて無理をしてはいけない、といういう話だった。「アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～」でも想定以上にバッファが消費されること自体は仕方ないと考えていて、それに対してマネジメントが支援する、というやり方だった。アジャイル開発では通常プロジェクトが予定通り進まないとき機能を削ることで納期と品質を守ろうとするが、発表された事例では比較的余裕がある（クリティカルチェーンではない）チームが助けることによってプロジェクト全体として解決する、ということだった。「人月の神話」の話を聞く限り、この方法が常に適用できるのかは疑問だが、発表事例ではうまく機能した、ということだろう。
（以下は英語版にはまだ書いていない部分）
一方、「日本型ハイブリッドアジャイルの導入と実践」は現実路線。SIを中心とする、日本のソフトウェアの産業構造を前提として、その中でアジャイルの要素をどのように取り込んでいくかという話。最初の要求・仕様の部分と最後のテストについては（ある程度の柔軟性を持たせながらも）基本的にWFにして、中間の設計・実装の部分をアジャイルにしてイテレーションを繰り返す、という方向性を示していた。この方法のメリットとして、契約内容を大きく変更せずに済むこと、スキルが高くない開発者でも開発できることを挙げていたが、正直この考え方にはあまり賛成できない。確かに、航空・宇宙や自動車など高い信頼性を要するソフトウェアでは多少利便性を犠牲にしても仕様変更を少なくして安全性を高めるという方向はありだと思うが、それ以外では既存のSIerの仕事を守るだけの後ろ向きのやり方にしか思えない。海外のエンジニアは情報工学を学んでいて優秀だと話していたが、日本のエンジニアが人件費が高くスキルが低いとしたら、それでも仕事になっているのは日本語の壁があるからだけである。（自分自身への警告も含めだが）個人として、また業界としてアジャイルに適応するか、あるいはアジャイルでは実現できないメリットを出せるかを考え、それができないのであれば別の業界に移るより仕方ないのではないかと思った。
何のために働くか
「新米スクラムマスタとQAおじさんのアジャイル珍道中」ではチーム内の、「アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～」ではチームを超えた協力関係を築くことが成功のかぎとして挙げられていた。ここではチームメンバーは、またチーム同士は協力し合うべきであり、また（条件さえそろえば）自然と協力するようになるものである、という考えに立っているように思える。「文化の壁」の資料でも、日本は基本的にアジャイル導入が難しいが、「個人の自立」に関してだけは（個人主義が弱いため）アジャイルが導入しやすい、ということになっている。「アジャイルミステリー分析」では納期に間に合いそうもないとシグナルを出せば助けてくれるという仕組みを作った、と話していた。そうしたら怠けようとする人もいるのではないかとも思ったが、そうした懸念については触れず、むしろチームが困ったときに助けてくれたら、次に他のチームが困ったときに助けたくなる、ということだった。
一方、VSMのセッションではどうやって関係者を説得するかという問題も質問に挙がっていて、その人の価値観に合わせて「プロジェクト成功で昇進できる」「夕方5時には帰れる」などメリットを説くと答えていた。こうした相手の個人的な利益に訴えることはアジャイルやDevOpsを推進する上で障害になるとは考えていないようだ。実際海外のアジャイル開発では「楽しむ」ことが重視されているようで、「納期もそれほど気にしない」とのことだった。先に楽しむことがあって、そうすれば後から協力や規律はついてくる、ということだろうか。今回関連した話は聞かなかったが、プロジェクトが回る仕組みを作る際にインセンティブの問題も含め、マネジメント、人事・評価、「文化」、技術、個々のエンジニアのスキル、その他各方面の問題に対処しなければならないとなるとさらに対応が難しくなるのではないかと思った。
その他
「Be lazy」はともかく、アジャイル開発の「楽しむ」ことやチーム全体のアプローチが、成果主義や厳しい競争など、海外（特に米国）について聞く、少なくとも一見相容れないような側面とどのように組み合わされているのかはよくわからなかった。
