エンジニアのスキルと抽象度
この記事を読む前に、「みんなちがってみんないい」と3回唱えよ
スキル相談で考えること
1on1や採用・育成の中で「新しく〇〇を勉強しようと思っているんですよねー、どうですかね？」かみたいな相談をされることが多く、基本的には「イイじゃん、Youやっちゃいなよ」の精神なのですが、なんのために？そのスキルはどこまで伸ばすのか？という話はなるべくするようにしています。
その時に期待されている役割や今のスキルを分析するために、「解決すべき課題の抽象度」「スキルの関連性」という話をよくするので共有しようと思います。
我々の仕事
我々は「課題（タスク）」を解決することでお金をもらっています。とくにエンジニアやデザイナーは"課題解決に特化する仕事"だと考えています。この課題には以下のようなものがあります。
解決すべき課題
・SQLのパフォーマンス問題
・iOSアプリユーザーさんの使い勝手が悪い
・組織の人数不足
・バックログ上のストーリーを実施
・デプロイ時間が遅い
・デザインプロセスが非効率
・サーバサイドのアプリの各レイヤーの設計が悪い
課題は様々な属性を持ちます。「難易度」や「どう解決するか」だけでなく、決まってないことの多さとして「抽象度」というものがあります。厳密な「抽象的である」というより「曖昧である」なほうが意味合いとして強いので曖昧度という考えでもよいかもしれません。
上記の課題を抽象度で分けると
上記のようになります。例として一番抽象度の低い「バックログ上のストーリー」であれば、when は "スプリント"、who は"アサイン"、what は"仕様書・デザイン"、Howは"既存の設計に合わせて"など明確で解決方法も具体的です。一方で一番抽象度の高い「組織の人数不足」は色々なことが不明確、不確実、そもそも実施すべきか、その課題の存在自体に気づきにくいという特徴があります。そしてこれは
抽象度の高い課題を課題をどこまで解決すべきか？を表現する線引
= 「役職」や「等級」
と考えられます。
役職と課題の「抽象度」
社長の仕事
社長とは何をする仕事でしょうか。経営、と一言で言えば簡単ですがその実、なんとかして会社を伸ばすことだと言えます。このなんとかするというのが抽象度の言わんとするところです。
役職と課題の抽象度には相関があり、役職が上がるごとに解決すべき課題の抽象度の幅が上がり、広がります。役職の頂点であるところの社長であれば「なんとかして会社を伸ばす」であり、作業者であれば「言語化された手順を実施する」だと思います。あくまで、基本的な範囲でありこれをどう考えるかは個々の解釈も含まれます。理解のためにここでは役職の高い人をシニア、低い人をジュニアとして考えてみましょう。それぞれが下記の図の色分けされた部分ような範囲を担当します。
上記図のように会社では解決範囲がある程度役職によって決められています。抽象度の高低で課題には以下のような特徴が現れます。
抽象度が 低い（具体的）課題
なにをするか明確、１人でもできる又は大人数であればその分早く解決できる、やる時期が明確、どう解決すべきか明確、解決手段が人によってぶれにくい
抽象度が 高い（抽象的）課題
見つけにくい、気づきにくい、実施することが正しいかわからない、1つのスキルでは解決できない、1人では解決できない、いまやるべきかわからない、答えが一つじゃない、責任が伴う
抽象度が上がるほど、そのドメインの知識やメタスキルが求められて不確実になる一方で責任も伴うので、シニアがこれを解決することに注力します。または解決のために具体化して、解決しやすくします。
「エンジニアにもコミュニケーション力が必要」という論調はこれにも関連していると思ってて、多くの「課題の具体化」には他部署の人やユーザーさんとの会話と合意形成が必要という話から来ると思っています。優秀なディレクターやマネージャーがいる現場で、作業者として具体的に決まりきった課題に集中するのは楽だし課題解決は楽しいのですが、それだけだと具体化の得意な人たちがいないとワークできない成果の再現性の低い人材になるリスクがあります。できて損はない課題の具体化、皆さんはどう考えるでしょうか？
解決の質
どんな課題でも解決の質が存在します。例えば「画像を差し替える」という具体的で単純な作業一つとっても「速さ」「再現性」などの質が存在します。最初は言われた通りしか解決できないタスクも、こなしていくうちにHow以外にも「そもそもなんでやる必要があるのか」「いまやるべきか」などに対して考え意思決定ができるようになってきます。ジュニア・シニアで求められる解決の質は下記のように高さで表現できます。
ジュニアであれば具体的な課題（作業）は解決できることを目指し、シニアはジュニアはより抽象度の高い課題も高い質で解決する必要があります。どの役職でも抽象度が高いほど難しく難易度が上がるため、質も下がってきます。
スキルアップ・キャリアアップは「解決の質」を上げて、「より高い抽象度の課題」を解決できるようになって大きな矩形を目指すことだと考えるとわかりやすいです。
上下だけではないキャリア
ただエンジニアやデザイナーには多様なキャリアパスがあり、必ずしも抽象度の高い課題を解決できること＝高い役職になることではありません。
スペシャリスト・テックリード・マネージャーなど同じシニアでも求められてくる範囲が異なります。私のイメージは下記です。
一つの領域のを突き詰め解決策の質を上げていくのであればスペシャリスト、質も上げつつチームや組織などを技術でリードしていくテックリード、広い視野で育成や事業折衝などもこなすマネージャーなど、会社によっても建て付けは異なるかと思います。
課題の抽象度だけでなく、質を上げていくことで、別のロールにもなることや、新しくロールを作ることも可能です。この役割は会社や組織状況によって大きく変わるので自分の運営する・または所属する組織内で自分がどういう状況を作っていくべきなのかを考える必要があります。
これは組織を見る上でもとても大事で、組織でどこまでの解決範囲を持てているか？という観点があります。抽象度の高い課題に取り組む人が少なければ指針が生まれにくく、隠れた課題に気づけません、逆に課題を実行する人・その質を上げる人がいなければ組織の動きが遅くなります。
抽象度が上がるほど、1つのスキルでは解決しきれないことがあります。この時、どこを伸ばすべきなんだっけ？といいうのを考えるためにスキルの関連性という考え方があります。
主軸スキルの関連性
役割で求められる・必要なスキルというのがあると思います。自分が求められている・得意なスキルを主軸として熟練度を高さ、近いスキルを横に、サーバサイドエンジニアを例に以下のように表現をします。
関連性
近くにあればあるほど伸ばしやすく、また成果を出しやすい
遠くにあるほど伸ばすのが大変で、成果も出にくい
伸ばそうとしているスキルが今持っているスキルとどういう関連性にあるのかを考えると見えてくることが色々あります。質問例としては
・いまはデータベース設計とアーキテクチャ設計どっちが得意ですかね？
・フロントも勉強始めてますけど、どこまでを目指しましょうかね？
・いまのサーバサイドのスキルのどれくらい目指します？
会社のスキルマップに合わせるのでなく、自分がスキルをそれぞれどんなふうに認識しているのかを相対的に考えてもらいます。実際にここまで図示することはないですが、頭の中で考えながら話して達成のイメージをクリアにしてもらいます。
またこの関連性は誰でもいつも固定ということはなく、環境を変えたり、考え方を変えることで関連性を変えることもできます。例えば「今は英語を仕事で使わないから英語を学んでもすぐ活かせないし、学びにくい」状況から、仕事で英語を使う環境へ変えることで「学んだことを実務で活かせるので英語と開発が近くなった」とかそういった具合です。
自分のメインのスキルに近いスキルを増やして掛け算のスキルセットで勝っていく戦略が今の個の時代には向いていると思っています。上記のような山の面積を効率よく増やしていくのが今のエンジニアの基本的な成長戦略だと私は思います。
まとめ
自分の数少ない時間をどこに投資していくかは慎重に選択していく必要があると思います。私も気が狂って「これからのエンジニアは格闘技！カポエラをはじめよう！」と思って技術力でなくキック力を磨いていたりしました。ただ強くなりました。
選択という作業はとても苦痛です。これは選択のパラドックスというやつで
「選択をする」ことで同時に別世界線の自分を生み出すことになり、そっちのほうがよかったと盲信していしまう脆弱性が人間にはあります（厳密には違うけど）。学び続ける、というのは学ぶこと以上に難しいので、その方針や、進め方を図にしたり言葉にしたりしておくことで、進むべき方向がクリアにして、間違えても修正方針が考えやすくしていきましょう。
最後にまた、「みんなちがってみんないい」と3回唱えよ
この記事が気に入ったらサポートをしてみませんか？