原田騎郎のレビュー一覧

ジョイ・インク 役職も部署もない全員主役のマネジメント

日本でいうサイボウズやソニックガーデンがそうなのかな？アメリカ・メンローイノベーションズ社のカルチャーと開発手法を紹介している。
スクラムやXPをベースに少しずつフィットする形に変えていったのが分かる。喜びや幸せという言葉はスクラムでも使われる。小恥ずかしい言葉だけど、私は好きだ。


■メンロー社からの問いかけ
喜びに溢れる意図を持った文化とは何か？
どうすれば壊れた文化を作り替え、喜びにたどり着けるか？
そうした試みをしながらも利益を出せるのか？

■新しい手法による新しい報酬
・プロダクトがちゃんと動き、期日通りに出荷して、トラブルも起きない
・こちらの提案を対象ユーザーが楽しんで使ってくれる
・組織図上の単なる部署ではなく、本当のチームに所属できる
・毎日何かしら新しい学びがある
・長い休暇を簡単に取れ、休暇中に呼び戻される心配もない
・仕事の成果を誇れる
・継続可能なやり方で、繰り返し高品質な成果を得られる

■メンローの特徴的なプラクティス
・階層がない組織：上司はいない、リーダーがいる。
・ペアプロ：常に2人1組で作業する。
・計画折り紙：計画シート上に見積もり時間サイズのタスクカードを載せていく。
・ショウ&テル：2週間ごとに進捗と状況を報告する顧客との合同イベント。
・デイリースタンドアップミーティング：毎朝10時に行う全員参加の民主的会議。

■メンローでは非生産的で喜びのない会議を撲滅した
ルール、官僚主義、階層を予測可能な儀式とストーリーテリングをするイベントに置き換えた。会社にありがちな官僚主義では、ルールによって情報共有と判断力を制限する。超えられない境界を作り上げてしまう。

■喜びを可視化するためにビジョンを書き下す
20⁇年6月1日、今日は・・・。
では書き始めよう。たっぷりと具体的に記述する。個人のことと世界のこと、両方を書く。自分のことだけではだめだ。自分自身のこと、自分が世界で作り出すのを助けている喜びの結果を書く。個人的なゴールと仕事のゴールの両方についても書こう。

■喜びと幸せは同じではない。喜びはより深く、意義があり、目的を持っている。幸せとはある時点における状態の話だ。幸せな状態が連続していなくても、喜びに満ちていられる。

ジョイ・インク 役職も部署もない全員主役のマネジメント

アジャイルとかスクラムが意識せず出来るようになるとこんな働き方になるんだなーという体験ができる書籍。昔なら遠い別の国の話に感じたかもしれないが、今なら手が届かないこともないなと読んでいて感じた。いつかメンロー社にも遊びに行ってみたい！

ジョイ・インク 役職も部署もない全員主役のマネジメント

だいぶやられた。自分の近頃を省みて、ふわふわそわそわした心持ちにさせられた。いい本。

原著がそもそも良いのだと思うのだけど、邦訳品質がとても高く、自然に素直に読みくだせた。訳者の顔ぶれを見ればさもありなん、ではあるけれど。

Kent Beck が来日講演したときに、繰り返し「誠実であること」について語っていたけど、それを思い出した。
喜び(Joy)、を社是とすることは、自分(たち) に対してかなりストリクトにエクストリームに誠実じゃないと続けられないだろうなー、と。

ジョイ・インク 役職も部署もない全員主役のマネジメント

13章の最初の引用「二つの自由のあり方がある。間違っているのは、人は自由に好きなことをしてよい。正しいのは、人はすべきことを自由にやってよい。」というところが印象に残っている。みんな好きなように楽しくやる、というのではなく、"曖昧さ"はなく、秩序があって、それでいて自由に、そして楽しく働いている。この違いはすごく大きい。ビジョンを共有し、ルールや手順が明確になっているから、それに沿って頑張れる。真面目に頑張っている人、正直な人が損をしないシステム。
業種が違うと活かせる部分とそうじゃない部分はあると思うけど、メンローという組織のあり方はすごく理想的だなと感じた。

ジョイ・インク 役職も部署もない全員主役のマネジメント

アジャイルで、とくにXPの作法で成立してる、技術と喜びに溢れた職場。
かなり多くの場面やストーリーを交えて、この会社がどのように過ごしているのかを紹介している。自分にも機会があれば、ぜひともこんな会社を作りたいと改めて思う。事業として成功している事例があることにその勇気を得られる。

アジャイルな思考に慣れていない人には、もしかしたらショッキングで素直には受け入れがたい内容かもしれない。しかし、それぞれ「なぜそうするのか」を著者の経営理念にもとづいて解説してあり、急には変わらなくても考え直す機会にはなるかもしれない。

ジョイ・インク 役職も部署もない全員主役のマネジメント

こうできたら！と思う反面、世間一般的にはに縛られてむず痒さを感じたり等。なんというか、本当にこうできるようにするには、いろんなところに働きかけていかないといけない気もしたり。ますます組織やプロダクトのあり方等考えさせられる1冊。

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

カタカナ語と抽象的な概念が多くやや掴みにくさはある。コンウェイの法則は、ソフトウェアと開発チームの関係性を指し示す概念で真を食っていると感じる。

セントラル方のアナリティクス組織に置き換えた時に3つのコラボレーション全てが当てはまるので、組織を最適化させる際には切り分けて考える必要がありそう。

① コラボレーション
② X as a Services
③ ファシリテーション
↓
①例：ビジネスパートナー活動・レポート作成
②例：tableauダッシュボード提供（作成ではなく
③例：セルフBI活動

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

PARTⅠ　デリバリーの手段としてのチーム
KEY TAKEWAYS　要点
Chapter 1
・コンウェイの法則では、ソフトウェアアーキテクチャーとチームインタラクションを同時に設計する利点を説いている。両者に働く力は同じものだからだ
・チームトポロジーはチームの目的と責任を明確にし、チーム間の相互関係の効果を向上させる
・チームトポロジーでは、戦略適応性の実現のために組織を調整しつつソフトウェアシステムの構築においては人間的なアプローチを利用する

　過去数十年にわたって、ビジネスを構成するための新しいアプローチがたくさん登場した。それらは依然として組織を静的なものとして見ていさて、組織を再編したあとに起こる現実のふるまいや構造は考慮に入れていなかった。たとえば、1990年代に登場しそこから数十年でかなり普及した「マトリクスマネジメント」は、個人にビジネスマネジャーとファンクショナルマネジャーの双方に報告させることで、複雑で、不確実性が高くさて、高度なスキルが必要な仕事に対応しようとした。純粋な職能型組織のチーム構造と比べると、ビジネス価値に焦点を当てているとはいえ、これもまた静的な世界観であり、ビジネスや技術の領域が急激に進化するにつれ、時代遅れになっていく。

Chapter 2
・組織はそのコミュニケーションパスを反映した設計を作り出す
・組織設計はソリューション探索の制約になり、取りうるソフトウェア設計を限定する
・全員が他のすべての人とコミュニケーションするよう求めるのは、混乱のもとである
・チーム内のフローがよくなるようなソフトウェアアーキテクチャーを選択せよ
・明瞭なチームインタラクションだけにコミュニケーションバスを限定することで、モジュール化した疎結合なシステムが生まれる

　コンウェイの法則の背後にある同形性を示す証拠が増えていることを考えると、技術リーダーの意見を聞かずにチームの形成、責任、境界について決定を下すというのは、ソフトウェアシステムを構築する組織にとって非常に非効率で、そしておそらく無責任なのだ。
　実際に、組織設計とソフトウェア設計は同じコインの裏表であり、どちらも同じだけの知識を持った人たちによってなされる必要がある。アラン・ケリーのソフトウェアアーキテクトの役割についての見解は、この考えをさらに発展させたものだ。
　これまで以上に確信するようになったことがある。アーキテクトを名乗る人には技術的スキルと社会的スキルの両方が必要であり、人間を理解し社会の枠組みのなかで仕事をする必要があるということだ。同時に、彼らには純粋な技術にとどまらない広範な権限が必要だ。組織構造や人事問題についても発言権を持つ、つまりマネジャーになる必要があるのだ。
　基本的に、組織設計にはエンジニアを巻き込む必要がある。というのも彼らは、APIインターフェイス、抽象化、カプセル化といった重要なソフトウェア設計の概念を理解しているからだ。ナオミ・スタンフォードはこのように付け加える。
「部署や課、システム、ビジネスプロセスといったものは、設計の一部としてより広い組織とのインターフェイスや境界を決める場合に限り、独立して設計できる」

Chapter 3
・チームはソフトウェアデリバリーにおける最も効果的な手段である。個人ではない
・ダンバー数を踏まえて、組織のグループのなかのチーム数を制限する
・チームの認知負荷の許容量に合わせて、責任を限定する
・チームごとに明確な責任の境界を作る
・チームの成功の助けとなるよう作業環境を変える


PART Ⅱ フローを機能させるチームトポロジー
KEY TAKEWAYS　要点
Chapter 4
・その場しのぎや頻繁なチーム設計の変更はソフトウェアのデリバリーを遅くする
・唯一絶対のトポロジーはないが、どの組織にとっても不適切なトボロジーはある
・どのトポロジーにするかを検討する際は、技術面や文化面での成熟度、組織の規模、技術面での規律といった観点が欠かせない
・特に、フィーチャーチームやプロダクトチームのパターンは強力だが、それを支える環境がある場合のみ機能する
・チームの責任を分割することでサイロを壊し、他のチームの能力を高める

Chapter 5
・4つの基本的なチームタイプによって、現代のソフトウェアチーム間のインタラクションは単純化できる
・業界におけるよくあるチームを基本的なチームタイプにマッピングすることで、オーナーシップの不明瞭さや過負荷または低負荷なチームを取り除き、組織を成功に導ける
・中心となるチームタイプは、ストリームアラインドチームだ。その他のチームタイプはすべてストリームアラインドチームを支援する
・その他のチームタイプとして、イネイプリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームがある
・トポロジーは大規模になると、しばしばフラクタル(自己相似)な形となる。すなわちチームから構成されるチームだ

ストリームアラインドチームが備える能力
　一般的に、ストリームアラインドチームは初期の要求探索の段階から本番運用まで作業を進めるのに必要な能力一式を備えている必要がある。そこのような能力には以下のようなものが含まれる(これに限らない)。
・アプリケーションセキュリティ
・事業成長性分析と運用継続性分析
・設計とアーキテクチャー
・開発とコーディング
・インフラストラクチャーと運用性
・メトリクスとモニタリング
・プロダクトマネジメントとオーナーシップ
・テストとQA
・ユーザーエクスペリエンス (UX)

Chapter 6
・チームファーストのアプローチを活用して、ソフトウェア境界を選択する
・ソフトウェアのデリバリーチェーンにおいて、隠れモノリスや結合に気をつける
・ビジネスドメインで境界づけられたコンテキストを踏まえたソフトウェア境界を利用する
・必要に応じて別のソフトウェア境界を検討する

PART Ⅲ イノベーションと高速なデリバリーのためにチームインタラクションを進化させる
KEY TAKEWAYS 要点
Chapter 7
・ソフトウェアデリバリーを強化するには、いずれかのチームインタラクションモードを選択する
・チームインタラクションモードにはコラボレーション、X-as-a- Service、ファシリテーションの3種類があり、他のチームにサービスを提供したり、そのサービスを進化させたりする
・コラボレーションはイノベーションを強力に推進するが、フローを低下させる可能性がある
・X-as-a-Serviceは他のチームがすばやくデリバリーするのを助けるが、それは境界が適切な場合に限られる
・ファシリテーションは複数チームをまたぐ問題の発生を回避したり、問題を見つけたりするのに役立つ

Chapter 8
・戦略的優位性の追求のために、異なるトポロジーを同時に活用する
・新しいアプローチの導入を加速するために、チームタイプやチームインタラクションを変える
・チームトポロジーを活用して、探索、開発、終了フェーズを区別する
・さまざまなニーズに対応するために、複数のチームタイプが同時に存在することを想定しておく
・組織変更のトリガーを認識しておく
・運用は、自律操舵のための高精度な入力センサーとして扱う

Chapter 9
・チームファーストのアプローチとコンウェイの法則、4つの基本的なチームタイプ、チームインタラクション、トポロジーの進化、組 織的センシングを組み合わせる
・さあ始めよう。 まずはチームから始めて、ストリームを特定し、 最 低限のプラットフォームを明らかにし、 能力ギャップを見極め、チームインタラクションを実践しよう

■4つのチームタイプと3つのインタラクションモード
　4つの基本的なチームタイプは以下のとおりだ。
・ストリームアラインドチーム：ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ
・プラットフォームチーム：下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす
・イネイブリングチーム：転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける
・コンプリケイテッド・サブシステムチーム：普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成される

　速いフローで効果的なソフトウェアのデリバリーを行うのに必要なのは、これらのチームの組み合わせだけだ。だが、効果的なソフトウェアデリバリーとは何なのかを理解し、それを実現していくには、4つの基本的なチームタイプ間のインタラクションモードも極めて重要である。
・コラボレーションモード： 特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある
・X-as-a-Serviceモード：あるチームが、別のチームが提供する何かを利用する(API、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている
・ファシリテーションモード：あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

やや難解。日本語は不自然でないがすんなり入ってきにくい。また日を改めて読み直してみる。
“いまどき”の組織編成のあり方として明確な指針を示していると感じる。将来に通用するかは分からないが、いまはこれがベストだろう。
事前の知識を必要としていて解説が平易でないところも多いうえ、組織を編成する責任者とか所属チームを拡張する一端を担うような人でないと使いどころが無さそう。組織のビジョンをこの書籍で共有することは難しい。

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

コンウェイの法則を意識するのは分かった。
4つの最適なチームや3つのインタラクションモードがあることは分かった。
自分のチームがどんな状況で、どうしたら良いか、考えるために良い本だと思う。

ジョイ・インク 役職も部署もない全員主役のマネジメント

みんなで学び合う文化を作る。
この本に早めに出会えればよかったなー、そうすると前職でもっと違う施策をとってだと思う。こういう文化を一から作り、改善が実感できていくのは楽しいだろうなー。

エースを作らず、皆で必要な無駄を取り入れて成長する
ペアプロ、デイリースタンドアップミーティングなどなど
二重投資が実は最短で低コスト、というマインドと自負を持つべきですね。

あと、ルールと計画に厳格なマネージャーではなく、恐怖によらない説明責任のもと、皆で改善して将来の計画を作っていこう、という雰囲気を作るチーム作りが大事と痛感。
これを肝に命じて、自分の仕事を見直していこう。だから、今の会社はマネージャーとは言わない。

ジョイ・インク 役職も部署もない全員主役のマネジメント

　読み終わって、うちの会社と比べてみる。
　う～ん、このやり方は絶対楽しいけれども、うちの会社には合わないだろうなぁ。

　ソフトウェア開発会社なのに、二人一組で一つのパソコンを使い、
　オープンスペースのオフィスは、机をつなげればチームの増減に対応できる。
　タスクはすべて無駄なく管理されて、ちょっとこれもやってよ、なんて仕事も発生しない。

　理想の働き方とは。

ジョイ・インク 役職も部署もない全員主役のマネジメント

喜び（joy）のある組織の作り方をメンロー・イノベーションズ社が行なっている取り組みを通じて紹介した本。
アジャイル、スクラム開発に沿った経営をしている。
常にペアでの作業を行い、一人のheroによる解決を許さない仕組みは長期的にみて非常に有効。取引先にもその分の費用を出してもらっているというのが素晴らしい。
取引先はだいぶ選ぶことになるので、日本で行うのは難しい印象を持った。
社内で動かせる部分から試していきたい

p180 ボスではなくリーダーを育てる
リーダーシップとは、核となる価値観を都合のよいときだけふりかざすことではない。価値観が崩されそうなとき、立て直しに参加することも意味する。
メンローで一番自然にリードできる人は、受容的で他人を尊重できる人。リーダーは落ち着き、我慢強さ、密かなる自信を示す。

p194 カオスを終わらせる、曖昧さをなくす
要件追加が来た時の対応方法。仕事を片付ける方法を探しても、廊下でプロジェクトマネジメントをやっても生活はよくならない。
そうした時にやる仕事は四半期の初めに設定したゴールとは関係ないことが多い。
朝出社すると、メンバーがアサインしたタスク以外のもので忙しくしている。仕事の責任者はマネージャーなのに、各自の優先事項が管理できない。

p203　ショッキングピンク判断
上司に仕事の割合を知ってもらうために、ボードにタスクカードの一覧を使い、新規開発以外のタスクにどれだけの時間をかけているかを知ってもらうため、ピンク色の目立つカードにして見分けがつくようにした