Adways Advent Calendar 2019 13日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2019

こんばんは。りょーまです。
社内でアジャイルやUXデザインを推進している人です。

先日、我々の開発するプロダクトでスプリントが100週目を迎えました！
実際にやってみたこととか、その結果わかったこととか
現場のリアル を書いていきたいと思います。

前提として、私の役割は以下のようなものです。

スクラムマスター
チームマネージャー

100週分の思いを詰め込んだのでめちゃめちゃ長くなってしまいましたが
お付き合いくださいませ。

※ アジャイル中心の話ではないです

スプリント100週の威力

これは気づきがない方がおかしいですね

f:id:AdwaysEngineerBlog:20191218144912p:plain

※ 1スプリント2週間の時期もありました

アジャイルとは

スプリントということで
まず最初にアジャイルに関しての簡単な説明をします

迅速かつ適応的にプロダクトを作り続ける開発手法(思想)のこと

まあ普通に言えばこんな感じなんですが
もう少し噛み砕くと

良いプロダクト作りたいよね！！！
「良い」それはユーザー(ステークホルダー)にとって価値があること
動くものを実際に触ってもらわないと価値があるかは 分からない
(それを界隈ではよく「不確実性」って呼んでいる)
分からないから、 一気に作るのはやめよう
どうせ間違える、どうせ失敗する、そのインパクトを最低限に抑えよう
そこで、 少しずつ作っていこう
少しずつ進めることで、早く間違える、早く失敗することができる
そこから 学びと改善を繰り返していくんだ

小さく考え、小さく作り
賢く失敗し、日常的に学び、柔軟に適応していく
それがアジャイルなんだ！どどん

気づいたことを書き出してみた

100週してみて一体どんな気づきがあったのか

f:id:AdwaysEngineerBlog:20191218144935p:plain

見えてきた3つの要素

これらをざっくりと抽象化すると大体以下の3つに分類できることがわかってきました

チーム/組織
知識/思考
行動

さて、細かくみていきましょう

チーム/組織

以前ブログチームビルディングを理論的に進める方法 - Adwaysエンジニアブログにも書きましたが、困難な事を解決するためにはチームの存在が必要不可欠です。

blog.engineer.adways.net

コミュニケーションから始まる

アジャイルは敏捷性を軸としています。
「我々は何をするべきか」「今どうなっているか」「これからどうしていくのか」
目的や理想、現状や課題を 各個人が常に十分に理解 し
継続的に改善を繰り返していく必要があります。
つまりは 密で高品質なコミュニケーション が必要とされます。

f:id:AdwaysEngineerBlog:20191218145050p:plain

コミュニケーションの定義

書籍「ヤフーの1on1」にて非常にしっくりくる言い回しで表現されていました。

自分の意図が相手に伝わって、相手が意図に沿って動いてくれること
出典：ヤフーの1on1―――部下を成長させるコミュニケーションの技法 | 本間浩輔 |本 | 通販 | Amazon

単純に会話するとか、仲良くすることがコミュニケーションの本質ではありません。
「POの意図が開発チームに伝わって、開発チームが意図に沿って動いてくれた」
こうなればアジャイルにおけるコミュニケーションがうまく行っているという事になります。

では、具体的に何をしてきたのかいくつかあげていきましょう。

ファシリテーション

よく勘違いされているのですが
ファシリテーション=司会をすることではありません。
ファシリテーターの任務は物事を 促進する ことです。

私自身もファシリテートをすることがよくありますが
次の三つは大事にしています。

疑問を投げかける
- チームでのディスカッションを活発化させるため
- 「〇〇についてはどう思う？」
- 自分が分かっていたとしても、参加者が分かっていなそうなら投げかける
要約する
- 話が進まない大きな理由は、「伝わっていないこと」「理解できていないこと」にある
- 文脈やポイントを整理し、こういうことかな？って要約してあげる
  - 仮に間違っていたとしても、間違っていることに気付ける
参加者に合意形成をさせる
- ファシリテーターをやる人はリーダーシップも高いことがあり、故に決定者になりがち
- 促進すると言うことは、相手がいて、その人達の主体性を刺激したい
  - 自分で決めてどうするんだよって話
- 基本的には合意形成に向かわせる
  - ただ、時にはトップダウンも必要

1on1

個人の集まりがチーム
- 一人一人の成長がものすごく重要
1on1の7つ道具 - Adwaysエンジニアブログ
- やり方とかはここに書いたので割愛

blog.engineer.adways.net

組織の壁を越えていく

密で高品質なコミュニケーションをとる
自分の意図を相手に伝え、相手に意図に沿って動いてもらう

・・・
・・・
・・・
一体誰と？？？

私は開発組織の人間ですが、プロダクトは開発だけでは成り立ちません。
ビジネスやデザイン といった異なる要素が絶妙に絡み合い、初めて(良い)プロダクトが生まれるのです(まだ経験半ばだけど。。)

f:id:AdwaysEngineerBlog:20191218145134p:plain

The Product Management Triangle – Product Logic

アジャイルのコミュニティに参加すると
「営業組織に理解してもらえない」
「うちのディレクターは期日を勝手に決めちゃう」
「エンジニアがビジネスに関心を持ってくれない」
といった愚痴悩みが溢れかえってます。

これは実際に弊社でも同様のことはありましたが
以下のような取り組みもあってか最近は随分と解消されたように思います。

エンジニアやデザイナーが営業組織に突入した
営業の偉い人やディレクターたちにアジャイルをちゃんと説明した
みんなでプロダクトを一緒に考える機会を作った
以上を続ける：一番大事

先日営業の方とランチに行った時に
「リーンキャンバスが〜」「ジャーニーマップが〜」って自然に出てきた時には感動を覚えました。
適切な手段と時間を掛ければ組織は変わります。

他にも色々やった

全部、広い意味で言えばコミュニケーションのため

幸せの四因子
- 心理的安全性の確保/向上
Geppo(Geppo - 従業員のコンディション変化発見ツール)
- メンバーの健康指標
Working Agreement
- 働く上での最低限のルール
ドラッカー風エクササイズ
- 期待マネジメント
デリゲーションポーカー
- 権限委譲
ムービングモチベーター
- モチベーション管理

チーム/組織はいわば環境です。
凸凹道を走るよりも、綺麗にならされたトラックを走る方が
ずっと良いタイムがでます。

結果を出したいのであれば、まずは組織に本格的に目を向けるべきだと私は本気で思っています。

知識/思考

正しい知識を持つことで、理想を設計することができ
理想を設計することで、課題を設計することができ
課題を設計する事で、意味ある行動に繋げることができます。

行動するとが大事なのは勿論のことなのですが
学術的背景を知っていることで、その行動の質をより高めることができます。

知識を深めるために

本を読む
- 原則を知ることはすごく大事
- 守破離
- やるならとことんやるべき
  - あるフェーズにおいてはそれが仕事で良い
  - 中途半端にやっても身につかない
コミュニティに参加する
- セミナーとかディスカションに行ってみる
- 先輩方や同士に現場のリアルを聞いてみる
- 他者よりできていることは自信に、できていないことは今後の糧に
言語化する
- 私がブログを書く理由がこれ
- 文字に起こすことで思考が整理され、インプットの質が高まる
- ノートでもホワイトボードでもパワポでもマインドマップでもなんでも良いので書き出してみること
説明する(他人に理解してもらう)
- 理解してもらうためには分かりやすい説明が必要
- 自身が本当にわかっていないと説明はできない
- 質問されて気づくことも多い
努力&努力
- 知識吸収は基本的にステークホルダーが存在しない
- 頑張れば頑張る分だけ身につく
- 逆に言えば言い訳できない

有効的だった知識や理論

一部抜粋

スクラム
- 全てはここから始まった
- スクラム体制が作られるまで - Adwaysエンジニアブログ
組織の成功循環モデル
- 関係-思考-行動-結果のサイクルが組織を成功に導く
- ダメな組織は逆でサイクルが回っている
イノベーター理論
- いきなり全員に広げない
- まずはアーリーアダプター(最初の理解者/仲間)を探す
タックマンモデル
- 形成-混乱-統一-機能
- 混乱期で諦めない
ゴールデンサークル
- why-how-what
- 目的から考えろ
OKR
- 組織の目標管理のために、ちまたで噂の〇〇〇を導入したみた話 - Adwaysエンジニアブログ
XP
- アジャイルにおける技術的改善アプローチ
  - CI/CD、ペア(モブ)プロ、TDD、リファクタリング
- スクラムのお友達
リーン
- アジャイルにおけるプロダクトマネジメント的アプローチ
  - リーンキャンバス、MVP
- スクラムのお友達
UXデザイン
- ユーザー体験を良くするための手法(視点)
  - ジャーニーマップ、ユーザーインタビュー、ペルソナ分析

blog.engineer.adways.net

今振り返れば色々な事を知ったなと思います。
アジャイルに開発するということは色んなものを包括している(しないと上手くいかない)ので、例えば何か一冊読んでも、情報不足に陥ります。
そこから広げて行った結果こうなりました。

何をして良いかわからないと悶々としている方がいましたら
まずは何か一冊手に取って、読み込んでみてはいかかでしょうか
きっと色々な可能性に出会えます。

行動

知識を得ることと行動することのバランスには気をつけなければいけません。
知識と行動は掛け算です。
ものすごく知識に豊富だったとしても、行動が僅かであれば当然ながら学びは少なくなります。

では、どうしたら行動に移すことができるのでしょうか。

行動力を高めるために

自信をつける

これがものすごく重要な要素となります。
行動しない/できない理由をあげるとより分かりやすいですね。

人間は変化を伴う行動を恐れる生き物です。
変化には失敗がつきもの。
怒られる、笑われる、罵倒される、評価されない。
こんなんじゃ誰もチャレンジ(行動)しませんよね。

そうならないために、 組織を作り、知識を高める ことが重要です。
一人でやるよりも、みんなでやる方が心強いし、フィードバックも多い。
テキトーにやるよりも、原則や理論を知って進めた方が、成功しやすい。
これらが 自信となり、行動に繋がってきます 。

チャレンジを称える

私の組織では、改善を目的とした 行動自体 を賞賛する仕組みがあります。
結果は問わず、何か新しいことや課題解決のために主体的に取り組んだ事をメンバー同士で褒め合います。

計画を立てる

小さく考え小さく作る。
まさにアジャイル的な考えですが、重要です。
大きすぎる目標だけだと行動の具体化に至りません。
如何に 価値があり、かつ行動可能なサイズ に切り出せるかがポイントとなります。

で、自分が行動したこと

スクラムマスターを辞めてみた(UXやってみた)
- 僕がスクラムマスターを辞めたワケ - Adwaysエンジニアブログ
- アジャイルな組織にUXチームを作って色々試している話 - Adwaysエンジニアブログ
グロースハック(ARRRA)やってみた
- 使われるモノを作るためにARRRAを採用したお話 - Adwaysエンジニアブログ
社内のスクラムマスターを集めてみた
- 学びを目的としたディスカッションを実施
- 別プロダクトのメンバーが集まり、気づきが多い有意義な場に
営業との関わりを増やしてみた
- 営業が関わるプロダクトの意思決定の場に積極的に参加
- エンジニア、デザイナ、ビジネスの三点が交わるようなファシリテートを意識した
- 初めて自分からランチ誘ってみたw