読書感想文です。今回読んだ本はずーっと気になってたこちら。
本のタイトルの通り、エンタープライズ(企業)にLEAN開発の手法を適用するための方法が書かれた一冊です。
この本を読もうと思った理由
オライリー(出版社)がシリーズ物として出版してるんだったら多分本物なんでしょ、と前から思っていました。で、こういうシリーズ物はきちんと出版された順に読んでいきたい派なんですが、ふと図書館でこの「LEAN ENTERPRISE」だけがちょこんと棚に載っているのを見つけてしまい、巡り合せを感じ借りてきてしまいました。
このリーンシリーズは2012年に日経BP社から「リーン・スタートアップ」が出版されたのが最初かと思います。
- 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
- 出版社/メーカー: 日経BP社
- 発売日: 2012/04/12
- メディア: 単行本
- 購入: 24人 クリック: 360回
- この商品を含むブログ (95件) を見る
その後、オライリージャパンがシリーズ物として、6冊出版しています。「LEAN ENTERPRISE」はオライリージャパンが出版している内の一冊です。オライリーの出版は以下のリンクにまとめられています。
O'Reilly Japan - The Lean Series
私がリーン開発に興味を持ち始めたのは、2015年ごろだったと思います。本屋のオライリーコーナーでRunning LEANとLEAN Analytics、LEAN顧客開発が平積みで置かれていて、ポップに「今話題のLEAN開発!」といったコメントが書いてあって気になり始めたのが最初だっと思います。
それからもうかれこれ3年、さぼっていたわけではないですが、後回し後回しになってようやく巡り合ったのがこの2018年8月というわけです。
全体の感想
満点!まではいかないけど、すごく良い本でした。アウトプットしたいと思える本でしたね。
まず本書の軸になる考え方、リーンスタートアップについて振り返ってまとめてみます。ざーっくり言うと、こんな感じです。
- 事業のアイディア(仮説)を出す
- アイディアの効果を測定できるMVP(最小限の効果を持った試作品)を作る
- 新しモノ好きのアーリーアダプター層に使ってもらう
- 効果を測定し、アイディアを捨てたり方向性を変えたり、小刻みな軌道修正を繰り返す
スモールスタートで始めて、短期間でユーザの関心を調べたり、ユーザの声を反映させながら、ニーズに合致した製品へ仕上げていくという考え方です。
本書を読んでいてビビっと来たのは、MVP(最小限の効果を持った試作品)のところですね。私はSIerに勤めているので、MVPを作る状況にはなりませんが、考え方は非常に参考になりました。
スモールスタートは割と知られたやり方ですが、MVPは言われると当たり前なんですけど実際に作ったって話は聞いたことがありません。技術者側の立場で考えると、最小限の効果しか持たない試作品というのは作っていて悶々とするんでしょうか。技術者だけのチームであればスモールスタートで、「小さくても完璧なモノ」を作りたくなってしまうんじゃないでしょうかね。こんなサービス作りたい!という熱意が強いほど、完璧なサービスに仕上げたくなってしまう、熱が高いほどMVP作成という効率的な開発法から離れていってしまうというの面白い事象だと思いました。
こういったリーン開発の手法はこれからルールを作っていく新しい組織や、容易にルールの改定が可能な小規模組織で導入しやすいです。じゃあ大きな組織でリーン開発の手法は適用できないのか?この疑問に答え、実例を交えて紹介するのが本書です。
だいぶ逸れてしまいましたが、本書を読んだ上での全体視点での感想です。
- LEAN開発とは、という目次項目はない
- ちゃんとしてる本
- 結構難しい
1つ目は本書に「LEAN開発とは」という目次項目はありません。LEAN開発とか、LEANスタートアップについて真面目に知りたいなら先述の「リーンスタートアップ」あたりを読む必要があるのでしょう。本書では冒頭に書いてありますが、理屈・理論をこね回す書籍ではありません。エンタープライズ(大企業)向けにリーンを適用しようという本なので、あくまで応用のための本になります。
といっても、リーンスタートアップという仕組みの上澄み部分だけを知りたいと考えている人には良書です。電子レンジの仕組みを知らなくても誰でも使えるのと同じです。
リーンの考え方の中で、大企業に適用することの出来る部分を詳しく書いてあるので、本書だけを読んでも問題ないと思います。リーンの理屈や全体像を知りたい人は出版された順に読んでいくのがよさそうです。
2つ目は「ちゃんとしてる本」です。何を言っているかと言うと、考え方の前提がきちんと提示されているという事を言っています。開発手法とかマネジメント手法というのは、他の科学分野と同じでいきなり新しい手法がぽんっと出てくるものではありません。「誰それが研究していた何とか論ではあれがこうだと言っている」と前提になった研究や書籍がくどいほど書いてある。数えたわけではないですが、全体の3割くらいのページに引用元が記されていて、巻末の参考文献は12ページもある。読みやすいライトな論文を読んでいるような感じです。
しかしちゃんとしているが故に一般書籍としては読みづらさがある。まぁ如何に今までしょうもない本を読んできたかの露呈となるので、これ以上は恥ずかしくて書けないですが、オライリーの読み物らしさはありましたね。人に薦められるかと言ったら、本気で「組織を変えたい」と思っている人以外には薦められないですね。
3つ目は「結構難しい」です。一つ一つのトピックは難しくないですし、それぞれ嚙み砕いて読者にわかるように”内容”が解説されています。問題は言葉です。私は割とこういう海外の開発手法の本は好んで読むのでそこまでではなかったですが、一般的なサラリーマンが手を出すと読み切れないかもしれません。ぐだぐだ書くよりも実例を出します。本書で説明なしに使われる言葉です。
デリバリー、イテレーション、インサイト、エンゲージメント、バックログ、WIP、インテグレーション、バッチ、ハードニング、デプロイ、マイグレーション、コンバージョン、ロギング
この言葉の意味や指すところがわからないと本書を読むのが苦痛になると思います。
本書のタイトルをもう一度見てみると、こうなっています。
「リーンエンタープライズ イノベーションを実現する創発的な組織作り」
特にIT系を示唆する用語がタイトルに入っていないので、一般のサラリーマンが「イノベーティブな組織を作りたい!」と思って手に取ると痛い思いをすると思います(普通のサラリーマンがオライリーコーナーに行くことは殆ど無いとは思いますが)。前述の固さと相成ってギブアップしてしまうのではないだろうか。
最初に戻ります。満点!とまで言えなかったのは、全体的な固さとちょこちょこカタカナ英語の意味がわからなかったところからの読みづらさです。こんな固い本だとは思ってなかったので心の準備が出来てなかったというのもありますが。
ただ内容は非常に面白かった。読み進むたびに考えさせられる良書でした。
ビビッときたところ
この時点で長いエントリになってしまいましたが、これは書いておきたいと思うポイントだけ引用します。
社会学者ウェストラムの組織の分類
病的組織は不安と恐怖が蔓延しています。人々は情報をため込んだり、政治的な理由から隠したり、自分を良く見せようと改ざんしたりします。
官僚的組織は自分たちの部門を守ります。部門にいる人は自分たちの「縄張り」を維持し、自分たちのルールを主張し、何でも自分たちのやり方でやろうとします。
創発的組織はミッションに集中します。「どうすれば目標を達成できるのか?」の質問に答え、高いパフォーマンスとそのために必要な事が何よりも優先されます。
私が勤めているSIerでは病的組織1、官僚的組織8.9、創発的組織0.1、といったところです。創発的組織は見たことがないですが、それなりの規模の会社なので無いことは無いはずという意味で0ではないだろうと。私のいる部署は超がつくほどの官僚的組織です。事前に根回しして、毒にも薬にもならない指摘を頂戴しないと話が先に進まない。そんな文化なのに、やれ働き改革だ、やれイノベーションだという耳障りの良い言葉が飛び交う。まずは自分たちの部署がどういう組織なのかを理解する必要性があるのだと思いました。
「プロジェクト」では、顧客に届けられた価値ではなく、仕事が時間・予算通りに完了したかどうかで人々を判断します。したがって、生産性は成果(アウトカム)ではなく、結果(アウトプット)にもとづいて計測されます。
開発者たちは、実世界で大規模に使えるようにすることではなく、開発マシンでコードを書きあげることに対して報酬を得るようになります。こうして私たちは働き過ぎと高稼働に報酬を与えてしまう持続不可能な「英雄文化」を作り出すのです。
会社や部署ごとに”俺たちのやり方”がありますが、結局下っ端は”俺たちのやり方”でやるべき作業をやることが仕事になっている。本来は予算制約の中で顧客が受け取る価値の最大化を図ることが求められるのに、いつの間にか俺たちのやり方を構成する作業をこなすことが仕事になってしまう。そしてその作業を如何に効率的に多くこなすかが評価の指標となっている。
100の価値を創る仕事に10時間をかけたら生産性は10です。今のうちの会社では(殆どの日本の会社もそうだと思うが)この仕事を9時間で済ますにはどうしたらいいかという話ばかりになっています。これって働き方改革だなんだという話が出る前からみんな頑張って取り組んでいたので、乾いた雑巾を絞る行為なんです。本物の改革を目指すならば、時間を削ることも大事ですが、結局のところは価値の量を増大させることに帰着します。当然そこには先行投資が必要になったり、仕事のやり方を変えたり、痛みが伴うことが多いですが、そうやって成果を求めていくことが重要なんだろうと思います。
(スタートアップ買収により)優秀な人材を獲得して病的あるいは官僚的文化に入れても、その文化が変わる事はありません。その人たちを壊してしまうだけです。
文化を意図的に変えるのは難しい事です。「文化は非常に安定的で、変革が困難」であり、「成功に至るまでの考え方、感じ方、世の中に対する認識など、グループが学び、蓄積したものを象徴するものが文化」だからです。
この部分を読んで頭をよぎったのは「組織の文化は金で買えない」ということ。買えるのはせいぜい文化を変革させるきっかけ程度のものです。
これらを達成してもらうまでは、問題の解決や機会の追求のために大規模な計画を開始するようなことはさせません。
・達成されるべき計測可能なビジネス成果を定義する
・成果に向かって計測可能な進捗を示せる、最少限のプロトタイプを構築する
・提案する解決策が顧客のために作られ、実際に価値を提供していることを実証する
ここはLEANの考え方が端的に書いてあるところだったので引用してみました。”計測可能”な進捗と成果を計る指標を定義し、最小限のプロトタイプを作って、価値を提供していることを実証する。
以前Yコンビネータ―の本を読んだ時も同じようなことが書いてありました。1週間の目標をたてて、測定すべき指標を追いかけて対策を立てていく。似たような考え方を持っている人の本を私が好んで読んでいるだけかもしれませんが、異なる本で同じことが書いてあると、やっぱりそうなのか、と思ってきますね。
従来の財務会計では、業績・キャッシュフロー・収益性比率を計測します。これらはイノベーションのために作られたものではないので、新しい製品や活動を抑制したり、殺したりする恐れがあります。
これは本書を読んで一番ビビビッときたところです。
私が務めているSIerでは厳格に業績が管理されていますが、それはSI事業であっても新事業計画でも同じ方法で管理されています。SIerではSI事業がベースになっているので、業績管理もSI事業を前提に考えられています。予算や納期、品質、使う技術などを長ったらしい計画書にまとめ、計画通りに予算を使いながら納品して、計画以上の利益を上げるというものです。
ただ新事業計画なんて不確実性だらけなんだから通常のSI事業並みの精度で計画を作ることなんて無理なんです(ちなみにSI事業にしてもそんなに高い精度で計画作れないですが)。じゃあ不確実性に対する予算をまとめてプールしておけばいいじゃない、と思う人もいるでしょうけど、業績管理システムはそんな入力項目を用意してくれていない。私が勤めている会社では不確実性なんてものはそもそも存在しないことになっています。そんなものがプロジェクトにあるんだとしたら「なぜ見積もりをすることができたのか?」という話しになり社内でボッコボコにされる。プロジェクトには不確実性が存在することをみんなが認識しているのに、社内のルール上、業績管理システム上は存在しないことになっている。表面上は会社のルールに従い、実態は不確実性に対してみんながそれぞれ独自の対処をしているのが現実です。工程ごとに多めにバッファを積んだり、計画外の要員に内緒で作業をさせたりとかやり方は色々あるようですけど。
これってすごくアホらしいんですよ。不確実性を無いものとするってのは、ただの会社や管理職の保身から出る理屈であって、プロジェクトを管理して多くの利益を生み出したいというプロジェクト管理の基本的な考えからは遠く離れています。大抵の場合は何だかんだ上手く終われているやり方ではありますが、やはり新事業をやるうえでSI事業と同じような考え方ではうまくいかないのだと思います。
本書を読んで特に考えさせられたのはここで、明確に書いてあるわけではないですが「不確実性とお友達になる」というのがリーン開発の本質なんじゃないかと思いました。不確実性を溜め込めば溜め込むほど爆発した時の威力が高いので、ほどほどにガス抜きさせてやって大爆発させないようにうまく付き合っていくのが大事なのではと。
小さく分散した自律的なチームをたくさん作る事です。本当に分散した組織は、補完性原則に従います。つまり、基本的に決定というものは、その決定によって直接影響を受ける人たちが下すべきなのです。官僚組織の上位レベルは、下位レベルでは効果的に行えないタスクのみを実行すべきです。上位レベルは下位レベルを「補完」すべきということです。
この考え方は初めて知ったのでメモっておく意味で引用。
以前、読書感想文を書いた「SEの教科書」にあった「上流工程で作り込んだ問題をプログラマが対処する。原因を作り出したところには、具体的な苦痛は無い場合が多い」という話と似ているなと思いました。微妙に対象が違う話ではありますが、本書に書いてある内容はより積極的に上位下位のそれぞれの人たちが”すべき事”に注目している点が面白いと感じました。
予防的コントロールを間違ったレベルで実行すると、不必要に高いコストをもたらします。
・簡単に自動化できる単純なタスクなのに、他のチームに実行をお願いしなければいけない。
・リスクを理解できない人から承認をもらう必要があるが、その人が多忙なのでボトルネックになっている。
・完成してもすぐに時代遅れになる不正確なドキュメントを大量に作らなければいけない。
・大きなバッチをチームや委員会に渡した後、その処理や承認が終わるまで待たなければならない。
私はSIerで金融系システムを担当することが多いのですが、これ全部あてはまる。もちろんガッチガチの運用をしているので、不必要に高いコストと一言で片づけるのは乱暴でそれが必要になった背景もあるんですが、全項目に「そうだそうだ」と思う所がある。権限や責任を厳密に定義しすぎると遅くなる(コストがかかる)という話です。アウトプットしたいと思ったのは、権限や責任所在の厳密さと、スピードやコストはトレードオフであるということ。何かまずい事が起こった時に再発防止策が実行されますが、これによって責任所在が明確になり権限が絞られていく。これ自体が悪い事ではないですが、業務の全てにこの考え方を適用していくのは誤りだと思います。金融系でガチガチのチームにいると、この再発防止の考え方がスタンダードになってしまって、何でもかんでもこの考え方を適用していってしまう。何でそうなるかと言うと、責任範囲が厳密に決められれば他の事を考えなくていいので楽になるからです。こうなると段々と上で引用した病的組織、官僚的組織の色合いが濃くなっていき、創発的組織が持つ要素は失われていく。そしてこの考え方は”文化”としてそこで働く人の心に刻み込まれる。
なので金融系SIのようなガチガチな仕事をしている人は特にこの責任所在の明確化とスピード・コストのトレードオフの関係性は強く意識して、対象の仕事によって使い分けないといけないと思う。
改善には決して終わりがありません。
これは覚えておきたい良い言葉なので引用。改善に取り組んですぐに良い結果が出るばかりではないですが、当たり前のように続けていくことが重要なんだなと。
おわりに
ここまで書いてあらためて振り返ると、良い事がいっぱい書いてある本だったなという印象です。個人的には読みづらさも感じましたが、内容はとても良い。特に基本的な考え方の部分でMVP(最小限の効果を持った試作品)は覚えておきたい。少し不思議なのは、仕事の中で資料作りをする時は、時間をかけずに粗い骨子を作ってレビューを受けるんですが、新事業や新しい取り組みの話になるとその考え方がスパッと頭から無くなってしまうということ。会社の中で予算のルールがあるからという理由もあると思いますが、なぜだか試作品を作るという考えがスパッと消えてしまう。
後は文中にも書いた「不確実性とお友達になる」。不確実性は見えないものなので、蓋をして隠しておきたいと考えてしまいますが、うまく付き合ってコントロールしていくことが重要なんだと思いました。
このリーン開発はとても面白い手法だったので、今後少なくともエリック・リースのリーン・スタートアップは読んでみたいと思います。
おわり