やったことない仕事をうまくやるための抽象化スキル

仕事 技術

抽象化スキルが、生死を分ける時代に : NED-WLTを読んでなんとなく書いてみる

自分が過去にやったことある仕事と同じような仕事をアサインされた場合には対応するのが簡単でしょうが当然のことながら世の中そういう仕事ばかりではないわけです。

自分がやったことない仕事をやることになる状況というのも少なくないでしょう。とはいえ仕事を振る方も普通であればそんなに無茶ぶりはしないはずです。例えばJavaでアプリ開発しかしたことない人間にインフラチームのリーダーをお願いするとかは無いでしょう。たぶん。

なので仕事を振る側はその人の今までの経験の延長線上でできるであろう範囲で仕事を振るもんだと思うわけです。例えばJavaでアプリ開発の経験あるならHadoopのMapReduceもまあ頑張れば書けるよねみたいな感じ。いやまあ実際問題をいうとMapReduceをちゃんと書くには単純なJavaスキル以外にMapReduceのお作法というか仕組みを理解してないといけないので結構大変だと思う。なのでHiveやPigのようなDSLを使ったりするわけですがその話はいったん置いておく。

仕事を振る側はそれなりに考えて作業を振っているので振られる側も「やったことないからできません、キリ」というのでは問題があると思うわけです。

やったことないからできませんではなくどうすればやったことないけどできるという方向に持っていけるかを考えるのが建設的でしょう。

まあ普通に考えるとやったことないけどできるというのは矛盾していると思います。

例えばHadoopの開発経験が無いのにHadoop案件のリーダーができます、キリ。とか面接の場で言ったら「何言ってんだコイツ」ぐらいにしか思われないでしょう。
Hadoop案件のリーダーができるということを面接の場で証明したいなら、Hadoop案件のリーダーができる人間にしか言えないようなことを言うしかないわけです。
ただそんなことを言えるような人間はそもそも面接のように査定される場には出てこないもんなんですけどね。

閑話休題

まあ面接の例はちょっと極端ですが、やったことない仕事をやるというのは日常的なことでしょう。

その場合当然のことながら一歩一歩新しいことを吸収してキャッチアップしていく必要があります。

しかしやったことある仕事と今度やる新しい仕事に共通点を見出すことができればキャッチアップがやりやすくなります。

この共通点の抽象度が高ければ高いほど汎用的になります。一方で具体性がその分なくなりますので即効性は無くなります。

適切なレベルで抽象化して共通点というか重要な枠組みを見出すというのが抽象化スキルなのかなあと思ってます。

例えばJavaでSeasar2を使ったことがあればDIコンテナについてある程度理解していると思うので別のDIコンテナ、例えばSpringを使うのはそれほど難しくないでしょう。

これはJavaに特化していますし抽象度が低い例です。逆に言うと具体性が高い例です。

抽象度が高い例をあげるとそれは差を見つける能力です。

これについてちょっと説明してみます。おそらくみんな無意識にやっている当たり前のことだと思いますがあえて書いてみます。

あなたはJava経験はあるけれど今回未経験のPythonの仕事をやることになったと仮定しましょう。

Aというモジュールに機能追加する仕事をアサインされたとします。

Pythonについて勉強しながらAというモジュールに機能追加するためコーディングを進めていましたがうまく動きません。途中までは想定通りにできていたのですが最後まで完成させることができません。いろいろコードを変えながら試してみますが全然動かずだんだん自分が何をしたかったのか忘れてきます。ええよくある状況ですねｗ

○を変えて試す→NG
●を変えて試す→NG
△を変えて試す→NG
...
○を変えて試す→NG。振り出しに戻る。あれそういえばこれ最初に試さなかったっけ。。。てか俺は何をしたいんだ。。。

という状況です。ええ実にありがちです。こういう頭が混乱した状況で進捗を訊かれた日にはさらにプレッシャーを感じるでしょう。

こういうときは頭を整理してどこまではうまくいってどこからうまくいかなかったのかを確認する必要があります。

例えば

  1. Aというモジュール
  2. Aというモジュールに□を追加して試す→OK
  3. Aというモジュールにさらに■を追加して試す→OK
  4. Aというモジュールにさらに◇を追加して試す→OK
  5. Aというモジュールにさらに◆を追加して試す→NG

という状況なら◆に原因があるのでこれをさらにブレークダウンします。

  1. ◆1を追加して試す→OK
  2. さらに◆2を追加して試す→OK
  3. さらに◆3を追加して試す→NG

◆3が原因ですね。こうしてブレークダウンしていってうまくいったときとうまくいかなかったときの差をソースの数行単位の差にまでブレークダウンして見つけることができれば問題の原因がわかります。これをさらに発展させるとgit bisectにつながってくるかなあと思いますがその話は置いておきます。

この差を見つける能力というのは別にJavaやPythonに限った話ではありませんし別にコードに限った話でもなくインフラにも適用できる汎用的なスキルです。


こういった抽象化スキルを身につけることが今後ずっとずっと重要になってくるような気がします。