プログラミングというより物事が出来る思考法～実践編
大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。
私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。
タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。
上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それから時間がたって実践もしたが今でもこれは凄く自分に役立っている。
Paulは絶対に理解を見逃さない
私は米国で、マイクロソフトの Azure Functions というサーバーレスのプラットフォームの開発チームでプログラマをやっている。その中で私が顎が外れるぐらい何回もびっくりしているのがPaulというエンジニアで多分私が人生で会った中で最も賢い人だ。
優秀な人の多いチームの中で、他の優秀な人からソフトウエアの設計や難しい問題の解決で頼られている。三流エンジニアである私からすると天上人だが、そんな彼の行動にふと気が付いたことがある。彼は絶対に自分が理解していない状態を見逃さないのだ。
ミーティングやディスカッションをしている時に自分だったら「まぁ、他の人が理解しているんやったら、わし理解してなくてもええやろ」みたいな場面でもPaulは絶対にこういうことに気づいた。
Sorry, I don't understand. The reason is …
Let me clarify my understanding …
Paulは何か自分が理解できなかったら、会議中にそれを絶対に見逃さずに、理解できるようになるまで、何回も質問をして理解するように頑張る。
また、何か不明確なことがあった時も上記のようなフレーズを使って「ごめん、よく理解していないんやけど、私の理解では・・・という事やと思ったんやけど、あってる？」といったセリフをよく使って、少しでも自分が「ふわっ」としたことがあれば明確にしてくる。
よくよく考えると、Paulじゃなくても、周りの多くの優秀なマネージャやエンジニアは皆これをやっている。自分が理解できてない状態を絶対に見逃さない。もう既に会議中に時間をかけて、理解して、「理解できてない」という状況を会議中にもう解決しているのだ。そして、そのことに誰一人イライラしたり、うっとうしがったりする人もいない。多分みんな気づいているのだ。「理解は時間が掛かるけど、これをすることでこの後の生産性は爆上がりする」とわかっているので、誰もそこに時間をかけることに渋い顔をする人はいない。
Pragnaは、理解に１時間かけても急がなかった
また、この前印象的だった出来事だが、私のマネージャのPragnaもやはり理解に時間をかける。Pragnaは私たちが作業が遅れても絶対にせかさない。そうなのだが、実はそれは自分であってもそうのようだ。恐らく彼女はエンジニアリングにおいて、急ぐとろくなことがないと骨身にしみているのだろう。彼女は多くのメンバーを抱えてるのに、我々がやっていることを完全に把握して、問題をアンブロックして、サポートして、優先順位付けを明確にしてくれる。
あるとき、インシデント（障害）が発生して私が対応した。その根本原因（RootCause）はかなり複雑なものだった。私が担当したので私は理解している。それをRetrospectiveという障害が起きたときに振り返りをして障害の再発防止と自動化を推進する会議があるのだが、そこでの議題にあがっていたので私が発表する必要がある。
このような時、私も参加するし、私に丸投げして振ればよいだけとも思うのだが、彼女は絶対に理解しようとがんばるのだ。彼女がどんなに忙しくても。ちょっとこれは衝撃だった。
「つよし、あの障害の件に関してよくわからないから、教えてくれない？」「いいよ、君がオフィスに来てるんやったら対面でやろう。ホワイトボードがあるとややこしいのも説明しやすいし」
私は彼女からいろいろ来る質問に対して、丁寧にホワイトボードで説明した。自分だったらあいまいなままほっておきそうな所も、彼女が「まだわたしはよくわかっていない」何回もいうので、そのわからない部分を聞いてまた説明していく。そんな感じのことをして気づいたらたった一つの障害を理解するのに彼女は１時間もかけて、しかも全く急ぎもしなかった。しかし最終的な彼女の理解は完璧だった。それは正直あんまり頭の良くない自分でも時間かけすぎやろと思うほどだった。だが彼女は当然という顔をしている。
ちなみに、彼女はめっちゃくちゃ忙しい。定時内はほぼ会議しかやってない位やし、夜遅くでもインシデントが発生したら率先して対応するし、何しろ１０人分ぐらいのメンバーの支援をしたり、アンブロックしているので、忙しくないはずがない。そんな彼女があわてることなく、人に丸投げしてもいいたった１つのインシデントを理解するのに１時間使った。後悔もなにもしていない様子だった。
Retrospectiveの当日、私は彼女の１０人いるチームメンバーの一人に過ぎないもかかわらず、彼女も一緒に会議にでていて、私が説明するのだが、私の説明に補足したほうがよいところなどを完璧にフォローアップして、仕事を完璧に遂行した。彼女はその後の各人のタスクの理解も常に完璧だから、本当に安心して自分の仕事に集中できる。
忙しいから「理解に時間を使う」
この「理解に時間が掛かる」というトピックは先日受けたインタビューでも「日本で導入が難しいもの」の一つに挙げられていた。ちなみに、PaulもPragnaもめっちゃくちゃ仕事しているし、忙しい人だ。もちろん暇じゃない。
でもそんな人でもなんでそれをするか？というと、そっちの方が「生産性が良い」からだと思う。エンジニアとしての矜持とかそういうふわっとしたものではなく、そっちの方が結局早いからそうしているのだと思う。いや、彼ら以外もみんなそうしている。新卒から、ベテランまでみんな「理解」の価値をすごく重く見ているように感じる。
どんな効果があるの？
私もすでに紹介したポストを書いた時点でこのことに気づき、自分でも理解に時間をかけるムーブをしている。周りの人みたいに完璧ではないが、それでもめっちゃくちゃ効果を感じる。具体的には次のようなことだ。
・昔は、「早く終わらせよう」としているので、理解が中途半端な状態でもの物事を進めるので、理解が浅く、自分が物事をコントロール出来てる感じが薄かったが、いったん理解すると、自信をもってこれでよいと思える
・ディスカッションにおいても、理解が浅かったのでわからなくても流していたし、対して重要な質問もできなかった。今は、理解が出来てないときは、デザインドキュメントをがっつり時間をかけて理解して挑むようにしたら、ものすごく深いディスカッションでもついていけて、Paulに褒めてもらえるような質問や指摘ができるようになった
・昔は他の人にまわわからないことがあっても、何回も聞くのを「わるいな」と思って躊躇していたが、今は気になるところがなくなるまで聞く。アーキテクチャの決定やなぜそうなったといったコンテキストや理由に確信が持てるようになった。
・プログラミングに置いても、昔と違って、１つでもわからなかったら調べる。Bingや、ChatGPTそして彼らは嘘ついている時があるので、元のリンクの情報（特に公式の情報）を読んで正確にそのメソッドをしらなかった、もしくはそのクラスを知らない場合、その公式ページを焦らず読むようにしている。すると、以前は、「この時はこの書き方ができる」という応用の効かない浅い知識だったものが、この別のパラメータを使うのはこういうときがいいなというのが理解できるし、内部挙動が気になったらデコンパイルして、中のソースを読んでみたりすることによって、自信をもってそのメソッドを使うことができるので迷ったり、何回も検索をすることがなくなった
などなど、上げればきりがないほどメリットがある。たった焦らず１回しっかり理解に時間を使うことによって、その後の加速度や、応用度が比較にならない。多分賢い人の仕組みはこういう積み重ねでできているのだろう。理解は絶対にコスパがいいと今になっては思う。そして、コスパ以上の「自分がコントロール出来ている」実感を得られるのも最高だ。
自分が会議の時間内に理解できないし、あまり流れを止めたくない時は？
とはいえ、おそらく読者の人も「自分の場合だと、会議の時間内にちゃんとすべてを理解できる気がしない」と思う人もいるかもしれない。正直私もそうだ。私は三流やし頭も良い方ではないので、時間が彼らより多めにかかる感じだ。そんな人はどうするか？というと単純で、会議が終わったあとに時間をブロックして、自分が理解できていないところを理解するようにしている。そういうケースで自分がする方法はこんな感じ。
・会議の内容を思い出しながら、自分で議事録を思い出しながら箇条書きで書く（これは記憶の効果を狙っている。詳しくは書籍に書いています）
・自分があやふやだったところを、AIが勝手に書いてくれる議事録を見ながら、「ああ、あいつらこんなこと言ってたのか！」と思いながら、わからない事は調べる。なんとも便利な世の中よ。ちなみに、BingやChatGPTがあるので、検索は以前より１００倍楽になっている。
・整理したノートはTeamsでみんなにシェアしても良いし、自分用のOneNoteに張っておく。忘れたら見返すことが出来る
という時間をブロックする。そうすると次回以降、飛躍的に理解度が高まるので、徐々にそんなことしなくてもよくなってくる。
日本でやるときはどうしたらいいの？
日本でもこの理解に時間をかけるプロセスはやっている人はやってるのではないだろうか？また、周りの目があって、定時内に理解に時間をかけにくいのであれば、定時後や休日に時間をかけて、「理解の時間」を取って、理解したい内容を時間をたっぷりかけて理解するのはどうだろう？確かにそれが許される環境に比べたらめんどくさいし、効率悪いがそれでも「理解」のコスパが結局上回ると思う。
たぶん私と同じような普通の頭の皆さんだと、なんでも全部理解しようとすると時間が無くなりすぎるということも発生するだろう。そんな時は「理解する」範囲を絞ると良い。範囲をかなり絞っても、「理解する」癖がつくとそのメリットが実感できるので、次に時間があるときにここ「理解」しようと思えるので自分に無理せず、理解出来ている範囲を増やすことができる。また小さなステップで習慣化できるのも見逃せない。
他のアイデアとしては、こういう「理解には時間がかかるけど、結局そっちの方が効率が良い」というのを周りの人にシェアするのはどうだろう？
具体的には自分で申し出て、部会とかで、発表するのはどうだろうか？いきなり、理解に時間をかけるプラクティスをし始めると、周りの人から「あいつはさぼってる」と思われるかもしれない。しかし、先に「こういう考えがあって、生産性を上げるためにやっている」と周りに理解されると。「あー、あいつはあれやってるんだな」とすくなくとも理解されるようになるので、やりやすさが以前と比べると圧倒的に高くなる。
もちろん上のマネジメント層を巻き込むとより有効だろう。しかし自分の部で発表するだけも相当違うだろう。（ちなみにこのプラクティスは私が日本にいるときに、何回もやってうまくいっているのでお勧めです）手前味噌だが、私の本はおかげさまで結構売れているので、「この本で紹介されていたマイクロソフトで実施されている生産性の手法だ」ぐらいちょっと盛って紹介してもいいだろう。結構文句言ってくる人はその手の権威によわかったりもするかもしれない。
まとめ
「理解に時間をかける」は、数ある生産性のTipsの中でもトップクラスに有用なものだ。ぜひ皆さんも自分で出来る範囲で実践して、エンジョイしてみてくだされ！