アジャイル開発でいこう～価値、原則、プラクティス～｜研修コースに参加してみた

2022-04-20 公開 2023-02-27 更新

今回参加したコースはアジャイル開発でいこう～価値、原則、プラクティス～です。

「 DX はアジャイル開発で進めるもの」という認識が当たり前になりました。朝会、ふりかえり、スプリント、バックログ、と言ったプラクティスも多くの現場で見られるようになりましたね。

でも、難しい！数年前に実践しましたが、やることなすこと、まず上手くいきません。始めてみると、「スプリントレビューで何もレビューできるものがない」「バックログの優先順位が間違っていた」といったことを経験し、本当にもどかしさを感じたものです。

このコースでは、そんな「難しい」アジャイル開発に 2001 年の黎明期から携わり、数多くの著書・訳書・カンファレンス登壇の実績がある安井力さんに登壇いただきました！アジャイル開発とは何なのか、手を変え品を変え、その本質をお話いただき、私自身アジャイル開発の経験がありましたが、たくさんの気づきがありました！

やはり第一人者の言葉には重みがあります。またどんな質問でも一緒に問題に向き合う姿勢が、とても印象的でした。アジャイルコーチは伊達ではありませんでした !!

では、どのような内容だったのか、レポートします！

コース情報

想定している受講者	ソフトウェア開発に関わる現場メンバーおよびマネージャアジャイルに関する経験や知識は不要
受講目標	自分の業務にアジャイルなアプローチを取り入れられるようになるチームや組織でのアジャイル移行の取り組みを検討できる

講師紹介

このコースで登壇されたのは冒頭でもふれた安井力さんです。

安井力

アジャイルコーチとして 10 年以上、ソフトウェア開発の現場や組織がアジャイルになる支援を続けている。開発技術の紹介、チームビルディング、組織とプロセスの改善などに取り組む。
アナログゲームを用いたワークショップも提供している。「心理的安全性ゲーム」「宝探しアジャイルゲーム」「カンバンゲーム」など。
著書・訳書に『アジャイルな見積りと計画づくり』(毎日コミュニケーションズ刊)『スクラム現場ガイド』(マイナビ出版刊) 『テスト駆動 Python 』(翔泳社刊)『 Joy, Inc. 』(翔泳社刊) など。

まずは受講者のアジャイルのイメージを確認するところから、コースがスタートしました。

ちなみに、ここで投票された項目すべてにアジャイルを導入すると効果がある、ということでした。

アジャイルな企業の例～日米の変わった企業

「変わった会社があります」という紹介とともに、アジャイル開発ではとても有名な企業をお話いただきました。

メンローイノベーションズという企業の例

仕事内容
- 受託開発
- 全員ペアを組んでペアプログラミングしている
- Joy.inc. という本のベースになった企業
  
  「ジョイ・インク役職も部署もない全員主役のマネジメント」（翔泳社刊）
毎週顧客がきて、今週に何をしてもらうのか、決められたサイズの中で、やることを決める
進捗が全員見えるようになってる
朝会を 60 人（ペア） 15 分で終わらせている
ペアは 1 週間で変わる
ショーアンドテルと呼ばれるスプリントレビューがある
1 週間でウォーターフォール（要求定義 -> プロジェクト計画 -> 実装 -> 受入テスト）を回している
XP をやっているという認識

ソニックガーデンという企業の例

全社員リモートワーク
- 家族旅行をする（オフィスがなく顔を合わせる機会が無かった）
顧客企業の顧問プログラマが専任で全部の開発を進める
- マネージャがいない
顧問プログラマとは
- 顧客の問題を見つけて、解決する
  - プログラムで解決できるなら解決する
- 一生涯プログラマで生きられる
「納品」をなくせばうまくいく
- XP が原型だけど、スクラムではない

2 社とも全く違うやり方ですが、同じアジャイルのアプローチ ( XP ) を適用しているうちに変化したんですね。アジャイル開発は会社によって違う、という好例です。

ちなみに、メンローイノベーションズはコロナによりペアプログラミングができなくなったものの、今ではリモートワークでもできるようアップデートされたそうです。

Culture. Storytelling. Joy. | Menlo Innovations

アジャイルな開発とは

ある物語

今度はアジャイル開発を物語風に紹介いただきました。

まずはよくあるシーンから。

あるところにビジネスマンがいた
すばらしいアイデアを持っているが開発スキルがない
そこでプログラマに「こんなものを作ってほしい」と依頼
できてみると、なにか違う
よくあるのが、思っていたものと違うものができること

そこでやり方を変えます。

要望の一部を切り出してそれを作る
それができたら、次の要望の一部を切り出して作る
ということで、小さく作ったものを少しずつ大きくしていく
1 回の依頼 → 納品ではなく、何回もぐるぐる回す

このやり方には、別の効果もあります。

このビジネスマンはいろいろなやりたいことがある
- どれから実現したらいいかわからない
プログラマは、どれか 1 つを小さく作る
できるだけ小さく作ったうえで有効であるかどうかを検証する
- 作りやすいように小さく作るのではなく、価値を検証するために小さく作る
ビジネス側はフィードバックをえて意思決定できる
お互いに考えていることがわかるようになる

やがて、もっと作りたいということになって、プログラマの人数を増やすとします。

もともと 1 人でやっていたプログラマが他のメンバーに指示するだけにする
- もともとのプログラマは、ものを作るやりがいが減る
ビジネスマン <-> チームでやろう
- もしやる気のないメンバーがいたなら変えていい
- 顧客（この場合はビジネスマン）が開発チームのやる気を搾取しようとするなら顧客も変えていい
いつの間にかオーダーするビジネスマンもチームになっている

この物語を聞いていると、以前の弊社のウェビナーに登場いただいた「星のや」さんの開発チームを思い出しました。アジャイルに開発を進めるようになって、プロダクトオーナーがいつの間にか開発チームと一体化していたエピソードが非常に印象的でした。

星野リゾートがこだわった「内製化」－現場出身メンバーが躍進するプロダクトオーナーチーム｜SEカレッジウェビナーレポート

アジャイルソフトウェア開発宣言

この物語のようにソフトウェアを作ったらいいじゃないかという人たちが、 2001 年にアジャイルソフトウェア開発宣言を公開しました。アジャイルという言葉がこの意味で使われるようになった初めてのことでした。

この有名な宣言には、実は続きがあります。

私たちは以下の原則に従う:

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、 2 ～ 3 週間から 2 ～ 3 ヶ月という
できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

（アジャイル宣言の背後にある原則より引用）

この原則の内容を掘り下げて解説いただきました。

「 2 ～ 3 週間から 2 ～ 3 ヶ月」

いまは「 2 ～ 3 時間から 2 ～ 3 日」と読み替えるといい

「フェイス・トゥ・フェイス」

いまはリモートが進んだ
ただし、たまにフェイス・トゥ・フェイスで話したときのものは再現できていない

「技術的卓越性と優れた設計」

アジャイルで開発するとなるとそれを支える技術が重要

「シンプルさ（ムダなく作れる量を最大限にすること）」

いまでは誤訳といわれている
正しくは「作らなくてすむ量を最大限にする」
ムダなことはやらないシンプルさ

「個人と対話を」

「個人との対話」と誤解されがち
原文は「 individuals and interactions 」
個人が大事だし、対話が大事、ということ

アジャイル宣言から 20 年たって、いろいろなアジャイルが出てきています。中には本当にアジャイルといえるんだろうか疑問に思うこともあります。そのときに参照するのが、この原則とのことでした。

アジャイル開発に必要なこと

では、アジャイル開発とは、具体的にどのようなものなのでしょうか。

ウォーターフォールとの違い
- この図ではない
アジャイルの開発の特徴 = アジャイルな人や組織の特徴
- ビジョンや目標を共有し、全体がそこに向かっている
- ルール、プロセス、手法が常に変わり続けている
- アウトカム（結果）を重視している
- チームごとに人が違うから、そのチームならではのやり方になっている
アジャイルなマインドセットも必要
- ある心理学の実験
  - 結果を褒められたグループはガチガチマインドセットになってアドバイスしない、嘘をつく
  - 努力を褒められたグループはアドバイスするようになる

アジャイルへのたどり着き方

アジャイル開発の原則やその柔軟に変化に対応するマインドがわかったところで、具体的にどのようにすると、アジャイル開発になるのか、その “たどり着き方” を解説いただきます。

XP を提唱したケント・ベックは、アジャイルの知識体系を、どういうプラクティスを実践すると、本当に欲しい価値にたどり着けるのか、たどり着ける理由は何か、この「価値」「原則」「プラクティス」の 3 つで整理しました。

例えば、「自転車に乗りたい」ということを、価値とプラクティスと原則で分けてみます。

自転車に乗って何がしたいのかが価値（ ex. 遠くに行きたい、速く行きたい、友だちと一緒に行きたい etc. ）
自転車に乗れるために何をするのか、それがプラクティス（ ex. ペダルを漕ぐ、バランスを取る、練習場所は転んでも痛くないところ etc. ）
それをすることでうまくいく理由を説明するのが原則（ ex. ペダルを漕ぐとチェーンとギアをつたって後輪が回り、前に進むようになる etc. ）

以下、この 3 つをそれぞれ見ていきます。

価値

価値とは、ほしいもの
ただでは手に入らない

では、その価値をどう測るのでしょうか。

図のような開発 Issue があったとして、価値の大小とコスト大小の 2 軸で分けてみます。開発の始めはどれから選びますか？

答えC → B → D → A

これを時間順に並べて積上げると、時間につれて積上げられたのが累積価値になります。

価値はリリースした後からあらわれる
価値は蓄積していく
機能は価値を生むもので、それ自体が価値ではない

また、この中で ROI が一番よいのはどれでしょうか？

こう考えると、価値については次のことが言えます。

時間をかけずに価値が生まれるものを優先
- 作らなくて良いものもわかる
- 作らないといけないものが新たにわかる

バックログの優先順位を決めるのに、とても指標になりやすいものですね！

原則

「価値を求めている人が誰で、その人が求めている価値はなんですか？」ここまで考えるのが価値です。「それは誰が実現するのか、実現する人は他の人とどうやって協調するのか？」これを考えるのが原則です。

原則を考えるときに、中心になる要素が 3 つあります。

コミュニケーション
技術
人

それぞれの要素を見てみましょう。

コミュニケーション

ホットであればあるほど、情報は伝わる (情報帯域という。 ex. 紙 < 動画、質疑応答なし < 質疑応答あり、電話での 2 人 < ホワイトボードに向かった 2 人)
コミュニケーションパスは少ない方が良い（ 3 人より 5 人、10 人のほうがコミュニケーションする工数がかかる ex. 10 人のメンバーがいるマネージャはコミュニケーションだけで 1 日が終わる）
コミュニケーションを小さく閉じると、今度は伝言ゲームが起こる
できるだけ、少人数で一緒にいるといい。ただし、それを実現するのは難しい

技術

バグ修正など時間ばかりかかって価値が生まれない = 技術的負債が溜まっている状態
技術的負債とは、無理をして頑張ってしまうと生まれる = 不適切なエンジニアリングをすると生まれやすい。複利で膨らむ
必ず生まれるので、常にキレイにし続ける努力が必要。それには将来予測ではなく変更容易性を大事にする

人

変更容易性を実現するのは難しい。アジャイルはそんな難しい仕組みでも実現できる「人」を育てよう、という方針
モチベーション 3.0 でお金 / 地位 / 安定から変わって、自律（自分に裁量があること）/ 熟達（成長できること）/ 目的（自分一人では出来ない大きな目的に貢献できること）に変わった
- お金ではモチベーションが保てない（ 800 万円を超えるとモチベーションが生まれにくいという研究結果もある）
チームによる学習も必要
- 重要になるのが心理的安全性
  - 今やっている仕事への質問や疑問、間違えがあると思えば、誰もが誰に対しても気兼ねなく言える
  - 心理的安全性が高いと学習が生まれ、パフォーマンスが上がる
  - 誤解されがちだが、心理的安全性が高くなると情報共有が進み、衝突がよく起きるようになる
  - 中原淳先生（立教大学教授）曰く「心理的安全性はしんどい」
    
    「心理的安全バブル」にご注意を!! : 心理的安全とは「チームで仲良くぬるま湯につかること」ではない！　 | 立教大学経営学部中原淳研究室 – 大人の学びを科学する | NAKAHARA-LAB.net より

プラクティス

最後はプラクティスです。

練習という訳が当てられがちだが「実践」
なぜやるのか、なんのためにやるのかを考えること
うまくいくかどうかやってみて改善するもの

超基本プラクティス

では、そのプラクティスについて、安井さんから誰にもおすすめのプラクティスを紹介いただきました。

このあと各プラクティスの進め方と XP とスクラムのプラクティスを紹介いただきました。なお、アジャイルのプラクティスというと、今ではスクラムが主流になりましたが、 XP のプラクティスの大部分が含まれています。

プラクティスの注意点

またプラクティスを使うのにあたって、注意点を紹介いただきました。

プラクティスは単独で使えるだけでなく相互作用している
- ex. “イテレーション” が始まると “タスクボード” が作られ、イテレーションが終わるときに “ふりかえり” がある
プラクティスはテコ（原則）が必要
- テコの原理が働く
- 持ち上げたい価値が大きくて重たければ重たいほど、プラクティスと原則は必要になる
プラクティスは書いてある通りにやってもダメ（学習するものだから）
- 常になぜやるのかを意識しないとダメ -> 手本通りにやって、ガイドと結果が違うなら、なぜ違うのか考えること
- 守破離が必要
  - 守の段階では本やガイド、コーチがいると良い

アジャイルの向き不向き

アジャイルに向き不向きがあるかというと、「あります」とはっきり断言された安井さん。向き不向きを知って、正しく適用しましょう、というお話をいただきました。

これはプロジェクトをマッピングした図。この図にある “カオス” はスクラム向けではない
“複雑” “込み入った” 領域で活きる
“シンプル” もアジャイルでもやってもよいが、オーバーヘッドが大きい。計画駆動がよい
これは仕事の進め方でもある
- 何が何だか分からない状態からわかる状態になっていく。それに合わせてやり方もかわる

開発の最初はアジャイルで進めながら、そのあと軌道に乗ってもアジャイルをそのまま適用しがちですが、そうではないと。その局面に合わせてやり方が変わるということで、これは目からうろこでした！