キャリアは具体と抽象の螺旋階段を登ることで築かれるのではという話
突然ですが、私はもうすぐ10年目を迎えるソフトウェアエンジニアです。今は担当する事業 / プロダクトの技術戦略を描いたり、と見せかけてたまにゴリゴリ機能開発をしたりしています。
だんだんとシニアになりリーダーシップを求められる立場になった昨今、「10年前の自分に何かアドバイスをするとしたら何を伝えてあげると良いだろうか」と考えることがあります。そして「具体と抽象の螺旋階段を登り続けろ」というのが割と筋の良い回答なのではないかという仮説を持ちました。
そこで今回は「キャリアは具体と抽象の螺旋階段を登ることで築かれるのでは」というテーマで言語化してみたいと思います。
キャリアアップに必要なスキルは「抽象的なテーマを自分なりに解釈し、具体のアクションに落とし込む力」
キャリアアップに必要なスキルとは何か。先に結論から言うと「抽象的なテーマを自分なりに解釈し、具体のアクションに落とし込む力」です。
例えば組織のトップ、CEOを想像してみてください。彼ら彼女らは「xxな社会を実現する」のようなスーパー抽象的なミッションを掲げ、それはつまりどういう状態なのかを解釈し、具体の実行計画を描きます。それを組織のメンバーに伝え、皆でそこに向かうための舵取りをします。CTOなんかも同様に技術視点でその抽象的なテーマを解釈して全社的な技術戦略を描きます。
CEOやCTOのような経営層から組織図をブレイクダウンして考えても、事業部長は事業部のミッション、プロダクトオーナーは担当プロダクトのミッションに対して同様の動きや成果を求められます。「事業 / プロダクトを通じてxxな社会を実現する」みたいなやつですね。
どれぐらいの大きさの箱の中で成果を求められるかが違うだけで、一般的にキャリアパスの上層にいる人たちは皆、抽象的なテーマを具体のアクションに落として成果を出すことが求められています。
じゃあ新卒1年目のメンバーに仕事をお願いする際、「xxな社会を実現してください」のようなリクエストをしてみるとどうでしょうか。「わかりました！」と自律的に具体的なアクションを定義して仕事を進めてもらえる世界線に出くわす確率はものすごく低いと思います。これを「新卒1年目でいきなりCEOやるの辛い問題」とでもしましょう。
抽象的なテーマを扱うにはまず具体の経験が必要
実は私も身を削って「新卒1年目でいきなりCEOやるの辛い問題」を立証した経験があります。私がエンジニアになりたての頃 (10年前)を振り返ると、当時は一刻も早く「組織に大きく貢献できるエンジニアになりたい」といったことをよく周りに話していました。
当時は自分なりにチャレンジングな目標を掲げていたつもりだったのですが、今思うと「組織に大きく貢献できるエンジニア is 何」という感じで、かなり抽象的なテーマでした。具体的なエンジニアの業務を全く知らないまま掲げた目標だったため、何ができるようになれば「組織に大きく貢献できるエンジニア」と言えるのかわかりませんでした。そして実態としてもアサインされた目の前のタスクを必死にこなしているだけでした。
結局、新卒時代のような具体の経験がない状態では目の前の与えられたタスクに120%の成果で応えることしかできないのではというのが私の結論です。
ではどうすれば抽象的なテーマを扱えるようになれるのでしょうか。
具体の経験を積むことで学びを抽象化できるようになる
目の前のタスクを通じて具体の経験をこなしていくと、今まで見えてこなかった景色が徐々に見えるようになってきます。
例えばプログラミングの世界でMVC (= Model / View / Controller)と言われる概念があります。「プロダクトにとって核となるビジネスロジックはModelに定義し、ControllerはModelからデータを受け取ってViewに流して、、」みたいなやつです。なぜそんなものがあるかと言うと、プロダクト開発が成功する可能性が高まるからです。歴代の偉い人達が数多の辛い開発経験を経て、「こうやったらうまく行ったぜ」というエッセンスを抽出し、概念として提唱してくれているものだからです。そのおかげで我々もMVCに倣って責務を整理して開発することで成功確率を上げることができるのです。
ですが実際やってみると、初めからそんなうまくはいきません。「MVCするぜ」といざ開発するとModelに定義するべき機能をControllerやViewに定義してしまったりみたいなことがよく起こります。これは「新卒1年目でいきなりCEOやるの辛い問題」に若干近い状況です。「MVCでいい感じに開発してください」と言われても、十分な開発経験がないと具体的にどうすればいいかわからないんですよね。
しかし運良くそれを指摘してくれる同僚が身近にいたら、コードレビュー等で「こういうロジックはModelに書くべきだよ、なぜなら…」という気づきをもらえます。人ではなく名著に出会うとかでも良いです。そういった経験を経て、自分なりに解釈し抽象化することで「こういうロジックはModelに書くべきだ！なぜなら…」と確固たる自分の概念が生まれていきます。このプロセスの蓄積によって真の意味でMVCを理解し、プロダクト開発の成功確率を上げられる人になれるのです。
抽象化した学びを自分の概念として確立させて効率的に成果を出せるように
前述のMVCを完全に理解し、「MVCは責務を適切に分離し、プロダクト全体をシンプルに保ち続けるための指針だ」と自分なりに解釈したとします。
ではそれをエンジニアではない人に伝えるケースを想像してみてください。例えばMVCを以下のようにカレー屋さんに置き換えてみるのはどうでしょうか。
Model = カレー屋さんの厨房 (カレーを作る、カレーの味、品質に責任を持つ)
Controller = カレー屋さんのウェイター / ウェイトレス (カレーをお客さんに届ける)
View = 最終的にお客さんに届くメニュー(カレーそのもの)
カレー屋さんにとってのコアバリューはカレーです。カレーの品質を担保するのは厨房の責任であり、ウェイターやウェイトレスは厨房から渡ってきたカレーをお客さんにデリバリーします。
ここであるウェイターが突然スパイスを適当に組み合わせて創作カレーを作るような事態を想像してみてください。謎の創作カレーが奇跡的に評判が良かったとしてもそれは突如暴走したウェイターにしか作れません。カレーを作る責務を追ったウェイターと厨房がいる状態になります。お客さんのオーダーによってフローが複数生まれ、運用が複雑になりそうです。そうではなくて「できるだけ運用をシンプルにするためにウェイターにはデリバリーだけをやってもらって、厨房で新しい創作カレーを作れる体制にしましょう」と言えば、間接的に多少はMVCの意義が伝わるのではないでしょうか。MVCに従うことでシンプルなカレーデリバリーが実現できそうな印象を抱いてもらえれば成功です。例えが上手いかどうかは一旦置いておいてください…
何が言いたかったかというと、「MVCフレームワークを使った開発経験とカレー屋に行った経験があるエンジニア」と「カレー屋に行った経験がある非エンジニア」でMVCの意義をある程度共有することができるということです。これは非エンジニアの人にプログラミングスクールに通ってもらって、MVCフレームワークに触れてもらって、レビューを受けてもらって、とするより遥かに効率的です。
またこの考え方は自分自身の成長にもレバレッジをかけることができます。もし今あなたがプロダクトマネージャーとして働いていて自分のキャリアに悩んでいるとしたら、「プロダクトマネジメントでロードマップを描いたように、自分のキャリアをプロダクトに見立ててロードマップを描いてみよう」みたいな考え方ができるようになります。0からキャリアについて考えるのに比べて、プロダクトマネジメントとの差分に着目すればいいだけなのでだいぶ楽になるのではないでしょうか。
具体と抽象の螺旋階段を上る
このように
具体の経験を積む
経験を振り返り、学びを抽象化する
自分なりの概念を確立する
概念を別のテーマに再投資する / 概念を人に伝え、皆で成長する
具体の経験を積む
…
みたいなサイクルを回すことによって「新卒1年目でいきなりCEOやるの辛い問題」から抜け出し、抽象的なテーマを自分なりに解釈し、具体のアクションに落とし込める人に近づくことができます。「xxな社会を実現する」みたいなテーマに対してもブレイクダウンして「そのような社会でビジネスの構造はどうなっているべきか」「理想の構造に対して現状はどうなっているのか」「その差分を埋めるために取れるアクションは何か」みたいに様々な経験を元に自分に問いを立てられるようになります。あとはその精度、解像度が上がるよう上記のサイクルを繰り返すのみです。
ちなみに自分で言っておいてなんですが、私は「xxな社会を実現してください」ってリクエストされたらちょっとキツいです。
正直これは「日々の経験の振り返りをしっかりしましょう」のような一言で終わらせることもできる話です。しかし毎日がんばって振り返りをしても、学びから自分の考えが確立されていかないと再投資ができず、苦しい期間が続いてしまいます。そこで「具体と抽象の螺旋階段を登る」という表現を敢えて使っています。
何百番煎じかわからないベタな例えですが、螺旋階段を登る際、上から見ると同じ場所をぐるぐる回っているように見えますが、横から見るとちゃんと上に登っています。
そのように学びを抽出しただけで満足して同じような所をぐるぐる回るのではなく、学びから自分の考えを確立し、より大きなテーマに向かって再投資ができているようなイメージを持つことが大切です。
まとめ
10年前の私は目の前の業務で成果を出すことにはコミットできていた自負がありますが、そこで得た学びを抽象化、概念化して次に活かすようなことはあまり出来ていなかったように思います。恥ずかしながら、最近ようやくその大切さに気づき始めたぐらいのステータスです。
社会人としてキャリアを歩み始めたばかりの方はぜひ具体と抽象の螺旋階段を登るようなイメージで仕事に取り組まれてみてはいかがでしょうか。
この記事が気に入ったらサポートをしてみませんか？