こんにちは 👋 DX Squad でインターンをしている山本です。

7月いっぱいでインターンが終了になるので、今回のインターンで学んだことを振り返ろうと思います。

技術的なスキルといったいわゆるハードスキル以外に、仕事に対する姿勢・考え方などソフトスキル面でも非常に学びが多かったので今回はそちらについてまとめていこうと思います。

Wantedly のインターンを検討している方や DX Squad に興味のある方々の参考になれば嬉しいです。

学んだこと

早速学んだことについて書いていきます。タイトルにもある通り以下のように大きく5つに分けてみました。

1. 問題の抽象化を考える
2. 問題をきれいに分割して依存関係を整理する
3. それぞれの問題に名前をつける
　　　　a. 今解いている問題が何なのか明確になる
  b. 伝えるべき相手に合わせてどの粒度で伝えるかを変えやすくなる
4. TODO リストにする
5. 余談
  a. パフォーマンスが悪いパターンとその対策

それぞれについて、具体的なエピソードも交えて詳しく説明していきます。

主に 1 ~ 4章で抽象的な問題に対する向き合い方について述べ、最後に5章でそれらに関連してパフォーマンスについてを述べようと思います。

1. 問題の抽象化を考える

インターン初日に、インターンで取り組む課題やその目的などについて説明を受けてから、自分で解釈したりそれについてどういうアプローチを取るかを考える時間がありました。

その後、考えた内容などをメンターの大坪さんに伝えたのですが、そこで指摘していただいたのがこの「問題を具体から帰納的に考える能力」と「問題を抽象化する能力」の話でした。

指摘していただいた内容はこうです。

「山本くんは、『課題をそのまま解くこと』はできても『そもそも何が達成されたら良いのか？と抽象的に考えること』に伸ばす余地がある」

「例えば、みんなでピザパをしようとなった時に、【ピザパの用意を『ピザの用意』と考えて注文までたどり着く】ことはできる、【ピザパの用意を『楽しい食事環境の提供』だと捉えて『寿司のほうが良い可能性はないか？』とか『ドリンクも用意するべきか？』などとより広い可能性を探索すること】が出来ていないね」

つまり、ユーザーが欲しい物をそのまま作ってもだめで、フォードの『もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。』という格言もありますが、「一般的にユーザーは本当のニーズに気づいてないことが多い」ということを意識して自分の課題に向き合う必要があるということです。

DX Squad に関していうと、「社内のエンジニアが本当に欲しいものはなにか？」を考える必要があり、その意味で「今達成するべきことはなにか？」を突き詰めることが非常に大事ということです。

2. 問題をきれいに分割して依存関係を整理する

エンジニアリングの文脈においては分割された問題の間に良いインターフェースが定義されることが多いです。これにより、依存関係が整理され、抽象的で複雑な問題を捉えやすくなります。

インターフェースについては上記の記事が非常に分かりやすく濃い内容になっているので、ぜひご覧ください！

良いインターフェースが定義されることで得られる利点は他にもあります。

それは「問題発生時の切り分けがしやすくなる」ということです。というのも、どんなに時間をかけて深く考えて作ったアプリケーションでもバグなどの穴は防ぎきれないものだと思います。

自分自身、考慮不足などで痛い目に遭うことが何度かあったのですが、設計時点で適切にインターフェースを設定することで問題の切り分けのしやすさが全く違うものになるということを今回のインターンで強く感じました。

例えば、今回のインターンでの課題を解決するために作成した deploy-status-notifier では、大きく機能として『検知』と『通知』に分けて考えていました。

検知モジュールから通知モジュールに何を伝えるべきかを考えた際、「replicaset の名前」・「docker image」・「commit hash」 など伝えるべき要素の候補は色々ありましたが、「replicaset 」に決めたことで以下の２つに問題が分割できるようになりました。

• replicaset の更新を検知する問題
• github に通知する問題

このように問題が分割できたことで、問題の箇所が素早く特定できるようになりました。

3. それぞれの問題に名前をつける

これは、自分の癖として思考を先に進めることに専念してそれまでの過程について聞かれると「あれ、こう考えたのなんでやっけ...」となることが多いのをメンターの大坪さんが見抜いて指摘してくださったことです。

指摘していただいた内容は以下のとおりです。

「思考が言語に引っ張られることが多いから、自分が今取り組んでいる問題に 『○○問題』って名前をつけるといいよ」

「例えば、deploy-status-notifier だと『デプロイの終了検知できない問題』とか『意図せず通知されてしまう問題』とか」

なお、deploy-status-notifier については今回のインターンで取り組んだ課題のまとめとして、上記の記事にまとめていますのでぜひこちらもご覧ください！

この指摘の真意は、「問題をきれいに分割して構造化しないと自分が何を解いているのかわからなくなってしまう。それを解決するには適切な問題サイズを一つの抽象と明示的に頭で捉える必要がある。このために名前付けが重要である」ということです。

この「名前付け」には以下の利点があります。

• 今解いている問題が何なのか明確になる
• 伝えるべき相手に合わせてどの粒度で伝えるかが変えやすくなる

これ以降でそれぞれについて詳しく説明します。

a. 今解いている問題が何なのか明確になる

これまで何か課題について深掘りされるといちいち思考過程を思い出して答える必要があり、時間はかかるし曖昧な回答をすることが多かったです。

名前をつけるようにすると、取り組んでいる課題が明確になり、深掘った質問に対しても「それは『△△問題』の話ですが今は『〇〇問題』に取り組んでいるので調査しておきます」といった具合に答えることができるようになりました。

これは複雑な問題に取り組んでいるときほど効果があると思うので、今後もどんどん名前を付けていこうと思っています！ 🙆‍♂️

b. 伝えるべき相手に合わせてどの粒度で伝えるかが変えやすくなる

相手に物事を説明して伝えたいことを正確に伝えるのは結構難しいことだと思います。例に漏れず自分もそうでした。

例えば自分が課題で取り組んでいる内容について、メンターである大坪さんに伝える場合と、CTO である川崎さんに伝える場合と、ビジネスサイドの方に伝える場合では、伝え方がまるで違ってくるはずです。

問題に名前をつけることで、話す相手によってコンテキストや抽象度合いを変えること(いわゆる抽象度コントロール)がしやすくなります。

ピザパの例を挙げると、ピザパのドリンクで迷ってる場合、それを伝える相手によって「ドリンク用意問題」・「どのアルコールが良いか問題」・「どのビールにするか問題」のどれを伝えるか変えるべきですが、それをしやすくなります。

ちなみに、自分の場合だと抽象度が低め、つまり具体的な要素を多めに伝えても良い場合が苦手でした。

今自分が取り組んでいる内容を話す際に、相手がビジネスサイドの方なら抽象的に上手く話せるのですが、メンターの大坪さんに対して話すとなると、全体像を伝える前に具体的な実装の話をしてしまったりと分かりづらく感じさせてしまうことが多かったです。

そこで、「名前付けだけでなく、抽象から具合のトップダウンで話した方が良いよ」と言っていただき、常にそれを意識することで伝わりづらさはかなり改善されたと思います。

4. TODO リストにする

ここまでで名前を付けた課題を全て覚えておくのは難しいので、 TODO リストにすると良いです。

TODO リストについてメンターの大坪さんの話がすごく良かったので書いておきます。

TODO リストは「上司からやれと言われたタスクたち」ではなく「秘書からお願いされたタスク」と捉える、という話です。

これまで TODO リストを作っても、「昨日の自分から課された、やらないといけないことリスト」と捉えてしまって、上司からやれと言われたような気持ちになって気乗りしないので、全然見ることが無かったそうです。これは自分も全く同じでした。

でも、「次の時間は〇〇のタスクをやってください」と言ってくれる秘書は欲しいと感じていたそうで、TODO リストと秘書の違いについて考えてみたところ、メンタルモデルの問題だと気づいたそうです。

〇〇問題と名前を付けてタスクに落とし込んだ後、それを「自分」というチームの、「明日の自分」、「明後日の自分」... といったメンバーにアサインしていくというメンタルモデルでいれば、TODO リストの見方が「昨日の自分という秘書からお願いされたことリスト」に変わる、ということです。

また、作った TODO リストの内容を issue やタスクに落とし込むことで自分が進捗管理しやすくなったり、他のメンバーから進捗が見えやすくなったりする利点もあります。

5. 余談

a. パフォーマンスが悪いパターンとその対策

パフォーマンスが悪いパターンには以下の二通りが考えられます。

• 経験が不足しているパターン
• 未知の問題に対する対応が下手なパターン

このうち前者は経験を積むしかないので省略しますが、後者については対策できそうです。

未知の問題に対する対応が下手な原因として、課題や目的が明確に定まっていない抽象的な課題に取り組む際に特にありがちですが、「自分がまず解くべき問題が何かが明確でない」ことが多いと思います。自分がそうでした。

「3. それぞれの問題に名前をつける」でも述べましたが、問題に名前をつけることで自分が解決すべき問題を明確にする必要があります。

また、問題に取り組む上でも意識すべきことがあって、「理想の状態に対して手持ちの武器を無理やり使おうとしない」ということです。

最善手があるにも関わらず、自分の持っている武器に固執することにより時間を浪費したり、問題が無駄に増えたりすることもあるので、これについても意識していくべきだと感じました。

まとめ

ここまで述べたように、今回のインターンではエンジニアをやっていく上での思考であったり姿勢に対する学びが非常に多かったです。問題に名前をつける習慣、それらを日々意識するメンタルモデルによって抽象的な問題に対する向き合い方が意識的にコントロール出来るようになったと思います。

技術的なスキルはもちろん、様々ことを考えながら働き色々な経験をして初めて気付くような仕事に対する考え方、姿勢に気づけてとても良い経験になりました。

今後は自分でこういったことに気付いていけるよう、大坪さんを見習って、カッコよく働くにはどうすれば良いか考えながら楽しみながらやっていきます！ 🙋‍♂️

この3ヶ月間、メンターの大坪さんには本当にお世話になりました！ありがとうございました！🙇

何度も言いますが、技術的なスキルを学べるインターンは多いですが、ここまでソフトスキルを吸収できるインターンはそうそう無いと思います！Wantedly のインターンを検討している方や DX Squad に興味のある方々の参考になれば嬉しいです！

文中でも挙げましたが、今回のインターンで学んだ技術的な内容もブログにまとめましたので、これから Wantedly のインターンを考えている方々もそうでない方もぜひ一読ください！🙇