こんにちは。プラットフォーム開発部 EMのchikaです。
昨年出版されてあちこちで話題になった「世界一流エンジニアの思考法」を読んだのですが、参考になるなぁ！社内のみんなにも知ってもらいたい！と思ったところがたくさんあったので、いくつか取り上げて感想交えて共有したいと思います。
この書籍について
本書は、マイクロソフトでエンジニアとして働く著者が日々仕事や自己研鑽の中での学びや気づきをブログ・noteに書いていたものを再編して書籍にされたものです。
simplearchitect.hatenablog.com
記事自体がすごく良くて、SNSやはてブでシェアされることも多いので、読んだことがある人も多いと思います。
これだけ日々の気づきを現場感がたっぷりと伝わるように、かつ読みやすく言語化しているものは見事だと思います。自分もそのような発信を見習いたい…
ということで以下、共有したいと思ったことを書きます。
個人の自己研鑽やキャリアを考える上で参考になる学びもたくさん書かれていますが、今回は特にみらい翻訳でも取り組んでいるアジャイル開発、リーン開発を実践する際のプラクティスとしてもよく言われるようなことを思考法として活かしているものがあるなと感じたので、いくつか印象に残った点を取り上げて、気づいたことなどを書こうと思います。
ウォーターフォールはやめておけ
本書の中で紹介されているサム・グッケンハイマー氏の一言は、著者には衝撃だったとブログにも書かれていますが、私も含め、日本のソフトウェア業界にいる方には大なり小なり刺さるのではないでしょうか。
「ウォーターフォールは一切メリットがないので、やめておきなさい」
みらい翻訳の開発現場ではスクラムを用いたアジャイル開発を志向しています。ただし、その浸透度、習熟度はまだまだだと感じるところも多いですし、WBS・ガントチャートで全体スケジュールと進捗を管理するようなウォーターフォール型のプロジェクトが必要になるケースもあります。
なので、私の中ではアジャイル or ウォーターフォール は「プロダクト開発はアジャイルを基本とすべきだが、一部のプロジェクトではウォーターフォールが合っていることもある、ケースバイケース」くらいの意見だったのですが、そんな中でのこの一言。
正直なところ「え、そこまで言い切って良いんだ...」と少々驚きましたが、同時に世界のソフトウェア開発に対する自分のトレンド認識が甘かったことを理解しました。
言い訳を挟むと、私が「一部のプロジェクト」と言ってイメージしてたのは、作る（構築する）ものがほぼ決まっているサービス導入系やプラットフォーム移行などのプロジェクトで、かつ動かせない（動かすのがとても困難な）納期が初めから決まってしまっているような性格のものなので、そのようなプロジェクトはそもそもここで議論される「ソフトウェア開発」の対象ではないのかもしれません。
ただ、自社プロダクトの開発であっても納期・スコープが固定されてウォーターフォール的な管理になってしまったり、アジャイルがなぜか「納期をコミットしようとしない、ぬるい考え方」のような見られ方をされがち、というのに同意していただける人は多いでしょう。それだけ日本でのウォーターフォールの存在感はまだまだ大きいです。
なので改めて「ウォーターフォールよりもアジャイルの方が良い」ではなく「ウォーターフォールはやめておけ」と言われてしまうほど時代錯誤に思われているということは日本人全員が知っておくべきだと思います。
simplearchitect.hatenablog.com
優先順位の付け方について
次に「優先順位をつける」のイメージについての日米差の言及についてです。
「バックログに優先順位をつけて優先順位の高いものに集中しよう」としたときに、日米で以下のように捉え方が違うと説明されていました。
- 日本人「全部はできないから、優先順位をつけて、どうしてもできないものは無理だから実施しないようにしよう。でも時間が許せば全部実施したい」
-
海外（アメリカ人）「最初の１個をピックアップしたら他はやらない。その１つにフォーカスしよう」
日本人の考え方、すごくよく分かってしまう 笑
チケットや一覧の全てに優先順位をつけようとした、あるいはそのように命じられたこと、ありませんか？
アメリカ人の「最初の1個をピックアップしたら他はやらない」は、読んだ当初は単に「並行で着手しない」ということかと思っていましたが、そうではなく、着手するタスク以外のものには順番付けすらしないということです。
「順番くらいつけておいた方が良いのでは？」「場当たり的で計画性がないように見えない？」と思ってしまう方も多いと思います。
しかし、一通りの優先順位を付けるだけでも時間がかかる ということ、そして最初の1つが終わる頃には時間をかけて決めた優先順位が変わっている可能性がある ということを踏まえた上で、それでも優先順位づけに時間をかけるか、どこまでやるかを判断するべきでしょう。
不確実性を受け入れる
筆者が、「日本人がもっとも苦手とする分野の一つかもしれない」と述べているのが、「不確実性を受け入れる」思考で、その背景として、不確実性を忌避しようとする文化的性質があり、丁寧に計画することに時間をかける傾向があるということです。
一方、米国では「納期は柔軟」であり、QCDS（品質・コスト・納期・スコープ）のトレードオフスライダーの１つでしかないということです。
それがよく伝わる著者の考えや同僚のセリフが挙げられていましたので一部抜粋しました。以下を読んで耳が痛い方もいるのではないでしょうか。
-
「無理して機能を完成させなくて良いから、品質の良いものを作るようにしようよ」
-
「楽に達成できる」計画で仕事をする
-
「なるはやで」「明日までに」というような火急な依頼はマネジメント能力の欠如とみなされる
-
計画は単に「見通しを立てて、仕事を進めやすくするため」のものでしかない。計画通りが良いという思考は捨てたほうが良い
-
-
寛容になりたかったら自分自身へのルールも緩やかにしてしまったほうが良い
-
「無理を承知で」のお願いの連鎖はみんなの疲弊を生み、チームや組織の業務改善に全く繋がらない
-
生産性を上げるには
「生産性」という言葉をイヤというほど耳にするようになった昨今ですが、本書でも仕事の生産性・効率化に関していくつかポイントを挙げて説明されていました。
生産性とはいかに考えずにできる仕事を増やすか
著者は仕事の難易度をレベル1〜4の4つに分けて分類し、レベル2以上がググったり、他の人の協力を必要としたりしてある程度時間がかかる仕事であるのに対し、最も難易度の低いレベル1は何も見ずにすぐに片付けられるため脳の負担が少なく楽にこなせる仕事だと定義しています。
そして生産性を上げるには、いかにこのレベル1の仕事を増やせるか、言い換えるとどうやってレベル2の仕事を、調べたり考えたりせずに即片付けられるレベル1相当に向上できるかが鍵だと説明されています。
私はこれを読んだ際に他の方のブログでもほぼ同じようなことを述べられているのを思い出しました。
まず効率化とは何か。
誤解が多い領域だが、これは、同じ仕事を「早くできるようになる」ではない。
（中略）
そうではなく、本質的には効率化とは、「考えなくてもできるようにすること」である。
（引用：仕事の効率化とは「考えずにできるようになる」こと。 | Books&Apps）
生産性や効率化といったテーマに取り組む際に、あらゆるところを振り返って無駄なところを探したり、全てを早くしないといけないのでは考えてしまったことがある人もいるではないでしょうか。
そういう時にまず最初に「考えずに片付けられるようになる可能性が高い仕事はどれか？」という観点は参考になるのではないでしょうか。
常にWIP=1
ここで数値化されているWIP（Work in Progress）とは同時並行に進めているタスクの数を示しており、ご存知の方も多いかと思います。
本書では、個人の仕事の進め方として、このWIPを常に1つにすることが重要だと強く主張されています。
-
どんなに忙しくても一度に一つのことしかしない
-
マルチタスクはどんな人にとっても生産性が悪い
紹介されているエピソードとして、「世界トップクラスのプログラミング力の持ち主」である著者の同僚が、どんなに忙しくても一度に一つのことしかしない、それでいて驚くほど生産性が高いということを書かれていて、説得力があります。
WIPについては、カンバンを用いるリーン開発でこのWIP数の上限を設けて並行タスクを抑えることが、フロー効率を上げるために重要なプラクティスとされています。フロー効率については過去に以下のエントリでまとめているので、参考にしていただけると幸いです。
miraitranslate-tech.hatenablog.jp
タイムボックス制にする
著者が学習の時間を確保するために、強制的に定時上がりと定時就寝をセットにして実践してみた結果、学習時間の確保ができただけでなく、仕事の生産性が上がったというエピソードを紹介していました。
実践した際のポイントを以下のように挙げられていましたが、私はこれがグサグサと刺さるので、自戒を込めて共有させていただきます。。
- どんなに切りが悪くても時間が来たらすぐに仕事をやめる
- 「完了」に焦点を当てない。予定はあくまで予定なので、タスクが終わらなくても割り当てた時間内でやめる。区切られた時間で集中する
（余談）開発生産性について
ちなみに、エンジニアの話における生産性というと、物的生産性？ or 付加価値生産性？ などその定義に疑問が生じやすいですが、ここで取り上げられている生産性はエンジニア個人の作業量・スピードに焦点を当てているので、物的生産性（物的労働生産性）の方を指しています。
完全に余談ですが、チームに求められる開発生産性については以前投稿した以下の記事を参考にしていただけると嬉しいです。
miraitranslate-tech.hatenablog.jp
さいごに
この記事に書いた他にも参考になる見解がたくさんあり、大変参考になるので、オススメです。まだ読んだことがない方で本記事で興味を持たれたら、ぜひ読んでみてください！
We are hiring!
みらい翻訳では、私たちと一緒に翻訳プロダクトの開発を進めていただけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
