「抽象度」を意識しただけで仕事ぶりが激変した人を見た

サマーインターンで学生さんのバディをした

先日、会社でエンジニア向けのサマーインターンを開催しました。優秀な学生エンジニアを8人ほど受け入れ、4人ずつのチーム開発で社内プロダクトの追加開発をしてもらうイベントです。

学生さんひとりひとりには「バディ」と呼ばれるメンター社員がつき、困ったときの質問対応をしたりその日の振り返りを一緒に取り組んだりしていました。ぼくもYくんという学生さんのバディとして参加しました。

学生さんは困っていた

Yくんはめちゃくちゃ好青年で、チームを明るく盛り上げるタイプの人でした。全員が緊張して硬直しがちな初日のチームビルディングでも、自分から率先して喋ったり初対面のチームメイトに話をまわしたりして、場に居心地の良い雰囲気を作っていました。チーム開発では「チームの仲の良さ」がダイレクトに生産性に直結するので、とても重要な役割です。

初日から明るく活躍していただいてこちらとしても一安心でした。しかもYくんはまだ17歳というのだから驚きです。サマーインターンは基本的に就活生しか受け入れておらず、しかも今回のインターンは実践的な開発スキルを持っている学生さんしか募集していなかったのですが、就活の早期化で少し間口が広かったのと、Yくんは高専に通っていてすでに技術力を持っていたのとで、見事合格したのです。スーパー人材ですね。

しかし、そんなYくんでも実際の開発にはなかなか苦戦していました。それもそのはずで、インターンでの開発内容は業務レベルなので、要求内容が高いのです。Yくんに限らず他の学生さんも手こずっていました。

私はバディとしてYくんをじっと観察し、彼がどう困っているのか、どうしてそうなっているのかを考えていました。するといくつかのパターンが見えてきました。

まず、Yくんはざっとこんなふうに困っていました。

• やるべきことをいち早く把握したくて、たくさんの資料を右往左往する
• 色々情報を摂取した結果、結局なにをやればいいかわからずあたふたする
• とりあえず手を動かして試行錯誤してみるも、エラーに阻まれて足踏みする
• 質問して対処法を教えてもらい、とりあえずプログラムが動作するようになるも、自分の理解は置いてけぼりになる
• やっとのことで求めていたプログラムが書けるも、レビューで「方針がよくない」と言われて手戻りする

ソフトウェアエンジニアなら誰もが一度は通ったことがある悩みです。他の職種でも似たようなことはあるのではないでしょうか。自分がそうなった場合を想像しだけでも気持ちが暗くなってしまいます。

どうしてそんな状況に陥ってしまっているのか、Yくんにインタビューしながら考察してみると、いくつかの原因が見えてきました。

まず、インプットする情報が多すぎるということです。Yくんはまだ若く、技術的知識を身につけるのはこれからというところ。知識を整理するための基礎がまだしっかりしていない状態でたくさんの新しい技術的知識やプロダクトに関する情報が入ってきて、軽くパニックになっているようでした。

また、焦りもYくんを追い詰めていたようです。周りはYくんよりも年長者で、チーム開発にも慣れている人が多く、Yくんと比べると手際よく進めているようでした。しかもインターン期間には限りがあり、ただでさえ短い時間で成果を出すことを迫られます。試行錯誤して、できなくて、焦って、また試行錯誤して…という悪循環が生まれていたようです。

インターン2日目の振り返りでは「自分ってこんなに何もできないんだなっていう無力感とか悔しさが溢れてきて、泣きそうになってしまいました。」と素直な心境を語ってくれました。

「抽象度」という軸を授ける

さて、ぼくはバディとしてどうにかしてYくんを助けなければいけません。

ぼくの目標は「インターンが終わってからもずっと大切にしたい考え方を持ち帰ってもらうこと」でした。正直、インターン中の開発が上手くいくかどうかは社員からすると些細な問題です。そんな短期間のインパクトよりも、「インターンが終わってからのエンジニア人生」という長期間でのインパクトを重要視していました。

まだ若い中で厳しい環境に飛び込んでチャレンジしてくれているYくんには、技術的な知識を色々授ける前に、もっと根本にある視点を教えるべきだと感じました。そこで、いくつかの具体的なテクニックを通して「抽象度」という軸を授けることにしました。

読まないコードリーディング

まずぼくが教えたのは、「読まないコードリーディング」というテクニックでした。既存のプログラムになにか処理を追加するときには、まず既存のプロダクトを読み解く必要があります。この作業を「コードリーディング」と呼びます。「読まないコードリーディング」は、なるべくコードを読まずに済ませようという考え方です。

プログラムは「関数」と呼ばれるひとまとまりのコードをたくさん組み合わせてできているのですが、Yくんはコードリーディングをするときにひとつひとつの関数の中身をじっくり読んでいるようでした。「何らかの資料探しをしているときに、出てくる資料すべてにじっくり目を通す」というようなイメージです。これでは時間がかかります。

そこでぼくは、「関数を読むのはまず名前と型だけにしておこう」とアドバイスしました。「型」というのは「この関数を動かすにはどの種類の情報を必要としていて、動かした結果どのような情報が出てくるんだろう？」といった関数の大枠のことです。

例えば「getUserIcon関数（名前）、ユーザーIDが必要で、アイコンURLが返ってくる（型）」という関数があった場合、そこまでしか読まない。中身の「DBにアクセスして、データをこういう風に整形して…」という処理を追いかけて実際どうなってるのかを確かめるのをやめます。文章でいうと、「見出しだけ読む」という感じです。名前と型がわかれば関数の概要は把握できるので、その情報をもとに全体像を掴んでいきます。

これで何を伝えたかったかというと、具体性の高い「表層」を詳しく追いかけるのは時間がかかるよ、ということです。短い時間で進捗を出すために、まずはより抽象度の高い「構造」の部分に着目する。ざっくりとした理解で俯瞰する意識が必要になります。

画像引用：https://goodpatch.com/blog/how-to-design-the-elements-of-ux

実際に上の図を見せて説明したところ、Yくんはかなり腑に落ちた様子で「読まないコードリーディング」を実践してくれました。当然ながら中身をじっくり読んでいた頃と比べてスイスイ進みます。

ひとりごとメモ

次に、「手を動かす前にひとりごとメモを書いて頭の中で作業を一通り終わらせる」ことを推奨しました。「ひとりごとメモ」というのは、例えば「〇〇についての資料を書く」という仕事があったときに、

• この資料はこういう人が読むんだよな
• 資料の要素はA, B, C, Dがあれば十分そうだな
• B, Cについては今のところよく知らないから調べなきゃな
• Cについてはあの人が詳しそうだから聞いてこようかな
• 要素が揃えばChatGPTにお願いできるかもな

…といった調子でツイート感覚でメモをする、ということです。

手を動かし始めると、どうしてもその場その場の「表層」に意識が行きがちです。手を動かす前にシミュレーションを行うと、自然と「戦略」や「要件」といった抽象を考えることになります（メモがひとりごと風なのは、頭に浮かんだことをそのまま出して余計な負担を減らすためです）。

ひとりごとメモを実践することで、「手を動かすときに何をやればいいかわからずあたふたする」ことがなくなりました。また、メモの時点で不安な箇所があればチームメイトやメンターに相談することができたので、自然と手戻りも少なくなります。

驚かされたのは、Yくんはコミュニケーションの上手さです。彼はひとりごとメモで自分の仕事範囲に仲間の得意分野があるとわかると、積極的に「ここ、お任せしちゃってもいいですか？」とお願いしていました。こうすることで、仲間の長所を活かしつつ自分の仕事の範囲を絞ることができます。「仕事ぶりが激変したな…」と思いました。

奥の考え方まで聞く

Yくんのコミュニケーション上手にかこつけて、もうひとつワザを教えました。「質問をして具体的な操作を教えてもらったときは、さらにその奥にある考えまで聞く」という質問のやり方です。

例えば「こういうエラーが出てうまくいかないのですが、どうしたら動くでしょうか？」と質問し、メンターが「ああ、ここをこうすれば動きそうだね」と教えてくれたとします。

対処法はわかったものの、このままでは理解が表層的になります。そこで、「え、今のどう考えたんですか？」と聞きます。すると「こういうエラー文が出ていて、いまこういうコードを書いているから、こういう原因じゃないかなっていうのがわかって、対処法があれとあれとあれで3つくらい思い浮かんで、一旦いちばんシンプルなやつで良さそうだったから、それを教えた感じ」みたいなことを教えてくれるかもしれません。というよりこういう内容が聞けるまでしつこく質問します。ここまでわかると理解が深まって応用がきくので、長期的な生産性が高まります。

Yくんのチームメイトは年上で技術力の高い人でした。Yくんは開発初日からその人に明るく素直に質問できていたのですが、「奥にある考えまで聞く」を意識することで技術の吸収がぐっと進んだようでした。インターン後に書いた体験記でも、そのことについて触れてくれています。

対処法だけを聞くだけでは勿体無いなと思えるようになったことがまず成長で、なぜその対処法を使おうと考えたかというその人の考え方、エッセンスの部分まで一緒に聞くというのが大事だなと感じました。

（Yくんの体験記より抜粋）****

無事、完走

こうしてYくんは無事、元気にインターンを終えることができました。コミュニケーション面でのチームへの貢献も大変大きかったですし、開発最終日には非常に詳細なひとりごとメモを残し、「読まないコードリーディング」も「これなしは考えられない」と語るほど自分のモノにしていました。素直なYくんだからこそ大きな成長を見せてくれて、バディとしてとても嬉しかったです。

今回Yくんに教えたことは、自分にとっては慣れていて無意識にやっているようなことです。しかし、だからこそ手順を端折ってしまいがちなことでもあります。もしかしたら知らず知らずのうちに表層部分で試行錯誤してしまっているときがあるかもしれません。改めて抽象度を意識することのインパクトを教えてもらったので、自分も普段の仕事から腰を据えて取り組んでいきたいと思いました。