Lean/Agile ゼミの陶山です。

先日、カナダでアジャイルコーチをされている Cherifa さんをお招きして、
社内でプレゼンしていただく機会を作ることができました。

Lean/Agile Meetup と題して開催し、その様子は PR Blog にまとめてもらっています。

https://cyberagent.ai/pr/archives/5108

Cherifa さんとは 今年の８月に San Diego で開催された Agile 2018 で出会いました。

Agile2018 参加レポート – Day 4 & 5, 総括

当時から日本にOffで旅行に来る計画があったそうで、日本に来たら会社を案内するよ、位の会話をしていたのですが、今回それが実現した形になりました。

この記事では、エンジニアとして、また Lean/Agile ゼミとして日々 Agile を研究・実践する立場から、
Cherifa さんのセッションや、彼女との会話を通じて学んだこと、その中でも特に印象深かったものについてまとめたいと思います。

#1 Factor of Self-Organization

まず Cherifa さんは Agile の要素を３つに分けて説明してくれました。

• Customer
• Team
• Improvement

これは Agile Manifesto の内容とも合致し、とても納得感のある説明だったのですが、
その中の Team を構成する要素の一つ「Self-Organization – 自己組織化」について悩んでいるところがあり、
安直な質問ではあるのですが、ストレートに聞いてみました。

「自己組織化にとっていちばん大切な、キーファクターはなんでしょうか？」

彼女の答えは、即答で「データ」でした。

判断に必要な情報が可視化、共有されていること、そしてその判断を実行するために必要な権限をチームが有すること。

前期のゼミ活動でアジャイルにおけるメトリクスとは？というテーマで研究を行っていて、データは

「正しい方向に進んでいるか？」
「うまくやれているところはどこか？改善できるところはどこか？」

を示す羅針盤のような存在として捉えていました。

もちろんチームや組織のコンテキストに合わせて適応する事が必要、というのは大前提だと思うのですが、
なるほどデータ自体が自己組織化を促すファクターにもなりうるのか、と新たな気づきを与えてもらいました。

Disciplined Agile Deliver Framework/DAD

Disciplined Agile Deliver – DAD – これは私の不勉強で、概念自体を知りませんでした。

セッションの最初の段階で Scaling Agile Framework との説明があったので、 SAFe の仲間かな？と思ったのですが、SAFe よりも古参で、どちらも RUP を源流としている、とのことでした。

スケールという言葉からは、スクラムの複数チームへの拡張である LeSS や、スクラムの持つ自己相似性を利用してスタックする Scrum@Scale のように、組織アーキテクチャのスケール、つまりサイズアップが連想されます。

DAD にももちろんこの意味でのスケールは含まれているのですが、
より複雑な（Complex）状況 ー 例えば、コンプライアンスやロケーション、大規模チームやソフトウェア ー
に Agile を適応するためのフレームワークである、と教えていただきました。
いまの環境の持つ Complexity Factor – 複雑さの要因をまず理解してから、そのコンテキストに Agile のプラクティスを「適応する」ことが大切だ、と。

なるほど確かに Agile をスケールするフレームワークだと納得感があります。
彼女の言葉を借りて、“Evolving(進化する)” のためのフレームワークという方が、コンテキストに適応する、継続的に改善する、という意味も感じられて好みでした。

DAD については知ったばかりでまだまだ説明できる段階にはないのですが、
今の自分の課題感ともマッチするところもあり、引き続き研究したいと考えています。

Value Dimension

Value(価値) とは何か、Value を届けるために必要なものはなにかー
これは私が Agile2018 から持ち帰った、もやもやしたテーマの１つでした。
そこで、セッションをやってくださることが決まったときに、私から彼女へトピックとして含めてもらえるようお願いしました。

Cherifa さんはセッションの中で、 Value Dimension というフレームワークで「価値」を説明してくれました。

• Business Architecture
  • 戦略、能力、バリューストリーム
    • 正しいことをしているか？
• イノベーション
  • 世の中に出てない新しいことか？
    • 顧客にとっての価値を創出しているか？
• Lean/Agile
  • プラクティスの適応
    • 正しいやり方でやっているか？
• Value Management
  • “LifeCycle of Value” ~ Define, Deliver, Harvest the value
    • 何が価値か？

もちろんこれを自分たちのビジネスに当てはめて、自分たちにとっての価値を考えなければならないのですが、
今まで曖昧だった「価値」を考える方向性を１つ与えてもらったような気がします。

また、「どれが一番大切なのか？」「どれか１つでも成り立つのか？」という質問に、「３つすべてが必要」と教えてくださったことも印象的でした。
たとえばプラクティスを適応するだけでは価値は届かないですし、価値を届けられても Agile プラクティスを適応して早く学ぶことで競合と戦っていなかければ生き残れない、と言う具合です。
これを心に留めて、より価値を届けるプロダクトを目指したいと思います。

Agile “Norm” in Japanese Culture

懇親会の際、会話のながれで「日本文化はとても Agile 的だ」と Cherifa さんがおっしゃっいました。
素直にとても嬉しかったのですが、私の日頃の感覚とけっこう相違があって、

「そんなことはないと思います」

という旨の回答をしてしまいました。

よくよく話を聞いてみると、
例えば、優先席の付近でどのように振る舞うか？ということであったり、
エスカレーターでは同じ方向に並ぶ… など、
みんなが「良い」とされている価値を理解していて、それをもとに行動しているよね、と。
これは「Team Norm（チームの約束）」そのものだよ、ということでした。

このような「暗黙知」ーみんなが「知っておくべき」とされていること、はチームでも起こりがちだと思います。
それを「忖度」する文化はとても日本的だと思うのですが、忖度するよりも明文化して、形式知にしておくことで約束を履行されるようにするべき、と考えていました。

しかし今回の Cherifa さんとのコミュニケーションを通じて、そもそも Goal を統一することが目的であって、形式知にすることが目的なわけではない。
Management3.0 で言うところの「環境を整える」ための手段の１つとして形式知にするというプラクティスがあるんだな、という理解の転換が起こりました。

まとめ

Agile Transformation はよく旅（Journey）に例えられます。
継続的であること、途中であること、苦難を伴うこと、様々なことが連想され、メタファーとして秀逸だなと思いますし、この表現が好きです。

学び続けること、考え続けること、伝え続けること、共有し続けること、挑戦し続けること、実験し続けること、そして適応し続けることー
これらが Agile を進めるために必要であると、勇気をもらったような気がします。

また、途中で出会う人々との縁を大切にすること、オープンマインドで新しい文化や考え方を受け入れること。
これもまた旅の楽しみであり、 Agile の醍醐味の１つなのかな、と改めて感じられました。

また Agile への想いが強まった、良い経験となりました！