■

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である

を読みました。
中島さんの

エンジニアとしての生き方　　IT技術者たちよ、世界へ出よう！ (インプレス選書)

はすごい感銘を受けたのですが、今回の内容は、ちょっと一般的に書きすぎているような気もしました。え？オブジェクト指向ってそうだったっけ？って使い方も出てきました。

エンジニアとしての生き方　で、すでに早起きスタイルは書かれていたので私も実践しています。
毎日3時起きです。
違う点は、ロケットスタートの開始点ですかね。
著者は寝る前にTODOリストを整理して、起きた瞬間からロケットスタートと図的には書かれています。（顔洗ったりしないのだろうか？）

私は3時からTODOリストを整理します。
その後、自分の時間。
出社してからがロケットスタートになります。

自宅でも仕事ができる環境であれば、前者でもいいと思いますね。忙しいときは実はやってたりしますね。モデル部分の実装は家でもできたりするので。

少し気になったのが、22:30-04:00の生活において、夜ご飯に晩酌しないのかな。
お酒が入ると起きづらいと思います。少なくとも私は。お酒一缶につき30分遅れるようなイメージ（笑

私はだいたい3時に起きる習慣になってしまっています。
確かにこのスタイルはすでに2年経っているので、習慣化する66日を経過しています。

また、朝の洗濯・洗濯干しや、朝ごはん作成、ゴミ収集などがある場合、仕事ばっかりは出来ないですよね。。

現在は夫婦共働きも多いと思うので、上記家事全般は夫婦で負担するべきかとは思います。

私の場合は21時に子どもと一緒に就寝すると決めているので、21:00-03:00の生活です。
03:00-05:00までが自分の時間で、うち30分を、その日の仕事を効率良くこなし17:30に必ず”定時退社”するための段取り検討用時間と定めています。
残り1時間半は本を読んだり、コードを書いたり、新しい技術を試したり、最近ではリーンを学習しています。


ビル・ゲイツたちに囲まれた裁判は緊張感伝わってきて面白かったです。
その3分で今まで数年かけてきたOS実装をあっさり「キャンセル」できるのは、すごいですよね。日本企業だったら数ヶ月いや、1年ぐらいかかると思います。
この判断は、部下の生産性にもろに響いてきますからね。

エンジニアとしての生き方には、Windows95でサードパーティ製のアプリを実行後にWindowsがメモリいじくって動かせるようにした功労者、という書かれ方をしてたのですが、
まさかWin95のプロトタイプもしていたなんて、右クリックからのコンテキストメニューやD&Dも実は中島さんのアイディアだったなんて…、びっくりしました。

MBWA(Management By Walking Around)歩きまわることによるマネジメントとウロウロスクラムマスター

MBWA(Management By Walking Around)とは、歩きまわるマネジメント、簡単に言うと、「マネージャーが現場をウロウロする」ということです。
これは非常に理にかなっています。
なぜなら、現場のことは現場が一番知っているからです。席に座って報告を待っているだけのマネージャーはダメで、自ら情報を取りに行く(pull)必要があります。
MBWAはそのことを端的にあらわしていると思います。
優れた成果を出すためには、最高のチームが必要です。最高のチームは、人間関係が良好で最高のコミュニケーションが取れます。
それには対話を通じたマネジメントが必要です。文書（電子メールも含む）より、対話をより重視しないといけません。
現場を歩きまわり、メンバーと対話をし、状況を確認するのです。メンバーとの関係が非常に蜜になります。メンバーはマネージャーが気にかけてくれていると安心します。
報告の場などを設けるのは時間の無駄です。報告のための資料を作る必要があります。資料をつくる役割を作る必要があります。 報告の時間が必要になります。報告後の指摘に対してさらに資料を作る必要があります。これこそ負のループです。
何の利益も生み出さない、身の保身でしかないのです。
「私はうまくやっていました。メンバーを管理（コントロール）していました。」これでは何の意味もないのです。
賢明なマネージャーはそのことを熟知しています。
日本では階層構造の組織が多いと思います。社長-部長-課長-係長・・・。この場合、CEO配下すべてのマネージャーが同一の意識を持たないとダメです。
例えば部長が報告を求めるなら、課長は報告をせざる得ず、その配下はすべて報告を求められることになります。うまくクッション出来るなら良いのですが。



MBWAスタイルのマネージャーは優れた米国企業では普通のことのようです。
マイクロソフトのプロジェクトマネージャーだった方の非常に参考になる良書があります。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

真のマネジメントとは、「メンバーを解放すること」です。メンバーに自律的に仕事をして頂き、何かあった場合の尻ぬぐいはマネージャーがする、ということです。マネージャーとはそのためにいるのです。

最高のリーダー、マネジャーがいつも考えているたったひとつのこと

それには「任せる勇気」が必要になります。マイクロマネジメント型のマネージャーは気が気でないかも知れません。
任せる勇気を持つためには、メンバーが自律的に仕事を進められる環境を用意する必要があります。
自律したチームは最強です。たとえ、チームが困難な状況にあっても立ち止まらなくなります。
マネージャーは、ただそんなチームやメンバーを信じて支援するだけです。

サーバント・リーダーシップとも呼ばれます。

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

これはまさに、スクラムにおけるスクラムマスターの役割です。
プロジェクトマネージャーであっても同じようなことが言えると思います。
良いスクラムマスターは、現場をウロウロします。ノートパソコン等の電子機器は持ってない。ペンと付箋紙を持ってウロウロします。
ウロウロマスターと呼ばれるくらいになると、いいかも知れません。

よくホウレンソウ（報告・連絡・相談）ということを言われますが、報告はいらないんじゃないかなぁと思います。
レンソウでいいんじゃないでしょうか。連絡と相談です。
報告なんかさせないで、欲しい情報は自ら取りに行きましょう。「欲しかった情報以上の何か」が得られると思います。
トヨタのA3であっても、とにかく現場を見に行くとあります。やはり強い企業はそうゆう思考なんですよね。
「お前、あの現場に行ったか？俺はこの前行ってきたぞ」

トヨタ式A3プロセスで仕事改革―A3用紙1枚で人を育て、組織を動かす

一度、最高のマネージャーの元で働いてみたいなぁ。
仕事がすごい楽しくなるのだと思います。会社に来ることが楽しくなる。

「毎日会社にきて、仕事がしたくてたまらないんです！超楽しい！」

もし、メンバーにそう言われたら、あなたも最高のマネージャーの一人なのかも知れません。

スクラムチームのワーキングアグリーメントとコンセンサス（合意）

ずっと考え続けていた。

 

認定スクラムマスター研修にて、研修全体のワーキングアグリーメントを決める際、「決め方を決めてくれ」という話が出ていた。

そこにいた大勢の研修生は、多数決という方式をとった。

 

講師の江端（@ebacky）さんが言った。

「あなたたちは設計上の重要な課題を解決する際にも、多数決で決めるのですか？」

確かに、設計上の重要な課題を解決する場合、多数決では決めない。

 

ただ、研修はそのまま進んでしまった。多くの決定を多数決で決めていた。

認定スクラムマスター研修は、研修自体を生徒たちが作っていく形式だったため、生徒たちが決めたルールで進める。ルール自体に、もやもや感があっても、全員をうまく説得できないと、そのルールを変えられない。

 

民主主義云々という話もチラホラ聞こえたが、「そんなんじゃない。多数決は変だ。」と個人的にずっと考え続けていた。

（イギリスのEU脱退でホットな話題でもある。）

 

研修を受けたのは2015/08で、今日は2016/6/29だから、実に１年ぐらいずっと悩んでいたのだが、やっと答えがでた。

答えは身近なところにあった。

スクラムには、プロダクト・オーナーという役割がある。

プロダクト・オーナーは製品に関するあらゆることを決断できる役割だ。

 

つまり、プロダクト・オーナーを決めればよかったのだ。

 

プロダクト・オーナーがYESと言えば、YES。プロダクト・オーナーにYESと言わせる説得力を持った題材があればいい。スクラムにおけるチームはその役割だ。

多数決ではダメなのだ。民衆が誤っていると、誤った方向に流れてしまう。これは民主主義のデメリットだ。とくにマスコミ・メディアによって洗脳されてしまうと、大衆は違った方へ進む。

（テレビをつけっぱなしにしている家庭は洗脳されている可能性が高い）

（もちろん、マスコミもメディアも洗脳しようとしている訳ではないが、結果的にそうなっているから質が悪い）

もちろん、プロダクト・オーナーが狂っている場合は、ナチス・ドイツのような悲惨なことになるだろう。

プロダクト・オーナーとチームの健全な関係性は非常に重要だ。

 

この考えに至るには、

「トヨタ式A３プロセスで仕事改革」

トヨタ式A3プロセスで仕事改革―A3用紙1枚で人を育て、組織を動かす

を読んでp88にある下記のセンテンスから着想した。

 

コンセンサス（合意）

やるべきこと：　

　オーナーを認識する

　オーナーとは合理的アプローチを提示するもの。合理的アプローチは、

　　ー関係者全員の考え方と合理的な懸念を反映し、

　　ー関係者はオーナーの成果獲得への協力に合意する

 

やってはいけないこと：

　・無暗に一致団結を目指す

　・多数決、あるいは「私がやろうと思っていたやり方だから賛成する」という態度

 

考え抜け、ということだと思う。

個人的な、１年がかりの疑問も解消できた。

幸せの条件とアジャイル

人間の幸福は、人間関係で決まるという研究結果が出たようです。
友達がたくさんいてもダメで、深い人間関係にあり、信頼できる人がそばにいると、肉体的に苦痛でも精神的には幸せになれる。

50、60代でリタイアしてからも自分の外に人脈を作って、常に他の人間と関わっていくことが幸せの条件のようです。

やはり自分たちはなんでもすぐに手に入ってすぐに利用できるものを好みます。
しかし、人間関係というのはそうではない。
泥臭かったり、面倒臭かったりするわけですが、それでも人間関係が私達に幸せをもたらしてくれるというのは、非常に興味深いです。

人間同士のつながりを常に改善しつづける、アジャイルであることは、人間を幸福にする上でも大切な手法なのかも知れません。
…と無理やりアジャイルと結びつけてみました（笑

ZERO to ONE

Agile Japan 2016でSORACOMの玉川氏が薦めていた本を読んでみた。

AgileJapan2016

ZERO to ONE

ゼロ・トゥ・ワン　君はゼロから何を生み出せるか

スタートアップとは、君が世界を変えられると、君自身が説得できた人たちの集まりだ。

• 競争するな、独占せよ。競争は資本主義の対極にある。
• 独占するには、隠れた真実を見つけよ

隠れた真実には2種類ある。自然についての隠れた真実と人間についての隠れた真実だ。自然についての隠れた真実はいたるところに存在する。

最高のスタートアップは、究極よりも少しマイルドなカルトと言っていい。

コンピュータは人間を補完するものであって、人間に替わるものじゃない。

どんなビジネスにも答えを出すべき７つの質問。

1. エンジニアリング
2. タイミング
3. 独占
4. 人材
5. 販売
6. 永続性
7. 隠れた真実

5つか6つ答えられるだけでも大丈夫だろう。

所感

逆張り的な発想で、やはり成功する人は考え方が凡人と違う。競争するな、独占せよ、なんてなかなか思いつかないが、たしかに独占できるような 市場、技術力、営業力がないんなら成功なんて出来ない。言われると納得するが、言われるまで気づかない。それこそが隠れた真実。

NHKクリエイティブライブラリー

www1.nhk.or.jp

これ切ったり貼ったりしてつかっていいなんて、すごい宝の山のような気がする・・・！
受信料払っていて良かった・・・（笑

スクラムでプロジェクトを始める前にするべきこと

スクラムはじめようって何からはじめればいいの？

スクラムやりたい！
いきなりスプリント開始～！
なんてうまくいくはずがありません。
走りながらにも限界があると思いますし、途中で疲れちゃいます。
スクラムは、実は事前の準備が本当に大切です。スクラムガイドなどには謳われていませんが…。

ここでは、今までスクラムを導入したことが無い組織でスクラムを導入するための道標を記載してみました。
真っ白な状態からスクラムをやりたいのであれば、一番最初に スクラム・マスターが必要だと思います。 スクラム・マスターが、「スクラムやろうぜ」の発起人になっていないとうまく回らない可能性が高いです。 チームとプロダクト・オーナーをうまく導けないからです。

今までスクラムを導入したことが無い組織の場合、スプリントの開始までに、２～３週間ぐらい必要です。
ここで述べるのはあくまで私個人の経験・学習の結果からくるものですので、すべてマストではありません。
スプリントを始めてしまって、１スプリント目で様々な整合を取りつつ行う手法もあるとは思います。（大変だと思いますが…）

以下、おおまかなTODOリストになります。

1. プロダクト・オーナーとスクラムマスターを決める
2. マネージャー（経営層）を味方につけ、共有する。
3. チームメンバーを集め、スクラムの説明をする。チームがやりたがらない場合は、ここで終了。
4. ステークホルダーを味方につけ、共有する。
5. プロダクト・バックログ作成
6. ぼんやりとでもアーキテクチャを決める(後から変更可能）
7. リリースプランニングとリリース計画作成と共有
8. 想定される成果物を洗い出し、必要かどうかを確認する
9. チームは、完了の定義(Done of Definition)を検討し、プロダクト・オーナーと合意を取る。
10. スプリント計画作成（時間と場所の確保、集計方法検討）
11. スプリントの開始！

プロダクト・オーナーとスクラムマスターを決める

特にスクラムマスターはプロダクト・オーナーにスクラムとはこうゆうもんだと説明し、納得頂く。
プロダクト・オーナーがすでにスクラムに詳しい場合は割愛可能。
アンチパターンとしては、同一人物が兼任してしまうパターン。うまくいかないと思います。
そんなに甘くないです。スクラムマスターもやることは山積みです。

マネージャー（経営層）を味方につけ、共有する。

味方にできるかどうかは、マネージャーの性格や、組織文化にも依存しますので、非常に難しいとは思いますが、経営層の誰かを味方につけたほうがいいです。
理由は、優秀なチームメンバーや物資リソースを集めやすくなるからです。
ホワイトボードや付箋の調達や、どの壁を使っていいかなども相談する必要が出てきます。
また、困ったときに相談できる偉い人がいると非常に安心です。
Fearless Changeの経営層の支持者パターン(28)ですね。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

チームメンバーを集め、スクラムの説明をする。チームがやりたがらない場合は、ここで終了。

マネージャーを味方につけたら、こんなメンバーが欲しいと相談します。
チームメンバーの素養としては、

• 選択肢を与える力（代替案の提案）
• 実現力
• ちょっとした社交性

が必要かと思います。上２つは認定スクラムマスター研修で習いました。
スプリントレビュー等ではチームがプロダクト・オーナー含めステークホルダーにインクリメントを説明しますので、少し話せる人が必要かと考えています。

説明をした結果、チームがやりたがらない場合は、ここで終了です。
無理強いはよくないと考えます。結局うまくいかないです。
チームをやる気にできるかどうかはスクラムマスターにかかっています。

ステークホルダーを味方につけ、共有する。

これも非常に大切です。特にプロダクト・バックログ作成とスプリント毎のスプリント・レビューには出席して頂いたほうが価値のあるものが出来上がりやすいです。
海外ではどうか知りませんが、プロダクト・オーナーが全て一人で何でも決められるっていうのは日本だと考えづらいです。特に企業が大きくなればなるほどその傾向は強いと考えます。
プロダクト・オーナーに全責任を背負わせてしまい、病んでしまう可能性もあるので…。
もちろん、最終決定権はプロダクト・オーナーにありますが、プロダクト・オーナー自身が間違っていることに気づくためには、ステークホルダーの意見も大切だと思います。
なので、プロダクト・バックログ作成とスプリント毎のスプリント・レビューにはステークホルダーに出てもらって、ちょっとした議論も入り交えつつ
本当の「セレモニー」という形で華々しくやっていくと良いと思います。特別感を出しましょう。

また、ここで大切なのが、ステークホルダーにスクラムの価値をわかっていただくことです。
計画はあくまで計画です、とか、やるべきことはどんどん変化します、ということは腹を割って話したほうがいいと思います。

プロダクト・バックログ作成

プロダクト・バックログを作成します。
ペルソナを決めて、ユーザーストーリー・マッピング手法を使うと、ストーリーの全体像が見えます。

qiita.com

なるべく、ステークホルダーにも参加してもらいます。もちろん、チームとプロダクト・オーナーも一緒にやるのが良いです。
丸１～２日缶詰になれる場所で、大きな壁に向かってストーリーを貼っていきます。

ユーザーストーリーマッピングも非常に効果的ですが、巨大なストーリーの場合は、スクラム現場ガイドの２９章「巨大なバックログの見積もりと優先順位付け」に参考になる手法が書かれています。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

ストーリーのサイズと優先順位を４象限マトリクスにしてプロダクト・バックログを作成します。

プロダクト・オーナーは、受け入れ条件を作成し、チームと共有する。

プロダクト・バックログを作成したら、プロダクト・オーナーは、各ストーリーもしくはストーリーの束において、受け入れ条件を作成します。
ただ、この段階で詳細まで書いてしまうとあとからストーリーが変わったりすると意味がなくなるので、
優先順位が高く、ストーリーが小さいもの（近いスプリントで行うもの）の受け入れ条件を作成したほうが良いと思います。

ぼんやりとでもアーキテクチャを決める(後から変更可能）

この段階で優先順位が高く、細かいストーリーが揃っているはずです。
全体像から、ソフトウェアのアーキテクチャをチームと一緒にぼんやりと決めておいたほうがいいです。
もちろん後から変更可能ではありますが、スプリントが開始した時点でアーキテクチャどうしよう？となると
スプリントプランニング時に正確なタスク分割もできないので、スプリント内で動くものが出来る確率は非常に低くなります。
データベースが必要なのか、WEBなのか、ネイティブアプリなのか、ネイティブの場合はOSはMacなのかWindowsなのか…など。

リリースプランニングとリリース計画作成と共有

プロダクト・バックログが出来上がると現時点での総ストーリーポイントがわかります。
総ストーリーポイントと、１スプリントでどれくらいのベロシティが出せるかを仮定で良いのでチームと話してみましょう。
最低のベロシティと最大のベロシティが出ると、全部でどれくらいのスプリント回数が必要か、どのストーリーがいつごろ出来上がるかというリリース計画が立てられます。
（あくまで変わるという前提付きですが）
リリース計画に関しては以下に書きました。

kshimizu.hatenadiary.jp

想定される成果物を洗い出し、必要かどうかを確認する

組織の文化や、法規制等によって、必要な成果物があらかじめ決められているケースもあります。
その場合には、単に「動くソフトウェア(Potentially Shippable Product Increment )」以外にも成果物が必要な場合があります。
その辺りを洗い出しておいて、スプリントプランニング時にチームにインプットします。プランニングのタスクの一つになるので、ここで抜け漏れは結構厳しいです。厳密に行きましょう。（チームにどやされる（汗

チームは、完了の定義(Done of Definition)を検討し、プロダクト・オーナーと合意を取る。

成果物と似ていますが、スプリントプランニングで洗い出されるタスクの完了の定義を、プロダクト・オーナーと合意を取ります。
例えば、Unit Testの作成は必須、コードレビューは必ず行う、
定量的にいうと、コードカバレッジが80%以上とか、Unit Test Failが0件であるとか、テストケースが何件以上あるとか、
各ストーリーのユーザマニュアルの作成が完了しているとか、（必要であれば）設計書を記載している、そのレビューが終わっている、など各タスクやスプリントの完了の定義をプロダクト・オーナーと合意を取ります。
完了の定義はプロダクト・オーナーとの合意が必須です。

スプリント計画作成（場所と時間等、バーンダウン集計をどうするか。Excelのテンプレート探し）

スプリントを1～4週間どの単位で行うのかをチームと議論をして決めます。議論した結果プロダクト・オーナーとも合意します。
また、各セレモニーをいつどこで行うかを決めます。
例えば、2週間1スプリントであれば、以下の様なチャートを作るといいと思います。

スプリントプランニングは丸１日かけますが、１日で終わらないことも多々あります。予備枠を設けておくと安心です。

バーンダウンチャートはスクラムの必須要素ではありませんが、チームの進捗を見る上では便利なツールです。
作り方等は予め考えていたほうが良いと思います。
バーンダウンやチケットはいきなり電子化しないことをお薦めします。
スプリントの振り返りでチームメンバーから電子化が必要だと出てくるまで待ったほうがいいと思います。
世界のスクラムマスターたちのディスカッションをまとめてくれたサイトがありました。
JIRAやTFSが優勢ですが、チームが必要だと思ったら、チームが導入するというスタンスで。

daipresents.com

さぁ、スプリントの開始です！

ここまでくるとやっとスクラムを開始できる土台が揃いました！あとは透明性・検査・適応を維持し、山あり谷あり、楽しくも厳しい旅の幕開けです！！