こんにちは。くろしばです。今回は本の紹介です。最近は日本の生産性がーとか、アメリカではー、とか何かと日本下げ、アメリカ上げなトピックが多いですね。
この本も例に漏れず舞台はアメリカのテック企業なのですが、そこまで卑下するような内容ではなく、前向きにアメリカでここがいい感じだったよー、取り入れてみたら？てきなライトな感じです。
エンジニア系のタイトルではありますが内容はエンジニアでなくても読めるようになっています。
スポンサーリンク
まずは本の紹介
ざっくり言うと
天才タイプではないエンジニアが努力を重ねてMicrosoftのエンジニアになってみた結果、
アメリカのトップ企業の働きっぷりは参考になるなー、よし、吸収できるものは全部してみよう！
的な活動のレポートのような本です。
Microsoftというと特にエンジニアの人は尻込みしてしまうかもしれませんが、意外と僕のような庶民でもその日から試せるようなエピソードばかりでとても参考になりました。
概念的な抽象本ではないのですぐに自分の実生活と結びつけることができます。
これ以降はポイントになる内容をカテゴリ別に分けてつらつらと挙げていきます。
本の要点はこんな感じ
仕事への向き合い方
・頭が良くても理解には時間がかかることを理解する
会社で仕事をしていると、なんでこの人こんなスピードでこんな難しいことを正確にこなせるんだ、、自分とは頭の作りが違うな。と思ったことがある人は多いのではないでしょうか？
このことについてシンプルに頭が良くても理解には時間がかかることを理解することが大事です。天才に見える人も実は正確に理解するのにはしっかりと時間をかけているのです。
凡人な自分は「あー、こんなに時間をかけて理解しにかかったら今日は何も成果がないなー」なんて思いがちですが、実はできる人との分かれ目なのはこっち。
できる人は脳みそが違うわけではなく、「難しいのきた。これはじっくり理解しないとスタート地点に立てないな。よし理解しよ。」これを素直に受け入れてるだけなのです。
それに付随して次のポイント
・ 短期で成果が上がっていないことに焦らない習慣
月給や年俸で評価される仕事ではそのスパンで成果を上げることを意識することが大事です。1週間やそこら成果が出なくても焦らないことが大事。
複雑なシステムを相手にするなら、じっくりと調査して、その基盤があるからこそ成果を上げることができると捉えるべきなのです。
日給や時給の場合も実は長期的な成果の方が大事な場合もあります。
契約上計算しやすいから自給になっているだけで求められている成果は1時間単位ではないという仕事は多いと思います。
例えば飲食店のアルバイトだって書類上は明文化されたオペレーションをこなすことに対して1000円前後の対価が支払われることになっているかもしれません。
しかし常連さんのお話にお付き合いして気持ちよくお帰りいただくことでリピートが生まれ、売り上げに貢献することだって立派な成果です。
むしろそちらの方が価値がある場合がほとんでじゃないですか？
その日1日何もアウトプットが出なくても、中長期でアウトプットを出すことを目指し続けることがうまくいく秘訣です。
・マルチタスク厳禁
何事にも最優先の1つだけをピックアップし、全力で。あれもこれもやろうとするとパフォーマンスは上がらないのです。
著者が経験した職場では、「で？どれが1番大事なの？」という意識が強く根付いていたようです。
100のうち10しかインパクトを与えることができないタスクを残業しながらこなしていくよりも、70のインパクトを持ったタスクを正確に洗い出す。
それが完了したら退勤して飲みにいく。
こうすること余計なことは考えず短時間でより多くのパフォーマンスを上げることができるのです。
成果の合計値よりもタイパを重視する思想とも言えそうですね。
大事なことが終わったらきちんと仕事を切り上げることも実はとても大事で、これが次に仕事に立ち向かうときのエネルギーを溜めてくれるわkです。
この思考回路が持続可能なライフワークバランスを保ち、より高いパフォーマンスをあげることにつながります。
次にもつながりますが、長時間労働はサステナブルではないとのこと。
・時間には必ず誓約を
最近はアジャイル開発(スクラム)でも注目されている時間制約の概念です。
一定の時間のみ集中して作業に向き合うことを決め、達成してもしなくてもそこで一旦区切ることが大事と言う考え方です。
これは身近な例で言うと週末の使い方に置き換えることができそうです。
土日暇だからあれもこれもできるな、と思っていていざ週末を迎えるとダラダラしてしまうことってありますよね。
いくら時間があっても2時間でこれを終わらせよう、そしたらあとはダラダラしよう、と決めしまうのです。
1日フルで頑張ろうとするとなかなか行動に映せなかったり中弛みしたりしますよね。
でも2時間しかない！となるとその2時間の集中力って結構上がりませんか？
これをうまく利用するのです。ポイントは時間内に終わらなくても延長しないと言うことです。これを守らないとタイムボックスの意味が崩壊してしまいます。
健全な状態で仕事に臨む
健康面については専門的な話を除くとこんな感じになります。
・テストステロン大事
とりあえずパワーが沸いている状態で仕事に臨むことが大事。パワーっていうのはテストステロンだ！
筋トレ(無酸素運動)をして、ちょっと息が上がるくらいランニングをして(有酸素運動)、たまねぎ肉魚卵レバーあたりを食らう。
・寝る
徹夜で頑張る時代は終わりました。しっかり寝てこそ最高のパフォーマンス。先ほどの短期で成果を上げようとする発想に似てるかもしれません。
・ディスプレイから離れる
ディスプレイから離れる時間を意識的に作ることが大事。イノベーションはディスクプレイをみていない時間に生まれます。
・瞑想
難しそうに聞こえるかもですが、要はPCでいうところの常駐プログラムを切ってCPUとかメモリを一旦低稼働にしてあげる感じです。
脳みそもずっと考え続けてると次の処理にスムーズに移れません。定期的に、意識的に無に近い状態を作りましょう。
エンジニアリング
エンジニアの職域にフォーカスした内容です。
・バグ改修は仮説を立てる
調査をするのに思いつくがままにログやソースをぼーっと眺めてしまうことってありますよね。
これでは効率的な調査や検討はできません。
Microsoftのでき男たちは、じっと考えて、この事象はこれに起因しているのでは？という仮説を立てから手を動かすそうです。
その仮説が外れればまたじっと考えて次の仮説。その仮説の実証に必要なスキルが不足していればその部分を人に頼ったりします。
解決までのストーリーが明確になることによってダラダラ当てずっぽうの調査をする時間を0にするのです。
・メンタルモデルの構築
数年以上経験のある人であればこの感覚がある人が多いのではないでしょうか？
長く関わったサービスと新しく参加したサービスへの"自分ならできる感"の違い。
このフワッとした感覚がエンジニアをやっていく上では非常に大事な要素でこの感覚を メンタルモデル と呼んでいるのだそう。
メンタルモデルが構築できていないサービス、プロジェクトの問題に丸腰で挑んでもいい成果はでません。
ドメインエキスパートに聞けるものはすぐ聞く。自分で考えて調べても無駄。この思考を持つ必要があるのです。
メンタルモデルは 理解、解釈、新しい状況に適応するためのマインド と定義することができ、これこそが仕事を進めていく上で最も大事なことなのです。
・できないことは頑張らない
メンタルモデルの話とも少し被りますが、
できないタスクには無理に立ち向かわないことも大事です。
なぜなら今はまだできないのだから。
そういった時は一段原始的な課題と向き合う姿勢を保つことです。
例えば、
バグの原因がわからない → ドメイン知識が足りていないから調査の仮説が立てられないのでは？ → まずはドメイン知識を理解する課題に向き合う
このように自分が届かない部分と戦うのではなく、戦うべき問題と戦うことを意識します。倒す相手を間違わないことがうまく仕事を進めていくコツです。
・理解が浅い知識は記憶されない。
サービスやシステムの仕様を質問された時に即答する人といつ聞いても調べないとわからない人っていますよね。
これって記憶力の問題というよりは理解の深さの問題なんです。
序盤の内容と被りますが、近道せずに実直に複雑な仕様の理解を乗り越え続けることで深い理解が手に入ります。
これを持っている人は記憶を引っ張ってくる紐の強固さが違うので、まるで暗記しているかのような即答ができるいうわけです。
理解をするときの目安としては、人に説明できるレベルで理解することです。
チームとして
最後に組織の作りについてです。
アメリカのプログラマーの給料が高いことは有名ですが、これには訳がありました。
そもそも日本のプログラマーとは職域の広さに差がありそうです。
ざっくりいうと
<アメリカ>
ざっくり管理、あとは作業者で考えて進めてね。方法は問わないけど何がサービスにとって1番の貢献なのかを考えて進めてね
<日本>
マイクロマネジメント。ここはこういうふうにしてね。いつまでにやってね。いまどれくらいできてる？いけそう？きつそう？
この違いがあります。プログラマーに任されている範囲が「書くこと」を大きく超えて考えることも含まれているようです。
システムは全体最適が大事なので、これではここの作り方がバラバラになるのでは？とも思ったのですがそれはコードレビューでカバーされているよう。
西洋は日本と比べ必要な批判は是々非々で行う習慣があります。
遠慮して先輩にコーディングの指摘をできない、なんてことは起こりづらく優秀なエンジニアたちによって闊達な議論がGit上で繰り広げられます。
その結果手戻りが発生しても「気づけてよかったね！オレたちの勝利だブラザー」←(本ではこんな書き方してないです。)的な前向きな発想でチーム内の開発方針も正しい方向に進んでいく仕組みがあるというわけです。
マイクロマネジメントはもはや必要なく、文化と技術と仕組みによってプログラマーがシステムを理想の方向に進めていくことができます。
まとめ
思ったより長くなってしまいましたが本の要点は以上です。
今すぐ実践できるものとそうではないものがあるかもしれません。
しかし、自分なりの理想を持って成果を出さればきっと今のチームや上司に影響を与えることができると思います。
短期で激変させるのではなく実直にアクションを起こしてみるのが大事かもしれません。
自分の今参画しているプロジェクトのマネージャーはこれに近い思想をもってチームを運営しているように見えるのでガンガン実践してみようかなと思っています。
ではでは( *｀ω´)ノ
スポンサーリンク
