Microsoftで働き方改革を評価された専門家の仕事の考え方とは？

本日は久々に、1冊の本を紹介したいと思います。

今回紹介する本は「すべての仕事を3分で終わらせる――外資系リーゼントマネジャーの仕事圧縮術」という本です。

岡田さんはダイヤモンド・オンラインで連載をお持ちで、編集者さんから情報を頂いて初めてみたときに、そのルックスに吹き出してしまいましたが、実際にお会いすると、見た目とは違って、とっても温厚で優しい雰囲気な方でした＾＾；

（ダイヤモンド・オンラインの連載は以下ＵＲＬよりご確認ください）
http://diamond.jp/category/staygold
　　
　　
マイクロソフトという事で、元々エンジニアもされていたこともあって、読んでいくなかで、個人的には「またＳＥやりたいかも…？」と思いながら見る感じになりましたが、内容も共感できる部分が多かったので、そのなかでも個人的にも重視しているポイントを3つ挙げてみたいと思います。

3分で終わらせる作業の見積り方

本の中で「仕事の9割は3分で終わる」という見出しがあります。

「そんなわけないやろぉ～」と思ってしまいそうな見出しですが、逆に「3分でどこまで完了させられるか」といった目線を持って考えると、3分で終わる範囲のタスクを処理することになるので、不可能にはならないのかなと思っています。
　　
　　
このあたりの文章を読んでいるときに思ったのが、作業工数の見積もり方についてです。

一般的には、達成したい目的に対して何の作業タスクがあって、それぞれの作業タスクに対してどのくらいの時間がかかるのか？という観点で作業時間を見積もると思います。

これを、達成したい目的に対して、3分で完了できるタスクを積み上げて、いくつのタスクができるのか？といった観点で見積もる（作業起点で時間を見積もるのではなく、時間起点で作業量を見積もる）ことで、細かく作業タスクを切り分けることができるようになるのかなと思いました。

拙著『すごい読書術』でも、1冊が読み切れないならば、集中力が続くところまで読み切ることを繰り返して、1冊を読了することを勧めていますが、それと同じことなのかなと。

このような作業見積の目線を持って細かく作業タスクの区切りをつけていくことで、作業が終わったときの完了感もありつつ、集中力も維持できるようになり、生産性も高まるのだと思いました。
　　
　　

まずは60点を目指す

本の中で「仕事はまずは60点を目指す」という見出しがあります。

私自身も似たような考えを持って作業を処理する傾向があるのですが、私がこの考えになったキッカケはＳＥ時代のときでした。
　　
　　
システム開発の手法は大きく2つに分けると、「ウォーターフォール型」と「プロト型」というものがあります。

「ウォーターフォール型」というのは、マイホームの建設をイメージしてもらうとわかりやすいかもしれません。まずはじめに「どんな家を作るのか（設計図）？」を決めて、それが決まったら「どうやって作るか（施工法）？」を決めて、その後、実際の建設に入っていく流れで作業をすることです。特徴としては、施工法を決めているときに、既に決まった間取り図を変えることは厳禁となり、まさにウォーターフォール（流れ落ちる）ように作業を進めていくところにあります。

それに対して「プロト型」は、アプリ開発をイメージしてもらうとわかりやすいかもしれません。ラフ⇒モックアップ⇒プロトタイプと、完成イメージの現物をテスト版のような感じで作成しながら、何を作るのか（設計図）を決めていき、決まった後はウォーターフォール型と同じく、実際のモノを作っていく流れになります。
　　
　　
違いとしては、設計図を作る過程で、空想イメージ（紙面上）で「何を作るのか？」を決めていくのか、実際のモノやサービスを動かしながら決めていくか、という部分になります。ウォーターフォール型では、次の作業に入った時点で設計図を変えることはできないので、設計図を確定させる段階で100点を目指す必要が出てきます。

対してプロト型では、実際のモノこそつくるものの、モックアップやプロトをつくっている段階では最初から100点を目指す必要がなく、60点でもいいのです。最終的には100点を目指すことになるのですが、「まずは60点」という気持ちになれると、精神的には相当楽な状態になれます。
　　
　　
これはシステム開発に限らず、通常の作業でも同じことがいえると思って以来、私も60点を複数回回転させて100点に近づけていく作業スタイルになりました。

精神的に追い詰められている状態と、精神的に余裕を持って作業ができる人、その時点でどちらが高い生産性を発揮できるか？

もちろん精神的に追い込んだほうが力を発揮できるという体育会系の方もいらっしゃいますが、私は完全に後者ですね･･･＾＾
　　
　　

すべての作業は共通項が多い

本の中で「すべての作業には共通点が多い」という見出しがあります。

これもＳＥ時代に感じていたところで、私は主に農業系分野のシステム構築をやっていましたが、それだけではなく、まったく異業種のシステム開発をやる機会もありました。
　　
　　
結局のところビジネスをやっている会社はすべて、原材料を仕入れて、それを加工編集して物づくりをして、つくったものを売るという、3つの作業をやっています。

実際につくるものが変わると、仕入れるものや売り方も変わりますが、大枠としてやっていることは変わらない、つまり大枠で考えれば分野は違えど、どの作業にも共通項のあるほうが可能性は高いということになるのです。

ブロガーでたとえるならば、ネタを仕入れて、自分なりの言葉でコーディングして、ＳＮＳなどを使って拡散する（売り込む）といった感じです。
　　
　　
よく新入社員で入った方に「3年は続けろ」的なことを言う上司の方がいますが、その意図はこのあたりにあるのかなと考えています。

共通項の土台は上記のような感じではあるものの、それが具体的な特定分野に乗っかったときに、それぞれのプロセスがどのような細かい作業で構成されているか、経験を通じて体得して、1つの分野での軸ができることで、その後は異業種であっても応用が可能になってくるのだと思います。

もちろん人間関係が悪い環境に耐えながら3年続ける必要はまったくないと思いますが、キャリアアップの観点では、このような視点を持ちつつ、軸を作ることは後々の応用に大きく効いてくるように思います。
　　
　　
直近の私でいえば、このような応用をしてきた分野としては出版があります。

出版の過程でやっている作業それぞれに対する考え方は、ＳＥ時代の経験と照らし合わせながら、「プログラムテストの観点でバグはないか…？結合テストの観点でバグはないか…？」といった感じでゲラチェックをやっていますね＾＾；
　　
　　

　　
特にＩＴ系業界でお仕事をされている方には、かなりイメージ変換しやすい文章になっていると思います。

もちろん、書かれているメソッド自体はどのような業種にも適用可能な内容となっていますので、まずは一度読んでみることをおすすめします。