川口恭伸のレビュー一覧
-
-
-
Posted by ブクログ
日本でいうサイボウズやソニックガーデンがそうなのかな？アメリカ・メンローイノベーションズ社のカルチャーと開発手法を紹介している。
スクラムやXPをベースに少しずつフィットする形に変えていったのが分かる。喜びや幸せという言葉はスクラムでも使われる。小恥ずかしい言葉だけど、私は好きだ。
■メンロー社からの問いかけ
喜びに溢れる意図を持った文化とは何か？
どうすれば壊れた文化を作り替え、喜びにたどり着けるか？
そうした試みをしながらも利益を出せるのか？
■新しい手法による新しい報酬
・プロダクトがちゃんと動き、期日通りに出荷して、トラブルも起きない
・こちらの提案を対象ユーザーが楽しんで使ってくれる
・組織図上の単なる部署ではなく、本当のチームに所属できる
・毎日何かしら新しい学びがある
・長い休暇を簡単に取れ、休暇中に呼び戻される心配もない
・仕事の成果を誇れる
・継続可能なやり方で、繰り返し高品質な成果を得られる
■メンローの特徴的なプラクティス
・階層がない組織：上司はいない、リーダーがいる。
・ペアプロ：常に2人1組で作業する。
・計画折り紙：計画シート上に見積もり時間サイズのタスクカードを載せていく。
・ショウ&テル：2週間ごとに進捗と状況を報告する顧客との合同イベント。
・デイリースタンドアップミーティング：毎朝10時に行う全員参加の民主的会議。
■メンローでは非生産的で喜びのない会議を撲滅した
ルール、官僚主義、階層を予測可能な儀式とストーリーテリングをするイベントに置き換えた。会社にありがちな官僚主義では、ルールによって情報共有と判断力を制限する。超えられない境界を作り上げてしまう。
■喜びを可視化するためにビジョンを書き下す
20⁇年6月1日、今日は・・・。
では書き始めよう。たっぷりと具体的に記述する。個人のことと世界のこと、両方を書く。自分のことだけではだめだ。自分自身のこと、自分が世界で作り出すのを助けている喜びの結果を書く。個人的なゴールと仕事のゴールの両方についても書こう。
■喜びと幸せは同じではない。喜びはより深く、意義があり、目的を持っている。幸せとはある時点における状態の話だ。幸せな状態が連続していなくても、喜びに満ちていられる。 -
-
-
Posted by ブクログ
13章の最初の引用「二つの自由のあり方がある。間違っているのは、人は自由に好きなことをしてよい。正しいのは、人はすべきことを自由にやってよい。」というところが印象に残っている。みんな好きなように楽しくやる、というのではなく、"曖昧さ"はなく、秩序があって、それでいて自由に、そして楽しく働いている。この違いはすごく大きい。ビジョンを共有し、ルールや手順が明確になっているから、それに沿って頑張れる。真面目に頑張っている人、正直な人が損をしないシステム。
業種が違うと活かせる部分とそうじゃない部分はあると思うけど、メンローという組織のあり方はすごく理想的だなと感じた。 -
-
-
Posted by ブクログ
先に紹介した「アジャイルの『ライトウィング』と『レフトウィング』」では、ライトウィングを「高速に石橋を叩いて渡る」と表現しています(※1-2)。「動いているシステムを壊さずに、高速に、着実に、製品をインクリメント (※1-3) していく」 ことが、アジャイル開発で達成したい状態です。大きな変更を一度に実現しようとしても、うまくいかないことは読者のみなさんも経験からわかるのではないでしょうか。この制約を踏まえて達成したい状態を実現するには、プロダクトが変化することを受け入れ、その変化の過程で開発の生産性やプロダクトの品質が落ちないようにする必要があります。そのために重要なのが「早く気がつく」 「小さい単位で完成させる」「継続的に見直す」の3つであり、それぞれを具現化するために一つ一つのプラクティスを実践していきます。
関係者を集め、ゴールやスコープを揃える
関係者を揃える/ゴールを揃える/スコープを揃える
多くの人が絡む作業をはじめる際は、最初の認識合わせが重要です。実装が完了し、テストを行い、デモを見せる段階になって初めて、作っていたものが期待と違うものになっていたとわかるのは誰もが避けたいことです。こうした事態を避けるには、関係者を早い段階から巻き込み、プロダクトに対して継続的にフィードバックを得られるようにすることが必要です。
一方で、多くの関係者を集めればよいというわけでもありません。さまざまな立場からパラパラに要望や要求が突きつけられることで、開発は簡単に迷走し、せっかくの時間や人を浪費することになります。筆者はそのような現場をいくつも見てきました。
多くの人が関わるプロジェクトで、円滑な進行をするために、認識合わせは以下の順に進めていくとよいでしょう(図5-1)。
1. 適切な関係者を揃える
開発者と異なる立場や役割の人は、これから開発するプロダクトのゴールや要件について、異なる情報や期待を持っているかもしれません。関係者が全員揃う前の段階で、いろいろな決定を下してしまうと、手戻りが発生するリスクが大きくなります。関係者の範囲は広く多様です。開発中に直接やりとりする役割もあれば、開発が終わってから動き出す役割もあります。開発の成果物をユーザーとして利用する人や、開発に直接関与しなくとも、リソースや情報を提供してくれる人も関係者です。関係書をきちんと洗い出せていなかった結果、後から物言いがついて開発が遅延または失敗するというのは残念ながらよく聞く話です。将来的に関わる人々を含めて、プロダクト開発でやりとりする関係者はしっかり探しておきましょう。図5-2は適切な関係者を挙げた一例です。
その人が関係者にあたるのかを見極めるためには、「今度こんな機能を開発するんですけど、関係や影響するところはありそうですか?」と尋ねてみましょう。話を急に振られたとしても、関係者であれば少し考えた後に、気づいた点を答えてくれるでしょう。短い質問であれば相手の時間をさほど取らないので、声をかけられて迷惑に感じる人は少ないはずです。後から関係者だったことが判明して手戻りが発生してしまうリスクを考えれば、早くに声をかけたほうがよい判断といえるでしょう。
関係者に該当していても、当人が持っている興味には幅があります。単にプロダクトに興味がある人もいれば、自分の仕事に直接関係や影響がある人もいます。また開開に対してどの程度の権限や影響力を持っているのかも異なります。それぞれが持つ開発との関係性を整理するのは大変ですが、「興味の高低」と「権限/影響力の高低」 の2軸で関係者を分類するだけでも、気にかけるべきことや適したコミュニケーション手段が整理できます(図5-3)。
筆者が調べた限りで最も古い出典は 「Strategies for Assessing and Managing Organizational Stakeholders」 5-1 です。その他にも、「ステークホルダー分類」 で調べると細部が異なるバリエーションがいくつか見つかります。
2. ゴールの認識を揃える
関係者への声かけが終わったら、次はゴールの認識を揃えていきます。ここでいうゴールとは、関係者全員がプロダクトを通して実現したいことを指します。集まった関係者は「置かれている状況」「持っている前提知識」「解決したい課題」がそれぞれ異なっている状態です(図5-4)。まずはお互いの理解や考え方を話し、共有することから始めましょう。
気をつけるべきなのは、プロダクトを通して最終的に何を実現したいのかをきちんと確認できているかどうかです。関係者の話を聞くことで、開発でやるべきことは明確になっていきます。しかし、やるべきことをすべて達成しても狙っていたゴールに辿り着かない場合があります。例えばECサイトで「ユーザーにまとめ買いを促したい」と考えた際、その理由は複数考えられます。他にも「一人当たりの売上を上げたい」「送料の負担を抑えたい」「定期購入を促したい」といった目標は異なる立場の人たちから出てくるであろうゴールです。まとめ買いを促すことが達成できても、プロダクトを通して実現したかったことが達成できていなければ意味がありません。ゴール認識を揃えておかなければ、開発する内容が適切かどうかを判断できません。関係書の話がゴール (What) ではなく、解決手段 (How) に向いているとこういった問題が起きやすくなります。また、成功の指標や基準は決まっていても解決手段がゴールに結びついていない、という場合もあります。先に揃えるべきはゴールであって、 解決の手段やスケジュール/スコープではありません。関係者から話を一通り聞き終わった後、その先に何を成し遂げたいのかを聞くようにしましょう。
プロダクトとしての理想のゴールを話そうとすると、抽象的でフワッとしたものになりがちです。例えば「すべてのユーザーが満足してくれるストレスのない購入体験」はまさに理想のECですが、その実現手段はいろいろと考えられます。理想のゴールの手前にある「一人当たりの売上を10%上げたい」「送料の負担を10%抑えたい」「6ヶ月間の定期購入比率を5%上げたい」といった、具体的なゴールを1つ選んだほうが、やるべきことを明確にでき、続くスコープの議論が進めやすくなります。
事業戦略や長期的な方向性についても、わかっている限りで話しておきましょう。事業の方向性はシステムの設計に大きな影響を与えます。将来の計画について話し合う中で、設計に影響する要素や懸念事項がちっとも議論されない場合、適切な設計が行えていない可能性が高いです。ただし、可能性の段階ですべての詳細を詰めることは困難であり、予想が外れることもあります。それでも、事業戦略や方向性についてあらかじめ話し合っておけば、実際にプロジェクトが進行してから問題が起きたとしても、議論の概略を元に対処できます。将来のプロジェクトの成功につながる大切なステップとして取り組みましょう。
3. スコープの認識を揃える
関係者が集まり向かうべきゴールの認識が揃ったら、どの時期に何を達成したいのか、プロダクトに必要な機能やそのためのユーザーストーリーを洗い出し、開発するスコープの認識を揃えます(図5-5)。
まずはやるべきことの洗い出しからです。考えていること、頭に思い浮かんだことはすべて共有しましょう。「これは担当外のことだから言わなくて大丈夫」と考えるのはよくありません。後になって実は必要だったと判明することがないよう、些細な事項でも検討する必要はないか確認しましょう。
やるべき項目を洗い出したら、緊急度や重要度を考慮して優先順位をつけます。同じ順位の項目ができないように、順序を定めます。優先順位がないと「すべて緊急である」「すべて重要である」と判断されてしまったときに、最初のリリースに含めたいユーザーストーリーが大きく膨れてしまい、スコープを小さくする議論ができなくなります。こうなるとスコープが大きいためにリリースまでの期間が長くなり、短くリリースして学びを得ていくというアジャイル開発の目標から遠ざかってしまいます。一方で最初のリリースは単に早ければよいというわけでもなく、プロダクトに求められる当たり前の品質や必須の機能も考慮する必要があります。そのためスコープはよく話し合い、「必ずやる」項目以外に「できればやりたい」「余裕があればやりたい」といった濃淡をつけることが大切です。機能やユーザーストーリーが決まれば、 実現するためにどの程度の手間が必要になりそうか、作業の規模を見積もれるようになります。チームがイテレーションごとにどれくらいの量をこなせそうか、過去の実横から推定します。過去の実績を持っていない新しいチームの場合、一定の時間、実際に作業をしてみて、進捗を計ってみましょう。作業の規模は当初の想定や希望と離れているかもしれません。初回のリリース時期を優先するのであれば、スコープに含まれるユーザーストーリーを見直して減らす必要があります。スコープを見直すときに何を重視するのか意識できるようにしましょう。
またスコープには、すべての機能やユーザーストーリーを含めるべきだと言われがちです。しかし、それはシステムが当たり前に使えるようになった未来を想像しているからこその認識でしょう。例えば最初はデータも少なく、検索や絞り込み機能は必要ないかもしれません。もしくはそもそも機能自体が必要ないこともあります。まず機能が必要となる前提条件を考え、開発側から関係者へ都度確認を取りましょう。スコープは少しでも小さく、明確なものに絞ることが重要です。スコープは適切な大きさに抑えられていても、ゴールの達成に寄与しないものが含まれているかもしれません。適切なスコープ設定は難しく、丁寧に議論を積み重ねる必要があります。どんなステップを経て達成していくか、順序の入れ替えが可能な箇所はどこになりそうか、 いつどんな協力が必要になりそうかなど、お互いが協力できるように納得がいくまで話し合いましょう。認識や考え方の差はすぐに埋まらないため、継続して議論していくことが必要です。
大きめの開発はDesign Docで目線を合わせる
Design Doc
「Design Doc」 とは開発を始める前に、開発の背景/目的/設計/代替案を整理するドキュメント手法です。ドキュメントを元に関係者と共有/議論することで、取り組みを明確化し、手戻りを減らすことを目的としています。Googleで取り組みが始まり、現在では多くの技術企業に取り入れられています。Design Docは設計書や仕様書というよりも議事録に近い位置づけで、何度も議論して修正しながら作り上げていくことを重視しています。この手法は、ソースコードを書き始める前のコードレビューのような役割も担っています。
Design Doc は、開発するものを十分に検討/詳細化できますが、一方で忙しくても読み通せるぐらいの短さにまとめる必要があります。重要な事項を書くことに絞り、詳細なことは書きすぎないことが重要です。すべての開発で事前に用意する必要はありません。筆者は数ヶ月以上かかる開発、いくつか実現案が考えられる開発、技術的/ドメイン的に新規で不慣れな開発に取り組む際、1~2週間程度の時間をかけて用意しています。
Design Doc の項目には規定はありませんが、そもそも「比較的形式ばらないドキュメント」という立ち位置です。項目が多ければよい、分量が書いてあればよいとするのではなく、自分たちの開発で何を明確に残しておかなければならないかを議論し、取捨選択してください。仕様書や設計書などのドキュメントでは記載される機会が少ない一方で、Design Doc では意味があるとされる項目に「目標でないこと」と 「代替案」があります。開発が長期化するとやることがぶれてきてしまいますが、はじめに目標としないことを明示しておくと、スコープが広がることを抑制できます。 また検討した際に考慮した代替案が記載してあると、開発時にどこまで考慮して意思決定したのかを推し量ることができ、意思決定の参考にも設計スキルの教育にも役立 ちます。
[Design Doc に含める項目]
・概要
・背景
・対象範囲
・目標
・目標でないこと
・解決策/技術アーキテクチャ
・システムコンテキスト図
・API
・データストレージ
・代替案
・マイルストーン
・懸念事項
・ログ
・セキュリティ
・オブザーバビリティ
・参考文献
"Four Keys Metrics”でチームのパフォーマンスを測る
Four Keys Metrics
デリバリーのパフォーマンスを測るメトリクスとして「Four Keys Metrics」があります。これはGoogle Cloud の DevOps Research and Assessment チームが研究から導いたもので、「Accelerate State of DevOps Report」という毎年公開される調査レポート 6-5 や 『Lean と DevOps の科学 [Accelerate] テクノロジーの戦略的活用が組織変革を加速する』 66 で紹介されています。Four Keys Metrics の項目は次の4つです。
1. リードタイム: コードコミットから本番環境稼働までに要する時間
2. デプロイの頻度: 本番環境へのリリースの頻度
3.平均修復時間:本番環境で障害が復旧するのに要する時間の平均
4. 変更失敗率:リリースが原因で本番環境に障害が発生する割合 -
-
-
-
Posted by ブクログ
みんなで学び合う文化を作る。
この本に早めに出会えればよかったなー、そうすると前職でもっと違う施策をとってだと思う。こういう文化を一から作り、改善が実感できていくのは楽しいだろうなー。
エースを作らず、皆で必要な無駄を取り入れて成長する
ペアプロ、デイリースタンドアップミーティングなどなど
二重投資が実は最短で低コスト、というマインドと自負を持つべきですね。
あと、ルールと計画に厳格なマネージャーではなく、恐怖によらない説明責任のもと、皆で改善して将来の計画を作っていこう、という雰囲気を作るチーム作りが大事と痛感。
これを肝に命じて、自分の仕事を見直していこう。だから、今の会社はマネージャーとは言わない。 -
-
Posted by ブクログ
ネタバレ喜び（joy）のある組織の作り方をメンロー・イノベーションズ社が行なっている取り組みを通じて紹介した本。
アジャイル、スクラム開発に沿った経営をしている。
常にペアでの作業を行い、一人のheroによる解決を許さない仕組みは長期的にみて非常に有効。取引先にもその分の費用を出してもらっているというのが素晴らしい。
取引先はだいぶ選ぶことになるので、日本で行うのは難しい印象を持った。
社内で動かせる部分から試していきたい
p180 ボスではなくリーダーを育てる
リーダーシップとは、核となる価値観を都合のよいときだけふりかざすことではない。価値観が崩されそうなとき、立て直しに参加することも意味する。
メンローで一番自然にリードできる人は、受容的で他人を尊重できる人。リーダーは落ち着き、我慢強さ、密かなる自信を示す。
p194 カオスを終わらせる、曖昧さをなくす
要件追加が来た時の対応方法。仕事を片付ける方法を探しても、廊下でプロジェクトマネジメントをやっても生活はよくならない。
そうした時にやる仕事は四半期の初めに設定したゴールとは関係ないことが多い。
朝出社すると、メンバーがアサインしたタスク以外のもので忙しくしている。仕事の責任者はマネージャーなのに、各自の優先事項が管理できない。
p203 ショッキングピンク判断
上司に仕事の割合を知ってもらうために、ボードにタスクカードの一覧を使い、新規開発以外のタスクにどれだけの時間をかけているかを知ってもらうため、ピンク色の目立つカードにして見分けがつくようにした