海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

Agile Leadership Summit 2019 に参加してきた

Agile Leadership Summit 2019 に参加してきた



どんなイベントか

Agile Leadesrship Summit 2019 に参加してきましたという話。

www.agileleadershipsummit.org

OST(Open Space Technology) 形式で、テーマだしとテーマごとにワイワイガヤガヤスタイル。

参加者はアジャイル界隈で有名人だとか、アジャイル実践している人たちがほとんど。

これはまあイベントの趣旨としても違和感ない話。しかし新鮮だった。

どんな感じだったのかは関さんがハッシュタグ(#AgileLeaders) をまとめてくださった通りな感じ。

togetter.com


基調講演

基調講演は武装解除に携わる瀬谷ルミ子さんの講演

紛争調停 → 紛争予防の活動にシフトしたとのこと。

コンフリクト解決とコンフリクト予防といった考え方は、コトの規模ははるかに違うが、日々のアジャイル推進とかとかなり似通った部分があったのでとても面白かった(小並感)

以下、適当におもいだせる部分で日々の仕事でも見かけると感じた部分。

  • 女性が調印プロセスにいない和平合意は破棄されやすい。 紛争で被害に遭った当事者を置き去りにして決定しても長続きしない。

  → 現場を無視してどうやるかを決めても長続きしないのと一緒

  • 自分たちが居なくなっても紛争の火種が早めに消せる状態が目的。自立を促す。   → これは普段から言っている通り、自分をクビにするのが SM なり PMO のお仕事、ってゆーのと同じ。

  • 身構えさせない会話をしないと本音が引き出せない。そんな研修もしている。

  → これは外部からコーチングで現場に入った時に超重要なスキル。どんなことやるのか非常に知りたいなあ。

  • 戦争はニュースになるけど平和はニュースにならない。

  → プロジェクトも順当に終わらせられた奴はあまり評価されない。ってのと似た感じがした。失礼ながら。


OST 学んだこと

自分はコーチ卒業のタイミングについていろいろ聞いてみたいのでボードマスターをやったのが1セッション。

他にもヤバめなチームがあるなら、そっち行った方がいいかな?と思いつつも、今のチームが放置して改善し続けられるかな?という悩みが多々あって、判断になる目安がいろんな観点から欲しかったので。

  • 自分たちで問題を解決できるようになったら

  • 自分たちで実験できるようになったら

  • 声がかからなくなったら or 話を聞くだけで彼らが自己解決できるようになったら。

あたりが目安だね、と。まあ思ってた通りくらいの結論だった。それはそれでよし。

あとはスタバ分室でゲリラで高収入をテーマにしたところもあったので出かけてきた。(謎)

話題になっていたのは、チームを離れてもチームがアジャイルになり続けてくような状態にメンテしてくれる活動家が育たないと、厳しい。スケールしない。っていう話。

こいつは離れた後に一番不安になるところなので非常に課題感があるところ。

フォロワーは生まれるけど、プロモーターまでは育たないし。

自分が開発をうまくやるにはどうしたらいいか、っていう観点から、チーム・組織がもっとうまくやるにはどうしたらいいか?っていう観点へ変わるのは、やっぱり難しい。

自動詞と他動詞なのか、SVC で語るのか SVOC で語るのかくらい変わってくる(懐かしい英文法の話)

持続可能なアジャイルチームを作るにはどんな人が必要か、そのために何をしたらいいか。

それがわかればアジャイルコーチって職業自体要らなくなりそう。

難しい


その他の印象

参加者の熱量がスゴイ

社内で実践者や広める役割の人に会うことはほぼないので、とても新鮮。

(社外とはいえ同志がいるってのはいいことよね。)

何をやれば解決できるのか、社内に有識者も見当たらないままこの7年くらいやってきたけど詐欺師症候群に近いような不安や孤独感の多い仕事だったけどもう少しアジャイルを頑張る気になれた気が、する。しんどいことには変わらんけど。


来年もやるそうで。来年は2日間開催とのこと。

確かに枠足りない気がしたからいい気がする。

スロットあたりの参加者はこれ以上増やせない気もするけど。

(傍観者ばっかりになっちゃう)

総論とてもよいイベントだったので、多分来年も参加だろうな。

来年も有給とって自費参加しそうではある。

最後に、素晴らしい運営の方々に素晴らしいイベントを設けてくれたことへの感謝を。

どうやってアジャイルを推進するか?

どうやってアジャイルを組織で推進するか

TL;DR

  • 組織内の知識を深める

  • 成功事例を小さく作り、仲間を増やす

  • トップダウンがあってもいいけど依存はしない

  • 手法ではなく、課題から始める


アジャイルを推進する状況を考えてみる

  1. アジャイルが好きで、自社に広めていきたい。

  2. アジャイルが流行ってるから、組織で取り入れたい。

  3. 偉い人に言われて、推進することになった。

大体この辺ですかね、推進する人の抱える背景は。

1.の方の落とし穴は、現場 VS 私&アジャイル になってしまいがちなことです。

その勝負に負けると、組織はあなたの愛するアジャイルから遠ざかります。 (現場と戦う時点であなたが勝っても彼らは遠ざかります)

2.の方の落とし穴は、何をやるべきかが判らず、イマイチ効果の低い導入となってしまうことです。

なんかアジャイルって上手くいった感じがしないんだよね、と言う実感が広がりやすいです。

3.の方の落とし穴は、何故やるのかを特定できず、場合によっては直近の成果に走ってしまい、結果・効果が得られないことです。

ドラスティックに進めると、組織のパフォーマンスがエラいことになります。(もちろんダメな方向に)

大抵どれも辛い結末になるので、避けやすい(今までのところ)やり方を考えています。

とりあえず現時点で、大事なのは冒頭に書いた4点かなと。


1. 組織内の知識を深める

アジャイルについて何も知らない人がいる組織で変えていくのは非常に大変です。

最低限レベルの情報は最初の教育で必須だと思います。

この情報化社会なので、ある程度みんな「アジャイル」と言う言葉は知っています。

『ドキュメント作らないんでしょ?』

マジでそれくらいのことを言われる環境で進める羽目になります。最低限大事。プロトコルがあってないのに突っ込んだカイゼンの会話はできないっす。

で、初期の教育フェーズで大事なのは、メンバーとの双方向の会話を可能な限りリッチにすること。

机上のお勉強だけならなんとなくわかった気がするしやれるほどわかった気はしないので。

話を聞いて、自分の頭で理解して、不安や疑問に思う点を挙げて、会話を重ねて理解を深めることが、教育の効果を最大化する上で大事。超大事。


2.成功事例を小さく作り、仲間を増やす

いきなり風呂敷を広げて大規模にやろうとするのは無謀です。

失敗した時のリスクは測りきれないし、コントロールも効かないでしょう。

彼らの成功を導けるよう、ただし導かれた、と言う受け身にならないように、イイ感じに導かないといけないです。超大変。

そもそも組織の変化というのはとても複雑なので、はじめにコレをやる!と決めてうまくいく場合はほとんどないです。

大抵の場合、現場にいる人間それぞれの利害が抵抗や受け入れやすさに変化します。

できることとしては、臨機応変に目の前の課題を潰し、メンバーの変化・組織の変化を加速させてあげることくらい。

複雑なものに対して事前に大きくやることは決めない。

クネビンフレームワークそのものですね。

www.slideshare.net

複雑なものに対して大きく計画駆動するのは、アジャイルで進むべきドメインに WF で突撃するのと同じくらい無謀です。監察大事。超大事。

まずは、小さく成功する。(改善する、だけではない)

改善する、だけだと、そこで ”良かったね” で止まってしまいがちになります。

メンバーが主体となって意識を持って、彼ら自信が「変化して、成功した」の体験を積むことで、コレから先に向けて変化するイキモノになる一歩が踏み出せます。

っていうか、そこで、カイゼンへの踏み出し方まで覚え始めてもらわないと、後が辛いです。

いきなり大きく変わ流のは難しいので、小さく改善する、で、成功した仲間(イキモノ)を増やす。

大きく広げる時にはそういったアプローチが後々重要になります。

#個人的に、過去に関わったメンバーが、全く異なる場面で、全く知らない方へアジャイルコーチングしている場面を見たときは超嬉しかったです。そういう仲間を増やすのは、少しだけ推進する人の心の支えになったりします。少しだけ。


3.トップダウンがあってもいいけど依存はしない

コレはちょっとだけ複雑な話?になります。

トップのコミットがあると、とてもスムーズにことが運びます。

体制図にもない状態から参画したこともありますが、まあまあ大変でした。

ある程度の Authorize はちょっとだけ虎の威を借りて仕事を進みやすくできます。

とはいえ、「●●事業部長がやるといっているので!」と印籠のように使うのは危険が多いです。

だいたい、1. の落とし穴の派生系で、私+アジャイル VS 現場、の構図になりやすく、推進しても効果に現れにくいです。

(なお、●●事業部長は味方じゃなくなったりします。突然に。)

なので、バランス大事にして進めるのが良いです。

Fearless change でも触れられているように、トップのサポートはとても強い武器になります。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

それがあるだけで、(睨まれる心配がない)という、不安も払拭できますので。

(やらないと睨まれるかもしれない、という消極的な積極性につながることもありますけど)


4.手法ではなく、課題から始める

一番大事だけど最後になってしまった。

スクラムとかカンバンとか、SAFe だとか LeSS だとか、全部手法です。

現場の課題が何で、それを解決できるのがどの手法なのか、を探すのが一番大事です。

手法が先じゃなくて、課題が先。

お薬が先じゃなくて、症状が先。

症状を診断して、病名を突き止めて、処方(手法)を提示する。

MR にならないでください。医者になってください。解決策の手法を目的にしないでください。

何度でも言いますが、

課題が先。手法は後。

スクラムが好きなのはいい、アジャイルが好きなのはいいですが、大事なのは、

顧客とプロダクトを見て、自分たちの課題を見つけて最適化し続けること。

#課題を照らし出すための手法として機能するいろいろな方法(スクラムだったり、カンバンのボトルネック探しだったり)がありますけどね。

どこかの誰かがスクラムでうまくいった、としても、それはあくまで「彼らの課題」に対して、その手法が機能した、ということです。

あなたに同じ「課題」があるとは限らないです。

形だけ真似するカーゴカルトは危険の塊です。注意。超注意。

カーゴ・カルト - Wikipedia

課題が見つかったら、どういう方向性で改善をするのかは、アジャイルに合わせましょう。

Agile manifesto の価値と原理があるので、そこから適当に導いてみましょう。実験しながら。

解決策はいろいろ取れるので、注意しながら進めましょう。

「問題が再発しないように、リリースまでに必要な仕様を網羅してから実装を始める」

とも解決できれば、

「さっさと問題に気づけるように早くレビューする」

とも解決できたりするのと同じです。解決の方向性が大事。

#適当にロジカルシンキングするといかにもそれっぽいソリューションは出せるので、とても注意しましょう。

#なぜなぜ分析なんてしても、見る人が甘ければいくらでも恣意的に曲げられるので。


っていうのを書いてたら、@Ryuzee 大先生がもっといいことを分かりやすく書いてたのでそっちをみましょう。(投げやり)

www.ryuzee.com


推進する人の集まりである、アジャイルリーダーシップサミット2019に参加できそうです。楽しみです。

www.agileleadershipsummit.org

DevOps は組織や文化の話なのか?

DevOps は組織や文化の話なのか?

TL;DR

  • 畢竟そうなるけど背景を踏まえて理解しようね。

  • その前にいっぱいやるべき事を無視して DevOps!は違うんじゃないかな


DevOps 素晴らしいという話?

最近話題の DevOps

猫も杓子も DevOps

これからやりたい DevOps

みんな大好き DevOps

そんな DevOps の話

DevOps, DevOps ってなんだ。


宇宙刑事ギャバン

よく聞くこと

DevOps はツールやプロセスではなく組織や文化の話だというコラムをよく見る。

DevOps志向の組織づくりをいかに進めるか|IT Leaders

なんでそうなるのか?っていう整理がしたい。(イマココ)

DevOps の経緯を知る

例のハートマークこと必ず現れるいつものアレ。

www.slideshare.net

2009 年に発表

「毎日何回もデプロイしてるよ」

→ 「マジか」→そして DevOps ブームへ

そもそも 10 deploys/day の何が嬉しいのか

みんなデプロイ回数でお金がもらえる契約とか?

じゃなくて、早く Production で使いたいから

  • 作り出した価値を早期に獲得したい
    • どんなにカッコよく作っても本番で使われないソフトウェアに価値はないから。
    • 本番で使われるのを待ってる間に作ったモノの価値が下がる(ビジネス的な熱が冷める)
  • 正しいものを作ったのか、リリースしてフィードバックを早期に得たい。
    • それにより、思い込みで作ってしまうサンクコストを減らしたい。

だいたいこの2つ。要は価値収益の最大化とリスク低減に効果がある。

そりゃあやる価値あるよね、というのはわかる。

(ココがやる理由として腹落ちしないなら無理してやる必要ないんじゃないかな!)

(遅くていい理由で被害を被るのはビジネス側だからあんまり気づきにくいしね!)

バリューストリームマップの話

バリューストリームマップというものがある

元はトヨタかな?

www.itmedia.co.jp

全体を見てボトルネックを探すことができる。

リーンで目指しているように、ボトルネック以上のパフォーマンスはでないので、解消すべき最大のボトルネックこそが、カイゼンをする最優先箇所。

ボトルネックでない部分をカイゼンしてもトータルのパフォーマンスは上がらないから意味がない。

なんで DevOps がバリューストリームで課題になってきたのか

アプリはアジャイルになって、リリースがボトルネックになっただけ。

f:id:Bashiko:20190626020029p:plain

そこで DevOps とやらで、リリースの障壁を下げたのが元々。

リリースがボトルネックにならないように、DevOps ツールが増えてきた。

DevOps ツールの話

元々 DevOps で使われるツール群は昔からあったものが多い。Puppet とか。

この辺はサーバのコンフィギュレーションを効率化するための意味合いが強かった。

どっちかというと主目的はインフラ業務(ミドルウェア突っ込んだりとか)の効率化・自動化。今で言うところの RPA。

サーバに SSH して (またはデータセンターでひーこらいいながら) あーだこーだ構成するよりツール一発で出来た方が属人化しにくい。

更にはアプリケーションのデプロイメントだとか、クラウド時代に突入してからはインフラも含めた自動化がその延長で実現出来たので Happy になった。

ただ、これはあくまでインフラ屋さん・運用屋さんの仕事の効率化の側面がメイン。

クラウドでインフラ面の自由度が増えて、デプロイの戦略が多様化出来たので、リリースのリスクが減らせることにより、DevOps が進んだと個人的には思うけど。

もっとバリューストリームを広げて考える

f:id:Bashiko:20190626020704p:plain

こんなのが欲しい!から、コレよコレ、サイコー!(またはクソ)までの LT

欲しいと思うのをいかに早く拾えるか。

または、いかに間違いに早く気付けるか。

ここで大体開発チームだけじゃなくて、組織の壁が出てくる

職能性組織の壁、扱う言語の壁、聞いちゃいけない現状のプロセスや体制。

とはいえここに手を入れないと、早く気づく機会を失うので、組織を再編して、職能性ではなく、限りなくEnd-to-End で、Opportunity 獲得 → リリースまでを実現できる組織が必要になってくる。(Measure も必要だけど)

ちょっと感じる、大きめ古めの企業における組織文化の壁

これを進めると、作ったものの正しさをチェックする機能(いわゆるソフトウェアテストとか)ではなく、正しいものを作ったかという検査の機会を持ててしまう。

作る側だけではなく、依頼した側(こういう表現は好きではない)にも、強制的にフィードバックが働くので、投げっぱなしジャーマンスープレックスなビジネスサイドがそのフィードバックに耐えられるかどうかについては、実は文化的に超えないといけない組織は多い気がする。

まあそもそもそこに疑問を持とうとしない、言ったものが作られれば、それをユーザーが使っていようが使っていまいが興味がない、と言う組織であれば、DevOps を進めてバリューストリームの LT を削減せよ、と言ったプレッシャーもないはずだから、課題にもなりにくいかなとも思う。

まあ本来、スクラムでいえば PO が、プロダクトの成功を気にしない、なんてのはあってはならないのだけど。

スクラムマスターの成果物

スクラムマスターの成果物ってなんだろうか

個人的にはそのチームそのものかなと。

チームの熟練度?文化?意識?とかが当てはまると思うのだけどうまい単語が思いつかない。

スクラムマスターが仕事をしていくと、段々とスクラムマスターが必要とされない、というか、専任のスクラムマスターがいなくてもいいかな、って瞬間が来る。

チームが課題解決できて、解決方向もアジャイルな意識付け、方向を向いていて、専任で置いとくコストメリットが合わなくなってくる。

専任のメリットは甚だ大きいけど、いなくてもそこそこ回る。嬉しいやら悲しいやら。

お菓子デプロイおじさん、空調おじさん、Slack 絵文字作製おじさんになり始めたら卒業のサイン。

(ぶっちやけその状況だとスクラムマスターとしての学びに繋がる困難/闇/地獄と遭遇しないので、個人的にもコスパが悪かったりする。)

(居心地はいいんだけど)

そういういいチームの状態を作るために、中間成果物としての日々のファシリテーションとか、プロセスとか Teaching/Coaching がある。

けどやっぱりあくまで最終目標とするアウトプットじゃないのかなと。

この辺はスポーツのコーチや子育てと同じかもしれんね。


(追記)逆に、チームを向上させる以外のことを成果物として目標・目的にしてしまうと、絶対に良いことにならない。

手段は目的にはなり得ないし、自分のレジュメのためだけになんらかの手段(プラクティスやプロセスやツールとか)を目的にするのはご法度と思っていい。

JIRA とかにチケットを書くときに気をつける事

チケットを書くうえで絶対に気をつけたい事

実現したい状態を書く。何をやるかではない。

JIRA とかでチケット駆動開発してたりとか、まあ付箋でもなんでも同じなんですが、気をつけなきゃいけないのは、付箋に書いても大抵伝わらないので、完了条件で揉めることが多々あるということ。

依頼した A さんにとっての期待値と、依頼された B さんにとっての 予測値は大抵ずれる。

壊れるほど愛しても 1/3 も伝わらないのにチケットに書いただけじゃもっと伝わらないのが人生。

で、だいたい揉める場合は、

「***する」

みたいな書き方をされてる。

これだと、やったかどうかを評価しがちで、やった後で、出来てる出来てないといった達成度を厳密にするために中世フラスコ画もビックリなレベルで異様に細かい Acceptance Criteria を書き込む羽目になる。

f:id:Bashiko:20190612025655p:plain
中世フラスコ画の雑なイメージ

なので、そのチケットを実行した結果、どういった状態になっていて欲しいのかを明確にして、共有するのがおすすめ。

というか、それを実現するための手法は正直どうでもよくないですかね > 依頼する側の人

とはいえ、どういった状態になっているか、という話も、認識ずれがまだ起こりやすい。

作った人「僕はこれで使えると思う」

みたいな不毛な主張と戦う羽目になってつらい。

なので、誰にとって?っていう視点を明確化するために、ペルソナとかを定義しておくといい。おすすめ。

ついでに言えば、実現手法について変なデザインをしないためにも、

「なぜそれが欲しいのか?」

まで表現しておくと、効率よく伝わる。

何故ならその欲求を満たしているかが判断基準になるから。

ってな情報をシンプルに描き起こせるので、ユーザーストーリーの書き方のテンプレートは、

***として(ペルソナ)

***したい(達成したい状態)

何故ならば***(理由)

っていう形にできてて、広く使われてる。

よく一部(または豪快に全部)の要素を吹っ飛ばしてチケットを書く人も多いけど、その分伝わらないリスクがあるのをゆめゆめ忘れないようにしないと後で泣く。


相手に伝わるかどうかのリスクは、エンジニアリング組織論への招待にて、”通信不確実性” って形で紹介されてた。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

これまでだと Perfect なドキュメントを書く!みたいになりがちだけど、会話の方が情報量多いし、コスパがいいと個人的には思うので、無駄なことしないで、チケット書いて対話するのが一番。

認識する事象と表現された表記が異なるってのはソシュールシーニュシニフィアンと同じ話。

ここに書いている内容もきっと Web 経由では 1/3 も伝わらない。


1/3の純情な感情 - SIAM SHADE


めっちゃどうでもいいけど、スクラムの用語は一般的に伝わりやすい言葉を使っているので、取っ付きやすい反面、誤解されてクソみたいなプラクティス運用されている場面もよく見かけるけど、これもまたスクラムガイドからは伝わりきらない通信不確実性の一つ。(スクラムマスターが機能していなともいう)