過去を忘れない事はマネージメントの仕事の一つ
最近仕事で実行している事として「過去の失敗を忘れないようにしておき、必要なタイミングで周囲に『過去にこんな事故があったけど今回は大丈夫だろうか?」みたいなリマインドをする」と言うのがある。
過去を忘れないようにするのは、長期的な展望を考える事と同じように意味があると思う。
やる事が一杯ある状況だと、長期的な展望とか過去とかについてじっくり考えられなくなりがちになるからだ。
ましてイテレーティブな開発スタイルだと過去と似たような場面が何度も登場するから一層効果的だ。
日々のトラブルを記録しておき、すぐに過去の失敗の詳細が思い出せるようにしておきたい。
なお、この時、過去も記憶しておきつつ、実際の再発予防も行おうとするとパンクしやすいので、再発予防は誰かに任せた方が良い。
関連:
納期優先の計画と工期優先の計画
昔、ある先輩マネージャーが教えてくれた興味深い話がある。
ある作業の計画を立てる場合に 「「納期」を優先して計画を立てる」 「「工期」を優先して計画を立てる」 という2つの考え方があるという話である。
2つの計画の立て方
納期優先
- 先に「この日までに完成させる」という「納期」を設定する。
- その後、ではそのためには何をすれば良いか? という考えを出発点にして計画を立てる。
工期優先
- 「これを完成させるには、AとBとCの作業で合計何日間必要」という見積もりを元に「工期」を設定する。
- 完成する時期は所与の条件として、戦略を立てる。
当然、納期優先で計画を立てれば計画の失敗リスクは高まる。
しかし、工期優先で計画を立てれば削れるはずの無駄な作業も含まれてしまうかもしれない。
なので、この両方の視点をもちつつ「今回はどちらに重点をおくか」と言うのをケースバイケースで判断していく必要があると思う。
危険なのは、納期優先で計画しているのに「今回は、リスクを取って納期優先で進めているんだ」という認識が欠けていたり、あるいは逆に工期優先で計画しているのに、それと意識せずに進めている場合である。
「今どっちを重視しているのか」は常に認識を持っておきたい。
余談
この記事では「工期」という単語を「タスクの完了までに必要なサブタスクを洗い出した上で、必要な期間を見積もって、バッファを加えたもの（≒普通に作業した場合に作業完了までにかかる期間）」という意味で使っている。
しかし、「工期」ってそういう意味だったろうか。辞書で軽く調べるとどうも意味が違うようだ。とにかくこの記事では上に書いたような意味で「工期」という単語を使っている。
領域に対する全体最適、時間に対する全体最適
はじめに
自身がマネージャーとしての仕事を(半分)行うようになってから、考えていることに
「マネージャーの仕事（やるべきこと）ってなんだろう」
というのがある。
今日は、その事について考えていた時の気付きについてメモを残す。
全体最適
マネージャーの仕事とはなんだろうか?
いろいろあるとは思うが、「チームが局所最適では全体最適になるように導く」というのは、重要な仕事の１つだと思う。
領域に対する全体最適 / 時間に対する全体最適
"全体最適"といっても色々あると思う。
たとえば、「スコープとスケジュールのトレードオフを検討する」と言うのは、マネージャーが良く遭遇する問題の１つだと思うが、
これは「スコープとスケジュールどちらを優先すれば全体として一番価値が高くなるか?」という全体最適の問題だとも言える。
他には、「今新機能の追加を見送って、保守コストが高くなっている機能のリファクタリングをするか、それとも保守コストが高くなっている事を許容して、新機能の追加を優先するか」というのも全体最適の問題の1つだと思う。
全体最適と呼ばれる行為は、おおむね以下の2つに分けられるのでは無いだろうか?
1. 領域に対する全体最適
- 異なる複数の領域の内、なにを優先したら価値が最大になるか? という問題。
- 例:
- スケジュールと品質とスコープどれを優先すべきか
- 例:
2. 時間に対する全体最適
- 短期と長期、どちらを優先したら価値が最大になるか? という問題。
- 例:
- リファクタリングと新機能追加とバグ対応のバランスをどうすべきか
- メンバーの学習と業務と休暇のバランスをどうすべきか
- 例:
まだまだ例がありそうだが、昼ごはんを食べる時間が無くなるので続きは今度考える。 また、なんだかトレードオフを前提とした話ばかりになってしまったが、それで良いのか違和感がある。が、これについても今度考える。
ジャングルと権限委譲
権限委譲: 意思決定権を渡す
上司が、自身の持つ意思決定権などを部下に渡す事を「権限委譲」という。
権限を委譲したジャンルについては、権限を委譲された部下が意思決定を行う。
権限委譲を行うことで以下のような効果が期待できる。
- 部下が、上司の判断を待たずに行動を開始できるようになる。（スピードアップ）
- 特定ジャンルへの専門性が高い部下に対して、そのジャンルの意思決定権を渡す事で、意思決定の精度が高まる。
- 部下が持つ仕事にたいする「所有感」が高まる。
委譲した権限は上司からなくなる
私は「権限委譲を行った事柄について、上司部下間で意見が対立した場合は、権限の委譲を受けた部下の意見が優先されるべき」と考えている。
もしそうしない場合、部下は自身の決定を上司に覆される可能性を考慮して行動するため、意思決定のスピードアップに繋がらないし、肝心な部分を自分で決められなければ仕事への所有感も増さないためだ。
意思決定を行う時に欠かせないもの
さて、このような形での権限委譲を行う時に、欠かせない物があると思う。
それは、上司部下間での価値観の統一だ。
あくまで全体の中の一部の権限委譲なので、全体との統一がなければ、全体として見た時に最適な意思決定にはならないだろう。
判断を任せるからこそ、判断の基準や価値観の統一が必要になると思う。
どうやって価値観を統一するか
では、どうすれば、上司部下間の価値観を統一できるだろうか。
これはあるベテランマネージャーがやっていた方法だが、権限を委譲したジャンルにおける課題について一覧を作成し、その重要度や解決の優先度について上司部下間で日頃から意見を交換するのが良い。
「今の業務にどのような課題があるか」や「なぜその課題が重要だと考えるのか」といった事について話すと微妙な価値観の違いが現れてくる。
たとえ話
ドラッカーが「ベトナムのジャングルにおける若い歩兵大尉へのインタビュー」として、次のようなエピソードを紹介している。
「この混乱した状況でどう指揮しているか」との質問に対する答えがこうだった。「ここでは、責任者は私である。しかし部下がジャングルで敵と遭遇し、どうしてよいかわからなくとも、何もしてやれない。私の仕事は、そうした場合どうしたらよいかを予め教えておくことだ。実際にどうするかは状況次第である。その状況は彼らにしか判断できない。責任は私にある。だが、どうするかを決められるのはその場にいる者だけだ」
Amazon.co.jp: ドラッカー名著集1 経営者の条件 電子書籍: Ｐ Ｆ ドラッカー, 上田 惇生: Kindleストア
判断の原則や基準の共有なくして、部下をジャングルに送り出せば、それは組織的な行動とは言えないであろう。
余談
私は上司／部下という単語が余り好きでは無い。単語の中に「上／下」という字が入っていて、上司／部下間に上下関係があるかのような感じがするからだ。
実際には上司／部下の違いはロールの違いにすぎないと持っている。
責任の権限のスコープが違うだけである。
この記事では、上司／部下とい単語を、
- より広い領域に対して責任と権限を持つものを「上司」
- より狭い領域に責任と権限を持つもの(その分専門性が高い)を「部下」
と言う意味で使っている。
上下ではなくロールである。
ハインリッヒの法則と日報
軽微な異常も放置するな
ハインリッヒの法則と言うのがある。
- 1つの重大な事故の背景に、30件の軽微な事故があり、その背景には300件の異常がある。
- 軽微な異常を放置しないことで、軽微な事故や、重大な事故をも防げる。
という経験則である。
この考え方にもとづいて、業務を改善していく場合に課題となる点がある。
「軽微な異常」は忘れてしまう
本当に間抜けに聞こえてしまうと思うが、
その課題とは「事故に繋がらない軽微な異常なんて忘れてしまう」と、言う点である。
スピード感が早い業務の場合、毎日なにかしらか対応すべき事が発生していて、
そういう状況だと異常が起きて「ヒヤリ」としたり「ハッ」としたりしても忘れてしまうのである。
「なんと意識が低い事か」という気持ちにもなるが、「人間そういうものだ」と言う前提で忘れないようにする仕組みを作っていく事が大切だと思う。
日報に記録しましょう
ここで便利なのが日報というツールだ。 「チャットに3行メモを貼る」というのでも良いので、とにかくデイリーで「どのような異常が起きたのか」という事を記録していき、 定期的（例えば1週間に1回とか）記録を振り返って改善を行うように、制度なり文化なりで担保しておく事が重要となる。
意識が高いメンバーの"努力"によって担保されている物を、仕組み化（ルーチンワーク化とも言える）していくことが大切だと思う。
アジャイルなチームを設計する時に考慮すべき2つの制約
1. 最小イテレーションサイズ
イテレーションが短ければ短いほど製品の品質が上がる
イテレーションが短ければ短いほど製品の品質が上がる
例えば:
チームが受けられるフィードバックも、振り返りから得られる教訓も断然bの方が多いに違いない。
イテレーションにはオーバーヘッドが伴う
しかし、ここで考慮しなければいけない事がある。 イテレーションにはオーバーヘッドが伴うということだ。
スプリント計画にもスプリントレビューにも当然時間がかかる。 例えば、3日で1イテレーションを回そうとすると、ものを作っている時間がほとんど無くなってしまうのだ。
そういうわけで、1イテレーションの長さには「これ以上は短くできない」という下限が存在する。 それが最小イテレーションサイズだ。
最小イテレーションサイズを考慮すべき理由
この最小イテレーションサイズは、時として問題になる。 プロダクトへの新しいフィーチャーの追加を非常に短いスパンで行いたい場合だ。
たとえば、架空のブラウザ向けソーシャルゲームの運営を考えてみよう。
- このチームの最小イテレーション単位が1週間だとする。
- しかし、新規イベントのリリースは1週間ごとに行いたいとする。
このような場合、実際に動くプログラムを作成して、スプリントレビューを行い、フィードバックを受けて、軌道を修正するという機会が1回も得られない。
これだと厳しい。
しかし、最小イテレーションサイズの制約があるので、イテレーションをこれ以上短くする事ができない。
このような問題が発生する場合がある。
どうすればいいのか?
このような場合の解決策の1つとして、
「チームを複数に分割してパイプライン化する」という方法が挙げられる。
2つのラインで、交互にリリースを繰り返すようにすれば、
ごく単純に考えた場合では、イテレーションのサイズを変えずに、倍のペースでリリースできる。
※リ = リリース
非常に短いスパンでの開発が必要な場合には検討すべき方法だと思う。
まとめ:
イテレーションのサイズには下限があり、その制約はリリース頻度の制約となる。しかし、チームをパイプライン化することで、その制約を緩和できる場合がある。
ただし、もし短いスパンでリリースを行わなくてもユーザーに価値を届け、収益を上げる事が可能であれば、それがそもそもの根本的解決かもしれない。
2. 最大自己組織化人数
アジャイルがもつ重要な要素として、「自己組織化」というコンセプトが挙げられる。
この自己組織化についても、（メンバーの資質に依存するところも多分にあると思うが、）「これ以上人数が増えると自己組織化できない」という上限があると考えている。
メンバーの人数と仕事量が増えると、コミュニケーションのパスが乗算で増えていくからである。
しかし、ある程度大人数が居ないとできない仕事もあると思う。
この問題については、今このようなアイディアを考えている。
チームを分割する指針として何が適切か - 宇宙は究極のフリーランチ
一言で言うと、「チームを分割してScrum of Scrumをしよう」という感じである。
これについては、今後実践の中でこの考え方が有効かどうか検証していきたいと思う。
会議のゴールをそのまま会議のタイトルにすると良い
「◯◯検討会議」とか「XXXキックオフ会議」では無く、
「◯◯を決める会議」とか、「XXXの作業に着手できるようにする会議」とする。
会議に参加する人全員が自然と会議のゴールを知っている状態になるので良い。 会議の冒頭でゴールを説明するよりずっと伝わりやすい。
同僚がやっていた。
命名はメッセージであり、コミュニケーションの手段であり、大切だという事例だった。
朝になったら自動で点灯するシーリングライトを買った
朝、周りが明るいと目がさめる。
朝になったら照明をつければ良いが、眠い状態で照明をつけるのが面倒なので自動で電気が付くようにしたい。
そういう時にオススメのシーリングライトがこちら。
毎日指定した時刻に勝手に点灯する機能がある。 数ヶ月使っているが大変快適。
時刻が30分きざみでしか指定出来なかったり、指定した時刻から微妙に前後した時刻に点灯したりするが全く大した問題では無い。 このページに詳しく書いてある。
マネジメントを兼任しているエンジニアにおすすめしたい本50冊
はじめに
自分は今、半分エンジニアをしながら、半分マネージメントに近いような事もするポジションで仕事をしている。
そう言う働き方をしている自分が、自分と同じような立場の人におすすめしたいと思った本を50冊ほど選んでみた。
4〜500冊くらいの中から選んだ(約)50冊なので、まあまあ選りすぐりの本といえると思う。
特におすすめ度が高い本には★印を付けてみた。
選書のヒントになれば幸いである。
選書の基準
エンジニアが持っている能力の中で、一番強力な武器はなんだろうか。
私は「モデリング(抽象化)」能力だと思う。
★印が付いている本は、 「現実の問題に対して、新しい方法のモデリングを行う事によって劇的な解決作を導き出す」というパターンの本ばかりである。 こういった解決方法こそエンジニアに向いていると思う。
おすすめしたい本50冊
新しいプロダクトを産みだす方法について
- ゼロ・トゥ・ワン―君はゼロから何を生み出せるか
- リーン・スタートアップ
ソフトウェア開発プロセスについて
- クリティカルチェーン ★
- アジャイルサムライ
- ラショナル統一プロセス“RUP”ガイドブック
- 世界一わかりやすいプロジェクト・マネージメント
マネジメントについて
- 最高のリーダー・マネージャーが考えているたった一つの事
- ドラッカー「マネジメント」 ★
- 採用基準
- 任せ方の教科書
社会について
業務プロセスを俯瞰し改善することについて
- リエンジニアリング革命
- インクス流! ★
- ザ・ゴール ★
組織設計について
- 組織戦略の考え方
- V字回復の経営 ★
戦略について
- 戦略と実行
- 戦略プロフェッショナル
- ストーリーとしての競争戦略
個人の仕事の進め方を見直したい時に
- レバレッジ時間術 ★
会議について
- デッドライン仕事術
- モダンミーティング7つの原則
思考を整理したい時に
- 技術の創造と設計 ★
- クリティカル・シンキング
- ファシリテーション・グラフィック
- ISSUEから始めよ ★
- ザ・ゴール2 - 思考プロセス -
- ゼロ秒思考
- あなたはコンピュータを理解していますか? 10年後、20年後まで必ず役立つ根っこの部分がきっちりわかる
分かりやすい文章について
- 日本語作文の技術
- 理科系の作文技術
よいプレゼンについて
ねむい時、やる気がでない時に
- 「脳力」をのばす!快適睡眠術
- 「朝がつらい」が無くなる本
- のうだま
デザインについて
- 誰のためのデザイン ★
- すべての人に知っておいてほしいWEBデザインの基本原則
- ノンデザイナーズ・デザインブック
- iPhoneアプリ設計の極意 - 思わずタップしたくなるアプリのデザイン
良いコードを書く方法について
- 良いコードを書く技術
- リーダブルコード
- コードコンプリート
- 実装パターン
- プログラミング作法
- テスト駆動開発入門
- レガシーコード改善ガイド
チームを分割する指針として何が適切か
はじめに
現在、私は、とあるソフトウェアプロダクトを開発する数十名規模のチームに所属している。このチームに対して適切な組織と開発プロセスを適用したいと思い良いスタイルを探している。
今日は、そういった事を考えている内に出てきた1つのアイディアについて書き留めたいと思う。
結論
先にどのようなアイディアなのか結論を書く。
- 数十名規模のチームにScrumを取り入れる方法として、Scrum of Scrumというスタイルがある。
- Scrum of Scrumで重要になるのは、各チームをどのように分割するかだ。
- 『単独で「ユーザーに届けるべき価値」を作れる独立したまとまりになる事』を指針としてチームを分割するのが良さそうだ。
- この指針には、チーム内のコミュニケーションをシンプルで密にし自己組織化を促進する効果がありそうだ。
Scrumの良さ
(うまくいけば)自己組織化が行われ、未知の状況に対する適応能力が高くなるのはScrumの良い点だ。
Scrumの課題
しかし多人数のチームにScrumを適用しようとすると色々問題も出てくる。
例えばデイリースタンドアップミーティングや、スプリント計画などを10名以上で行うにはかなりの困難だろう。
数十名規模のチームで、これを実践出来ているチームを見たこともあるが(驚異的だと思う)、そういう事が出来るチームを意図的に作り出す事は難しい事だし、長期的な取り組みが必要だ。
なにか、別の選択肢は無いだろうか。
解決策: 小さなチームの複合体にする
この問題について、DeNAのComm開発チームが面白い取り組みをしている。
Scrumを行う小さなチームを複数用意して、それらのチームのPOで更にScrumを行うという方法によって、多人数のチームにScrumを適応しているのだ。（Scrum of Scrumと言うらしい）
確かに、この方法ならScrumのスタイルを維持したまま、大規模な開発が出来そうだ。
"小さなチームの複合体"を実現するには
この"小さなチームの複合体"を実現するにあたっては、チームの分割方法が重要になると思う。
いや、今はScrum of Scrumについて書いたが、どのような開発プロセスであってもチームの分割は重要なテーマだと思う。
今のところ、たぶんこう言う事が重要になるのでは無いかと思っている。
- 「単独で「ユーザーに届けるべき価値」を作れる」そのために…
- 目的を持っている事
- 何をどういう順番で行うか決定する権限を持っている事
- 開発に必要な全ての機能を持っている事 (エンジニアだけ、とか企画だけ、では無い)
高凝集、疎結合であればコミュニケーションパスはシンプルで密になる。これは自己組織化を行うにあたって重要な点だと思う。
参考
この本に『「創って、作って、売る」小さなチーム』というコンセプトが登場する。
職能別の縦割り組織を、プロダクト別の"横割り"組織に変え、各プロダクトのリーダーに強力な権限を与えて自走性を高める事で、赤字事業部を見事に黒字化させる話だ。
この本で語られているコンセプトを参考に、この指針を考えた。
Amazon.co.jp: Ｖ字回復の経営 2年で会社を変えられますか 企業変革ドラマ (日経ビジネス人文庫) 電子書籍: 三枝 匡: Kindleストア
