suusan2号の戯れ

SIerでインフラSE⇛WEB系でエンジニアのおっさん

「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」を読んだ

流行ってるので読んだ。

内容について

著者であるジョン・ドーアというGoogleに投資した投資家が、Intel で学びGoogle含む投資先の企業に伝えたOKRという手法についての本。

それぞれの企業が OKRをどのように活用したのかというケーススタディを中心として、OKRはどのように設定するべきかやOKRをどのように運営するかという話が展開されていく。どちらかというと経営層の立場から、OKRを組織にどのようにインストール / 運用するか、という話が多い。そのため1社員として、どのようにOKRを設定するべきかのようなHow Toを期待すると面食らうかもしれない。

感想

OKRについて「野心的な目標としてObjectiveを、それを図る指標としてKey Resultsを決める」くらいの認識しかなかったし、過去職場に導入されたときもOKRを導入することで何かが良くなるなんていうことには懐疑的だった。しかしこの本を読んで、それは自分がOKRを「個人の目標管理手法」くらいにしか捉えていなかったからなんだなと気がついた。OKRは最終的には個人も設定はするものの、根本は「組織として何にフォーカスして、何にコミットするのか」を明確にするということなんだなと思う。

だからOKRを元にどう組織を運営していくのかということが重要で、個人がどうOKRを立てたらいいかといった話はOKRの一部に過ぎない(もちろん適切に設定することは大切)。だから組織として何にフォーカスするかというOKRの設定無しに、個人がそれぞれ勝手にOKRを設定してもあまり意味がない(これまでの目標管理とあまり変わらない)ということが分かった。 OKRを実践するには、適切なOKRの設定だけでは全く不十分で「これはKRのXXXに寄与するからやろう」とか「これはどのKRにも寄与しないんじゃないか?」みたいな会話が現場でできる必要があるんじゃないかと思う。

OKRはあくまで組織として大きな成果を出すための手法なのだということを理解すると、OKRでよく言われる以下の項目がだいぶしっくりくるようになる。

  • 全メンバーのOKRは共有されている必要がある
  • OKRを給与評価と連動しない

上述したとおり、適切なOKRの設定方法みたいなHow Toを提供してくれる本ではないのだけれど、1社員の立場で自分の立てるOKRはどういうものが望ましいのかということのエッセンスはつかめた気がする。 自分の目標というよりも、自分の役割の中で何をすれば会社のOKR達成につながるか、と捉えてOKRは設定したほうがよいのだろうなー

2018年の振り返り

2018年にやったことの振り返り。年末に書いていたのだけど熱を出して寝てたので年が明けてしまった・・・

大まかな仕事としてはこんな感じ。平行して採用関連の仕事や、他チームの支援なんかもやっていた。

  • 1-6 月 レガシーシステムのリニューアル (Kotlin + Spring Boot + Nuxt.jsなど)
  • 7-11月 機械学習チームに異動しての画像認識を使った新サービス開発(Rails + Vue.js + Flask + TensorFlowなど)
  • 12月 2人目が生まれたので育休

仕事

レガシーシステムリニューアルやった

上半期の振り返りに大体書いた。自分は主軸を機械学習チームに移したが、もともとのチームでちゃんと機能開発などできている状態なのは嬉しい。 suzan2go.hatenablog.com

機械学習チームに異動した

7-11月に機械学習チームに異動していた。とはいえ自分自身は機械学習をやっていたわけではなく、機械学習を使った新サービスの機械学習部分以外を全部やっていた感じ。全体のアーキ設計からAWS等のインフラ、アプリケーションの実装まで、機械学習そのもの以外のところは全部やれたので楽しかった。機械学習を活用したアプリケーションだと、メモリがめっちゃ食うとかGPU使わないと遅いとか普通のWEBアプリとは違う考慮ポイントが沢山あって設計のしがいがあった。

前述したとおり機械学習そのものは触らなかったのだけれど、機械学習エンジニアの作ったモジュールを動かしたり、 TensorFlowが動く環境作ったりするのはそれだけで面白い。AWSで環境をTerraformで作るところも、機械学習エンジニアの作ったモジュールを組み込んだPythonAPIサーバを作るのも、ユーザー側画面のRailsも、そのフロントのVue.jsも、ほぼ自分一人でやってたので、途中は死にそうだったけど、PM / 事業責任者がMVPを理解してくれていて仕事がやりやすかった。

他チームの支援した

他チームでレガシーシステムのリニューアルやっているところがちょっと炎上していたので、プロジェクトの支援を一ヶ月くらいやっていた。具体的には以下のようなことをしていたと思う。

上述の機械学習チームでの新サービス開発、イベントでの登壇など重なっていて正直キャパオーバしていて、あまりちゃんと支援できなくて申し訳ないなという気持ち。。。それでも一緒にやってもらえて助かったと言われたのが救い。

採用まわり

採用そのものというより、イベントのスポンサー関連の仕事が多かった気がする。ノベルティ作ったり、ブースの対応なんかはだいぶ知見が溜まってきていて、自分が関わらなくても普通に回るようになっているのが嬉しい。Vue Fesのスポンサーで、会社のロゴが入ったビールを、Vue.js公式Twitterで取り上げてもらえたのは、最高だった。

他には、リモートワークを始めるためのルールとかその辺の整理とかやったりした。他社と比べると、環境面ではまだまだというところも多いので改善していきたい。

この振り返りとは直接関係ないんだけど、他社のリモートワーク・副業の状況を表にしてみると、リモートワークはイメージほど認められてない(メルカリも調べた限りではやってないし、認めている会社も週1までとか制限が多い)けど、副業を認めていない会社は大手WEB系でも殆どなかったので驚いた。

育休

11月下旬に二人目が生まれたので、そこからすぐに育休をとった。一人目は特に育休はとらなかったのだけれど、二人目ということもあり取得した。一人目のときに比べて自分たちの育児スキルがあがっているということもあり、赤ちゃんのお世話は自体は一人目と比べるとだいぶ楽。上の子と下の子が同時にグズったときは本当辛いけど、上の子がだいぶお姉さんやってくれるようになってきたので、何とかなりそうな気がしてきた。2019年1月から復帰です。

登壇

2018年は意識的に登壇回数を増やした。 Kotlin Fest 2018、Vue Fes Japan 2018 Reject Conferenceといった100人以上の参加者がいる会場で発表できたのがよかったなと思う。JS、Kotlin、Rubyと3つのコミュニティで登壇できたの何気にすごいと思っている(自画自賛)

あとgRPC-Webについての資料が自分の資料では過去最高記録ではてブがついて嬉しかった。*1

roppongi.js

社内テックトーク

roppongi.js

meguro.rb

Kotlin Fest 2018

meguro.rb

Vue Fes Japan 2018 Reject Conference

登壇ではないけどエンジニアHubに取材してもらったりも。怖くてはてブのコメント見てなかったけど好意的なものが多くて安心した。

employment.en-japan.com

インプット

2018年の前半ではDDDに関する本を読んだりしたけど、読んだのは全体的にマネジメント・採用に関する本が多かった。特に読んでよかった本としては以下。

実践ドメイン駆動設計を読んだ - suusan2号の戯れ

ティール組織を読んだ - suusan2号の戯れ

「チームが機能するとはどういうことか」を読んだ - suusan2号の戯れ

「エンジニアリング組織論への招待」も読んだし面白かったけど、個人的には「ティール組織」の方を推したいと思います。

所感

技術的には本当に色々できた1年だったと思う。仕事でいろんな言語やFWを触ったことで、自分のなかで設計・実装のレベルを一つ上げられたような感覚がある。 また今までWEBアプリケーションのインフラ構築を一から自分でやった経験は仕事ではなかったのだけれど*2、Terraform使ってAWS環境を作るところを一通りやれたのはよかった。

一方で上に書いたことと微妙に矛盾するのだけれど、さらに自分が触ったことのない言語やFWを使ったWEBアプリケーションの開発を経験しても、現時点ではそれほど成長していけるイメージがない。もうすこし何かを突き詰めるか、全く別のことをやらないと行けない気がしている。そうなると自分が目指すべきはEMとか、SREとかになるのかなぁ。社内にげきつよ機械学習エンジニアがいるので、その人に師事して機械学習エンジニアを目指すのもありかもしれない*3

あとはこの1年で複数のプロジェクトを渡り歩いたので、もうすこし腰を据えてプロダクトに取り組みたいという気持ちもあったりする。今の所、これやってみたい!と思えるようなのは社内にはないのだけれど。

2019年の抱負

今年の抱負を書こうと思ったのだけど、仕事においては特に思いつかなかった。育休で一ヶ月以上家族と向き合ってるからかもしれない。

思いつかなかったけど、今年は車買わないといけない波動を感じているので、1.5ばんくし くらいもらえるように頑張りたいと思います。5000兆円欲しいです。

あとがき

下書きのまま年が明けてしまったので、2018年に書いた「今年」を「2018年」に置き換えるのがめちゃだるかった

過去の振り返り

suzan2go.hatenablog.com

suzan2go.hatenablog.com

suzan2go.hatenablog.com

suzan2go.hatenablog.com

*1:はてなブックマーク - フロントエンドエンジニアも知っておきたいgRPC - Speaker Deck

*2:既存の構成に何か追加 / 削除する程度はやったことあった

*3:ジョークです

クラウドワークスを退職して一年くらいがたちました。

この記事はex-crowdworks Advent Calendar 2018の17日目の記事です。  

クラウドワークス辞めて大体一年くらいたちました。辞めるときに会社のブログに退職エントリーを書いたのですが、まあ当然当たり障りのないことしか書いてないし、一年経ったからこそ冷静に見える点も色々あろうということで何か書きます。

注意として、自分がいたのは2017年10月までですので、当然情報も当時のものとなります。今とは異なる部分もあると思いますので、鵜呑みにしないで全部妄想だと思っておいてください。

なぜ辞めたのか

昨日終了してしまったこのサービスの立ち上げからリリース後の諸々が本当に大変で若干燃え尽き症候群になっていて、技術面、環境面で今と違うことをやりたくなったというのが理由の一つ。これはやんわりと会社のブログにも書きました。もう少し具体的に書くと以下です。

  • Rails + JSでずっと仕事していて、このスキルセット以外のところもやっていきたい
  • 海外経験積みたい

当時はこの2つを軸に次の会社を選んでた気がしますが、今思うと後者はそれほど重要じゃなかったかもしれない。というか子供が小さいうちはなかなか海外にいったりは、出張ベースでもなかなか難しいですね*1

もう一つはまあぶっちゃけ金です。奥さんが専業主婦だったので、子供が生まれてからは特にこのお賃金じゃ結構きついなーという感じでした。今思うとそう思うようになったきっかけは転職ドラフトで、「あれ、もしかして私の年収低すぎ・・・?」となったからだった気がする。もちろん残って会社の中で給料上げるという選択肢もありました。しかし当時の人事考課制度では何回最高評価取り続ければそこまでいけるねん・・・って感じだったというのもあり、いくつかの会社に話を聞いて内定をもらい、転職したという感じになります。

在籍中に給料が上がらなかったわけではありません。在籍2年半の間にたしか80万くらいは上がったかなと思います。ただ入社時に結構年収下げて入った(当時はSIでSEやっていて、プログラマとしてはヘッポコだったので納得はしています。残業時間もだいぶ減ったし)というのもあり、、、というところからだいたいどのくらいのお賃金だったか察してください。

で、転職してどれくらいあがったのかというと、前にmizchiさんがつぶやいてた内容を御覧ください。いくつかの会社から内定をもらいましたが、提示額でいうと最低でも大体これくらいのアップにはなってました。

エンジニア全員の給与を把握していたわけではないので、給与水準がどうだったのかとかということは正確には分かりません。何人かから話を聞いた感じだと、相場からは低かったような気はしますが、自分に関していうと上記のTweetのような状況だったように思います*2。昇給レンジや昇給プロセスは、どれくらいの成果を出せば・何ができるようになればどれくらい年収に反映されるかというのがある程度明確というメリットがある一方で、市場価値との乖離が大きい場合にはデメリットもあるなと思ったのでした。

転職してみて

転職先は大人の事情でここには書けないのですが*3、それなりの規模の会社です。社内に沢山のシステムがあり、技術選択の自由度が本当に高いので、自分の技術の幅も相当広げることができました。クラウドワークスにいたときはほぼRails、JS(CoffeeScript……)が全てという感じだったわけですが*4、転職後はSpringBoot、Kotlin、JavaPython、Vue.js、TypeScriptなどをプロダクションで書いていて、普通に仕事してるだけでネタができて、いろんなコミュニティ(Kotlin、Ruby、Vue.js……)で登壇できたのは凄くいい経験になりました。

一方でクラウドワークスのときのほうが色々と緩かったので、自分たちが使うツールやプロセスの自由度(タスク管理ツールとか)は高くて、各チームが自分たちにあったものをガンガン導入して使えていたので、転職直後は結構萎えていたりもしました。DXを高めるためにchat bot作ったり、CIにフックしていろんな警告だしたりといった取り組みが活発だったので、転職してから「ゴンお前だったのか・・・」みたいな気持ちになったりもしました。ただ最近は現職も結構改善が進んで、自分の貢献はほんの少しですが、1年前と比べるとかなり良い環境になってきたと思います。

また開発プロセスなんかもクラウドワークスにいたときの方が色々進んでいたなと思う面もあるわけですが、実際にそれでビジネス面でうまくいっていったかというと、あくまで個人的な感覚ですが当時はそんなことなかったので、なかなか難しいなと思ったりしました。綺麗なコードを書けば利益がでるわけではない・・・・・・的な方向の話です。

あとは現職で数年塩漬けにされてる中身がわからない独自FWのJavaのリプレースとかやった今、クラウドワークス時代に技術的負債とか言ってたものの中にはそんなに大げさなもんでもなく粛々とやればいいだけのものも合った気がしました。まあ確かに両端ポリモーフィックのテーブルみたいな闇とかもあったような気もしますが妄想だからきっとだいじょうぶです。

まとめ

なんだかんだ最低限の社会性フィルターを通して書いていたら割と当たり障りのない内容になってしまった・・・・・・

一つ言っておくことがあるとすれば、転職のときに社長や経営層の人と話して感じた違和感のようなものはきっと大切にしたほうがいいということです。

*1:うちの場合はですが

*2:繰り返しになりますが当時のお話であり、今どうなってるかは知りません

*3:自分の過去資料とか漁ってもらえば分かるはず

*4:いまは新規事業でReact Nativeのアプリがあったり、APIを静的型付き言語・DDDで作りかえようみたいな話があるようです

「GraphQLのmutationは動的にネストしたリソースを更新するもの」ではない

「参照系はGraphQLだけど、更新系はRESTでPOSTにします」みたいな意見を稀によく見る。 もちろん何かしらのトレードオフを考えてRESTを選択しているのだとは思うのだけど、GraphQLのmutation(要は更新系)を誤解している人も中にはいるのではなかろうか。

先日GraphQLのmutationは難しそう……という意見をもらって、詳しく聞いてみるとmutationについて誤解があるようだった。 もしかしたら同じような勘違いをされている方は他にもいるかもしれないなーと思ったのでまとめておく。

※実際、自分も何となくリソースの更新も柔軟にできるようなイメージを持っていたところはあった。

GraphQLとは

もはや色々な入門記事が溢れているので、詳しく説明することはしないが、 A query language for your API と公式にあるように、以下のようなフォーマットでサーバーサイドとやりとりをすることで、柔軟にデータを取得することができるようになっている。

GraphQLでは参照系をqueryといいます。

query {
  hero {
    name
    # Queries can have comments!
    friends {
      name
    }
  }
}
{
  "data": {
    "hero": {
      "name": "R2-D2",
      "friends": [
        {
          "name": "Luke Skywalker"
        },
        {
          "name": "Han Solo"
        },
        {
          "name": "Leia Organa"
        }
      ]
    }
  }
}

GraphQLというとこの説明が多く、柔軟にリソースを取得できるというところがメリットとして語られる。そのせいか、なんとなく更新系も柔軟にいけるのでは?みたいなイメージを持ってしまうのかもしれない。

GraphQLのmutationとは?

RESTでGETでデータ更新することが基本的にはアンチパターンなように、queryでデータ更新を行うのは推奨されておらず、mutationというものを使う。queryの印象に引っ張られて、mutationも以下のようなフォーマットでネストされたデータ構造を一気に更新できる……みたいなイメージを何となく持ってしまいそうだが、mutationにはそんな機能は用意されていない。

# GraphQLにこんなシンタックスはありません!!!
mutation {
  hero {
    name = "hoge"
    # Queries can have comments!
    friends {
      name = piyopiyo
    }
  }
}

以下のようにRPC形式*1のフォーマットでmutationのリクエストは定義する。

mutation {
  updateHeroName(name: '太郎') {
    # 以下はあくまで戻り値として何を取得したいか
    hero {
       name
    }
  }
}

上記の例でいうとupdateHeroName の中で具体的に何をするのかは自分たちの実装に完全に委ねられている。要はどのデータを実際に更新するかは自分たちの実装次第であり、GraphQLが絡むのはリクエストとレスポンスの型だけとなる。これを見ると、タイトルにあるように 「GraphQLのmutationは動的にネストしたリソースを更新するもの」ではない ということが分かると思う。

戻り値となるJSONのレスポンスに必要なデータはqueryと同じく柔軟に決められるが、データ更新という側面に絞って言えばRESTと比べたmutationの明確なメリット・違いは、リクエストとレスポンスに型が付けられる(付けやすい)ことくらいかもしれない。

GraphQLでmutationを使う意味はないのか?

こうやってみると、GraphQLのmutationはqueryほど強力な機能をもっているわけではなく、あまり使うメリットが感じられないかもしれません。しかしながらGraphQLを使っていればGraphiQLといったツールの恩恵を受けられますし、参照系をGraphQLで作るならあえて更新系をRESTにする必要はないんじゃないかなーというのがちょっとだけGraphQLでAPIを作った自分の感想です。

f:id:suzan2go:20181120234450p:plain
GraphiQLの画面

*1:この言い方が正しいのかわからないけど

「レガシーアプリケーションのリニューアルにNuxt.jsで戦う」というタイトルでVue Fes Japan 2018 Reject Conferenceに登壇してきました

vuejs-meetup.connpass.com

VueFesにCFPを出したんだけど、残念ながら採択されず・・・・・・だったのですが有り難いことにReject Conferenceに登壇させて頂くことができました。

VueFesで公開されている資料がすごいものばっかりだったので、発表資料の作成は本当に難儀しましたw いろいろ考えましたがVueFesで公開されている内容とかぶっているところは潔くそちらにフォワードする形式にしました。会場でもややウケだったのでまあよかったかなと思います。 Nuxt.jsでのTypeScriptは変そうという認識の方が多いようだったので、その辺りは皆さんの参考になっていれば嬉しいです。

VueFes本番は家庭の用事で行けなかったので、自分がスポンサーで申し込んだビールに対面できました!感動!(スポンサーしただけなのでデザイン等には一切関わってないですがw)

また懇親会で、「弊社さん最近めっちゃイベントで見るようになりました(意訳)」と言われたのが凄く嬉しかったです。会社の対外的なプレゼンス上がってきてるなら嬉しい・・・・・・

来年もVueFesやるということなので、来年は採択されるようにVueを書き続けたいなと思ったのでした。やるぞー!

「チームが機能するとはどういうことか」を読んだ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

一ヶ月くらい前にnaoya_ito さんの記事を急に思い出して読んでみたらとても良い事が書いてあった。この本は、資料の参考文献で強くおすすめされていたので買って読んでみた。

まとめ

プロセス知識スペクトル

この本で繰り返し言われているのは、仕事の中にも「知識の成熟度」と「不確実性」に応じてルーチンの業務、複雑な業務、イノベーションの業務 があり(本の中ではプロセス知識スペクトルと言われる)、それにより適切なチーミングと学習のあり方を変える必要があるということだった。新規事業のような不確実性の高い仕事と、書類仕事のような手順の決まりきった仕事では、当然ながら仕事の進め方や許される失敗は異なる。当たり前のことではあるのだけれど、自分の業務がどういう位置づけのものなのか、このような分類を意識して考えたことがなかったので新鮮だった。

心理的安全

今でこそ「心理的安全が大切」というようなことはよく言われているのだけれど、なぜ心理的安全が大切でそれによってどんなことが実現されるのか、といったことをきちんと説明してくれている。また心理的安全な環境を生み出すには、リーダーがどのような行動を取る必要があるのかということも記載されている。紹介されているリーダー行動のなかで、個人的には以下が特に重要なんじゃないかと思う。

  • 現在持っている知識の限界を認める
  • リーダーが自分もよく間違うことを積極的に示す

エンジニアに限らないけど、リーダーになるような人はプレーヤーとしても優秀な人が多く、チームメンバーからすると「とりあえずリーダーの言うことに従っておこう」となりがちなんじゃなかろうか(※自分はあまり思ったことないけど、そんな雰囲気を感じるチームは見たことがある)。

境界を超える

組織のなかでチーミングをするときによくある3つの境界として以下が紹介されている。

  • 物理的な距離・・分離による相違
  • 地位・・・格差による相違
  • 知識・・・多様性による相違

個人的には知識による相違について説明している箇所に頷くポイントが多かった。設計・モデリングをするときに、登場人物の関連図やユースケース図を関係者でワークショップ的に作るということをやると、システムに対する理解度が圧倒的に上がって、その後の開発がとてもやりやすくなった経験があるんだけど、こういった図・試作品をバウンダリーオブジェクトというらしい。バウンダリーオブジェクトを使うことで、職業や専門知識による境界が取り払われやすくなるらしい。

フレーミング

またこれまで「目標はワクワクするものがよい」ということを何となく思っていたのだけれど、それはフレーミングというものだったんだなーということがよく分かった。

著者がMICSという新しい医療技術を導入するというプロジェクトを調査した結果、成功したプロジェクトはフレーミングが異なっていたそうだ。フレーミングとは一言でいうと「プロジェクトをどのように解釈するか」ということだと思う。成功したプロジェクトではリーダーが、新技術の導入を「患者の利益」「チームの能力を高める」といった目的で捉えていたのに対し、失敗したプロジェクトでは「世間に遅れをとらない」といった後ろ向きの目的で捉えていた。目標が前向きなチームでは「患者が少しでも早く快復する手助けするときのワクワクした気持ち」を感じたり、「自分たちの可能性を試す機会」とメンバーは考え、積極的にプロジェクトに関わり助け合っていた。

これは自分がちょうど最近まで関わっていたシステムリニューアルのプロジェクトがそうだったと思う。単純に「レガシーなアプリケーションがメンテ不能になったのでリプレースします」ではモチベーションを保つことが難しかったと思うが、「レガシーなアプリケーションをモダンな技術を使って社内外に誇れるアーキテクチャにしていく」という目標(まあ明にこんなことを言われてたわけではないのだけれど、そんな雰囲気はあった)があったからやっていけた感はあった。

感想

決して読みやすい本ではなかったのだけれど、最近よく言われていることが体系的にまとめられており、学びがあった。これを読んだ上で naoya_ito さんの資料を見てみると、あーこれはこの本からの話かーというのがいくつかある。naoya_itoさんの資料にも、文化を変えようとすることは悪手だと書かれているんだけど、この本にもまさになことが書いてある。

学習する文化は、新しい働き方―なおいっそう、相互依存し、ほかの人の仕事や必要性に気づき、向上しようとする働き方―を実践する副産物として現れるのであって、その逆ではない。

もっとこういう文化にしたい・・・といった話は大なり小なり今の組織でもこれまでいた組織でも上がってきたんだけど、結局のところ今目の前にある仕事をどのように行っていくのか、その働き方を変えていく、なぜ働き方を変える必要があるのか同意する、というプロセスを踏まないと文化は変わっていかないんだなー

特にソフトウェアエンジニア向けの本というわけではなく、本書の中の例でもソフトウェアエンジニアの例が出てくることは殆どない。スクラムアジャイルといったキーワードも登場すらしていないんだけど、これらの文脈で出てくる話と類似するものが多いのはちょっと驚いた。

コンサルを超える問題解決と価値創造の全技法 を読んだ

コンサルを超える 問題解決と価値創造の全技法

コンサルを超える 問題解決と価値創造の全技法

普段はこういう本はあまり買わないのだけれど、新幹線に乗る直前でスマホの電池があと僅かだったので、暇つぶしのために買った。

感想

買う前の期待値が大分低かったせいか、すごく面白く感じた。特に分析や戦略を考える上でコンサルがよく使うらしいフレームワークについて、ある程度網羅して記載されているのがよかった。7Sとか社内で何回か聞いたことあったけど、マッキンゼーの手法だったのね。

単純にフレームワークを紹介するだけでなくて、そのフレームワークを使ってどのように問題解決を行っていくか書かれていたのもよかった。正直こういったフレームワークみたいなの、使っても何か自明じゃんみたいなことしか分からないことが経験的には多くて、あまり信頼してなかったけど現場で使うときの視点というか考え方がわかったのがよかった。

例えばMECE。そんなん見方によっていくらでも分け方あるし、なんならうまく分けられないことのが多いやんーと思うことが多く、MECEを徹底的にやることに何か意味があるのかと思っていた。本にはずばりこれについて書いてあって「MECEに分ける目的は、それを完璧に行うことではない。むしろ、うまく切れないところから、違う答えが見えてくるところにこそ、勝ちがあるのだ。」とあって感心した。

他にも、マトリクスで物事を捉える方法についてなど、フレームワークについて一般的な説明だけでなくて、それを使っていかに問題を捉えるかが割と実践的に書いてあったので、こういう本では珍しく仕事で活用するイメージが湧くものが多かった。

一方で、偉人的な昔話とか、マッキンゼー VS ボスコン的な話は、ちょっとアレな感じ……

コンサルが使う思考のフレームワークを網羅的に浅くどんな感じか知りたい人は、読むと面白そう。一方で、こういった本をいくつか読んだ事がある人にとっては一つ一つの掘り下げは割とあっさりしたものなので物足りない内容かもしれない。