tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

エンジニアリング組織論への招待 の私的まとめ

昨年読み「経験から感じていたことが、言語化されてまとまっている素晴らしい書籍だ!」と感じました。 が、「具体的に何を学んだか?」と聞かれると今ひとつ心もとない状態だったので、自分の言葉でまとめ直してみました。

コミュニケーション能力と不確実性

コミュニケーション能力とは「コミュニケーションの不確実性」を減少させ、「組織内で連続的に発生してしまう不確実性の負のループを止めることができる」力を指す。

不確実性の発生源は2つ、「未来(環境不確実性)」と「他人(通信不確実性)」である。 通信不確実性はさらに下記の3種に分けることができる。

  1. 他者理解の不確実性:他人や事象を完全には理解できない。
  2. 伝達の不確実性:コミュニケーションが意図通り相手に伝わるとは限らない。
  3. 成果の不確実性:仮に意図通り理解されたとして、発信者の予想通りに行動するとは限らない

上記を念頭に置いた上で、少しでも不確実性を減らそうとすることによって物事を前に進めることができる。 しかし現実では、人は不確実性に向き合うことに不安を覚え、向き合うことを避けてしまうことから様々な問題を引き起こしてしまう。

エンジニアがソフトウェア・製品に向き合うように、人・チーム・組織に向き合い、「どうしたら効率よく不確実性を減らしていけるか」を考えつづけることで優れたチーム・組織を作ることができる。

組織は何らかの曖昧な指示を入力とし、具体的な作業に置き換えて少しずつ完了させていくことで、プロジェクト・プロダクトを前に進める活動を断続的に行なっているといえる。組織形態は下記の2つに大別することができる。

  1. マイクロマネジメント組織:具体的で細かい指示を指示者が出し、指示を受けたものがその通りに実行する組織。
  2. 自己組織化された組織:抽象的で自由度のある指示を指示者が出し、指示を受けたものが考えて行動する組織。

マイクロマネジメント組織の能力は指示者に律速されてしまう。 指示者の不在で仕事が回らなくなり、指示を受ける人が増えるにつれ指示者の負荷が高まり、指示を受ける側では不確実性を大して減らすことができない。 従って不確実性を効率よく減らしていける組織を目指すのであれば自己組織化された組織となる必要がある。

またコミュニケーションの不確実性を効率よく減らしていくには下記に留意する必要がある。

  1. 論理的思考の盲点
  2. 経験主義と仮説思考
  3. システム思考

「論理的思考の盲点」とは、人は論理的に考えていると自分で思っていても、その時の感情や誤った仮定に影響されて論理的でなくなることがあることを指す。 自分の認知がどういう時に歪むのかを把握し、客観視することでネガティブな感情の拡大再生産を食い止める。

「経験主義と仮説思考」は「行動することで「経験=情報」を得る。結果を観察し、結果を踏まえて問題解決を行う。部分的な情報しか得られないかもしれないが、全体像を想定し問題解決を進める。」という考え方である。 経験主義ではコントロールできるものを操作し、観測できるものの結果を見ることで前に進まなければならない。 面白いことに人は不安を感じると他社の気持ちなどコントロールできないものをコントロールしようとする。

「システム思考」は要素同士の関係性に注目して問題の構造を解き明かす考え方である。

メンタリング

メンタリングとは対話を通してメンターの思考力を相手(メンティ)へ一時的に貸し出し、相手の歪んだ認知を補正し、次の行動を明確にし、成長を促す手法である。 メンタリング後は「高い目標」が明確になり、その目標と今の自分の行動・習慣がどのように繋がっているかが明確にイメージでき、そのために何をすればよいかが明確になっている状態を目指す。

メンタリングに似た手法にティーチングがあるが、これは他者による説得である。 人は自分で見つけた答えに対して高い納得感と自己効力感を得て、積極的な解決行動を取ることが期待できる。 そのためメンタリングではメンティに自分自身の問題だと自覚させる。

メンタリングでは下記の3つを実施する。

  1. 傾聴
  2. 可視化
  3. フレーミング

まずは相手の話を「傾聴」し、相手が今の状態になった理由を理解する。 傾聴で必要なのは「同感」ではなく「共感」である。

次に相手が問題を客観視できない状態を可視化してあげて、「問題と私たち」に構造を変える。 相手が問題を客観視できない状態にあることは下記のキーワードに着目することで気がつくことができる。

  • こちら系:この会社は…この人は…、一体感を持っていない時に出てくる。
  • あちら系:あの部署は…あの人は…、相手は自分と違う、線引きされた異なる存在として認識している。
  • 極端系:いつも…すべて…絶対に…、ゼロイチで物事を捉えている。間の状態が認識できていない。
  • すべき系:普通…〜すべき、〇〇でないとならないという考え方が頭にあり、そこに限定して考えている。
  • 決めつけ系:どうせ…、感情的になっている。事実を捉えられていない。

相手の問題を一足飛びに解決することはできない。バグの原因を切り分けするように、話を聞きながら少しずつ問題の範囲を再定義(リフレーミング)して限定していくとよい。

メンターの役割はメンティを自律的な問題解決に導くことであり、メンティの問題を解決することではない。

メンタリングでは次に取るべき行動がはっきりするようにする。下記を参考に行動を設定すると良い。

  • Specific : 具体的である
  • Measurable : 測定可能である
  • Achievable : 達成可能である
  • Related : メンティの課題と行動が関連している。
  • Time-Bound : 時間制限がある。いつまでにやるかが明確になっている。

プロダクト開発とアジャイルな状態

プロジェクトとプロダクトは似た文脈で使われることが多いが、目的が異なる。 プロジェクトは「始まり」と「終わり」があり、「成果を出して終了する」ことが目的である。 最大のリスクは「終了しないこと」であるため、スケジュールに対する不確実性を減少させるように取り組む。 プロダクトは「継続的に収益をあげ」、「終了しないこと」が目的となる。 最大のリスクは「終了してしまうこと」であるため、市場に対する不確実性を減少させるように取り組む。

ソフトウェア開発の前提が変化し、プロジェクト型開発からプロダクト型開発への変化が迫られている。 ウォーターフォールはどう作るか(方法不確実性)と何を作るか(目的不確実性)の削減を目的としていた。 アジャイルはさらにチームが同じゴールに向かって動けているか(通信不確実性)の削減を目的としてる。 アジャイル開発は従来の開発よりも広いスコープを対象として、開発チームを捉え直す動きと言える。

アジャイルとは「チームが環境に適応して、不確実性を最も効率よく削減できている状態」のことである。自己組織化とも呼ばれる。自己組織化は下記が達成されているかを指標に判断することができる。

  • 情報の非対称性が小さい
  • 認知の歪みが少ない
  • チームより小さい限定合理性が働かない
  • 対人リスクを取れていて、心理的安全性が高い
  • 課題・不安に向き合い、不確実性の削減が効率よくできる
  • チーム全体のゴール認識レベルが高い

アジャイルな開発では下記に取り組んでいる。

  • 不安に向き合う
  • 少人数の対話を重視する
  • 役割を分けない
  • 経験したことのみを知識に変える。
  • 意思決定を遅延する
  • 価値の流れを最適化する

アジャイル開発のフレームワークで定義されているプラクティスは実行さえすれば問題が解決するものではない。 チームの背景・コンテキストが異なっても有効な銀の弾丸は無く、自分たちのやり方や役割を見直し変えていく「脱構築」機能をチームが身につけられるようになることを要求している。

スケジュールマネジメント

スケジュールマネジメントは、いかに効率よく「スケジュールに対する不安」とその発生源である「方法不確実性」を削減するかを考えることである。 具体的にはスケジュール通り終わるか、少し伸びてしまうかの間の幅をどのようにして見える化し、効率よく削減できるのかを考え、経営と現場の間で進捗に関して透明性を保つことを継続的に行う。

以下の3つに注目して進めると良い。

  1. 制約スラックを削減する。
  2. 見積もり予測可能性を上げる。
  3. プロジェクトバッファの消費を可視化し改善する

「制約スラック」とは作業に順番があったり、特定のスキルを持つ人に依存している状態を指す。 これらを削減し、作業に取り組むにあたっての制約を取り除く。

見積もり予測を上げる方法はいくつかある。 不確定性の大きいタスクは分解する。初めての取り組みであれば概念検証をプロトタイピングで行い、あたり検討をつける。 絶対見積もりにするとノルマ・約束になってしまうため、相対的に規模を見積もるようにする。 また小さくスプリントを繰り返すのも良い。開発サイクルを決め、人員を固定し、制約スラックが発生しにくいように要件を切っていくことで再現性の高い開発ができるようになる。

最後にバッファは作業・タスクごとに個別に取るのではなく、全体でまとめて1つのバッファを持つようにする。 これによりスケジュール不確実性の削減をプロジェクトバッファの消費という形で見える化できる。

ユーザーストーリーは「どのような人が」「何ができる」「そのことでどのような感情になる」の3点で構成する。 誰が、何のためにという文脈を最終顧客の観点から記述することで思い込みを排除する。

開発に着手できる状態になっているかを判断するフレームワークにINVESTがある。

  • Independent:独立している。他のストーリーと依存関係がない。
  • Negotiable:交渉できる。実現可能方法について交渉の余地がある。
  • Valuable:価値がある。ストーリーを完了させることでユーザに価値を届けることができる。
  • Estimable:見積もりできる。ストーリー完了までに必要な作業、要する時間が見積もれるだけの情報がある。
  • Small:小さい(≒適切な大きさである)。固定期間のスプリント内で回していくのにちょうど良い。
  • Testable:検証可能である。ストーリーが完了したことを客観的に判断できる。

生産性を出すための組織編成

生産性の定義は「投入したリソースに対してどれだけの付加価値を得られたのかを測ったもの」である。 問題は個人の能力の総和が必ずしも組織全体の能力とはならない点である。 組織がメンバの能力を完全に引き出すためには、「1.その中で行われるコミュニケーションが100%の完全な情報伝達である」、「2.構成員が完全に同一の目的・思惑で動いている」必要がある。現実にはどちらも前提条件として成り立たない。 従って組織拡大を行う際は、誰が、誰と、どんなコミュニケーションを、どの頻度でとるようにするかという設計を行い、コミュニケーションコストを一定に保つように組織を分割していく必要がある。

具体的には下記に留意する必要がある。

  • 権限の委譲と期待値調整
  • 適切な組織・コミュニケーション・外部リソース調達の設計
  • 全体感のあるゴール設定と透明性の確保
  • 技術的負債の見える化

メンバを職能で組織を分けると組織間でのコミュニケーション・取引コストを増大させてしまう。 ある事業やプロダクトに対して、職能・職種を横断してチームを組成することで、コミュニケーション・取引コストをできる限り下げたチームを作ることができる。書籍では機能横断型のチームと呼んでいるが、アジャイル開発の分野では「クロスファンクショナルチーム」や「フィーチャーチーム」と呼ばれていることが多い。

複数のチーム・チームメンバを一つのゴールに導くには目標設定と管理が欠かせない。 旧来の組織で広く使われている目標管理(MBO:Management By Objectives)は本来、「目標による管理、およびセルフコントロール」であり、自ら立てた目標を達成していくことによるモチベーションの内的動機付けを重視していた。 しかしいつの間にか後者が抜け落ちてノルマ感だけが残ってしまった。

組織全体への理解がなければ誤った最適化が進んでしまうため、近年ではOKR(Objectives and Key Results)が広がっている。 OKRの重要なポイントは透明性の重視にある。目標設定を通じて、従業員一人一人が組織全体を見渡して、自分が何のために仕事をしているのかを深く理解するのがOKRの果たす重要な役割である。

感想

まとめた結果でも1章の分量が多く、不確実性の考え方が一番学んだことなのだなと思う。2章以降はマネジメントに関する知識が広範に網羅されているが、どこかで聞いた話も多く、単独で理解を深めるには少し足りないし、他資料へのポインタとするには引きにくい印象を持った。

マネジメントに関わる人には読んで欲しいが、開発者などに紹介するにはまとめた内容+他書籍へのポインタとするのが良さそう。

報告のやり方を揃える

f:id:tune:20190102145501p:plain

概要

アジャイル開発・スクラムで開発スケジュールの確認、進捗を測る方法としてはバックログ・バーンダウン(アップ)チャート・ベロシティ・スプリントレビューと様々なやり方が存在する。しかし旧来組織の中で一部チームだけがアジャイル開発に取り組んでいる状況だと、他のチームとの報告のやり方が異なることで懸念を示されたり、内容が理解されなかったりすることがある。

このような場合、無理にアジャイルスクラムのやり方を押し付けて理解させるのではなく、旧来組織のフォーマットに進捗を変換して報告すると良い。

チームの対外的な窓口としてはスクラムマスターがその役割を担うのが良さそうだが、管理職が行っても、プロダクトオーナーが行っても問題ないと考える。報告対象が状況を把握しやすく情報をまとめられる人が担当すれば良い。

どこから報告のやり方を変えるべきか? アジャイル開発に巻き込む管理職の見分け方は?

報告フォーマットを変えることでアジャイル開発に取り組むことに対する波風を抑えることができるが、少しでも抵抗されたら即フォーマットを変えれば良いというものでもない。

組織の階層を上に辿っていくとある地点で「開発対象が理解できる管理職」から「管理のための管理職」に切り替わる箇所がある。ここがアジャイル開発に巻き込む管理職を見分けるポイントで、「開発対象が理解できる管理職」までを巻き込むようにすれば良い。報告フォーマットを切り替えるタイミングもここになるように組織にアジャイル開発を広めていくことを目標にする。

ネタ元

認定LeSS実践者研修にて

Re: エンジニアリングマネージャーでいるのがつらくなったときは

f:id:tune:20181229102317p:plain

はじめに

c5meru.hatenablog.jp

自分もチームリーダー→プロジェクトリーダー→プロジェクトマネージャーと役割が変わっていった時に、同じようなことを考えたことがあったなと思い出しました。

私の場合

マネージャーはチーム・組織を開発するのが仕事

海外子会社に出向してある製品開発に携わることになり、ガラッと環境が変わりました。最初はプロジェクト管理として入り、次にソフトウェア部門のマネージャー、プロジェクトリーダーと役割が拡大していきました。実装作業から離れ、協力会社・取引先との打ち合わせ・調整・マネジメントが主業務となり、社内の面談でも自分の成果を伝えることが難しいなと感じるようになりました。

1年ぐらい炎上するプロジェクトと格闘したのち、ある時の上司との面談で「うまくできていたのか、できていなかったのかまったく手応えがない」と打ち明けたところ「協力会社・取引先からプロジェクトに参画してもらって助かっていると感謝の言葉が来ていただろ、あれが全てだ」とコメントをもらいました。

その時から私のマネージメントに対する認識が変わったことを覚えています。 エンジニアの開発対象がコード・ソフトウェアであるように、マネージャーの開発対象はメンバ・チーム・組織・開発プロセスです。メンバが直面している課題を解決し、チーム・組織全体での成果を引き上げることがお仕事です。 マネージメントに対する認識が変わった後では、開発チーム・プロジェクトが「雰囲気良く協力し合い」、「技術的・組織な課題に対処できており」、「スケジュール通り進捗」していればそれを自分の成果として上司に伝えています。何度か上司が変わりましたが、変わらず良い評価をもらえています。

チームの雰囲気を察知する

職場の人間関係に対して常にアンテナを張っていなければいけない気がする不安 ・Slackから目が離せない ・あそこで話している人たち、何を話しているのだろう?

「人を管理する」と捉えると上記の発想になりやすい気がしますが、「チーム・組織を良い状態に引き上げる」と考えると少し違った手が打てます。

例えばこんな感じです。

  • 定期的に振り返り(KPT)を実施してもらい、問題として上がってくる内容に目を通す。
  • チームで解決できない問題を「リーダー・マネージャーに対処してほしい問題」としてあげてもらい、付箋で壁に貼るなどして皆が見える場に置く
  • 上がってくる課題に対して「何らかの施策」を「早急に打つ」。根本原因に迫れれば良いが、効果はやってみないとわからないので小さな一歩でもとりあえず試してみる。課題をあげても対応されないと士気が下がるので早くに対応する。
  • 問題はいつ、どのようなものが上がってくるかわからないので自分の時間は空けておく。むしろ暇なぐらいが良い。
  • 時間ができたらまめに職場を歩き回り、メンバと会話する。「さんぽ」と自称して、話しかけてもらうハードルを下げる。色々な問題がカジュアルに出てくるようになる。

要は問題を提起するやり方がメンバに定着し、改善する流れがつくれれば細かく見張る必要は減っていきます。

プレイヤーに未練はないの?

次々新しいものが出てくる実装・技術を身につけてスキルアップしていくことは楽しいですが、マネジメントも同様に学ぶものが多くあります。

私は「仕事をうまく回せるチームを"再現性"を持たせて作れるか」をテーマにして取り組んでいます。 同じメンバ・同じチーム・同じプロダクト・同じ課題に直面することはなく、課題に対する施策も効果があるものもあればそうでないものもあるのがマネジメントだと思っています。

今の自分の自己評価は「30〜40人のソフトウェアエンジニアをまとめて、1つの製品をアジャイルに開発できる」です。これがゴールではなく、この先には「ビジネス・バックオフィスもまとめて全社でアジャイルにやる」、「100〜200人、もしくはそれ以上の人数で大規模アジャイル開発を実現する」といったチャレンジがあると考えています。

スーパーマンリーダー、プレイングマネージャーに対するスタンス

いたらラッキーだけど、いないと回らないチーム・組織になってしまった時点でマネジメントの負けかなと考えています。

  • チームの単一ボトルネックに容易になりうる
  • メンバの尊敬を集めるかもしれないが、「自分はリーダー・マネージャーになれない」という先入観を与えてしまうかもしれない
  • メンバに任せるべきところを任せられず、チームとしての成長を阻害する要因になるかもしれない

おわりに

マネジメントはマネジメントの面白さがあると思います。

あなたのチームのスクラムマスター、「スクラム秘書」になっていませんか?

f:id:tune:20181222173752p:plain

概要

「私たちは毎スプリント、スクラムマスターをローテーションします(“We rotate the Scrum Master role every Sprint” – Serious Scrum – Medium)」という記事の中にある「スクラム秘書(Scrum Secretary)」という表現が面白かったので、悪いスクラムマスターの例として流行ってほしい。

詳細

スクラム秘書とは

元記事では下記の悩みに対する解決策として毎スプリントのローテーションが実施されたとある。

No-one wants to be the Scrum Master in our team. That is why we decided to rotate. Every Sprint we switch the Scrum Master role.

私たちのチームでは誰もスクラムマスターになりたがりません。だからローテーションすることに決めたんです。毎スプリントでスクラムマスターの役割を変えています。

リーダーシップを取りたがる人がおらず、スクラムに対する理解が浅く、適切なコーチもいないとこのような発想にたどり着くのでしょうか。 スクラム秘書がいるチームはこんな雰囲気なのでしょう。

  • スクラムを始めた時に年上、役職者、当初のリーダーがなんとなく役割を引き受ける。
  • プロダクトオーナーが上位に置いているバックログアイテムを適当にもらってくる。スプリント内に終わるかどうかはあまり気にしない。
  • 毎朝の朝会の司会を淡々とこなす。各自がやってることを報告してすぐに朝会が終わる。
  • スプリントが始まるとスクラムマスターとしての帽子を脱ぎ、一開発者として黙々と開発に没頭する。チームの状態はたいして気にしない。
  • スプリント終盤になって遅れが出てきても特に何もしない。朝会で「遅れているのでみなさん頑張りましょう」と言うだけ。
  • 決まりなのでスプリントレビューを実施する、もしくは誰も来てくれないのでスプリントレビューをスキップする。たいして盛り上がらず時間が過ぎるだけ。
  • 振り返りはみんながやっているKPT! TRYは「次から気をつける」「次スプリントからはXXXを頑張る」といった気合いTRYが決まる。

当然のことながら、スクラムマスターは誰でも簡単にすぐできる役割ではなく、「メンバ全員スクラムマスター経験者」とかで無い限り、スクラムマスターのローテーションはできません。

望ましいスクラムマスターの振る舞い

スクラムガイドにある責務は下記の通りです。

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

スクラムマスターはスクラムガイドに定義されたスクラムを推進し、助けることに責任を持つ。スクラムマスターは皆がスクラムの理論・練習・ルール・価値を理解することを助けることでこれを実現する。

先に挙げた問題に対し、望ましいスクラムマスターはこう振る舞います。

  • スクラムを理解している人、チームのために働く人をスクラムマスターとして任命する。任命してうまくいかなければ途中で交代する。
  • プロダクトオーナーが上位に置いているバックログアイテムをもらってくる。価値が理解できないもの、着手条件を満たしてないもの、スプリント内に終わらないものは引き受けず、プロダクトオーナーと対応を協議する。
  • 毎朝のデイリーミーティングで「チームが昨日やったこと、チームが今日やること、チームとしての課題」を確認する。朝会とは限らず、チームにとって最も良い時間にやる。
  • スクラムマスターは自分の時間をチームが最大の成果を引き出せるように自分の時間を使う。メンバを助け、チームの問題や障害を取り除き、時に対外的な盾となってチームを守る。
  • 計画に対して順調に推移しているか、バーンダウンチャートなどを使って確認する。遅れている場合は対応策を、スプリント内に作業が終わらない場合はその時点でプロダクトオーナーと相談する。
  • スプリントレビューを実施し、顧客の反応を観察し、プロダクトをより良くするための開発項目・アイデアを引き出す。
  • 振り返りはみんながやっているKPT! だが、全ての課題を改善することはできないため、最も重要な課題1〜2個に絞り、具体的なアクションにTRYを落とし込む。

下記は少しオーバーな表現で示されていますが、チームを守るためになんでもするのがスクラムマスターです。

www.youtube.com

ネタ元

medium.com

バックログアイテムを4象限に分類する

解説

プロダクトオーナーはプロダクトバックログアイテムに優先順位を定める時、様々な事項を考慮する必要がある。 新機能の追加、技術負債の解消、アーキテクチャ・技術基盤の見直しなど。 無意識のうちに特定の領域を優先してしまうことがないよう、「過去-将来」と「ビジネス-技術」の2軸でプロダクトバックログアイテムを分類し、どの領域にどれだけのリソースを費やすのかあらかじめ決めておく。

過去 & ビジネス

バグフィックス、顧客サポート、ちょっとした改善など。 既存顧客のためにリソースを使うことになる。

将来 & ビジネス

新機能の追加。新しく顧客を引き込むためにリソースを使うことになる。

過去 & 技術

技術負債の解消。遺産のために生じるコストや、将来の開発効率を改善させるためにリソースを使うことになる。

将来 & 技術

新技術の導入。将来のコストダウンや、開発効率の改善、差別化のためにリソースを使うことになる。

効果

どの領域にどれだけ注力しているからが簡単にわかることになる。 スプリントレビューで成果を見せる際にどの領域の作業かを示すことで、誰向けの作業かビジネス側の人にわかりやすくなる。

ネタ元

medium.com

www.growingagile.co.za

Re: FOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬

はじめに

国内のLeSS事例をまとめている際に見つけた大規模スクラムにおけるプロダクトの定義 - TechとPoemeの間の筆者さんがFOLIOアドベントカレンダーで、会社の開発体制・組織構造の変遷について下記の記事を公開されていました。

t-and-p.hatenablog.com

「英語のLeSS本を読むくらいなら、開発体制もLeSSにしちゃえば挙げられている課題は解決しそうなのに」と思ったのですが、はてブのコメントでは書ききれない分量なのでここにまとめます。

LeSS (Large Scale Scrum)とは

日本語だと下記の記事が素晴らしくまとまっています。

qiita.com

このブログでも下記に情報をまとめています。

tune.hatenadiary.jp

FOLIOさんの開発体制・状況はこんな感じなのかな…?

記事を読んでの想像です。違っていたらごめんなさい、すぐ訂正します。

  • 証券会社という性質上か「抑えるべきところは抑え、固く進める必要がある」雰囲気がありそう。アジリティ・スピード感を持たせた開発を対外的に言いにくいのかもしれない。
  • スクラムで規定されているイベントはやっていないか、部分的に取り入れていそう。元記事の筆者さんが入社したのが2018年2月らしいのでアジャイル開発の知見を持つ人がそこから入ったのかもしれない。
  • ウォーターフォールではないのだろうが、アジャイル開発とも対外的に言えない開発プロセスになっている。
  • 技術力の高いメンバの底力でベンチャー企業のスピード感に追いついてきたが、人が増え・やることが増えたことで組織づくりが急務になっている。

LeSSを導入したら解決するはずの点

プロジェクトではなくプロダクトを作る

アジャイル開発は顧客にとって価値がある成果を短期間で提供していくことが目的です。元ブログの 今,個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間でも「フロー効率」として挙げられている点です。 有期のプロジェクトだと終了時にメンバが入れ替えになることでチーム開発力が低下したり、文化が失われてしまいます。また締め切りが常に頭に貼り付いているような状態だと「そもそもどんな課題を解決することが目的だったのか」が後回しになってしまいます。 あくまで利用者・顧客にとっての価値を第一に置いておけば自然とプロダクト開発に皆の意識が揃っていきます。

プロダクトの定義は大きく設定する

LeSSで推奨されている考え方です。「そもそもどんな課題を解決することが目的だったのか」が正しくチーム・メンバに理解されてないとその場しのぎの解決策に負けてしまいます。

LeSS実践者研修の講師 Bas Vodde氏がNokiaを例に挙げたのが下記の考え方です。

  1. 通信モジュール/ライブラリ
  2. 通信チップ/基盤
  3. 通信機器
  4. 通信基地局/通信キャリア

Nokiaの製品は通信基地局向けの機器(3)ですが、末端のエンジニアが主に取り組むのは通信モジュール/ライブラリの開発(1)でしょう。とはいえ単に決まっている仕様をコードに落とし込む作業と、通信機器としてどう有るべきかを頭に描いた状態でやる作業の結果は大きく異なるでしょう。とはいえNokiaは通信キャリアではないので大きければ良いとは言っても自社でコントロールできない基地局運用や通信キャリアのビジネスモデル(4)まで考えた開発はできないでしょう。ということでNokiaの開発者にとってもっとも大きいプロダクトの定義は通信機器(3)でしょう。

FOLIOさんだとこんな感じでしょうか?

  1. 投資運用アルゴリズム
  2. マイクロサービス
  3. PORT/FOLIOサービス
  4. 投資プラットフォーム
  5. ワクワクする投資文化(?)

元記事のプロジェクトのスコープは2と3の間に見えますが、実際は4あたりなのかな。

「バックエンドエンジニアのサブグループ化」ではなく「クロスファンクショナルのフィーチャーチーム」を作る

顧客に価値が提供できるのは「3.PORT/FOLIOサービス」か「4.投資プラットフォーム」として世に出せたタイミングになるので、企画からリリースまでのタイミングを短くするのがもっとも望ましい開発体制となります。そのためには1つのチームが企画からリリースまで単独で遂行できる必要があり、「バックエンド/フロントエンドなどの職能チーム」ではなく「上から下までチーム内で取り扱えるクロスファンクショナルのフィーチャーチーム」を構成しなくてはなりません。

「フロントエンドより」「バックエンドより」はあっても良いですが、「バックエンドしか触れない」チームはNGです。

こうなると

  1. チーム間で調整・すり合わせのためのミーティング(XXX定例)や調整役(XXXプロジェクトリーダー)が必要になる
  2. 会社・組織として最優先で取り組まなければならない開発項目があっても、バックエンドに関する項目がないとチームが遊ぶことになる。またはバックエンドチームが全く価値のない開発作業を時間を埋めるために始めることになる。

フィーチャーチームは下記に詳しく書かれています。

「マイクロサービスのオーナーシップの不明瞭さ」はコンポーネントメンターを置く

フィーチャーチームを構成すると全チーム(全員)が全てのコードを触れることになりますが、好き勝手に作っていては設計方針がずれてしまいます。また技術負債や問題があってもオーナーシップが薄れ、返済・解消が遅れがちになります。

これを解決するLeSSのプラクティスがコンポーネントコミュニティー & コンポーネントメンターです。

私ならこんな順序でLeSS導入をするかな

1. バックログを作り、開発優先順位を見える化し、共通のものとする

進行中のプロジェクトが扱っている開発中の仕様のドキュメントや,プロジェクトのスコープや課題の一覧をまとめるpj-doc と呼ばれるプラクティスが社内で確立したり

内容的にスクラムバックログと呼ばれる項目に思えます。全社で唯一の開発優先順位を決めたバックログをまず作ります。そして唯一のプロダクトオーナーを決めましょう。プロダクトオーナーが複数人いると方針がぶれるので、優先順位を決めるまでの議論は喧々諤々やった方が良いですが、最後の意思決定者だけは1人に決めます。

2. フィーチャーチームを構成する

職能別のチームを解体し、複数のレイヤに携われるフィーチャーチームに作り直します。

チーム構成を考える上で、バランスのとれたスキル配分となるよう、スキルマップを作って参考にします。

またチームを下から支えるリーダー、スクラムマスターを決めます。職能チームのリーダーが引き継ぐことも一案ですが、専門技術をリードする能力と、チームをまとめる能力は異なるので、できそうな人をピックアップしてリーダーに任命しても良いかもしれません。

先にリーダーを決め、リーダーにチームとしてありたい姿を語ってもらい、メンバにどのリーダーについていくか決めさせるやり方もあります。私はやったことはありませんが、面白い取り組みだと思います。

tech.nikkeibp.co.jp

3. DONEの定義の拡張ワークショップを実施する

2で作ったフィーチャーチームは社内の全機能を開発できることはなく、PORTのみ・FOLIOのみ・またはそのうちの一部だけに知見があるという状態だと思います。またPORT/FOLIOは扱えるが、テスト・マニュアル・法規制確認など「リリースまでにやらなくてはいけないが、各チームがスプリント内で扱えないもの」があるはずです。一朝一夕に扱える領域は増やせませんが、増やす順番・目標・時期を決めるために「DONEの定義の拡張ワークショップ」をやると良いです。

独立した記事でまだまとめていませんが、下記で少し触れています。

Re: スクラムを大人数で運用したところ💩な結果になった。 - tuneの日記

4. コンポーネントメンターを任命し、コンポーネントコミュニティの運営を依頼する

マイクロサービスに詳しい人にメンターとなることを依頼し、コミュニティを作ることを依頼します。まずは社内のSlackチャネルにマイクロサービス固有の議論をするチャネルを作り、アナウンスして興味がある人に参加をお願いします。あとは好きに議論するなり、定期的にメンバを集めて打ち合わせを持つなりすれば良いと思います。

コンポーネントメンターにPull Requestのレビューを依頼することをやりそうですが、開発のボトルネックにならないように注意しましょう。メンターはコンポーネントの相談に乗り、時に方針を出すことに注力するべきで、コードレビューやテストの責任はあくまでチーム内で完結できるように育てていく方が良いです。

LeSS実践者研修オススメ

上記の内容を3日間で学べるLeSS実践者研修オススメです。次回は2018年3月12〜14日です。

training.odd-e.jp

スクラム開発を取り入れるためにパイロットプロジェクトを作るべきか

概要

結論から言うと「無い」。

開発・組織・社内全体をアジャイル開発・スクラム開発に切り替えるためであっても、複数のプロダクトを、複数のチームで別個に開発する限りは一気に取り入れた方が良い。

詳細

パイロットプロジェクトの目的

weblioの説明が短くまとまっていました。

実際的ではあるが限定された運用条件のもとで,情報処理システムの暫定版を試験するように計画されるプロジェクトであって,後にそのシステムの最終版を試験するために使用されるもの.

少数のチームで実験的な取り組みを行い、学んだことを踏まえて次のプロジェクトに活かしたり、組織内に横展開を図るための進め方です。

なぜスクラム開発はパイロットプロジェクト方式と相入れないのか

スクラム開発は不透明な課題に対して、チームとして協力し合い、チームの自律性を促し、メンバの成長を実現させ生産性を高める人にフォーカスしたフレームワークです。チームが取り組むプロダクトが違えば、チームメンバの性格や能力も異なり、各チームが直面する困難も異なります。

スクラム開発を学ぶために外部からアジャイルコーチを招き、小さくスタートする形がよく見られますが、チームが得た学びはチームのものであり、別のチームでも活用可能な一般的な知見が得られるかは保証できません。むしろ一斉に導入した方がアジャイルコーチが全員を集めて知識を集中的に教えることができ、レベル差が小さいスクラムマスター同士で困ったことを相談でき、組織へのアジャイル開発導入も短時間で完了します。

1つのプロダクトを大人数・複数チームで開発する場合はどうするか

たくさんのアジャイル開発チームを作るのであれば一気に導入した方が良いですが、1つのプロダクトを手がける大規模チームを作る場合はプロセス変革・組織変革を伴うため一気に導入してはなりません。

小さな単位で初め、少しずつ拡大していきます。

ネタ元

LeSS実践者研修で講師だったBas Vodde氏の話より。