組織の発展というクラス構造のリファクタリング方法について

組織構造は、オブジェクト指向におけるクラス設計に近い。

Amazonは採用の時に、OLPと呼ばれるアマゾンのカルチャーに適応した人しか採用しないそうだ。Bar RaiserというOLP大臣のような人がいて、その人とビジネスユニットが違っていても、面接者がOLPを満たしているかについてOKが出ないと採用されないとのこと。

これを「OLPで定義されたインターフェースを所有している」と記述するとオブジェクト指向設計みたいに見えてくる。

「インターフェース」とは、仕事の要求に対する応答可能性や一定以上のクオリティを備えているという宣言である。

例えば、
・ソースコードを記述する能力 hasCodingSkill
・Hadoopを使ったシステムの設計、開発能力 canDevelopmentWithHadoop
・自社のビジネスを理解していること canEmpathyOurBusiness
・人材採用能力 hasRecruitingSkill
・チームマネジメントスキル canAttractiveTeamMember
・自社の○○事業部のなんとかの役割  hasXXXRoleSkill

記述が適切かは置いておいて…こんなイメージ。メソッドにはなってないが、もっと役割を定義できればメソッドでも全然構わない。

ベンチャーやスタートアップの初期フェーズにおいては、一人の人に多数のインターフェースを期待するか、もしくは、余裕がないのでもっとも必要ないくつかのスキルを使って戦う。例えば、経理インターフェースを社長が担うようなことはままある。

その後、会社が大きくなるにつれて、専門分化されたスキルの人材を取り入れたりして、会社が所有するアクティビティは増えていく。

例えば、スポーツチームのスポンサーになって広告機能を有するためのスタッフなどは相当特殊なインターフェースであり、本当に大きな企業じゃないとその機能を支えることができない狭いインターフェースだとも言える。そのインターフェースを備えた人材の母数もニーズも狭い。

ただ、よく言われる小さな会社言説あるあるとして、

・小さな会社はなんでもやらされる

であるとか、

・小さな会社は、以外とやれることが少なくて限定的である

というネガティブな言説については、

1.費用対効果がなければアサインされないしうまくもできないわけだから、その人がインターフェースを所有していない仕事は振られない。
2.その人がインターフェースを作りたいと思えば、期待ベースでアサインすることはある。

つまり、その人のやりたいベースで、インターフェースを構築するお手伝いをすることは可能。大企業の場合は、所属替えで、そのような可能性もあるかもしれないが、どっちにせよ、上司に「インターフェースを増やすための期待を抱かせること」はマストだし、それに対する現状スキルに対する相応のエビデンスもないと、期待を抱くのは難しい。

大企業だろうが小さな組織であろうが、自分が望むインターフェースで力を発揮するためのハードルの高さはケースバイケースとも言えよう。そのために転職という手段で、自分が望むインターフェースにアタッチしにいくこともできる。ただし、デフォルトインターフェースに対するクラスチェンジはレベルが1になるくらいの決意を持ってやるのは忘れずに。

現状、当社が採用活動をやっている制約として、「ものつくり職は、コードで語れないと活躍できない」という制約がある。まだ一人あたりに期待する範囲が多くて、大多数の役割において、コードという最終形態まで落とし込んで、pull requestまでできる人材じゃないと困るという状況。

現状、一番、人材としてはもったいないのに採用できない転職希望者候補としては、

1.高学歴+大手SIer所属
2.28歳を超えて、給料もそれなりに高い
3.で、コードを書いたことがない

などという上流工程専門のSE属性の方とはマッチングが悪い。

要は、社会的実績は申し分ないのに、我々が求めるコードに対するインターフェースが欠如しているというケースだ。

もしかしたら、もっと組織が大きくなって、組織構造をリファクタリングしていけば変わるかもと言うイメージをあるし、Web業界がもっと成熟してくれば、いわゆる上流工程、下流工程に役割が別れる可能性もゼロではないし、クラウドの発展でセキュリティやスケーラビリティが、ビジネスから切り離されたとしたら、そうなっていくのかもしれない。実際、巨大ポータル系の会社だとそんな感じになっているらしく、違う部分で、インターフェースが折り合わず採用が難しい面があったりする。

それと並行して、我々はずっとコード至上主義のサービスに対しては比較的小規模のチームで成長していくべきだというイメージも持っている。Rails級のコードクオリティを文化として求められて辛いとか、他社基準に聞くところと比べて、めちゃめちゃ基準が高いわけではないが、それでもテクノロジベンチャーとして、採用に関わるメンバの中では、未知の技術への適応力などについて、妥協するのはやめとこ、という約束をしているので、ある程度以上の期待感は欲しているのだが、それでも多様なキャリアを採用したい気持ちはあるので、いろいろ考えている。

というのも、自分の27歳頃にWeb業界に転職した時点の履歴書を、普通にwantedly経由やエージェント経由で、今の自分に見せたら採用するかというと採用しない可能性が高い。それだけ偶然の出会いのようなものが、当時の転職の実現に影響したと思っている。

確かに、転職後にとある採用サイトで、自分の履歴を入力してみて、無料でオンラインでアドバイスをくれるサービスというのに入力してみたら、「よく異業種に転職できましたね」と言われたが、当時はピンとこなかったのだが、今なら理解できる。

当時は、電気制御だろうがWebだろうがエンジニアリングとして抽象化してみれば、なんでもできる自信はあったわけだが、例えばSQLであるとかサーバサイド言語であるとかWebビジネスという技術に対するインターフェースへの期待を元に採用判断をするならば、なんの実績も知識もない人だったわけなので、採用はできないだろう。更に今はRailsやらMVCアーキテクチャだのとフレームワークの経験なども求められて、業界としてのあたりまえが増えてしまって、昔よりも確実にハードルが高い。それを鑑みても転職できたのは実にラッキーな出来事であった。

逆に言えば、この人がその先どのような成長を見せるか、というのは、履歴書からは読めない、かもしれない、ということになる。

ということは、まぁ自分の存在を正当化するならば、ポテンシャルで採用しても、その後の勉強如何でリカバリーする期待を持てるということだし、できれば自分のためにも期待していきたいと思っている。

例えば、新卒3年以内ぐらいなら、学歴をエビデンスとして、人柄、やる気ベースでポテンシャル採用することは可能である、と言ったようなことだ。新卒で大企業の名前がどこかについている会社に入ってしまったが、やってる仕事が将来、クラウドやAIで代替されそうな役割であることに気がついてしまったら、すぐに転職を検討すべきかもしれず、そういう人材であれば、第二新卒として迎え入れるのは我々としてもハッピーである。

とはいえ現状のチームの中で、誰かがリーダーやメンターとして指導するという役割を担う以上は、その人達との相性や周りのチームメンバーが一緒に働きたいと思うことはマストなので、そこらへんを見極めていくのが面接の重要な意味ということになる。要は最後はケースバイケースだが、それ故に、転職や就職は折り合いファーストなので、落ちたからと言って、あんまりガッカリしないで欲しいというのは、その辺に理由がある。

今後、我々もビジネスの発展にあわせて、組織構造を常にリファクタリングし、新しいインターフェース要求を増やしたり、チームメンバーのキャリアパスを作っていくなどして、組織が受容可能なインターフェースを増やしてあげるチャレンジを作っていかないといけない。それが技術者の新卒採用であったり、今だとお断りせざるを得ない経験の方を受け入れられるようになるはずだ。

僕自身も、その組織設計論に対する専門知識や経験があるわけではないので、スケーラビリティのある組織のクラス構造をしっかり理解しているわけではない。それについては、さまざまな人たちの助言を元に作り上げていかねばならないと思っているわけで、自分自身がピーターの法則としてのボトルネッックになってはいけないと常に思いながら組織というか、チームメンバーのやりがいを継続することを目的にアーキテクチャだけは妥協せずにリファクタリングしていかねばならないよな、とよく思ったりしている。

オブジェクト指向的に考えてみた記事は、どこか冷たいように見えるかもしれないが、関わるのが人間である以上、どういう状況下であっても、最終的には、ビジネスで求められる役割において、働く人の脳内のポジティブ物質やアドレナリンを如何に出し続けられるか?ということを、その人に期待できることが、「適切なインターフェースを兼ね備えている」前提条件であることを、最後に付け加えておく。

【PR】BASE株式会社 17職種、仲間を絶賛募集中!