ugo's 読書感想文

読んだ本のまとめや学んだことを書いていきます。

世界一流エンジニアの思考法

概要

マイクロソフト勤務の著者が、働く中での気づきや、 周りのエンジニアから学んだことを、自身の考えを絡めてまとめている。

自身の経験として、エンジニアに向いていなかった過去から、それ以前の経験を活かし、どのように適用していき 一流との差や、一流と一緒に働くことに対して、どういうアプローチを取ったのかというのを紹介している。

特別なことは確かにやっていないのだが、自身の行いを確実なものとして認識して 間違ったやり方ではなかったと認識するには体系的に理解するのにいいかもしれない。

最近の日本の企業としても働き方はかなり変わっていて、本書に出てくるような働き方ができるような企業も増えてきているので これから、自身の働き方をどう自分で調整していくか、自分の動き方をどうしていくかということに悩んでいる方には指標になるのではないだろうか。

各章の大枠

各章に書かれている大事だと思った箇所や、参考になりそうだと思った箇所を記述していく。

生産性

仮説を証明する

どんな一流のエンジニアでも、やり方さえ間違えなければ自分でも同じことが可能である。

例えば、慣れていない場合、クエリに間違いが発生してる時など、いろいろと手を動かして試してみようとするが 一流エンジニアとなると最初のログをじっくり読んだ後に仮説を立ててから行動をする。

つまり、最初に推測したものを実証するようにクエリを投げるようにするようにするのである。

そうすれば、複数回クエリを投げずとも、結果にたどり着くことが早いのである。

十分な理解を持って手を動かす

一流のエンジニアは、特別頭がいいと言うわけではなく、ちゃんと理解してから手を動かすということをする。

学習用のビデオを見る時も、10回見て、分からないところはポーズをしてメモをするなどを取る。

どんな人でも理解に時間がかかることはあるので、それ相応の努力をしていることになる。

そして、手を動かすのは最後になる。

無駄に手を動かして、試行錯誤するのではなく、仕組みを理解してからの方が時短に繋がる。

理解とはどうなることか

  • 構造を掴んで人に説明できること
  • いつでもどこでも即座に取り出して使えること
  • 知見を踏まえて応用がきくこと

コードの話でいえば、コードの意図とその背後のアーキテクチャを理解することを優先する。

言えば当たり前のことだが、これが基礎となる。 基礎は誰にでも分かるが、習得には時間がかかる。

この基礎を学ぶには、著者がやったことは

  • 定時後や週末にプログラミングの基礎を学ぶ
  • 言語の仕様を理解する
  • LeetCodeなどの問題を毎日解く

などである。

大事なのは、基礎を簡単だと馬鹿にせず、1からやり直しをするということだ。

ドキュメントを残す

ドキュメントを書くには以下のメリットがある。

  • ドキュメントを書くことで自分の頭が整理される。抜け落ちていた視点に気づくことができる
  • 考えてる時のことをドキュメントにすることで、それをシェアするだけで済むようになる。あとでドキュメントとしてまとめるというのは退屈な仕事になる。

自分が良いソフトウェアを書く上で、理解して効率よく開発するために書くということを理解しておこう。

メンタルモデル

多くのことを同時に把握するには、メンタルモデルを作れるようになることが重要である。

メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論。

ここではシステム思考というフレームワークを頭にインプットする。

ソフトウェアのアーキテクチャ、クラスの構造、ソフトウェアのどういったパーツがどこにあるか、システム全体を先に把握する。

それから、全体の関係図、フローをビジュアル図としてイメージし、各パートの関係性をあてはめていく思考法。

そういった図を頭の中に持つことで、障害が出た時や、話の焦点となるものがクリアになり、どこに何の話があったか紐付けがしやすくなるというもの。

構築の手順としては、エキスパートに頼るというもの。2時間以上詰まったら即座に聞くなどをする。

大事な感覚

自分が仕事をコントロールしているという感覚。

どんなことも、基礎を固め、分からないことなどをしっかり助言を頂くことで仕事をコントロールすることができる。

それを自分で感じ取ることができるようになることが重要。

Be Lazyというマインドセット

より少ない時間で価値を最大化するという考え方。

  • 結果達成のために、最小限の努力をする
  • 不必要なことをやらない
  • 簡潔さを目指す
  • 優先順位をつける
  • 時間や努力ではなく、アウトプットと生産性に重点を置く
  • 長時間労働しない
  • 会議を時間内で完結し、価値を提供する

これらは当たり前に見えるが、落とし穴がある。

このために大事なことは

「最初の1個をピックアップしてやったら他はやらない」

ということ

その一つにフォーカスをあてる。

一つのことを確実にやるということが大事。

なぜなら、ソフトウェアのうちで本当に大事で使われる機能は40%くらいという統計がある。

それに対して100%を注ぐことは無駄とは言わないまでも価値が最大化できていないと言うことに繋がる。

この、Be Lazyというのはやらなくていいことはやらないというマインドのこと。 そうすることでやることを減らすというマインドのことである。

また、会議の中で結論を作るということも大事。 持ち帰って検討することは極力せず、会議の時間内で完結することは生産的である。

失敗のリスクを取る

失敗や間違いを受け入れることを行う。

具体的には

  • 間違いを厳しく批判したりしない
  • 失敗から学ぶ
  • 早く失敗する
  • 実験が推奨
  • 現状維持や標準を要求せず、臨機応変が推奨される
  • 避難や恐怖感のない環境

人間である以上、失敗はつきものなので、早く失敗をして早くフィードバックを得て、早く間違いを修正していくの精神が大事になる。

検討ばかりをして、さっさとやらないことの方がリスクになってしまうということを肝に銘じておく必要がある。

例えば、さっと作れるならプロトタイプを作ってしまってから話し合いをし、フィードバックをもらう方が断然早いし、話がスムーズに進むというようなものだ。

アーキテクチャやツールが数種類あって悩む場合もあるだろうが、結論的にはなんでも良いとなる。 圧倒的な差があれば悩む必要がないし、決めあぐねるくらいであれば大差がないのである。

さっさと間違えて、修正したものを出せば良いだけなのだ。

不確実性を受け入れる

変化に柔軟な対応が必要なソフトウェアにおいて、とくに必要とされるマインドになる。

具体的には

  • マネジメントは詳細までものを期待しない
  • 予算と報告のプロセスは精密な結果の予測を要求しない
  • 内部プロセスは計画や優先順位の変更に柔軟である。
  • 事前に全ての問題分析が完了せずとも、新しいことに挑戦する姿勢を持つ
  • システムとプロセスは柔軟で、複数の頻繁な変更を受け入れられる
  • 学びに基づいて、変化を精力的に行う

ここで気になるのは、納期になるだろう。

しかし、日米で納期に関しては意味が異なる。

日本では、納期までに予定された機能が全て搭載された製品を予定された品質で納品が必要となる。

アメリカでは、納期に厳しくなく、実際納期になった時にリリースされるものは予定より少ない量であることも多い。

納期に間に合わせるために徹夜する人なども少ない。

ソフトウェア開発において、納期通りというのはほとんどない。 多くの不確実性をはらんでいるからだ。

ではどうすればいいのか

進捗の実績だけで状況判断し、納期を固定したままスコープを出し入れするのが現実的である。

納期は守りつつ、間に合わないものはリリースに入れずに次に回すか、もしくはやめるのである。

中長期で見たときに、無理をして徹夜などで間に合わせても、エンジニアの体調が崩れてしまった方が生産性が下がるので、マネジメント的には効率が悪いからだ。

そして、無理して出来上がった実績は、後世に引き継がれてしまう可能性があるのだ。 つまり、前回これだけできたのだから、今回もこれくらいいけるよねというような形で無理が続いてしまう可能性があるのである。

守らなければいけない納期

しかし、そうは言っても、絶対に遅れてはならない納期というのもある。 法律的に関わるものであったり、オリンピックのようにその時に出ていないと意味が全くなくなるような納期である。

そう言うものに対しては、シンプルに早く進めるしかない。

すでに動いているものをリリースすると約束できれば良い。 例えば、フィーチャーフラグを使ってフラグの切り替えでリリースできるようにすることで公開とすることも可能であるのだ。

余裕のある計画を立てる

不確実性の高いソフトウェアにおいて、その人のできる日数を納期にするのではなく、プラス何日か余裕のあるスケジュールを設定する。

アメリカでは、「なるはやである」とか、「明日までに」というオーダーはマネジメント能力の欠如とみなされる。

生み出すものの量ではなく、価値にフォーカスをあてるマインドが大事になってくる。

コードリーディングにおける脳の負荷

以前書いた

ugo-ev.hatenablog.com

プログラマー脳と内容が重複する箇所が多かったので端折る。

ざっくりと以下のようなことである。

極力読まないようにする。

他の開発者を信じて、読まなくても挙動が分かる部分は動作だけ理解してコードは読まないなど

クラスの役割だけ把握し、インターフェースを理解することで、読む量を減らす。

重要なことは、「自分にとって難しすぎると感じる時は、大抵脳の使い方が間違っているサインである」

人に説明できるようにする

人は記憶力がいいものではない。

では、どうすれば記憶の中に留めておけるだろうか。

人に説明できるように理解すればいいだけの話である。

人に説明できるということは構造を整理して把握して、脳のメモリに乗せる必要があるということである。

また、先述したメンタルモデルをつくることも状況の細かいことを把握するコツになる。

そのため、単に「できた」で終わるのではなく、「説明が可能か」というところまでセルフチェックをした方が良い。

復習するタイミング

記憶しやすくなる復習のタイミングの習慣化というのを意識をする。

以下のタイミングが良い - 覚えた翌日 - そのさらに1週間後

意識の中に残せるようにするには、次の三つのファクターが重要になる。

  • 理解
  • 記憶
  • 反復

頭の中のみで整理する

ディスカッションをするにしても、頭の中にフレームワークがあるから理解できる。

頭の中でのみ物事を整理する訓練をしていけば、それができるようになる。

具体的には

  • ミーティングの議事をその場で書かない
  • 人の話を聞く時は、その後に誰かに説明することを想定して頭の中で整理しながら聞く
  • 頭の中で整理してから文章に書く

コミュニケーションにおける原則

エンジニアの人には、情報が少ない方が好まれる。 たくさん情報があっても消化できないという感覚による。

PRなどに大量に説明があっても、誰も読まないし、逆にスルーされることもよくある話。 もっと単純化する必要がある。

最初から全部説明せず、情報量を減らすコミュニケーションの仕方がすごく重要。

相手が求めているものへの感度

相手が何を欲しているかを理解して、自分用のメモを作る際にも共有できるような形で書いておく。

そうすることで、いつでもそのリンクを送るだけで良くなる。

見る人が欲しい情報はこれだろうという形で整理しておくべきである。

日頃から伝えることを前提としてメモなどの準備をしておくと、何か聞かれた際の工数削減にもなるのである。

他の人にシェアできる形式を意識して、文書を書くということに時間を惜しまずにすることで、将来の自分の工数削減になるのである。

環境

また、当書ではコミュニケーションの取りやすさという視点で

クイックコールと呼ばれる、簡易的な通話を行い、気軽にペアプロをしたり、一緒に考えたりしてもらうようなこともある。

もちろん、声のかけやすい環境というのを心がけることでクイックコールをしやすいという面もあれば、クイックコールされやすいということもある。

クイックコールをされる側としては、ちょっと手助けするだけでプロジェクトがスムーズに進むのでいいこともある。

なので、どんどんクイックコールをするようにしたり、そういうのが良い環境を作ることが重要になる。

チームビルディング

サーバントリーダーシップ

サーバントリーダーシップとは、リーダーはビジョンとKPIを示すが、実際にどう動くかはチームが主体的に考えて意思決定していく。

対して、コマンドアンドコントロールという管理体制では、マネージャーが部下に指示をする形になる。

サーバントリーダーシップのスタイルでは、現場のメンバーがかなりの権限を与えられて、どう実行するかを各自で考えているのである。

自己組織

自己組織チームとは、チームが自ら考えて自分で意思決定をするスタイルになる。

3つの特徴がある。

  1. 生産性が高い
  2. チームのエンゲージメント(満足度)が高い
  3. よりよいソリューションが選択されやすい

タスクの割り振りもチームが自らやっていく。

基本的にメンバー各自がやりたい仕事を「自分がやる」と選択している。

何が重要かというと、メンバーが楽しんでいるかが重要視される。

楽しい仕事でなければ、生産性は上がらないし、楽しい仕事であれば生産性は何倍も高くなるのである。

マネージャーの存在は仕事を楽しめているかを確認すること

マネージャーといっても、日本とアメリカでも全然違う。

日本では、進捗管理や課題管理を行なったりする。いわば、指揮をする人である。

アメリカでは、サーバントリーダーシップ制のもとでマネージャーが重視するのは、各メンバーのメンタル面になる。

マネージャーの一番の関心事は、メンバーがいかに幸せに働けているかになっている。

なので、随時「楽しめているか」を確認し、心地の良いムードを作ろうとしている。

そのため、マネージャーはメンバーに対して、困っている部分に対するアドバイスはするが、具体的にあれしろ、これしろなどと細かく指示することはない。

例として、1on1の時間では、共有したいことややってみたいことの相談のほか、悩みなどにアドバイスをくれるというものになる。 誰かを見習えなどの話はなく、メンバーの個性を手助けする姿勢がある。

納期に対する意識

日本だと、納期は絶対というイメージがある。

しかし、不測の事態は見通せないため、達成されないということも頻繁に生じる。

そのため、マネージャーは基本的に、一度仕事をプログラマに割り振ったら、あとはもう信頼するしかないのである。

逆に、そのプログラマが精一杯やっても遅れてしまったのなら、それがその時できるベストだったということである。

日本ではよく、技術者はどんな批判も受け入れ、まさかりを投げ合って成長するものというような雰囲気があるが、そんな辛い思いをしなくてもプロフェッショナルにはなれるのである。

基本的に、みんな自分が一番大切で、自分の幸せを第一に考えることを前提としているのである。

ミドル層

サーバントリーダーシップ方への転換で、一番抵抗が激しいのがこの層になる。

トップ層とは違い、新技術の導入や変革に対して、前向きになりにくい。 プロジェクトやサービスごとに数字を持っているので、自分の慣れていない方法で新しいことを始めるのに相当勇気がいるからだ。 彼らは慣れていないリーダーシップのやり方で発揮しなければならない。

しかし、しっかりトレーニングをすれば、過去のマネジメント経験も生きて、新しいサーバントリーダーが誕生しやすくなる。

生活術

ワークライフバランスについて

基本的に、働く人の裁量に任せられる。

日中はミーティングなどが多い時は、夜に集中してコーディングの時間を取るとかをする人もいる。

生産性を上げるには、定時上がりの方が効率が良かったりもする。

ただし、定時で上がったあとは自分の好きなトピックについて学習したりを行う。 そのように、学習をしなければ生産性は上がらないのである。

タイムボックス制を取り入れる

定時が来たら仕事が終わっていなくても強制的に切り上げるというような感じでタイムボックスを取り入れると良い。

そうすると頭がスッキリし、リフレッシュしたりする。

夜の時間は自分の趣味に回すことができるので、気持ち的にも余裕が持てるようになる。

そうしていくと生産性が上がるのである。

違うことをする

気分のリフレッシュに以下のようなことを頭に留めておくと良い。

  • 水泳をする時に息継ぎをせずに泳ぐことはできない。
  • 発送のブレークスルーは、その仕事をしていない時に発生する。
  • 1日に一つのことに集中できるのは4時間。
  • 何もしない休息ではなく、いつもと違うことをする。

幸せ

この本で一番好きな言葉がある。

「幸せを感じるから成功するのであって、成功したら幸せになるわけではない」

という言葉だ。

物事を整理するということを意識する。

例えば、ランニングに行ったら走ることだけで完了とするのではなく、帰って水分補給をしてシャワーを浴びて万端の状態になるまでを一連の所作として行う。

それが達成されては初めてランニングが完了するとした時の達成感によって、幸せを感じることができるのである。

まとめ

上記のほかにもいろいろと書かれていることはあったが、自分にとって重要だと思われるところだけを抜粋した。

AIに対しての考えであったり、ワークライフバランスや体の衰えに対する考えや実際の行動など

非常に参考になることが多く、プログラマーとしてやっていこうと思ってる人には一読の価値があるだろうと思った。

Microsoftで働かれてることもあり、Microsoft製品名を全面に出しているのは気になったが、内容には大きく影響の与えるものではないので、随時自分の使ってるツールなどに置き換えてもいいとは思う。

この本を読む直前に意外と自分の中での発見したことがあり、それが答え合わせのように書かれていたので、自分の感じたものは間違いではなかったのだと改めて確認できたのも良かったと思う。

SCRUM MASTER THE BOOK

自己組織化

スクラムにおける自己組織化は、スプリントゴール、バックログ、動作するプロダクトを期間内にデリバリーすることに限られる。 あるメンバーにとって気二位いらないことがある時は、チーム全員で話し合ってお互いを理解し、協力や助け合いの方法を変えていかなければならない。 重要な特徴として、一人ひとりのマインドセットがある。 良いチームは、「私」ではなく、「私たち」の姿勢を持っている。 「問題を解決するために、チームを手助けできることはありますか?みなさんのお役に立てることはなんでしょう?」 というふうに考えられるようにすること。

自己組織化したチームは一つの生命体となる。 チームメンバーが、自分自身ではなく、自己組織化したチーム全体のあり方に責任を持ち、説明責任を果たし始めたら、偉大なチームの一員へと一歩近づく。 スクラムマスターは、チームを「個人の集まり」ではなく、「一つの存在」として認識していけるように重要性に気づいてもらわなければならない。

スクラムマスターの責務

  • チームが責任を持つように促し、共通のアイデンティティと目標に沿って行動することを支援する
  • 透明性とコラボレーションを推進する
  • チームの自発的な行動を促すことを通じて、障害物を取り除く
  • アジャイルスクラムの考え方を理解し、自分自身も学び続ける
  • アジャイルスクラムの価値を維持し、他の人がスクラムを視界し、実施するのを助ける
  • 守るべきときは、開発チームを守る
  • スクラムのミーティングをファシリテートする
  • チームがより効率的になるよう、手助けする

チームメンバーと兼務

デメリット

システム全体を俯瞰する視点とシステム思考の能力を欠いてしまう。 リーダーシップやチェンジマネジメントのスキルを欠くこともある。 チームの能力を向上させることに気が回らない。

メリット

メンバーの一員なのd、チームメンバーの間には相互に信頼がある。 スクラムの基本とチームの弱点を理解しているので、レトロスペクティブで指摘を入れることができる。

結果

重要性が低いものとみなされ、完全に消滅してしまうこともある。

プロダクトオーナーと兼務

デメリット

相反する関係になる。 スクラムマスターは、デリバリーの責務を担うべきではない。 デリバリーの責務はプロダクトオーナーの責務。

メリット

チームメンバーの一員として扱ってもらいやすくなる。

結果

スクラムマスターの役割は淘汰され、POがすべてをコントロールするようになる。

マネージャーと兼務

デメリット

命令的になる。 コーチングせずにメンタリングに頼る。 メンバーとの関係性を欠いたものになりがち。

メリット

優秀なマネージャーはリーダーであり、チェンジマネジメントの経験があるため、移行期間中の対応がより素早くなる。

結果

ほとんどのマネージャは組織を率いることを夢見るので、スクラムマスターをやったとしても一時的なものになる。 自己組織化、自己肯定感、当事者意識が弱くなりがち。

複数のチームを兼務

デメリット

時間が足りない。 早めに議論をファシリテートし、対立が大きくなるのを防げないと、かなり難しい仕事になります。

メリット

このスクラムマスターは素早く学び、困難な問題を解決する経験を豊富に持つ。 理想は、2チームまで、最大でも3つまで。 3つでも手が余る場合が多く、必要な情報が不足し、衝突を防いだり、チームを次のレベルに高めたりすることができなくなるため。

結果

システム思考に秀でることが多い。 チームは一つ一つ異なることを理解しているから。 多様な文化に合わせてスクラムをうまく実装できる。

スクラムマスターはリーダー

スクラムマスターはリーダーシップを取る職務になる。 創造性、ビジョン、直感が必要。 共感力があり、聞き上手で、いつでも関係性を修復する準備ができている。 組織をまたいだコミュニティを構築できる。

スクラムマスターの役割

ティーチングとメンタリング

スクラムアジャイルの基本的な進め方を伝えるもの。 自らの経験に基づき、効果的なプラクティスや手法を提案する。 アジャイルへの移行の序盤では、何度も繰り返し説明しなければならない。 それぞれのプラクティスがなぜ組み込まれ、どうすればうまくいくのか、チームが理解しきれないから。

障害物の除去

仕事の前にこの質問から始める。 「チームがもっと仕事をしやすくするために、私はなにができるだろうか?」 チームを手助けする一つの方法は、障害物を取り除き、効率よく仕事ができるようにする。

ファシリテーション

会議や、会話には、ゴール、成果物、期待する結果が明確に定義されているべき。 ファシリテーションを行う際は、議論の内容や解決策について絶対に干渉しないのがルール。

コーチン

偉大なスクラムマスターが持つべき最も重要なスキルの一つ。 一度習得してしまえば、信じられないほど強力。 スクラムにおけるコーチングは、個人の成長だけでなく、チームの自己組織化、責任、オーナーシップにも焦点を当てる。

スクラムを始めるにあたって知っておくべきこと

スクラムの背景にあるダイナミクス(動力学)や原則を理解する必要がある。 以下はフェーズに合わせた事象と、スクラムマスターが行うこと。

障害物

スクラムマスターは、チームの障害をチームに気づかせて、自分たちで解決するように進める方法がある。 それを怠ることで、チームの秘書になってしまい、チームは誰かが問題を解決してくれるのを待つような自信のないグループになってしまう。

立ち往生

ある程度長い間スクラムをやっていて、良いスクラムチームではないが、問題に感じてる程でもないチームにある話で スクラムマスターはチームに何をすべきかをいうものではない。 場合によっては、そのようなスクラムマスターはチームから受け入れを拒否され、チームを去るしかなくなる。

責任

自己組織化もできているチームでは、ファシリテーションが役割を果たしてきたと言える。 次のアプローチに進むため、ミーティングの進行を任せるべき。 軽いタッチのファシリテーションの準備をし、チームに空間を与え、信頼する。 もし、間違った方向に議論が行った場合はコーチングをする。 ここではスクラムマスターは、注意深く耳を傾け、何が起こっているのかを把握し、必要なら手助けをできるように準備を整えておく。

偉大なスクラムマスターに必要なこと

それは「観察」になる。 チームの議論を促したり、チーム自身で決めるよう問いかけたり、問題解決を試みたりといったことをチームに代わってもらい、観察する。 全部なる早で問題解決してチームを作業に戻したい衝動に抵抗できれば、「自己組織化したチームを作る」という目標に大きく近づく。 観察する役割まで一歩下がり、どのアプローチをなぜとるかをチームが判断することを強く促すから。 傾聴することは、コミュニケーションや意思決定をする上で最も重要な要素の一つ。

偉大なスクラムマスターを目指すためのヒント

  • スクラムマスターの心理状態モデルのうち、どのアプローチを取るかを決める前に、観察する。
  • チーム自身で障害物を取り除くよう手助けすることを通じて、障害物を取り除く。
  • ファシリテーションとは、会議を開催したり、本を読んだり、研修に出ることだけではない。
  • コーチングで重要なのは、あなたの経験ではなく、良い質問をする能力。
  • スクラムマスター道の3つのレベルすべてに取り組む。開発チームのレベルのみにとどまってはいけない。
  • アジャイルスクラムは、偉大なスクラムマスターの働き方と生き方そのもの。

メタスキル

ある状況において意図的に取る態度、考え方、スタンスのこと。 具体的なスキルを引き出す、より抽象的なスキルのことを言う。

スクラムマスターのメタスキルは

  • ティーチング
  • 傾聴
  • 好奇心
  • 尊敬
  • 遊び心
  • 忍耐

状況に応じて適切なものを選び、意図的に使用することがとても大事。

クネビンフレームワーク

hirolaboratory.com

コンピタンス

理論だけではなく、スクラムマスターは気づきを得るために、幅広く物事を調べる必要がある。 カンファレンスに参加して、他の参加者や講演者とリアルな状況について話し合うのも1つの手。

  • 説明と経験の共有 アジャイルに関する概念をさまざまな相手に売り込んで、強く関心を引き、夢中にさせることができないといけない。 実際の経験がないと、特定のプラクティスや成果物を採用するのは難しい。

  • ファシリテーションコーチング 自分の経験は置いておいて、傾聴と好奇心のメタスキルを適用し、チームに決定してもらう。 チームを信じ、自分より良い解決策を思いつくように自分なりの解決策を考えつく手助けをする。

コアコンピタンス

3つの知識 - ビジネス知識 - チェンジマネジメント - 技術知識

どのコンピテンスを持っているか

について、どれが足りないかを考えていく。

チームビルディング

タックマンの集団発達モデルというのがある。

  • フォーミング(形成期)
  • ストーミング(混乱期)
  • ノーミング(統一期)
  • パフォーミング(機能期)
  • 変動

チームの機能不全

信頼の欠如

それぞれの人は、他人にはない専門性、特別な技術知識、業務領域のノウハウを持っていると信じている。

そのため、サイロ(外との断絶した世界や領域、中に閉じこもった状態)を守りたい。

衝突への恐怖

ニセモノの調和を取り繕う傾向がある。

領域ごとに分けているのに、議論に時間を使うのを避ける。

1つのユーザーストーリーに協力して取り組むなんて意味がない。コミュニケーションに不必要な混乱を生むと思っている。

コミットメントの不足

次のような言葉は低レベルの信頼の欠如によるもの。

スプリントの終わりまでに、何を終わらせられるかは言えない。何が起こるか分からないのだから。

自分の担当部分はすぐ終わるけど、他人の分はなんとも言えない。

説明責任の回避

スプリントの終わりには、できなかった理由をつけて例外扱いし、次のスプリントにも同じ量の仕事ができると計画する。

時々起こりうることではあるが、定期的に起こるなら、機能不全である。

結果への無関心

顧客に価値を届けるという目標に対して、担当範囲のコーディングやテストだけを終わらせるという関心しかない状態をなくす。

スクラムマスターのやること

達成したいことを明確にし、なぜ達成したいのかどのように達成するのか、計画の実現を目指すようにする。

チームの協定や、ワーキングアグリーメントを作成するように支援しないといけない。

守りの姿勢

チームが提案した時に守りに入ってしまうことがある。

例えば、2週間スプリントを1週間スプリントに変える時などは、変化を恐れて守りに入ったりするなど。

それを変えるための提案も、今の結果に満足することで守りに入る。

壁を作る

自分のアイデアを何度も繰り返して、他の人のいうことに耳を傾けない。

自分がやってるので、自分のやり方でやる。他の人がやる時はその人のやり方でいいよ、というようなことを言うこと。

直接的ではないが、最後は同じ結果になる。

これは、仕事のやり方がバラバラな個人の集まりとして働くことになる。

侮辱する

君何も分かってないね

とうようなことを言う。

これは非常に険悪なものに発展する。

責任

問題が起こると、頭の中の思考では解決策を考え始める。

順番に以下が頭の中で行われる。

  • 否認
  • 責任転嫁
  • 正当化
  • 回避
  • 義務
  • 放棄
  • 責任

解決: バグが報告された時、修正するだけでなく、再発防止に次回はどこを変えてみるかを議論する。

部族としての組織

スクラムバット

  • ステージ1 ほとんど起こらない。 ストリートギャングなどで起こるようなこと。 人生は最低だ。の文化のこと

  • ステージ2 アジャイルの環境では、移行の初期の段階でこのステージに陥る。

「自分の」人生は最低だ。に移行する。

このこときから、スクラムバットが発生する。

スクラムバットとは、スクラムを一部を取り入れてはいるものの、やっていない部分やうまくできていないところがあることを言う。

  • ステージ3 自分はすばらしい、でもあなたは違うフェーズ。

一人一人が成功体験を持つ必要がある。

このステージでは、人々は個人的な成果や肩書きが重要だと思っている。

自分は人よりよくがんばっているという感覚を持っている。

このステージのSMはチームを過小評価している。

  • ステージ4 チームとして一つの目標を持っていて、競争に興味がなくなるフェーズ。

人々は自分達は最高だと思っている。

チームは自己中心的ではなくなり、外に目を向け始める。

そのためには、個人として活躍するための十分な場を与え、十分に評価しなければ、チームは真にアジャイルの文化になる準備ができていないのでスクラムは失敗する。

重要なことは 1. 個人の評価よりもチームの成功の方 2. 一般的に、周囲と競う気持ちは弱まる 3. 自分達はすごくて、他の人たちを手助けもできる

  • ステージ5 これまでの続き。競争力は弱まる。

アジャイルコーチの中にはこのレベルで仕事をしている人がいる。

つまり、他のアジャイルコーチを競合とみなさない。

業界全体を良くしていこうという考えでいるため、お互いが協力し合い、市場を成長させる。

変化の実装

アジャイルの車輪は、変化のタイミングや理由が正しいか、判断するのに役立つエクササイズになります。

顧客満足、生産性、市場に出すまでの時間、チームの健康、チームのコラボレーション、チーム外とのコミュニケーション、継続的改善、効率性、品質、変化への反応、顧客からフィードバックを得る、デリバリーの予測可能性から成る。

半年後にはどこにいたいかの期待値を評価として、円の中央を最小として、パラメータをふってみる。

どこが改善点か見えてくるでしょう。

行動を変える

変化をエッジとして見る。

エッジとは、既知と未知の境界線。自分自身について知っていることの限界。

新たな行動、アイデア、視点を試す時はいつでも、エッジを超えている。

チームと個人が成長し、変化する限り、常に新天地と探索すべきエッジがある。

SMとしての役割は、あらゆる変化の中で乗り越える小さなエッジを理解し、個人、チーム、組織がエッジを乗り越える手助けをすること。

そうすると、SMの心理状態モデルのうち、最も適したアプローチはコーチングになる。

人々がエッジを乗り越える準備ができたら、いつでも手を差し伸べ、力の限り助けるべき。

変化を成功させるための8つのステップ

  • 危機意識を持つ

変化を必然にする。

人は痛みを感じるまで改善の必要性を感じない。

正当な動機と理由があれば、変化は起きる。

正直で透明性のあるものを提示していく。

  • チームをガイドする

アーリーアダプターに焦点をあて、1人では難しいことをチームの一員になってもらって乗り越えるように働きかける。

広範な人々を巻き込みたいなら、組織構造にとらわれるべきではない。

  • 変化のビジョン

変化のビジョンとその戦略を練る。

何円何百というアイディアを人々が理解できるよう、その変化について明確かつシンプルに説明できるようにする。

変化を推進するチームのメンバー全員が、5分以内に説明できるようにする。

  • 理解と了承

人々はさまざまな不安を抱えている。

置かれている状況も違えば、やり方を変えることの影響もさまざま。

優れた傾聴のスキル、状況把握、人々の情熱を引き出す能力が必要となる。

新しいアイデアを受け入れるのに時間がかかる人には、忍耐も必要となる。

  • 人々の行動を促す

チェンジマネジメントのこの部分は、SMがやることに近い。

人々の行動を促すために障害物を取り除く必要がある。

人々への感謝と称賛を忘れずに、変化に向けて行動していきましょう。

  • 短期の成功

成功を頻繁にアピールする。

長期的ビジョンや野心的なゴールを持つ。

ポジティブな雰囲気になる。

失敗を隠さずに、この瞬間を大事にすることを行う。

失敗を隠すことは、良からぬうわさが立つリスクにつながり、これまでの努力を台無しにしてしまう可能性がある。

  • 気を緩めない

望ましい状態に到達していないのに、あまりに早く「完了した」と認識してしまったために、変化が失敗に終わることがある。

まだ新しい状態が定着していないので、遅かれ早かれ以前の習慣に戻ってしまう。

しかるべき階段を越えたら、変化をする必要がなくなるわけではなく、完璧などない旅なので完了するということもない。

  • 新しい文化を創る

定着させること。

新しい働き方を組織の文化にとって不可欠なものにする。

フィードバックに基づいて計画を変えていくという言葉が出て来れば良い方向。

ポジティブさを高める

レトロスペクティブでは、基本的に褒めたり、いいところについて話し合う会にする。

この先続けたいことや、もっとやりたいことについて話すことに費やすようにする。

ネガティブな要素は、1つのネガティブイベントに対して、3〜5つほどのポジティブイベントが含まれるべきである。

ポジティブな出来事を見える化し、成功を祝う。

そして、どれだけ状況が厳しくても、パニックにならず、ポジティブさと笑顔を増やす。

ファシリテーション

ファシリテーションは、すべてのスクラムマスターのコアプラクティス。

ファシリテーションとは、議論の枠組みと流れを定義すること。

優れたファシリテーターは、柔軟でアジェンダを変更する準備ができている必要がある。

馬の熱量を把握し、それに応じてフォーマットを調整する必要がある。

やるべきこと

  1. ファシリテーターは、内容ではなく議論の枠組みに責任に持つ
  2. 開始前に各会議の明確な目的と成果物を定める
  3. 会議の目的とアウトカムを参加者と一緒にレビューする
  4. 会議の開始と終了の際に、チェックインアクティビティを行う
  5. パーキングロットについて説明し、使っていく
  6. 自分の計画に必要以上に執着しない。もしその計画がうまくいかないなら、状況やチームのニー時に合わせて変える
  7. 人々の理解を深め、さまざまな意見を得るため、議論の幅を広げたり、狭めたりする。

コーチン

すべてのスクラムマスターにとって最も重要なスキルの一つ。

自己認識と自己実現を呼び起こすこと。

創造的な解決策を考え出し、自分自身を成長させる目標を決める際に役立つ。

人の潜在能力を解き放ち、パフォーマンスを最大化する。

傾聴のスキルに注目する。

アドバイスを与えるのではなく、人々が自分自身の解決策を考え出す手助けをする。

独自の解決策を生み出すべきで、あなたの唯一できることは、鏡を調整して気づきを与え、新しい視点を見つけてもらうこと。

根本原因調査

  • 予測可能性 何が、どこから、いつ、誰が、なぜという質問を行う。 フィッシュボーン呼ばれる。
  • なぜなぜ5回
  • 品質が低い

まとめ

スクラムを行う上で必要な知識や、最低限の行動などの指針となる参考になった。

スクラム初心者や、僕のようなスクラムマスター未経験からスクラムをやるってなった時でもこの本を参考にすることで、ある程度スクラムのイメージはつくと思う。

これまで少し漠然としていたスクラム像が、当本を通して少し具体化したように思われる。

そもそも「論理的に考える」って何から始めればいいの?

こちらの本を読んだので感想を書こうかと思います。

概要

論理的思考はどこの場面でも使われる。

勉強の場でも、仕事の場でも、人とのおしゃべりの場でも。

人生を左右するような大きな分岐的になることもある。

論理的思考ができるかどうかで、その人の言葉の重みも変わるし、その後の人生にも大きく影響が出て来る。

本の進行

本自体は、登場人物同時の会話で進行していくため、非常に読みやすい。

会話なので、ところどころジョークが混じったり、状況の説明などが入るのが息抜きになって緩急づいた本になっている。

内容自体も、先生と生徒 のような構図で、生徒側に読者を置き換えることで感情移入も、情景も掴みやすい。

ある程度論理的思考について考えたり読んだりしてきた人であれば、スラスラと読めて、短期間で読める良いボリューム感だった。

内容

非常に分かりやすい。

先生役の登場人物が、生徒に対して、どういった場面で論理的思考が必要か、どういう考え方をすれば良いのかを3、4つ程提示するのだが

例題を出して、それに対して回答例もつけてくれていて、しかも図が差挟まっているので分かりやすい。

一つの例題に対して、2、30ページあるが文字量的にも、前述したように会話の部分もあるのでそこまで重くなく、スムーズに読み進められる。

議題

議題はいくつか用意されている。

  • 考えるための準備(考え始めのスタートとゴールを決める)
  • 逆から考える
  • 三段論法(演繹思考法)について
  • 帰納的に考える
  • 整理の仕方(表を使う)
  • 反例を用意する
  • 背理法について
  • 相手の主張を簡単に否定するコツ
  • 優柔不断を無くすための判断基準について
  • 重み付け
  • 説得力のある決め方(消去法)
  • 常識を疑う
  • ズルいことが考えられる人(盲点を見つけることができる人)

ワークショップ

この議題に対して、生徒役の人が答えて、正解に導かれていく。

その時に、生徒役の人は必死に答えを見つけようと考えるのだが、その時に自分もまずは考えてみるというのをやってみると良さそう。

本が相手となるワークショップができるような作りになっているのもとても良かった。

まとめ

基本的には、この本に書いてあることを実践するだけでもかなり論理的思考を再現できるような気がする。

しかし、実際に仕事の場で使おうと思うとそれなりに訓練が必要になってくる。

何度かこの本を流し読みでもいいので定期的に意識をより戻して、仕事の中でも意識できるようにしておくと良いだろうと思われる。

全く自分には論理的思考がないというような人でも、この本を一通りなぞることで、枠組みは掴めると思うので、地盤を固めるはじめの一歩としてはかなり良い本のような気がした。

みんなでアジャイル

はじめに

以下の方を読みました。

アジャイルについての本は、3〜4冊目くらいになります。

ある程度、アジャイルについての考えや実践を通して内省を行なったり、記事を読んだりしていたのもあり

薄らとアジャイルについての知識や行動について身についてきていました。

しかし、いろんな職能に当てはまるプラクティスゆえに、抽象的な概念が多く、なかなか効果を最大化するというようなスキルには変えにくいのもアジャイル

そう言うわけで、アジャイルについての本をどんどん読んでいこうという一環で読むことにしました。

本記事は、内容にはほぼ触れず、読んだ感想だけを書こうと思います。

感想

上記でも書いたように、いろんな職能に対して適用できるプラクティスとして、 アジャイルが存在していることが前提となります。

どうしてもエンジニアをしていると、開発に焦点が当たりがちになりますが、 開発以外にも適用することができます。

むしろ、開発以外にこそアジャイルを組み込まないと、 サービスの最大化を図ることができないのだと思いました。

アジャイルを取り込むことで

開発以外にアジャイルを取り込むことでどうなるか

多くは、サービスを取り囲む全員の向いている方向が定まるというのがあります。

それは何に繋がるか

それぞれの職能でやるべきことが、一点に向かって絞り込まれていくというところになります。

チーム横断でのコンテキストの共有や、価値基準についての話を行うことができることで、 より早い理想の実現を可能にしていくのがアジャイルの基本となってきます。

アジャイルは必須か

どんなチームにもアジャイルが必要かという疑問については、「完璧なアジャイルは必須ではない」というのが答えになります。

アジャイルというのは取り組みのことであり、こういったことをすれば良いといったプラクティスがあるだけで、それに従うことが前に進むことに繋がるわけではないということです。

つまり、アジャイルにおける考え方、「顧客を引き込む」、「必要性について話す」、「全ての準備が整った上での開発ができている」など、必要な概念を必要な分だけ取り入れればいいのです。

アジャイルを取り入れるから、全ての考えに従う必要があるという考えはいらず、顧客と対話ができているなら、それはすでにアジャイルに取り組んでいると言えたり、マーケティングやセールスと方向性を共にできているのであれば、それはアジャイルが導入されていることにつながります。

なので、それらが必要ない仕事については導入する必要がないという認識になります。

例えば、必要なものが明確で、これが欲しいというのが決まっているものについてはアジャイルというより、どう実現するか、だけに焦点を当てればいいので、実現工程にのみ部分的なアジャイルで事足ります。

そして、アジャイルを行うことも、そのチームの構成や、人、組織体系によって行うことが異なるので、「これ」といった完璧なアジャイルが用意されているのではなく、アジャイルの考えに則ったチームごとのやることを選定していくことが必要になるかと思います。

「なぜ」、「どのように」、「どのようなもの」を洗い出し、話し合う。

それができるだけでも、十分アジャイルを取り込んでいると言えるでしょう。

方向性が全く見当違いの職能チームで構成されていたら

方向性が定まらなければ、話し合いもできないかもしれません。

そう言った時に必要なのが、方向性の統一化になります。

これも結局概念で、方法は自分で編み出す他ないです。

ただ、この本にはこうするといいよといった示唆はあるので、実践するだけでも効果を得られることでしょう。

そういったこともあり、アジャイルの導入への最初の一歩を踏み出すには、この本は分量、内容共に手軽な感じがあります。

まとめ

アジャイルの導入は個人的にはすごくワクワクする話です。

これまで、沈澱していた底にある物を掘り起こし、再びそこに新しい風を吹き起こすような新鮮さを感じます。

しかし、それはコップの中のココアのようなスプーン一振りで混ざり合うようなものではなく

針金のような細いもので、プールの水を幾度となくかき回す必要があるほど大きく労力と時間がかかるものかもしれません。

そういった意味で、アジャイルというのは表面的なもので終わってしまうことが多いのかなという印象を受けました。

僕個人は今のプロダクトでアジャイルを採用していて、まだまだ未熟なアジャイルをしているという自覚はありますが

その中でも、少しずつ本にあるようなことを試してもいいし、アジャイルの概念に則っとって自分のやり方を試してみるなど、経験を積んでいければと思います。

Go言語 プログラミングエッセンス

概要

自分は実務でのGoでの開発はほぼ皆無に等しく、

サービス的にはGoを使ってるものの、レビューすることはあれど、自分が書くということはほぼしてませんでした。

そのため、自分でもGoを書く練習をしようと思い、本書を買いました。

Goの言語的な使い方について細かく書いてあることもあり、中途半端に学んでいた自分にとっては有益な本でした。

Goの言語仕様

Goの言語的な設計や考えなどが説明されており

Goによるプログラムはもちろん、コマンドや機能、テストについても書かれています。

コマンドは特に、開発で利用できるものが多くあり、自動生成コマンドであったりパフォーマンス計測であったり、インストールのコマンドについても細かく書いてあるので、一読の価値がありました。

文法

Goの文法的なところも少し説明があります。

僕は文法は他のところで学んでいたり、別言語での経験はあるので、ある程度飛ばしつつ読みましたが、初めてプログラミング言語を触るという人は参考になるかと思います。

Goだからといって特別なことはなく、純粋に文法を学んでいくにも素直な説明なので入ってきやすいかと思います。

開発

Goを利用してCLIの開発とWebアプリケーションの開発が紹介されています。

特によく使われているフレームワークやライブラリの紹介があるのは嬉しかったです。

慣れていない人からするとどんなライブラリを使えばいいとかの勘所がないので、長いことGoに触れてきた方の紹介としてライブラリが紹介されていると心強いですね。

そして、Webフレームワークなども紹介されていますが、基本的にGoは言語としての開発力が高く、フレームワークと言ってもGo言語の拡張としてのものしかないようで、得にルーティングの部分を吸収してくれる役割が大きいようです。

そう言った点もあり、どこにどんなフレームワークが良いかといった技術選定も、各フレームワークがどういった思想や機能を兼ね備えてるかを理解するのに良かったです。

並行処理

もちろん、並行処理についても1章使っており

channelを利用した並行処理、スロットルによる並列処理の制限など

少し学ぶのに難しい部分についてもサンプルコードと一緒に書かれているのは良かったです。

サンプルコードも何百行もあるものではなく、焦点を絞った形になっているのでコードも理解しやすいです。

ただ、1行1行の処理の説明はないので、ある程度独学で学んだ人が書き方を学ぶといった形に適しているかと思いました。

一部Go言語の仕様っぽい箇所があり、なぜそう書けるのか分からず悩む箇所がありました。

それも、素直にそう書くんだと受け入れる気持ちで読めば、何度か読んでいるうちに恐らく馴染んでくるでしょう。

実際のコードは、URLを元にスクレイピングして情報を取得するなどを想定して作られているのでイメージはしやすいかと思います。

テスト

Table-Driven-Tests を元にテーブルテストを書く紹介があります。

テストライブラリがGo言語の仕様で用意されていたりするので、そちらを用いてのテストをしています。

その中でいろんなテクニックも紹介されており、テストの効率的な実行の仕方や、前処理後処理の書き方なども学ぶことができました。

またこちらも並列テストの紹介があり、テストの速度などを上げるための仕方もサンプルコードがあります。

モックを使ったテストの紹介がなかったのが、少し気がかりでしたが、学ぶことが多い章でした。

計測

ベンチマークを取る機能が言語仕様として備わってるのは結構珍しいらしく、手法を紹介されていました。

僕自身は普段はあまりベンチマークを取るということを意識してはいなかったので、少しイメージがしにくいところではありましたが、そもそもベンチマークがとれるということも知らなかったので、知識としてあっても良いと思いました。

これからGoを触っていく中でベンチマークも取ることがあるかもしれないですしね。

まとめ

まとめとしては、とても学びが多い本でした。

もちろん既に知っていることや、あまり自分には必要なさそうな箇所もあったとは思いますが

いずれにしても再確認や、知識として知っておくというだけでも読んで良かったと思える本でした。

まだまだGoを始めて日が浅い自分なので、こういったベストプラクティスなどをまとめてもらえるのは、すごく有益でした。

個人開発ではGoを触っているので、もう一回読みながら書いてるコードに適用していけたらと思います。

Team Topologies

はじめに

チームトポロジーというのは、チームにおける形成図のようなものを指して、最適な組織構成とは何かを定義し、必要に応じて適用することで、チームの開発、運用、デリバリーを早く行えるようにする考え方を示している。

この本には、主に各チームや機能の定義、どういった概念かの説明を行った上で

どういったフェーズに当てはまれば良いか、どういった適用の仕方が良いかを解説する。

チームトポロジーとは

チームは常に未完成だが、最善を尽くした状態でもある。

チームは独立して存在しているわけではなく、熱意を持ったメンバーで構成し、自律的で、長続きさせるべきである。

そして、顧客に価値を届けるためにチームのことを考え、チームを進化させなければいけない。

そのための明快なパターンを提供することが、チームトポロジーである。

チーム構造を最適化する方法を見つけ出そうと奮闘している組織や、チーム設計が特にビジネスアウトカムやソフトウェアに影響を与えることにまだ気づいていない組織に役に立つ。

チームトポロジーの考え

以下の4つの基本的なチーム - ストリームアラインドチーム - プラットフォームチーム - イネイブリングチーム - コンプリケイテッド・サブシステムチーム

以下の3つのインタラクションモード - コラボレーション - X-as-a-Service - ファシリテーション

チームトポロジーでは、技術や組織の成熟に応じてどう進化するかに目を向けている。

適応型モデルを重視し、チーム間の相互関係に積極的に優先順位をつけることで

ソフトウェアの比重が高い現代の企業がビジネスや技術の観点で戦略変更が必要になったことを感知するための、特定の技術に依存しない重要なメカニズムを提供する。

つまり、人間的なアプローチも重視しているということ。

同形力

組織の本当のコミュニケーションパスと、結果として得られるソフトウェアアーキテクチャーには強い相関関係がある。

理論上、理想的なシステムアーキテクチャーでも、組織モデルに合わなければ変えなければならない。

認知負荷

人間の認知容量には限界がある。

同時に、チームにも認知容量が存在する。

しかし、担当割り当ての際に、この認知負荷について議論されることは滅多にない。

認知負荷とはどんなもので、定量化することが難しいからだ。

チームへの要求というのは日々増え続ける。

だが、新規サービスの開発は、チームの時間は全て支えて、認知負荷が何もないかのように計画されることが多い。

チームは既存のサービスの修正や拡張も求められるが、それらは無視されているからだ。

これにより、チームのモチベーションの低下などが発生しうる。

私たちは、チームを最優先して、認知負荷を制限するよう呼びかけていく必要がある。

認知負荷をしっかり考えることは、チームサイズを決めたり、責任を割り当てたり、他のチームとの境界を設定したりする上で、とても役に立つ。

チームの認知負荷を制限し、チーム間のコミュニケーションを明確に設計する必要がある。

チームトポロジーのゴールは、コラボレーションが必要な場所やタイミング、実行に集中してコミュニケーションのオーバヘッドを減らすべき場所やタイミングを、組織が適応しながら動的に見つけられるようなアプローチとメンタルツールを提供すること。

チーム内のフローをよくするソフトウェアアーキテクチャ

チームの編成前に、どんなソフトウェアアーキテクチャが必要かを理解する必要がある。

コミュニケーションパスとインセンティブがソフトウェアアーキテクチャーを決定づけてしまうからだ。

そのためにはソフトウェアアーキテクチャのグッドプラクティスに従うと良い。

  • 疎結合
  • 高凝集性
  • 明確かつ適切なバージョン互換性
  • 明確かつ適切なチーム横断でのテスト実行

ものごとを分離し、チーム内にとどめておくことが重要。

組織設計には技術的専門知識が必要

アーキテクチャとチーム編成の間にある自己相似の力が現実のものであることを受け入れるなら、エンジニアリングチームに強い影響を持つのだということを受け入れなければいけない。

チームの編成

偶発的、行き当たりばったりでチームを編成するのではなく、断続的にチームを設計する必要がある。

このような設計によるチーム構造のことをチームトポロジーと呼ぶ。

しっかりと思慮深く練られたチーム構成は成功する確率が高い。

フィーチャーチーム

職能横断型かつコンポーネント横断型のチームのこと。

一貫で、顧客に提供、使用状況、パフォーマンスを監視できるチームを指す。

しかし、自給自足、つまり他のチームを待つことなく機能を本番にリリースできる場合に限る。

エンジニアリングの成熟度が高くないと、ワークフローの自動化やボーイスカウトルールに従わなかったりなどが発生する。

プロダクトチーム

基本的にはフィーチャーチームと同じだが、1つかそれ以上のプロダクトの機能全体を担当するという点が異なる。

インフラ、プラットフォーム、テスト環境、ビルドシステム、デリバリーパイプラインなどに依存する。

ソフトウェア開発の構築と運用はとても不確実性が高いため、スケジュールに沿って、同じ仕事のストリームのなかで複数のチームが調整を行うのは難しい。

そのため、ブロッキングが発生してしまう。

ノンブロッキングにするには、セルフサービス型の能力という形を取ることが多い。

テスト環境の洗い出し、デプロイパイプラインの作成、監視など。

しかし、プロダクトチームが自律性を満たしていないシステムの一部でありながら、早くデリバリーするようにプレッシャーをかけられると摩擦が増えていく。

クラウドチーム

プロダクトチームは、必要に応じて新しいイメージやテンプレートを作り、自分達の環境やリソースをプロビジョニングできる自立性が必要になる。

そして、クラウドチームはそのプロビジョニングプロセスを引き続き担当し、

  • 必要な管理
  • ポリシーの適用
  • 監視

を確実に行えるようにする。

しかし、クラウドチームはプロダクトチームのニーズと適切なリスクおよびコンプライアンス管理のニーズに合うような、高品質のセルフサービスを提供することに注力すべきなのである。

4つの基本的なチームタイプ

ストリームアラインドチーム

価値のある単一の仕事のストリームに沿って働くチームのこと。

ストリームとは

機能一式のこともある

ユーザージャーニーや、ユーザーペルソナの一つのような場合もある

顧客やユーザーに価値を届けられるように、チームに権限が委譲されている

つまり、他のチームへの引き継ぎが発生しない

どのストリームでも、長期的に維持される仕事のポートフォリオもしくは、プログラムの一部として、予算が割り当てられる

これまでの、顧客からの大きな要望、複数の顧客からの小さな要望を、プロジェクトが承認され予算が割り当てられ、フロント、バック、データベースなどいくつかのチームに割り振られ、既存のバックログに追加されるというやり方とは全然異なる。

期待されるふるまいとしては以下のようなものがある。

  • フィーチャーデリバリーの安定したフローを作ること
  • 最新の変更へのフィードバックに基づいてすばやく軌道修正できる
  • プロダクトの進化に実験的なアプローチを用い、常に学んで適応する
  • 他のチームへの引き継ぎを最小限にする(理想はゼロ)
  • このチームが実現した変更フローの安定性と、技術面およびチームの健全性の観点での補助的なメトリクスで評価される
  • コードの品質変化(技術的負債)に対応するための時間を持たなければならない
  • 積極的かつ定期的に支援を受ける他のチームタイプと連携する
  • メンバーは「自律」「熟達」「目的」を達成しようとしているか、達成していると感じる

イネイブリングチーム

複数のストリームアラインドチームの支援を行う

適切なツール、プラクティス、フレームワークなどのアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案などを行う

協調的な性格が強く、ストリームアラインドチームの課題や不足点を理解しようとする

サーバントリーダーシップとも考えられる

期待されるふるまい

  • ストリームアラインドチームのニーズを探索し、定期的にチェックポイントを設け、より多くのコラボレーションが必要になるタイミングについて合意する
  • 専門領域での新しいアプローチ、ツール、プラクティスについて先んじる。
  • 技術的な良いニュースも悪いニュースも伝える。技術的なライフサイクルマネジメントを支援するため
  • ストリームアラインドチームが直接使うのが難しい外部(もしくは内部)サービスのプロキシーとしてふるまうこともある
  • ストリームアラインドチームを横断した学習も促進するため、組織内の適切な情報共有を促すキュレーターとして活動する

ストリームアラインドチームへのインタラクションは、短期間(数週間〜数ヶ月)にとどめる方が良い。

新しいスキルを身につけたら、日常的なインタラクションはやめ、別のチームにフォーカスするようにする。

CoP(コミュニティオブプラクティス)も、同じように知識を広めるためのチーム。

イネイブリングチームが短期的に目的を達成するものとしたら、CoPは長期的に広く行う部隊。

コンプリケイテッド・サブシステムチーム

複雑なサブシステムを含んだり利用するシステムの担当となるストリームアラインドチームの認知負荷を減らすことにある

習得や育成の難しいスキルや専門能力を活かして、担当するサブシステムの複雑さに取り組む

期待されるふるまい

  • 担当するサブシステムの開発状況を意識して、適切にふるまう。初期の探索や開発の段階では、ストリームアラインドチームと密接にコラボレーションする。サブシステムが安定してきたら、インタラクションを減らし、サブシステムのインターフェイス、機能の使用状況と進化に集中する
  • サブシステムのデリバリー速度と品質は、ストリームアラインドチームが開発した場合(分割の判断をする前)より明らかに向上する
  • サブシステムを利用するストリームアラインドチームのニーズを尊重し、適切に優先順位をつけて変更をデリバリーする

プラットフォームチーム

ストリームアラインドチームが自律的に仕事を届けられるようにすることで、ストリームアラインドチームは本番環境のアプリケーションの開発、運用、修正を含む全体のオーナーシップを持つ。

ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる。

提供するサービスが目的に一致し、信頼性が高く、使いやすいプロダクトになるように扱う必要がある。

基本的に、少数のサービスを高い品質で提供することに集中する必要がある。

期待されるふるまい

ストリームアラインドチームが必要とする下位の内部サービスを提供することで認知負荷を減らし、ストリームアラインドチームがより上位のサービスや機能を提供できるようにする。

そのために以下のことを行う

  1. ストリームアラインドチームのニーズを理解する
  2. 高速プロトタイピングの手法を使い、ストリームアラインドチームのメンバーを巻き込んで何がうまくいって何がうまくいかないかのフィードバックを素早く得る。
  3. プラットフォームをプロダクトとして扱い、ユーザビリティと信頼性に強くフォーカスする。定期的にサービスが目的にあってるか、使いやすいかを検査する
  4. 手本を示すことでリードする。可能な限りストリームアラインドチームと一緒に使い、下位のプラットフォームを利用する
  5. 新しい内部向けサービスの採用には他の新技術と同じように時間がかかること、テクノロジー採用ライフサイクルの採用曲線に沿って進化することを理解する。

プラットフォームをプロダクトやサービスのように管理する

プラットフォームにはユーザー(開発チーム)がいて、運用対応の時間(開発チームが使う時間)も決まっている。

開発チームがなるべく効果的に働けるようにするには、次のことを行う必要がある。

  1. プラットフォームを稼働中のシステムとして扱い、ダウンタイムを計画し管理する。
  2. ソフトウェアプロダクトマネジメントサービスマネジメントのテクニックを使う。

プラットフォームチームの主要顧客はプロダクトチームになる。

運用対応の時間を決め、インシデントやサポートの対応期限を定め、プラットフォームサポートのオンコールのローテーションを設定、適切なコミュニケーションチャネルを用意、インシデントや計画買いダウンタイムを管理を行う必要がある。

開発チームと定期的に話し合いを行い、何が必要かを理解しようとする。

機能の利用度合いをメトリクスとして追跡し、対話と優先度設定に利用したりもする。

モノリス

アプリケーションモノリス

多くの依存関係や責任を持つ単一かつ巨大なアプリケーションで、多くの錆巣やさまざまなユーザージャーニーを公開しているもの。

ユーザーはデプロイの間、アプリケーションを使えない。

本番環境相当の環境でテストしていたとしても、そのあと変わってしまっているため、予期せぬ問題に悩まされる。

データベース結合モノリス

同一のデータベーススキーマと結合している複数のアプリケーションやサービスから構成される。

それぞれ別々に変更、テスト、デプロイが難しい。

データベースをコアのビジネスのエンジンと考えている場合に発生する。

人手が足りていないことが多く、デリバリーにおける大きなボトルネックになる。

モノリシックビルド

新バージョンのために、単一の巨大な継続的インテグレーションでビルドを行う。

アプリケーションモノリスが、モノリシックビルドをもたらすが、小規模なサービスでも同じ問題は起こりうる。

コンポーネント間の依存関係を管理する標準的な仕組みを使うのではなく、コードベース全体をビルドするようなビルドスクリプトになっている場合。

モノシリックリリース

全てをまとめてリリースする

小さなコンポーネントをまとめてリリースする

サービスのモックは使わずに、共有の固定環境でしかテストできない場合

コンポーネントの最新バージョンをまとめて同一の環境に導入することになる。

コンポーネント一式をひとかたまりとしてデプロイすることで、テストしたものが本番環境でも実行されるという確証を得る。

QAチームによってテストを担当される場合もあるが、キャパシティが限られていて、複数のサービスの変更をまとめて行うことが理にかなっていると考えるため。

モノシリックモデル

単一のドメイン言語と表現(フォーマット)を多くのさまざまなコンテキストに強制的に適用しようとするソフトウェアのこと。

小さな組織では、チームが明示的に同意している場合であれば、この手の一貫性を重視するのは理にかなっている。

だが、組織内のチームやドメインが片手で収まらない数になると、意図せずアーキテクチャーや実装の制約になる可能性がある。

モノリシック思考

チームの「画一的」な考え方のこと。

技術面やチーム間の実装アプローチのばらつきを最小限にするための標準化をおこなう。

しかし、優れたエンジニアは新しい技術を学ぶことができるし、学習したがる。

そういった機会を単一の技術スタックやツールを強制し、チームの選択の自由を奪う。

仕事で適切なツールを使う能力に大きな悪影響を及ぼし、モチベーションを阻害したりもする。

モノリシックワークスペース

地理的に同じ場所にいるすべてのチームや個人に適用する単一のオフィスレイアウトのパターンのこと。

オープンプランオフィスがコラボレーションを促進するという通説もある。

だが、採用した2つの組織での調査の結果、それは否定されていて、対面でのやりとりが大幅に減少し、電子的なやりとりが増えたのだ。

それは、場所を同じにするだけでなく、目的を同じにすることによるものだ。

リスク

継続的デリバリーができているかにも大きく影響を与える。

疎結合のシステムアーキテクチャのもとで継続的デリバリーが実現できているのであれば、小さな変更を頻繁にデプロイするリスクは実際に減少する。

ユーザーの数によって許容できるリスクもある。

数百万の無料ユーザーと、数百人の有償ユーザーを仮定したとき

数百万人に影響のあるリスクは潜在有償ユーザーの損失が大きいが

数百人の有償ユーザーのみに影響がある場合、個別対応なども不可能ではないと考えると、優先度としては下がったりもする。

3つのチームインタラクションモード

以下の3つのインタラクションモードの組み合わせが多くの企業に必要。

1つのチームが2つの異なるチームに対して別のインタラクションモードを利用することもある。

どのチームがどのチームに対して、どのインタラクションモードをすれば良いか、何を期待されているだろうかということを意識するようにならなければならない。

それぞれの定義から書いて、それぞれの立ち振る舞いを書いていこうと思う。

定義

  • コラボレーション 2チームが一定期間密接な作業をすることで、新しいパターンや手法や制限を発見する。 責任は曖昧になるが、問題を素早く解決し、素早く学習を促進させる。

  • X-as-a-Service 一方のチームが別のチームから「サービスとして」提供されたもの(サービスやAPIなど)を使用する。 責任は明確に定義されている。利用する側のチームはすばやいデリバリーが可能になる。 サービスの提供者はいかに利用しやすくするかを目指す。

  • ファシリテーション 一方のチームが、別のチームが新しいアプローチを学習したり習得したりするのを一定期間支援する。 ファシリテーションを行う側のチームは相手チームを早く独り立ちさせることを目標として、ファシリテーションをされる側のチームは学習に対してオープンな態度を取る。

コラボレーションモード

イノベーションとすばやい探索を行う。

しかし、境界は曖昧である。

主に、やることとしては他のチームとの協業である。

新しいものをいち早く取り込み、他のチームへ展開する役割を果たす。

異なるスキルの人たちで構築されたチームによって運用され、さまざまな経験や知識を融合して、難しい問題解決にアプローチする。

他のチームへの学習を促すのもこのチームの役割である。

そして、チーム間の協力がほぼ全面的なのを示す。

異なるスキル感のチームが二つ存在していても、一つのチームとしてみなす。

重点分野と責任範囲の重なりが少ない場合でも、多い場合でも全体的なアウトカムに対して共同責任を負うことになる。

コラボレーションという行為が、責任境界を曖昧にするためだ。

そのため、コラボレーション中においては、認知負荷はずっと高くなる。

他のチームの学習において責任を伴う形で行う必要があるからだ。

これはオーバーヘッドが高くなることを示唆する。

しかし、新しいプラクティスを学ぶ機会にもなり、2つのチームのインタラクションを起こすことで、一緒に働くことにより有効性を高めることができる。

そのため、チーム間の摩擦は全くなくすか、極力少なくする努力は必要になってくる。

X-as-a-Serviceモード

あまり、手間をかけずに「まずは動く」コードライブラリ、コンポーネントAPI、プラットフォームを必要とするチームがいるという状況に適している。

他のチームに使われるような場合である。

システム開発の後期フェーズや、新しいアプローチの探索より、こちらのアプローチが必要とされる時期に効力を発揮する。

これにより、デリバリーチームは自分達の仕事のコアでない側面について理解する必要がなくなり、よりすばやいデリバリーを可能にする。

認知負荷の観点では、より低いものになる。

これは、優れたクリーンなAPIがあるためだ。

そのかわり、デベロッパーエクスペリエンス(DevEx)は非常に魅力的なものにしなければならない。

提供されるサービスは、使用、テスト、導入、デバッグが容易である必要がある。

ファシリテーションモード

1つ以上のチームが、別チームから積極的に作業の一部をファシリテーションまたは、コーチしてもらう場合に適している。

主に、イネイブリングチームにより運用される。

他チームの支援と能力を提供し、生産性と有効性を高める助けとなる。

他チームが使用している既存のコンポーネントやサービスのギャップや不整合を発見することもある。

そのため、どちらかというと、主要なソフトウェアシステムや付随するコンポーネントやプラットフォームの構築は行わず、それぞれの構築を行うチーム間のインタラクションの品質に注目する。

チーム間のコミュニケーションを、システムが求めるアーキテクチャに基づいて定義し、明確化するのに役立つ。

必要なインタラクションモード

チームが達成すべきことによって、必要なインタラクションモードは異なる。

最終的には、特定の理由でチームインタラクションがコラボレーションとX-as-a-Serviceの間を行き来することを期待される。

そうすることで組織はアジリティを獲得できる。

多様なトポロジーと多様なチームインタラクションは、組織の各所での目的や状況に応じて、それぞれのタイミングで進化させなければいけない。

そのためには、「自分達は何かを発見しようとしているのか?」「どれくらいの速さで?」といった自問をしなければいけない。

組織のチームトポロジーは、数ヶ月にわたりゆっくり変化するのだ。

チームトポロジーの変化のきっかけ

兆候としてあるのが以下 - スタートアップ企業が成長し、15人を超える - 1チームの変更により、他のたくさんのチームが長く待たされる - システム内の特定のコンポーネントやワークフローへの変更は、多忙だろうと不在だろうと、いつも決まって同じ人に割り当てられる。 - チームメンバーはドキュメントの不足に不満を持っている。

これは「今優先すべき仕事は何か」ではなく「分かっているのは誰か」に計画が左右されることによる兆候になる。

これが常態化すると、個人のモチベーションに悪影響を与える可能性がある。

そして、結果としてシステムの大きさやコードの大きさが、大きくなりすぎていることに全体像を把握しきれなくなって初めて気が付くようになる。

また、兆候としてあがる側面に

  • デリバリーのリズムが遅くなり始めている

ということがある。

  • リリースに時間がかかるようになった
  • チームのベロシティやスループットのメトリクスが、1年前と比べて明らかに低下しているという現象
  • デリバリープロセスについて、メンバーが手数の多さに不満が出てくる

モダンでハイパフォーマンスな組織になる3つの方法

  • システム思考: 組織のごく一部だけでなく、全体の早いフローを最適化する
  • フィードバックループ: 運用部門からの情報と指導による開発
  • 継続的な実験と学習の文化: すべてのチームインタラクションに対するセンシングとフィードバック

OpsとDevの強力なコミュニケーション経路に依存する。

つまり、OpsとDevを同じチームに配置するか、少なくとも同じ変更ストリームに沿って仕事をしているストリームアラインドチームにペアを組ませて、運用上のインシデントにスウォーミングさせること。

まとめ

この本には、すごく丁寧に各チームと機能や振る舞いの説明があった。

かなり大きな組織になっていかないと適用が難しいようなところもあるかもしれない。

それこそ、何チームにも渡って一つのサービスを運用し、これからの拡大を行なっていく見通しを立てるには良いかもしれないが、まだ100人規模などの組織、かつ開発チームも1つか2つといった状況下ですぐに適用できるかと言えば、そこまでな気がする。

しかし、チームがどうあれば良いか、どういうフェーズでどういう動きが求められるかなどの考えを知っておくことは、今後組織を形成する際の参考にはなるだろうと思う。

チームビルディングの一つの基盤としての考え方には、すごく寄与するのではないかと感じた。

アジャイルサムライ

概要

アジャイルでの開発が多くなってきて、アジャイル開発であったりスクラムが組まれるということも多くなってきたこともあり、ちゃんと学んだ方がいいなと感じたところが始まり。

アジャイル開発の中でさまざまな用語が飛び交うのと、その用語の持つ役割を適切に運用に回せるようになることを目的として、勉強を始めた。

実際今の現場でもスクラムを採用しているが、やはりどうしてもスクラムに定義されているようには適切に回すことができていないように思える。

一部難しい部分もあるとは思うが、まずは下地をということで、人気の高い当書を選んでみた。

スクラムアジャイルの一つの具体的なフレームワーク

  1. 計画の立て方
  2. うまくいっている度合いを測る方法
  3. 3つの真実を受け入れることの効果

3つの真実

  • プロジェクトの開始時点に全ての要求を集めることはできない
    • 情報が出揃っていなくても進める必要がある
  • 集めたところで、要求はどれも必ずといっていいほど変わる
  • 起きた変化を受け入れ、変化に応じて計画を変える
  • やるべきことはいつだって、与えられた時間と資金より多い
    • やれることをやるだけ。与えられた時間とリソースを超えたToDoリストを前にしてもプレッシャーを感じなくなくなる。

やること

  • 大きな問題は小さくする
  • 大事なことに集中して、それ以外を忘れる
  • ちゃんと動くソフトウェアを届ける
  • フィードバックを求める
  • 進路を変える
  • 成果責任を果たす

アジャイルでは、開発工程が他の工程から独立して行われることはない

アジャイルでは、役割は分担されていない。プロジェクトの成功に寄与することはなんだって協力する。

人は自分の得意分野にこだわりすぎる傾向がある。そのため、細かい定義は容易しない。

そして、品質に責任を持つのはチーム。 not 品質保証部門。

そのため、メンバーは開発工程のそれぞれを密接に連携しながら、日々の作業を進めていく。

やるべきこと

  • 同じ場所で働く

プロジェクトを始める段階でメンバー全員が集まれるだけの旅費と予算を確保し、たった数日でもその期間を用意すること。

最初が肝心。

これさえできれば、あとはオンラインでもなんでもなんとでもなる。

  • 顧客の存在

積極的に関わってくれる顧客の存在が大事。

顧客が積極的に関わらないプロダクトは犯罪的と思って良い。

プロダクトにふさわしい人材が関わらないで、どうやってそのプロダクトを魅力的にしていけるのか。

積極的に関わってくれる顧客がいない場合

2週間で何かしらのお客様の課題を解決しますと宣言するところから始める。

あとは、どうやってその問題を解決したかを報告するかを考える。

これを繰り返すことで、3回、4回目くらいには自分の姿がお客様から見て変わっているものになっているだろう。

そうすると、頼り甲斐に感じてもらい、積極的に関わってもらいやすくなる。

いろんな理由で関わりたくないお客様は存在する。

しかし、お客様との信頼関係を築くことが大事になり、頼りにしてもらうことが近道なのだとしたら、信頼貯金を増やすところから始めるというのが一番良い方法になる。

自己組織化

アジャイルチームは、目標を与えられると、それをどうやって達成するかを一歩下がった視点からみんなで客観的に考える。

そのためには、自己組織化されていることが条件となる。

自己組織化とは、自らのエゴを押し出し過ぎないように気をつけながら、チームで力を合わせるということ。

そのとき、それぞれのチームの一員として(各人のスキルと情熱と資質を発揮しながら)、どう振る舞えば最善の成果をお客さんに届けられるかを考え抜く必要がある。

人に合わせて役割分担を決めていくことが重要で

テスターにプロジェクトマネジメントを期待するとか、開発者にデザイナーになれという話ではない。

自己組織化するには

  1. 自分達で計画を立てる。見積もりも自分達で作る。自分達のプロジェクトだという意識を持つ。
  2. テスト済みのちゃんと動くソフトウェアを提供し続けることにこそ心を砕く。
  3. 自分から動ける人を探す。自分の運命は自らの手で切り開こうとする人が良い。

成果主義と権限委譲

しかし、全員が全員自己組織に合わせた人間という訳ではない。

言われた事を淡々とこなしていくことの方が楽なのに、どうしてそんな自分から権限を委譲されにいくかと疑問に抱く人もいる。

それはそれで終わりかと言われれば、そうではなく

お客さんの前でデモをしてみせることで、自分たちのソフトウェアに期待している人が実在することに気づくことになる。

この実感による効果は非常に大きいものになる。

一度でもデモに失敗すると、ちゃんと次からは動くものを用意し、フィードバックを得る準備を整えられているかに気を配れるようになる。

職能横断型チーム(Cross-Functional Team)

顧客の要望に最初から最後まで応えられる開発チームのこと。

そのためには、開発チームに適切なスキルと専門知識が備わっていて、顧客が必要とするあらゆるフィーチャをきちんと届けられる必要がある。

一般的にはゼネラリストが望ましい。

役割分担

アジャイルチームにおける、メンバーに対して役割のようなものは存在しない。

その役割によって果たされる仕事が、チームの誰かによってちゃんとこなされるようになっているかどうかだけに気をかける必要がある。

アジャイルなアナリストは、フィーチャー実装にあたって、どうやって実現するかを誰かがしっかりと詳細まで調べ上げねばならない。

顧客の必要とするものを徹底的に洗い出し、実装に向けてプロトタイプやデモ、技術調査など、なんでもするような立ち位置。

アジャイルプログラマは、質の高いソフトウェアを生み出すことに心血を注ぐプロフェッショナル。

テストやリファクタリング、CIなどを通して実現を行う。

何を作るかをはっきりさせ、できるだけシンプルに実現する。

アジャイルなプロジェクトマネージャは、プロジェクトを成功させる唯一の方法は、開発チームを成功させることだと心得ている。

断続的に計画を立てていくこと、立てた計画を見直す、必要ならプロジェクトの方向性を調整することも含む。

アジャイルな○○

アジャイルなプロジェクトマネージャ (p35)

開発チームの障害を取り除くためなら地の果てまでも行きかねない。

上位のプロジェクト関係者に、開発チームに期待できることをマネジメントするのもアジャイルマネージャの仕事。

ステークホルダーへ状況を報告し、社内の人間関係を円滑にする。

チームを外圧から守る盾となる。

アジャイルなUXデザイナー

UXはプロダクトの価値を顧客に届けることにおいて、分析やUXデザインの分野で腕を振るってくれる。

イテレーションを通じて少しずつ積み重ねていくことにためらいがない。

全てを作るのではなく、フィーチャを実装するタイミングに合わせて少しずつデザインしてくれる。

インセプションデッキ

プロジェクトがダメになる

スタート時点で、話し合うことすらやっていないため。

まずやるべきこと

  • ゴールやビジョン、プロジェクトの状況や背景についてチームでよく話あっておくこと。そうすことで、チームは状況に応じて適切な判断を下せる。
  • ステークホルダーに情報を提供すること。彼らにはプロジェクトを続けるかどうかを決断するための材料が必要。

手強い質問をする

初期であれば、間違っていろんな質問をする余地がある。

あけすけな質問をすることもできる。

例えば - どれくらい経験を積んでいるチームですか? - では、あなた自身はこの手の仕事の経験はありますか? - ご予算はどれくらいですか? - このプロジェクトを統括するのはどなたですか? などなど

この質問に答えるために、インセプションデッキがある。

インセプションデッキとは

プロジェクトを革新まで煮詰めて抽出した共通理解を、開発チームだけじゃなく、より広範囲なプロジェクト関係者全員(いわゆるプロジェクトコミュニティ)へ手軽に伝えるためのツールだ。

プロジェクトに関わる人は全員参加する資格がある。

インセプションデッキの課題の成果をパワポとかで出すと、このプロジェクトは何であって、何でないのか、価値を届けるためにどこに力を注ぐべきか。などなどがわかってくる。

そして、ステークホルダーを巻き込むことが重要になる。

インセプションデッキの課題一覧 - 我々はなぜここにいるのか? - エレベーターピッチを作る - パッケージデザインを作る - やらないことリストを作る - ご近所さんを探せ - 解決案を描く - 夜も眠れなくなるような問題はなんだろう? - 期間を見極める - 何を諦めるのかをはっきりさせる - 何がどれだけ必要なのか

エレベーターピッチ

エレベーターピッチの由来は

今まさに乗ろうとしているエレベータに一緒に乗ろうとしているのが、3ヶ月前からどうにかして会いたいと思っていたベンチャーキャピタルの関係者であったら、まさにその間の30秒の間に、新規事業について説明ができるかどうかで資金援助が決まってしまうという状態で、エレベーターに飛び乗るようなところから来ている。

つまり、短い時間でアイディアを伝えることが重要になってくるのだ。

そして、これは実際のエレベーターピッチのテンプレートにするとわずか2行になる。

主に以下の様な形で作られる。

・[潜在的なニーズを満たしたり、抱えている課題を解決したり]したい ・[対象顧客]向けの、 ・[プロダクト名]というプロダクトは、 ・[プロダクトのカテゴリー]である。 ・これは[重要な利点、対価に見合う説得力のある理由]ができ、 ・[代替手段の最右翼]とは違って、 ・[差別化の決定的な特徴]が備わっている。

というような形式で作られる。

この時の注意点が、基本的にこれは外部の人間、つまりプロダクトに詳しくない人間に向けて作られる言葉になる。

なので、フィーチャを想像して書くのではない。

効能を伝える必要がある。

つまり、エンジンのフィーチャを「245馬力エンジン」と伝えても響かない。

高速道路でも楽々追い越し などの言葉に言い換えることで相手は理解することができ、どこでそのプロダクトを使うことができるかイメージすることができるのだ。

建設現場のエレベーターピッチを作るとしたら以下のようになる。

・[建設現場の作業を把握]したい ・[現場責任者]向けの、 ・[CSWP]というプロダクトは、 ・[危険作業許可証発行システム]である。 ・これは[作業許可証を申請・追跡・監査する]ことができ、 ・[現行の紙ベースのシステム]とは違って、 ・[ウェブ経由で、いつでもどこからでも利用できる機能]が備わっている。

チームを選ぶことはアーキテクチャを選ぶこと

大きな金槌を持っていると、何もかもが釘に見える。

データベースに強いチームは重い処理をとにかくSQLに任せようとするもの。

オブジェクト指向に強いチームは、複雑だと感じた処理ならなんでもオブジェクト指向で解決したがる。

このように、チームの強みによって戦略が決まってきてしまう。

技術的な得意分野を早めに表明しておくのは大事なことである。

リスク

ブルームバーグによると、全てが順調にいくことなどありえない。完璧な計画などないというものである。

しかし、それにも慣れなければならない。

何が起きるかわかっているものもあれば、わからないものもある。

分からないものに対しては、起こってから対応するしかない。

そのため、リスクについて話す必要がある。

これは、人によっては臆病者に思われるので、飛ばして進めたくなる人も多い。

しかし、プロジェクトを成功させるために何が必要かをみんなが納得していくにあたって、とても大切なプロセスになる。

プロジェクトの重要要素

  • 品質
  • 時間
  • スコープ
  • 予算

対応策 - スコープを削る - もっと人を増やす - リリース日を延期する - 品質を犠牲にする

アジャイルサムライは

時間と予算を固定する。

時間は有限で、お客さんに届けられる価値が遅れれば遅れるほど、何も提供できなくなるという最悪の事態に陥る。

予算も有限であり、利用可能な資源が潤沢ということはないので、スポンサーから集めるしかない。しかし、気の進まぬ仕事ゆえ、この予算を固定に決めることで避けるようにする。

品質は、時間と引き換えに犠牲にしがちだが、それはお門違いになる。品質なくして成立するものはないからだ。

故に、アジャイルサムライは品質も固定として扱い、常に高い水準を保ち続けようとする。

スコープのみ、唯一動かすことができるものとして残る。

やることが多すぎる時、それを減らすということを行う。

アジャイルサムライは、計画を変え、現実を変えない。

ユーザーストーリー

ユーザーストーリーは、顧客がソフトウェアで実現したいと思っているフィーチャを完結に記述したもの。

インデックスカードと呼ばれる小さめのカードに書く。(何でもかんでも書き出そうとするのを抑制するため)

完結にしかインデックスカードにしか書かない。

これはチームへの戒めのために使う。

フィーチャーの本質を捉えるキーワードを書き留めておく。

書いた段階ではそれが本当に必要なものかまだ分からないためである。何ヶ月も先になったころにはソフトウェアも見間違えるほど変わってるかもしれない。

本当に必要になった時に、思い出せるほどのキーワードを書いておくだけで良い。

よく書けているユーザーストーリー

顧客にとって何かしらの価値が書かれていること。

どういうことか

ユーザーストーリーはビジネスの観点から評価できないといけない。

お客さんに理解できるシンプルな言葉づかいでユーザーストーリーを書くことを心がけるのもそのため。

例えば

データベースにコネクションプールを導入する

ではなく、

現状の10秒かかるページの読み込み速度を、2秒まで縮める

などなど。

end to endで書かれている事が必要とされる。

ユーザーストーリーを作るために

顧客へのインタビューで得られた情報を基に、必要なユーザーストーリーを作ってみる。

例えば次のようなものが期待される。

  • 次回のセール品の一覧
  • 地元のサーフィン大会の結果の掲載
  • 今後のイベントやサーフィン大会の一覧
  • ウェブカメラでビーチの様子を配信する
  • サーフィンレッスンとその料金を表示する
  • 中古のボードや装備の販売コーナー
  • ウェブサイトはサクサク表示する
  • デザインはかっこよく

この時、下2番のストーリについてはテストがしにくいものになる。

ではどうするか

  • サイトのページはどれも2秒以内に読み込めること

などと置き換えてみる。

ユーザーストーリーを作るためのテンプレートは以下のようになる。

誰の ためのストーリーで

何を したいのか

なぜ そうしたいのか

アジャイルの進め方

  1. インセプションデッキを作る
  2. プロジェクトの最初の手強い質問をする
  3. プロジェクトの方向性をプロジェクトみんなで考える
  4. インセプションデッキによってスコープ設定やプロジェクトの期待マネジメントができる
  5. プロジェクトの基本的な考え方やスコープ、存在意義が変化したら、再びインセプションデッキを更新する。全員でチームの向いてる先と、プロジェクトの理解が揃っているかを確認する

見積もり

アジャイルにおける初期の見積もりは、ひどい当てずっぽうのようなもの

結論から言うと、前もって正確な見積もりなどは無理に等しい。

では、何を前もって得られるか

  • 今後の計画を立てられる
  • 見積もりは当てずっぽうだという前提を踏まえている
  • ソフトウェア開発の複雑さを認めている

しかし、プロジェクト初期段階で予算を決めたりしなきゃいけない状況で、あまりにも当てずっぽうでは不都合が生じる。

そのため、

  • ストーリーそれぞれを互いに相対的なサイズで見積もる
  • ポイントをもとにして進捗を追跡する

を行う。

相対的にタスクの大きさを見て、ストーリーを見積もる。

クッキー1枚を食べるのに10分かかるというのを1というポイントとしたら、その2倍は20分かかりポイントは2になる。

と言ったふうに。

ここで重要なのは、1ポイントは1営業日と考えないということだ。

あくまで、目安の基準という考えで

あるタスクを3日と見積もっていたが、実際は4日かかったとなれば、全てのタスクを1.3倍しないといけないかというとそうではなく

あくまで基準なので、ポイントとして定義し絶対的なものではないという認識を持つ。

日数

ここで問題になるのは、ストーリーは日数ではないか?

「クッキーを1枚食べるのに10分かかる」 の10分は時間だから、どう扱えばいいの?という疑問が出る。

しかし、ここに関しては、人によって日数で見積もりをする人もいて、それが分かりやすいという人もいるが

実際には、例えば1日と見積もったが、それは8時間フルで集中できた時の見積もりだろうか?

実際にはミーティングが入ったり、集中できない日もある。

そう言った場合結局曖昧なものになってしまう。

それならポイントで見積もる方が、あなたの理想の100%集中できる日と隣の人の理想の100%集中できる日などで考える必要がないからだ。

見積もり技法

三角測量

代表的なストーリーをいくつか基準として選出して、残りのストーリーを、基準になるストーリーとの相対サイズで見積もるやり方。

そのためには、

  • 論理的にまとめられるタスクがあるか
  • エンドツーエンドになっているストーリーがあるか(アーキテクチャ検証に最適)
  • プロジェクトを象徴するような代表的なストーリーがあるか

を確認する。

そうして、タスクに対してストーリーポイントをつけていく。

同じストーリーポイントだとしても、実際に実装してみると難易度が異なっていたということもありうる。

そうしたら再設定を行うのが良い。

しかし、相対的なサイズの定め型がそれなりに適切な場合だとすると、そのままにする方が良い。

毎回再見積もりをしていては、チームのベロシティを図ることが難しくなり、計画づくりがややこしくなるからだ。

そのため、未知なタスクが生まれてきた場合は、「スパイク」を用意すると良い

スパイク

未知のタスクに対して、調査などを行うためのタスク。

より見積もりを精密にすることを目的とするタスクになる。

プランニングポーカー

見積もりゲームと考えるとわかりやすい。

開発メンバーが、それぞれひとつひとつのストーリーをまず自分自身で見積もる。

そうしたら、メンバー同士で見せ合って、チームとして統一した見積もりを出す。

そこで一致すれば終わりだが、食い違いがあればその違いについて話し合ってメンバーそれぞれが再び見積もる。

合致するまでそれを繰り返す。

注意点として、投票システムではないということ。

3人の新米経験者の見積もりが、1人の熟練経験者の見積もりに「勝つ」仕組みではない。

ベロシティの測定

期日固定

リリース日を固定にして決定する。

チームにある程度の緊張感が生まれる。

リリースに間に合わせるためのスコープの調整を行う必要が出てくる可能性がある。

フィーチャーセット固定

フィーチャーを固定し、リリース日を調整するようにするやり方。

しかし、スコープを柔軟にしておくという考え方は依然として有効。

プロジェクトが進むことで新たにわかることがあるフィーチャーはあるからだ。

ただ、こうしておくとチームが届けなくてはいけないフィーチャーセットを意識することがしやすくなる。

そのため、可能な限り期日を調整することを行う。

バーンダウンチャート

チームがどれくらいの速度でストーリーを実装しているかをひと目でわかるようにした図のこと。

以下4つの視点からバーンダウンチャートは有効

  • どれだけ仕事を完了させたのか
  • どれだけ仕事が残っているのか
  • チームのベロシティ
  • いつ頃すべてを完了させられそうか

バーンダウンチャートの縦軸は残っている作業の総量になる。

横軸は時間を表す。

この時の線の傾き(イテレーションでチームが完了させた作業量)がチームのベロシティになる。

バーンアップチャート

基本はバーンダウンチャートと同じだが、上に向かって積み上がっていくところが異なる。

途中でスコープが広がってしまった場合には、それがすぐに分かるのが特徴。

バーンアップチャートの方がプロジェクト期間を通じたスコープの変動を追跡しやすい。

アジャイルを支える技術

アジャイル開発を支えるエンジニアリングのプラクティスの紹介

それぞれ、細かく設計されていて、一つ一つが本になるボリュームなので、ここではサラッとだけ記載。

ユニットテスト

ビルドしたコードがちゃんと動くことを示す方法

リファクタリング

コードをシンプルでクリーンな状態に保ち、読みやすくするための技術

テスト駆動開発(TDD)

複雑さに立ちむあかうための設計技法

断続的インテグレーション

決まった間隔ですべてを統合し、プロダクトをリリース可能な状態を保ち続ける取り組み