読者です 読者をやめる 読者になる 読者になる

器用貧乏系エンジニアの憂鬱

このところ Inposter Syndrome *1 やエンジニアキャリア形成についてオンライン/オフラインで重ねて見聞きする機会があり、改めて言語化 (+可視化) しておきたいなと思ったのが筆を執った動機です。

タイトルは語感を拝借しただけで特に僕が憂鬱になっているわけではないです。お正月の読み物コンテンツとしてご家族でお楽しみください。

学び

  • matplotlib で レーダーチャートを描くのはかなり厳しい

器用貧乏系エンジニアとは

器用貧乏とは、新明解国語辞典第7版によると、以下のように定義されています。

「器用」なため、一つの事に集中出来なかったり 他から重宝がられて雑多な用に使われたりして、かえって、大成出来ないこと。

転じて、ビジネスにおけるスキルセットを評価する際に、いわゆる Generalist やオールマイティータイプの自己謙遜あるいは自嘲表現として用いられることがあります。これを更にエンジニアのコンテクストに転じたのが、器用貧乏エンジニアということとします。

この善し悪しは非常に難しいのですが、悪い面について個人的な経験から言うと、なまじある程度自分できるだろうという感覚 (慢心?) を持っているために何でも自分でやってしまい、プロフェッショナルに任せたり、誰かを頼ったほうが結果としてよいものができる機会を逸してしまうことがある、ということでしょうか。

良い面として、自立稼働できる範囲が広いためスピーディに物事を進められるということがあると思います。特に、コンピューター1台あれば製品を作り上げられるソフトウェア開発においてこれは顕著な部分です。

長所と短所は表裏一体と言いますから、自覚的であればよいのではないだろうかと思っています。

なお器用貧乏という言葉を取り上げた背景として、僕自身が学生時分から悪い面での器用貧乏を自覚することが多分にあったからです。これはいまだに引きずっていますので三つ子の魂なんとやらですね。

自尊心の消失

仮に、次のような Generalist タイプの A = Annie がいたとします。数値がいくらかということは本質ではないのですが 5つのパラメータのポイントは5に振ってあります。

f:id:iktakahiro:20170101203024p:plain:w400

エンジニアの評価指標としては大味過ぎるうえに全然MECEでもなく、かつ綺麗に同レベルなスキルを持っているというのも現実的ではないのですが、あくまで例ですので大目に見てください。

Annie が自分自身を「器用貧乏である = 専門性がない」と感じるのは、例えば次のような Specialist B = Barbara と比べたときでしょう。

f:id:iktakahiro:20170101202905p:plain:w400

Annie と Barbara のパラメータの合計はともに25なのですが、Barbara の場合特定の領域で 9ポイントと高いスコアを持っていて、つまりこの部分が専門性ということになります。

Annie の強みは 1人で何役もこなすことができる点にあるので、組織の立ち上がり時期など不確定要素が大きい場面で重用されることがあります。

いっぽう何らかの難しい問題に取り組む場合、例えば Front End の領域においてレベル8以上ないと解決出来ない課題にぶつかった場合、Generalist タイプが何人いても歯が立たない ということになってしまい、その道の Specialist である Barbara さんが求められます。それ故に、取り組むべき課題領域がある程度明らかになってきた段階、言い換えると分業化が進められる段階においては、各分野の Specialist タイプを揃えるのがよいのだとも言われます。

もちろん最初期から高い専門性が必要な場合もあるでしょうし、組織形成の方法論についてはさまざまありますのであくまで一例です。ただいずれにしても、一定以上の成熟をした組織においては Specialist タイプが求められることが多い傾向にあると (おそらく一般に) 考えられており、そのため Generalist にとって、Specialist ではないことが負の面として捉えられるのだと思います。

下位互換の溜息

以下のようなパラメータをもった Generalist C = Charlotte がいたとします。Charlotte はすべてのパラメータを7に振ってあります。

f:id:iktakahiro:20170101210604p:plain:w400

Annie からみると Charlotte はスペック的に 上位互換 にあたり、Annie は「Charlotte とに比べたら自分は何もできない」という下位互換的な劣等感を感じるかも知れません。この「何もできない」という感覚は結構強力で、人を後ろ向きにさせるに充分な威力を持っているように思います。

※ ちなみにここでグラフを重ねて見せたりするとちょっと気が利いた感じになると思うんですが綺麗に見せるための実装コストが高くて断念しました。厳しい。

また厄介な問題として 実際 に Charlotte が実在しなかったとしても Annie は同じように考えるかも知れない、ということがあります。非実在フルスタックエンジニア とも言うべき幻像を勝手に見繕ってひとりでに劣等感に浸っているというケースですね。これがポジティブな謙虚さの獲得に働けばよいのですが、そうでない場合、典型的な Inposter Syndrome に陥る危険をはらんでいます。

専門性と Identity の分裂

専門性をもつ Barbara にも勝てない相手がいます。さらに上位の専門性をもつ Specialist D = Dorothy です。

f:id:iktakahiro:20170101231739p:plain:w400

さて、Barbara は Dorothy に負けているとは感じつつ、自分の得意領域については引き続き認められる傾向が強いのではないでしょうか。

実際は専門領域ですらあいつに負けた!きぃっ!となる人が多くいるのかも知れません。ただ、Generalist/Specialist の自己承認の獲得プロセスと、「私はこれが得意」という Identity を持っているかどうか、という2つは無関係ではないように思えます。器用貧乏を自覚 -- それが事実ではなかったとしても -- しているタイプは Identity が弱いからこそ他人と比較して落ち込みがちであるという理屈です。

器用貧乏の生存戦略

ここまでにいくつもプロットしておいてなんなのですが、実際の人の技能というものは単純にプロットできないケースがままあります。単位時間あたりの何某、ということであれば定量的に観測したり比較できるのですが...またそもそも、スキルの大小ではなくあるビジネスの目標における貢献度や達成度という指標で評価される場合*2もありますから、結局のところ何を指標に定めるかということによって自己肯定感も変化するものと思われます。

ともかく、なんとか器用貧乏を脱出するというのが一手なのでしょうけれど、パラメータを振り直すわけにもいかず、なかなか脱出できないからこその器用貧乏という側面もあって、じゃあどうしていこうかということで以下に生存戦略を整理してみました。

軸を加える

器用貧乏を自認するタイプの1つの生存戦略として 別のパラメータを加えてみる、ということがあると思います。

これまで5軸しかなかったパラメータセットに第6の軸を加えてみます。

f:id:iktakahiro:20170101232730p:plain:w400

Communication という軸はちょっとベタすぎたかも知れませんが、ともかく我々の住む世界では、ロールプレイングゲームのように「力・魔力・素早さ」といった単純なパラメータが固定的に決まっているわけではなく、求められる能力が刻々と変わります。別の視座を持ってみることで、自分の強みを見つけられる可能性があります*3

総合力で勝負する

総合力をそのまま強みとすることもできると思います。自身の体験なのですが、Webサービスの画面遷移について考えているとき、RDB のテーブル設計とREST API の URI パターン、そして SPA の Routing 設定という3つを一気通貫で考えると実装がとてもシンプルになるのではないかと気付いたことがありました*4。この発見はごく個人的なことだったかも知れませんが、複数の領域に取り組んでいなければ得られなかった気付きだったと思っています。

じつにさまざまなものが Commodity 化してしまう昨今、横断的活用能力のようなものが強みになりやすくなっている時代であるとも思います。

ロールを変える

ロールを変えてみる。器用貧乏と観測しているスキルセットはあくまで特定集団 (e.g. プログラマ) と比較した場合であるはずですから、集団を変えてみるということです。これは「軸を加える」とほとんど同じ試みであると思います。

ただ、いわゆる狭義のソフトウェアエンジニアであることやコードを書き続けることにこだわりを持っている場合ロールの変更は容易ではないかも知れず、これは引き続き向き合うべき課題であるように感じます。また、ロールの変更先が無専門によって成り立つというわけでもないでしょうから結局同じ問題に突き当たる可能性もあります。

鶏口牛後 という故事がありまして、Annie であれば Barbara も Charlotte もいない環境を見つけて生きていくということも選択肢としてはありなのかなとは思います。ただ、その場合も 非実在 Charlotte が常に存在しますので逃げられない気はしますね。Charlotte 手強い。

卑屈になるのをやめよう

みんなちがって、みんないい。

ということに尽きると思うんですが、「人それぞれに価値があるのです」と表明しているその人自身にぶっちぎりの専門性があったりして...みたいなところありますよね。

ただ、隣の芝は青い理論と言いますか、Charlotte や Dorothy にも悩みはあるかも知れないよね、ということと、例え多くの技能が実際にプロットできてしまったとしても、それらと人格はやっぱり別もの、ということはある程度真理な気がしており、このくだりの情報量全然ない感じですけれど、まぁそんなに気にしないでいいんじゃないかなというスタンスで生きていくのがよいのではないでしょうか。

matplotlib と レーダーチャートの話

最後に matplotlib の話します?

公式ドキュメントにレーダーチャート作成のサンプルが一応あるんですが

これコード量が多くて参考にするのが結構しんどいんですよね。D3.js のサンプルも似たような感じっぽいのでこんなもんなのでしょうか。Excel だと一瞬で作図できた気がしますが。

重ね合わせなくてレーダーチャート描いた意味があったのか果たして、という逡巡もあったのでちょっとだけ頑張ってみたのが以下です。

f:id:iktakahiro:20170102012747p:plain:w350

レーダーチャート作成の専門性を持ちたい人生だった。

関連するかも知れない書籍

タイトルがまさにという感じですが原著がとっても有名ですね。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

環境を変えることに後ろめたさを感じている人向け。この話はまたどこかでしたいです。

西の魔女が死んだ (新潮文庫)

西の魔女が死んだ (新潮文庫)

*1:http://syobochim.hatenablog.com/entry/2016/09/21/130400 とか

*2:前者は職能、後者は実績などとされます

*3:しかしこれ実は Communication の Specialist なのでもはや Generalist じゃないじゃんというツッコミはできますね...。Charlotte が実は Communication 能力が著しく低かったという仮定のほうが妥当だったかも知れません

*4:その一部を整理したのが右記の資料でした Go 言語と React で考える「いい感じなURL設計」入門