「リーンスタートアップ」を読みました
確か『「ユーザーストーリーマッピング」を読みました - @ikikko のはてなブログ』でMVP(Minimum Viable Product)という言葉が出てきて、その言葉をもうちょっと確認したくて、この本を手に取ってみました。
- 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
- 出版社/メーカー: 日経BP社
- 発売日: 2012/04/12
- メディア: 単行本
- 購入: 24人 クリック: 360回
- この商品を含むブログ (94件) を見る
はじめに
- アントレプレナーはあらゆるところにいる
- 企業とはマネジメントである
- 検証による学び
- 構築・計測・学習
- 革新会計
上記のリーンスタートアップの5原則のうち、太字にした 3, 4 が今の自分にささってます。要するに、作りっぱなではなく、ちゃんと検証したり計測・学習しようねということだと理解してます。
第4章 実験
「とりあえず製品をリリースして様子を見よう」という方針で進むと、このような問題に悩まされがちだ。私はこの方針をナイキの有名なスローガンにちなんで「Just Do It(やってみよう)」型企業と呼ぶ。この方針に従うと様子を見ることには必ず成功するが、検証による学びが得られるとはかぎらない。失敗がなければ学びもないーそれが科学的手法の教えるところなのだ。
あー、やりがちだし分かる。「様子を見よう」ってのは、思考停止の兆候なのかもしれない。
「様子を見る」ってのは、つまり「何を検証したいか」・ひいては「どうあって欲しいか」というゴールをちゃんと考えきれていないということなのかな?ゴールがゆるふわな状態でのアクションは、結局そのアクションがゴールに結びついてるかどうか分からないという状態になりかねないと思ってます。なので、「様子を見る」というアクションは極力取らないようにしよう。
第6章 構築・検証
MVPに対して、「作り込みすぎたり約束しすぎたりという衝動をいかに抑える」ための実例が参考になった。エンジニア目線だとどうしても自動化・ソフトウェア化が一番のMinimumだと思い込みがちだけど、それよりもっと手前に、コンセプトに価値があるかを検証できる手段はあるよということ。
- 動画型MVP:Dropboxの実例
- 優れた体験をプロトタイプででも提供するのは困難と判断して、動画でコンセプトを説明
- コンシェルジュ型MVP:Food on the Tableという、自分や家族の好みに応じて1週間の献立と食材のリストを作ってくれるサービスの実例
- レシピ作成を最初からソフトウェアで自動化するのではなく、文字通り中の人として顧客の自宅まで出向いて欲しい献立を対面で確認して、それをもとにレシピを手動で作成
あとは、品質についてのこの原理も、なるほどと思いました。
誰が顧客なのかがわからなければ、何が品質なのかもわからない。
第7章 計測
コホート分析なるものが気になりました。こっち方面ド素人なんですが、これ結構いい指標なんじゃないだろうか。総数などに紛らわされずに、同じ指標でアクションの結果を計測していけそう。Mixpanel上で、これっぽいやつが実現できるかは不明(Retentionが近そうだけど)なので、だれか教えろください。もしくは、社内のその筋の人に聞いてみよう。
コホート分析の場合、総売上や総顧客数のような総計あるいは累積値を見るのではなく、製品と新しく接する顧客グループの成績を個別に見る。
...
さて、このグラフをよく見るといくつかのトレンドが読み取れる。製品の改良はわずかだが効いている。我々の製品を5回以上使う人は5%以下から20%近くまで増えた。しかし、この部分が4倍になってもIMVUを買ってくれる顧客の割合は1%前後で変わらない。
...
これはコホート分析なので、古い製品の第一印象に顧客がとらわれているんじゃないかとか、外部環境がよくないとか、そういう言い訳はできない。
あとは、スプリットテスト(A/Bテスト)とカンバンについてが面白かったです。「Xという機能をリリースしたとき、それは顧客の行動に影響を与えたか」を、スプリットテストなしでは測るのが難しい・コストがかかるけど、スプリットテストを実行するとこの辺が分かりやすくなる、とのこと。カンバンは、WIPの制限などはまあいわゆるカンバンの定義そのままなのですが、ステータスの一種に「構築完了」後に「検証中」を用意して、機能のユーザ価値まで検証を強制してるのがいいなと思いました。詳しくは、図を見てもらうと。
第10章 成長
3種の成長エンジンというのが気になりました。3種全部備えた事業もあるけど、原則としてはどれか1種に集中してそのエンジンをチューニングすることにかけた方がいいよとのこと。
- 粘着型成長エンジン
- 一度顧客が使い始めるとずっと使ってくれることを念頭においた事業・ビジネスモデル。なので、解約率を指標とする。
- ウイルス型成長エンジン
- 顧客が使うにつれて自然と広まっていくような事業・ビジネスモデル。ウイルス係数(顧客一人あたり何人の友達を連れてくるか)が大事になり、1.0(=1人当たり1人を連れてくる)を境に指数関数的に成長し始める。
- 支出型成長エンジン
- 顧客を獲得するのに必要な支出と売上が相関してるような事業・ビジネスモデル。成長にあたって、顧客当たりの支出を抑える or 売上を増やすのどちらか。
今のうちのサービスだと、どれに該当するのだろう?粘着型:ウイルス型が 7:3 ぐらいかな。ITSやチャットなどのコミュニケーションツールは、ナレッジがたまると乗り換えコストが高く、ずっと使い続けた方がいい粘着型。かつ、組織の外部の人と使う際は一緒に使って自然と広まっていく、ウイルス型の側面もあるので。
どんぴしゃ自分が向かう分野ではないかもだけど、この辺の人たちと同じ文脈・同じ言葉で話せるようにという意味では、まあ読んで損はなかった本かなという気がしてます。あと、正直最後の方は息切れしたので、また別の機会に読み直してみたいです。
「Fearless Change」を読みました
いいものは色々取り入れようと日々奮闘しているのですが、そうは言っても取り入れ方にもいいやり方とちょっと受け入れづらいやり方ありますよね。というわけで、お次はこの本です。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (16件) を見る
第1部 概要
第3部 48のパターン
どうでもいい話ですが、48という数字を見ると別のものを連想しちゃいます。。。
7 ブラウンバッグ・ミーティング / 9 何か食べながら
両方とも、食べることに関するパターンです。
「ブラウンバッグ・ミーティング」は、要するにランチミーティング。ランチミーティングは結構好きなんです。時間を有効活用してる感じがするとか、お弁当持ってきてるからとか仕事上人と合わせづらくてランチ一緒に行けてないけど行きたいとかの理由で。ただ、何回かランチミーティングやったら、あまり芳しくなかったのでちょっとサミシイ><
「何か食べながら」は、そのまんまですね。食べながら話すと、リラックスできてより前向きに話し合えるとのこと。うちでも、リリース後のふりかえりとか、特別なイベントの際には経費でケーキなどを準備してもらうように進めています。あとは、ちょっと長くなりそうなミーティングの場合、1時間ぐらいでいったん休憩を挟んで、甘いものやコーヒーなどをとってもらうように仕向けるとか。
15 空間を演出する
物理的に掲載して、否応なしに目に入るようにするパターン。カンバンなどでもあるように、物理で見せるとやっぱり分かりやすい。ただ、うちはオフィスが分散してるので、ちょっと難しいんですよね。物理の力は偉大だと思ってるので、何かうまくやる方法を見つけたいとは思ってるところ。
お隣さんの製品ですが、「JIRA とアナログのボードの併用」ってのはいいアイデアだなーと思いました。一度試しにやってみたい。オフィスに遊びに行って見せてもらうかーw
22 種をまく
プレゼンやミーティングを行うときに、参考書籍やURLを出せるようにしておく、というパターン。割りとこれはやってる。特に、リモートの人と会話するときは、参考URLをぱっと出すと、相手もイメージしやすいので。
24 定期的な連絡
「コーチングマネジメント」を読みました - @ikikko のはてなブログにもあったけど、定期的にリマインドするの大事。何もしないと、人は忘れるものなので。
36 場所重要
少し特別なイベントを行うときは、普段の作業場所ではなく、ちょっと場所を入れ替えるというパターン。普段の場所だと、良くも悪くもすぐに普段の仕事に戻れるので、半強制的に切り替える。「9 何か食べながら」とかと組み合わせるとよさげですね。
46 恐れは無用
抵抗勢力がまったくいない状況を想像すると、ぞっとする。あなた一人で常に 100% の正しさを保証しなければならない。これはおそろしいことではないだろうか。
なるほど。こういう視点はなかった。こういうのを意識しておくと、何か抵抗や批判を受けたときも、リスクを潰してくれた・協力してくれたと前向きに考えることができるようになりますね。
基本的にこの本はパターン集なので、ざっくり頭に入れておいて、よさそうな機会に本引っ張り出して確認・適用みたいな流れになりそうかな。
「ユーザーストーリーマッピング」を読みました
良くも悪くも独自の感性でやってきた今の組織に対して、外部のベストプラクティスをうまく取り入れながらよりよいやり方を模索するのが、今の自分の役割の一つです。そのうちの一つに、ユーザーストーリーがありました。ユーザーストーリーはいいものだと思うのですが、全体像がちょっと掴みにくいなあと思ってたところだったので、この本を手に取ってみました。
- 作者: Jeff Patton,川口恭伸,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/07/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (7件) を見る
3章 より早く学ぶためのプラン
ちょいちょい見る、下記の図の説明が腑に落ちました。
このようなリリースプランを立てれば、毎回のリリースで人々が実際に使えるものを届けることができる。しかし、私の目的が長距離旅行で、大きな荷物を持っていたら、この乗り物の例みたいにスケートボードなんかもらっても、ちょっとイラッとするだろう。(中略)あなたの目標が私を喜ばせることなら、これはまずいと思うはずだ。しかし、あなたの目標が学ぶことなら、その目標は達成できている。そう、これでいいのだ。あなたは、私がおもったより遠方まで旅行したいんだと考えていることを学んだし、その課題が片付いたら、私が楽しさにも価値を置いていることを学ぶだろう。
...
すべてのリリースを実験として扱い、何を学びたいのか忘れないようにしよう。
よく「単位を小さくリリースしろ」って言われるけど、(単位が小さいがゆえに)ユーザにとって価値が小さいのをリリースしてもどうなんだろう?と思ってました。けど、そのリリースの目的が(ユーザへの価値提供ではなく)学びであるならば、小さくリリースすることによってその学びを達成できたのであればいいことなんですね。予測と違う結果でも、「予測が違うかった」と学べたということで。
5章 あなたはもうやり方を知っている
この章では、「朝起きてから仕事に行く準備ができるまで」という題材で、実際にストーリーマッピングの作り方を試す流れになっています。こうやって、本で学んだ知識を実際に体験できるような章を用意しておいてくれるの、非常にありがたいですね。本読んだだけだと、ふむふむじゃあ実際にはどうやるの?ってなりがちですが、一度体験しておくと実導入する際にもう少し取り掛かりやすくなるので。
せっかくなので、会社で希望者募って一緒にやってみようかな。もし誰も希望者いなければ、会社の隅で一人さみしく付箋紙と戯れることになると思いますが・・・
(2016/11/16 追記)
やってみました。結果はこちら。オフィスの3~4名ぐらいが乗ってくれて、嬉しかったです。
16章 リファイン、定義、構築
ミーティングの形式について。
人数がある程度以上になると、興味が薄くてスマートフォンをいじったり別のチャットをやったりする人が出てきますよね。積極的に関与するほどではないけど、会話の流れを聞いておきたい人もいるという場合に有効なミーティングの形式として、「フィッシュボウル・コラボレーション」というパターンが紹介されていました。詳細は以下の画像を。
これ、割りといいなあと思いました。人数増えてくると参加者間で温度差が出て来るけど、それをうまく吸収できそう。一度取り入れてみたいですね。うちは拠点が分散してて hangouts などオンラインでミーティングする形式なので、物理的な円を描くとかはできなさそう。各参加者が、積極モードなのか、観察モードなのかを判別できるような仕組みがあればよさそう。
あと当たり前だけど、ユーザーストーリーマップを扱うときはユーザーストーリーも扱います。本の半分ぐらいはユーザーストーリーの説明も色々書かれてて参考になりました。まだ知識レベルな理解なので、ちゃんと実践投入してこの本で得た知識を活かせるようにいきたいです。(もしくは、やってみた結果今の自分たちに合わないと学んだならば、それはそれで成果だと思うし)
「XPエクストリームプログラミング入門」を読みました
基本的に仕事ではスクラム(or カンバン)をベースに考えてるのですが、スクラムの中でもXPのプラクティスは補完的に使えると思うし、Webで流し読みぐらいしかしたことなかったので、今改めて。
- 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2005/12
- メディア: 単行本
- 購入: 3人 クリック: 55回
- この商品を含むブログ (70件) を見る
第9章 応用プラクティス
「チームの継続」と「チームの縮小」。まさに考えてるところなので、参考になりました。
小規模な組織にはこのような問題はない。チームが1つあるだけだ。
...
大規模な組織は、チームの価値を無視し、代わりに「プログラミングリソース」という分子または流動体のメタファを採用する場合が多い。(中略)この戦略では、部分的な効率性は最大限となるが、全体的には組織の効率性が損なわれる。
今僕が見ているチームは、まさにスケールしている最中なので、小規模・大規模のこの辺がよく実感できます。合わせて、うちでは分散拠点なので、ロケーションの問題も考慮しないといけないのが、更にややこしいところなんですよね。もちろん、ロケーションの問題を極力埋めるために、オンラインビデオ会議などシステムで回避できるようなものも積極的に取り入れようと試みてはいますが。
第10章 XPチーム全体
メトリクス(測定値)とは何ぞや?というのを、すごい分かりやすく説明した文章があったので引用。
速度計が速度を指し示すのと同じように、開発後の欠陥と投資から収益までの時間はどちらもチームの有効性を示している。速度計の針をつかんで動かしてみても、車の速度を上げることはできない。速度を上げたければ、アクセルを踏み、その効果を確認するために速度計を見る。同じように、測定値に基づいて目標を設定できるが、チームは根本的な問題に対処する必要がある。数字を直接改善しようとしても、数字が修正されるだけで、プロジェクトに関する透明性の価値が排除されてしまう。
メトリクスはあくまで現状を測るためのものなんですよね。メトリクス自体を補正しようとしても、まったく意味がない、というのが分かりやすい例えでした。
ただ、そもそもメトリクスがないと、実際にいい方向に向かってるのか悪い方向に向かってるのかが分からない(感覚的にはある程度わかっていても)。なので、まずはメトリクスを取ってみるというところは意識付けしていきたいなと思ってます。
その他にも制約理論の話とか、ちょいちょい見たことがある話もありましたが、もろもろ再確認できました。ただ、正直なところ、何か文章が頭に入ってきづらかったんですよね。。寝不足で疲れてたとかもあるのかも。読書も持続可能なペースでいきたいものです。
「コーチングマネジメント」を読みました
テクニックや知識的なところだけでなく、人と対峙する面も求められる今の役割・立場的に必要そうとは思ってた「コーチングスキル」。いくつか推薦してもらった本の中から、まずはこれを読んでみました。
- 作者: 伊藤守
- 出版社/メーカー: ディスカヴァー・トゥエンティワン
- 発売日: 2012/11/02
- メディア: Kindle版
- この商品を含むブログを見る
PART1 : 今求められるマネジメント革命
ゴルフを教えないゴルフコーチ
ここで取り上げられてたやり取りが印象的でした。なるほど、こういうのがコーチングの基本形なのかなと感じました。
「目標に対する集中度は1から10で何点?」
「自分の体や動きに対する気づきは1から10で何点?」
「今のショットから学んだレベルは1から10で何点?」
みたいな感じで、コーチが特に技術的なアドバイスをするわけではなく、現状を気づかせる問いかけをするだけ。けれど、それによって、自分自身で考えて行動するようになる、という話。
ミスショットのときも、それを責めるとかではなくあくまで気づきを与えるような問いかけが、例に挙げられていました。
「どうやってあんなふうにボールを曲げたんだね?」
「打つ前から曲がるような気がしたし、・・・頭が混乱していたし、腕も緊張していた」
「そう、それでどんなことを学んだ?」
「混乱しているときは、仕切り直しだな」
「今までだって仕切りなおしのチャンスはあったと思うんだけど、それができなかったのはどうしてなんだろう?」
「一緒にプレーしている人の目を気にしていたのかな?」
PART3 : コーチング・スキル
クローズド・クエスチョンとオープン・クエスチョン
「なぜ?」って言葉は、オープンクエスチョンに見えて、実はクローズドクエスチョンに近いという話。「なぜ」と聞くと相手を萎縮させてしまって、結果的にクローズドクエスチョンになりがちだということです。
「なぜできなかったんだ?」
「なぜそんなことをやってしまったんだ?」
そのかわり、「HOW」や「WHAT」を使うとのこと。一般的には、HOWがアイディアを発展させて、WHATが問題をはっきりさせると説明されています。
「どうやったら、同じ失敗を繰り返さないですむと思う?」
「次はどういうふうにやる予定?」
「何が足りなかったんだろう?」
「何か気がついたことはなかった?」
選択の幅を広げる質問
クローズド・クエスチョンの「Yes / No」「やるか、やらないか」は選択ではなくて脅迫らしい。コーチは、必ず3つ以上の選択肢を見つけ出して、自発的に選択できる状態をセットしなければいけないって。
結構難しい気がするけど、頑張ってみる。
アクナレッジメント
「賞賛」などの評価を含む言葉ではなく、事実を事実として伝える。評価が入ると、意見なので受け取りにくくなるということらしいです。「You」「I」「We」の視点があり、一番効果的なのは「We」のアクナレッジメント。
具体例をあげるのはやめておくかな。意識的か無意識的かにせよ、これと同じ言葉を誰かが聞いたとき、わざとらしく感じるかもなので。
エコロジカルチェック
何か変化があったときに、質問しながらその変化によって生じた歪みを見つけること、らしい。例えば、こんな状態になってるとして、
「頭では分かっているんだけどしっくりしない」
「何か違和感がある」
「最初はいいと思ったけど、今はちょっと」
これらの心理的な違和感や歪みを、こんな質問であらためて確認する感じ。
「今やっていることは、やる前に考えていたことと一致していますか?」
「やり方を変えて、気分はどうですか?」
「思ったような成果が上がっていますか?」
「ストレスはどうですか?」
「何か違和感はありませんか?」
「体の変化どうですか?」
「生活のバランスはとれていますか?」
要はやりっぱなしでなくて、ちゃんとアフターフォロー的なところも意識してってことかな。こういった「継続的な取り組み」ってのは、最近のマイブームというか、自分・組織に対して根付かせていきたいと思ってます。ふりかえりにしろ、例の本で学んだ見積もりと計画づくりにしろ、ここでのエコロジカルチェックにしろ。
一通り書いた後に見返してみると、ちょっとコーチングのスキル的なところばっかり目についちゃったかな。また適当なタイミングで見返してみて、そのときはどう思うかを感じてみたいです。
「アジャイルな見積もりと計画づくり」を読みました
名著と言われながら、今まであまり興味がなくて読んでなかった分野。もっと早く読んでおけばよかったなと思う反面、おそらく以前の自分では消化できなかった&活かせなかっただろうなと思ってはいます。
アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?
- 作者: Mike Cohn
- 出版社/メーカー: マイナビ出版
- 発売日: 2009/01/29
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
1章:計画の目的
1. なぜ見積もりや計画づくりが必要なのか?
しょっぱなにあるこの問いかけ、最初からすごいためになる文章です。この本を読むまでは、見積もりや計画って、やりたくないけどやらざるを得ないといった、どちらかというと消極的な理由しか思い浮かびませんでした。でも、それだけでないよという話。具体的には、以下の5つが挙げられています。
- リスクを軽減する
- 不確実性を減らす
- 意思決定を支援する
- 信頼を確立する
- 情報を伝達する
この中で太字にしたものが、消極的な理由ではなく、計画作りをしていくことによってもっと前に進めるための理由かなと感じました。開発者・チームにおいても、いやいや計画づくりをやっていくのではなく、チームが計画づくりをやっていくことによって、ビジネス面での意思決定を支援したり他チームとの信頼を確立していくことを意識する。それが結果的に、開発チームだけでなく全体のサービス・プロダクトにいい影響をもたらしていくというのは、自他共に意識づけていきたいなと強く思いました。
あとは、これかな。
3. アジャイルな計画づくりとは?
本書で扱うのはアジャイルな「計画づくり(planning)」だ。アジャイルな「計画(plan)」ではない。
...
アジャイルな計画づくりで重視するのは、計画よりも、計画を作る過程そのものなのだ。
プロジェクト初期のみ「計画」を作成するだけじゃだめで、ちゃんと日々の活動の中で計画を更新していく「計画づくり」が大事だよということ。これって、プロセス改善の文脈でのメトリクスとかでも同様だよなーというのを思い描きながら読んでました。
11章:「望ましさ」による優先順位づけ
狩野モデルについての説明。このモデルについてはどっかで見たことがある気がするけど、本の中で出たので改めて見なおしてみました。守備範囲的にはプロダクトオーナーの領域っぽいけど、スクラムマスターとしてもさらっとでも知っておいて損はない領域だし、参考になりました。
モデルの説明については、先人のブログを参考に。
d.hatena.ne.jp
16章:ベロシティの見積もり
ベロシティは常に固定になるわけではなく当然幅があるけど、その幅をどう扱うかの話。3イテレーション(スプリント)以上取れる場合、以下の方法が挙げられていました。
- イテレーション毎のベロシティをそのまま幅として扱う
- 不確実性コーンを活用する
前者は単純。3回のイテレーションのベロシティが (12, 15, 16) ポイントだった場合、見積もり幅は 12~16 ポイントと扱います。
後者は、不確実性コーンと呼ばれる、プロジェクトの状況に応じて不確実性の幅が変わる図を流用しています。ここで、3回イテレーションこなした後の平均ベロシティが20ならば、下限が20*0.85=17, 上限が20*1.15=23 で、17~23 の幅に収まるだろうと推測する感じ。
実施したイテレーション数 | 下限の係数 | 上限の係数 |
---|---|---|
1 | 0.60 | 1.60 |
2 | 0.80 | 1.25 |
3 | 0.85 | 1.15 |
4以上 | 0.90 | 1.10 |
ちょっと計算式は複雑になるけど、不確実性コーンをもとにした方が、今のうちのチームにとってはいいかなと思いました。理由としては、ベロシティの平均が基準となってるから。
うちのやり方として、1イテレーション内できれいに終わりきらないことがあるのですが、その場合各イテレーションのベロシティは変動しやすくなるんですよね。ただ、各イテレーション毎の変動はともかく、移動平均をとっていくと中長期的には問題とならないことが多い*1。なので、平均を考慮した方がより精度が高いものが出せるかなと思っています。
22章:なぜアジャイルな計画づくりがうまくいくのか
11. ゆとりを残す
チームメンバー全員の時間を100%使い切るような計画を立てないこと。特にイテレーション計画では気をつけること。高速道路の限界100%まで車を詰め込むと、誰も身動きの取れない渋滞になってしまう。開発チームもこれと同じだ。メンバー個々の時間を限界まで使ってしまうと、プロジェクトの進みは遅くなってしまう。
はい、やってしまってました。イテレーション計画ミーティング時は作業時間見積もりをしてるのですが、このとき全時間を詰め込もうとして結局計画したものが全部終わりきらない。終わらないものを計画時に話すのムダだし、終わらなかったという事実はチームメンバーのモチベーション的にもいい影響を与えない。
なので、最近ではベロシティ(実績)ベースで考えるようにしようとしてます。普段大体これぐらいポイント消化できてるのだから、(作業時間はもうちょい余裕あるけど)計画するのはここまでにしておこう。で、おかわりできるならばそのとき考えよう、という方針にしてます。
チームがもっと成熟して毎回安定して計画したものを終わらせられるようになってきたならば、その次はいかにベロシティを上げていくかを考えていく感じ。もしかしたらその中で、作業時間のムダに着目していって、より効率的にタスクに取り掛かれるようになるかもしれないなーとは考えています。
いつもより長くなった。それだけためになる内容が多かったです。特に1章の「1. なぜ見積もりや計画づくりが必要なのか?」は常に意識しておきたいです。
あと、タイムリーなことに、先月の WEB+DB PRESS でちょうど見積もりの話がでてました。こちらも参考に。
- 作者: 原田騎郎,吉羽龍太郎,松浦隼人,須藤涼介,生沼一公,森下雅章,前島真一,鍛治匠一,伊藤直也,のざきひろふみ,うらがみ,高山温,佐々木健一,わかめまさひろ,ひげぽん,遠藤雅伸,海野弘成,はまちや2,竹原,藤田正訓,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2016/06/24
- メディア: 大型本
- この商品を含むブログを見る
*1:この辺は「7章:再見積もり」の「4. 部分的に完了したストーリーの再見積もり」も参考に。
「ピープルウエア」を読みました
事務所にあったやつをひっぱってきたので、最新でないちょっと古いやつ。名著と言われてたけど読んだことなかったし、今の立ち位置的に読んでおいて損はないと思って。
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2001/11/26
- メディア: 単行本
- 購入: 26人 クリック: 339回
- この商品を含むブログ (197件) を見る
第 II 部:オフィス環境と生産性
騒音、特に電話の話。電話という点では、うちにはそこまで影響がないとは思ってます。が、(別チームの)ミーティングがうるさい問題は以前ちょっと感じてたので、その辺を頭に思い浮かべながら読んでました。
なお、つい先日事務所引っ越しして、ミーティングルームが増えたので、今はかなり改善されてるのかなと思ってます。
第 III 部:人材を揃える
採用における「能力テスト」についての説明が気になりました。
その人物は、能力テストで測られた作業を2年間で終え、他の作業を20年間やることになるかもしれない。
採用の際には、今できることという短期的な視点だけではなく、長期的にどうなりそうかを重視するのがよさそうだというのを、改めて考える機会となりました(もちろん、今までも無意識的にそういう風に考えていたとは思いますが、改めてということで)。
第 IV 部:生産性の高いチームを育てる
組織のビジネス的な目標、例えば「今期の利益を2倍にする」といったものが、ダイレクトに個人やチームの目標と結びつくかは分からないという話。この点も、うちではある程度解消されているのかなと感じています。というのは、自分たちが作ってるサービスを自分たち自身でも使ってるので、「サービスをよりよくすること=自分たちも楽になる」というのが分かりやすく実感できる目標なためです。
とは言っても、「自分たちのサービスをよりよくする」だけじゃ足りないところももちろんあるので、やっぱりその他やれることはやっておく必要があります。という点では、この辺かな。
チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。
このチームの目的は満たされたとき、チームのメンバーはずっと効率よく働く。一体になったことでベクトルが合ったからだ。
これを達成するためにも、チームの目標が何なのかと、それを各チームメンバーにも意識付ける取り組みに注力しようとしてるところです。
全般的に、名著と言われるほどには自分が読み解けない点が多かった気がしました。もっと経験を積んだ後に読み直すと、また違ったものが見えてくるのかなあ。