本記事について
JaSST'21 Tokyo (JaSSTソフトウェアテストシンポジウム-JaSST'21 Tokyo)
A1）基調講演
「Being Agile about Architecture」
Joseph W. Yoder （Refactory CEO）
の聴講メモです。
Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
JaSST'21東京基調講演のまとめ - Togetter
【参考】としている箇所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。
講演メモ
早く進みながら品質は高く、というのをアジャイルで両立させないといけない。
アジャイルそのものはプロセスではない。非常に短いスプリントで、フィードバックし、改善すること。アジャイルはハードウェアにも適用でき、テスラがその一例となる。
アジャイルには原則がある。
(1) やる気のある人たちが集まること。
(2) 継続的改善で、常に適合して改善していくこと。トヨタは TQM (Total Quality Management) の中で重要な要素として取り入れている。
(3) 変化を受け入れること。必要であれば適合して変化していく必要がある。ビジネスもいち早く変わっていかねばならない。ビジネスにとっての価値に焦点を当てる。
(4) アジャイルでは技術に献身的に取り組む。
(5) 信頼と透明性。上司はチームを俯瞰し、メンバーはお互いに透明性をもってコミュニケーションをとる。
例えば、鮨職人は常に改善の余地がないかを考え、新しいレシピを考案している。アジャイルとはそうした状態を指している。アプローチは様々ある。
アジャイルですべて達成できるわけではない。
(1) "KISS Simple is Best" という言葉はあるが、必ずしもシンプルになるとは言えない。例えば機械学習は複雑だ。
(2) 早いことが必ずしも良いことではない。時にはスピードを緩め、行き先を見据えなければいけない。
(3) 時に変更要件が次々と出てくる。その中でセキュリティなどにも配慮しないといけない。配慮すべきことを後回しにすると、手遅れになってしまうことがある。
【参考】
KISSの原則 - Wikipedia
アジャイル・リーンの価値
- オーバーデザインはダメ (Design Simplicity)。もともとの価値がなくなる。
- 短いフィードバックで、常に見直し続ける。
- ステークホルダーのニーズを満たす。
- 学びながら継続的に改善する。
- 人中心の開発をする。
- 自分達も成長していく。
パターンはグッドプラクティスと考えることができる。
パターンとはナレッジを共有すること。
上手くいったこと、いかなかったことをパターンとして共有する。
常に新しいものが出てくる。マイクロサービスをやるべきか、機械学習をやるべきか。IoTをやるべきか。
色々な意思決定をしながらトレンドについていかなければならない。
アジャイルはプロジェクトが始まったときだけでなく、その後も考え続けなければいけない。
持続可能なアーキテクチャを作りたい。会社にとっての優先順位を考え、バランスを考えなければいけない。ビジネスとアーキテクチャのバランスを取る必要がある。
アーキテクチャの検討を始めるとき、巨人の肩に乗る（リファレンスアーキテクチャを参考にする）ことを考える。
これまでのテクノロジーを参考にする。Java, Ruby on Rails, Spring といったフレームワーク・データベースなどの過去の知見を参考にする。今は決めずにロードマップに入れて後で決めるということもある。
巨人の肩に乗ることの例として、例えば Azure は IoT のリファレンスアーキテクチャを提供している。
リファレンスアーキテクチャには課題があるかもしれない。足りないものがあるかもしれない。そうした不足しているものを追加しないといけないかもしれない。例えばセキュリティやロギングなど。
どこに問題があるのか、どこが難しいのかを見極め、計画を立てることだ。
最大責任地点 (Most Responsible Moment) を選ぶ。
品質ロードマップのどこにアーキテクチャ判断地点を置くのかを考える。つまり、システム品質にいつ対応するのかを決めないといけない。
パフォーマンス・安定性・プラットフォーム・モバイル対応、こういった点をいつ決めるのか計画しなければいけない。責任地点に向けて計画を立てるのだ。スライドの "Qualify the Roadmap" はその一例だ。
"Tracer Bullets" とは要件に対してアーキテクチャが合致しているのか、それとも過剰（オーバーデザイン）なのか、その方向性を導くことだ。
"Test Architecture" ではアーキテクチャそのものをテストする。これはシステム全体の品質にも影響する。テスト設計をできるだけ早期に策定する必要がある。
スライドのフロー（青色のタスク）はプロジェクトのいつでも立ち戻ることができる。だが、なるべく早期に取り組むべきことでもある。
アジャイルはプロセスではない。プロセスはスクラムなどを指す。
バックログのアイテムとして技術的負債を追加することもできる。
Philippe Kruchten はバックログのアイテムに色を付けることを提唱している。
グリーンはOK。レッドは直す必要があるもの。目に見えないものはイエローかブラック。
開発者だけでなくQAやプロダクトマネージャーと一緒にフィードバックする。
【参考】
バックログのアイテムの色分けについて詳細な解説記事がありました。
What Color is your Backlog?
継続してモニタリングし、評価することが必要だ。
また、トリガーを設定しておくこと。例えば、このままだとSLAを満たせなくなるなど。それをチーム内にアナウンスする。
【参考】
スライドに登場する "Architecture Spikes" について。
スパイクって何だろう？って人はRyuzeeさんのこのサイトが分かりやすいですhttps://t.co/kOPeJHYymr
— ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ (@nemorine) 2021年3月15日
#jassttokyo #A1
技術的負債の管理をしなければいけない。
周囲の環境の変化でアーキテクチャがマッチしなくなるかもしれない。そうした技術的負債は早めに解消しておかないと、大きくなりすぎて解消できなくなるかもしれない。乱雑な台所は片付けに多大な時間が必要となる。短期間で取り組んで解消へ導かなければいけない。
"Technical Debt Management" では技術的負債をエビデンス・コンテキスト・インパクトといった観点から整理している。ここでのインパクトとはビジネスへの影響を指す。
私 (Joseph Yoder) に連絡をもらえれば、彼女らの博士論文の内容を紹介する。
ビジネスのS曲線。
新しいアイディアを温める (Ferment)。飛躍する (Takeoff)。成熟する (Maturity)。
これを Kent Beck は 3X と言っている (eXplore, eXpand, eXtract)。
Takeoff するとドキュメントや QA が必要となる。
Maturity に達すると一つのミスが致命傷となる。なので、ここは技術的負債を返し、ミスを減らさないといけない。
タイムリーかつ可視化した情報がなければ改善はできない。
価値ある情報を可視化するため、その対象を考えなければいけない。開発者ならコードやテストだろう。マネージャーなら対顧客かもしれない。チーム・プロジェクト・立場を考えて価値と評価指標を考えないといけないし、メトリクスも変えていく必要がある。
これはアジャイルの透明性と親和性がある。
技術的な判断はビジネスの価値を考えて行うべきだ。
The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. - Bill Gates
効率的なオペレーションに自動化を適用すれば効率を高めることができる。
一方、非効率なオペレーションに自動化を適用すれば、非効率性が高まるだけだ。
反復的なタスク、待ちの多いタスク、リスクの高い箇所を可能な限り自動化すべきだ。
アジャイルはフレキシブルだ。ビジネスにとって一番価値のあるものに合わせて実装していく必要がある。
一年前に決めたことを引きずってはいけない。現状に合わせて見直すことだ。
改善する時に重要なことは時折ポーズする（立ち止まる）ことだ。いつまでも進み続けていては考える時間を確保できない。スラックタイム (Slack Time) が必要だ。
これをプロセスに組み込んでも良いかもしれない。例えば、20%ルールや Hack Day 等。
Spotify の Innovation のモデルを例示する。
プロトタイプで作ってみて、リリースして、フィードバックを受ける。
調整のやりすぎでマイクロオプティマイズになることがある。そこで立ち止まることにより、より良い方向へ向かうことができる。
イノベーションのためには Slack Time が必要だ。この本の表紙に描かれたバネの例がお気に入りだ。バネが伸びきっていたら何かが起きた時に切れてしまう。何かあったときの余裕が必要だ。超過している状況は危険だ。
※英語版にリンクしています。日本語版は表紙が異なるため。
THINKING, FAST AND SLOW もお勧めの本だ。
※日本語版にリンクしています。
スケジュールに余裕があると、タスクを入れたくなるが、そこで改善に取り組む。
速さと生産性はイコールではない。
速いということは価値ではない。
一番価値があるものを作ることがゴールだ。
実験の段階 (Ferment) では技術的負債ではない。だが、Takeoff した後はプラクティスを変える必要がある。
盲目的にアジャイルをするのではなく、アジャイルになるということ。プロセスやプラクティスではなく、アジャイルのマインドセットを持つということだ。
✅ Agile doesn’t cure INCOMPETENCE.
— Mike Beedle (@mikebeedle) 2018年3月21日
You can coach teams to be more engaged and collaborative, but NO Agile framework, method, or mindset can save you from BLATANT FAILURE if your development team is INCOMPETENT in basic engineering practices.
Technical excellence is a MUST!
アジャイルは技術力不足を補うものではない。卓越した技術力は必要だ。
あなたが何に価値を見出すのか？それを大切にしてほしい。
"If you think good architecture is expensive, try bad architecture." という言葉を引用して締めくくりとしたい。
Q & A
Q
ユーザビリティをどうやって可視化するのか？
A.
パフォーマンスは数字で表現できるが、ユーザビリティは測りにくい。ただ、ユーザビリティのテストがあるし、機械学習でユーザーからフィードバックを得るというのも一つだ。例えば、ユーザーのキーストローク・視点・視線から測ることができる。ここまで測定できるラボを設置するのは難しいが、観察することはできる。例えばシナリオを作成し、タスクを試してもらい、そのフィードバックを得る。そして数字に紐づける。
Q.
進化性 (Evolvability) の測定はどうすればよい？
A.
新しいフィーチャーをリリースするまでにどのぐらい時間がかかったか？というのを測定する。以前に似たようなフィーチャーをリリースした時と比べ、どのぐらい違うか？記録しておくことが大前提だが、そうやって測ることができる。
Q.
SRE (Site Reliability Engineering) について。機能テストとは別に SRE にどの程度の時間を割くべきか。
A.
ケースバイケースとしかいえない。火星に人を送るのであれば相当な時間をかけなければいけない。計画して決断を下す。
※余談ですが、SRE とは何のことを指している？というやり取りがありました。同じような略語が多いので、正確な回答をするために気を遣ってくださったようです。
Q.
プロジェクトをウォータフォールで進めざる得ない中でも、今回の講演のようなアジャイルベースでの改善を入れ込むことはできますか？
A.
答えはYesです。
ウォーターフォールは誤解されている。実はこれはループです。要件があって、分析して、ビルドして…。でも本当はループなのです。だからアジャイルチームがループの中で改善することはできる。
もともとの最初のペーパー（論文）を読んでほしい。
【参考】
W. W.ロイスによって1970年に発表された論文で、ウォーターフォールの起源とされている。
Managing the Development of Large Software Systems
Q.
Slack Time はプロジェクト内で設けるべきか。それとも分けるべきか。
A.
両方だ。プロジェクト内に設けないと、問題があったときに大変だ。例えば、メンバーが急な病気で休まざるを得ないとき、Slack Time がないと大変だ。また、別のスプリントとして設けることもできる。
Q.
＜質問不明＞
A.
技術的負債とはとても重要な概念だ。すべての技術的負債には理由がある。
技術的負債の返済はビジネス上の決定だ。エンジニアやQAが決めるのではなく、ビジネスとして決定しないといけない。デリバリーが遅くなるとか、ビジネス上のインパクトを見せるべき。エンジニア・マネージャー・ビジネス担当者、全員で議論すべきだ。
Q.
技術的負債やアーキテクチャを見直すといった活動をどれくらいの周期（1スプリント、1ヶ月、4半期など）で組み込んでいくとよいのでしょうか。
A.
技術的負債はタイミングを決めて返すというより、常に行うべきだ。
トヨタは全員が品質の責任を持っている。ラインで働く方も問題があれば止めることができる。
台所を常にきれいに整理するようなものだ。時には時間がかかることをスプリントという形で行っても良いかもしれない。
Q.
ロードマップのチェックポイント（責任地点）は何回実施するものでしょうか。また、その責任者はいつ決定するものでしょうか？
A
システムや会社による。大まかなロードマップ（スライドの Quality the Roadmap のような）を決めておく。また、その責任者を決めておく。
Q.
派生開発の場合、パターンのうちどこから始めると良いでしょうか？
A.
派生開発の場合、既にプロジェクトが走っている。それでもパターンは全て適用可能だが、スライドのフローの青色のタスクから始めるのが良いだろう。何が起きているかを分析し、痛みを見出し、進化をしていく。
