先日、前職の先輩と一緒に飲んでたときにスキルの境界線の話したのでそれについて思ってること書いてみる。
以前にも似たようなこと書いた。
結局言いたいことはこのエントリと同じことなんだけど、転職して（まだ数日だけど）チームのあり方の違いとか考えるところとかあるのでもうちょっと詳しく書いてみる。
忙しい人のために先に結論
- アーキテクチャは市場で何が求められているかによって最適な形が変わる。
- アーキテクチャのあり方が変わるとそれを効率的に設計・構築するために最適なスキルのあり方も変わる。
- Conway の法則によれ組織のあり方はアーキテクチャのあり方によって規定されるべきである。つまり市場のあり方が変われば理想の組織のあり方もスキルのあり方も変わる。
- 似たようなスキルセットを持った人たちによってエコシステムが形成される。
要求の変化や技術の変化
アーキテクチャは基本的にその時代によって変わる。たかだが5〜6年程度しか業務としてソフトウェア開発をしていない若輩者なので説得力ないかもしれないけど、直接関わったことはなくても文献で各技術の栄枯盛衰について調べたり、年上の先輩エンジニアの方の話を聞いたりして僕なりに考えた結果としてこれだけは間違いないと思っている。
ユーザが求めるものが変われば当然それを満足するためのアーキテクチャは変わるし、要求そのものが変わらなくても技術の変化によってそれまで高い技術力が必要だったものがお金で解決可能になったりする。例えば PC 中心だった世の中からスマートフォンやタブレットが中心的デバイスになったのは前者の好例だし、SaaS や IaaS によってサービスやインフラを安価に調達可能になったのは後者の好例だ。
スキルの境界の変化は随時起こる
理想のアーキテクチャが時代によって変わるんだから当然それを使うために必要なスキルも変わるし、その境界線も変わる。以前も書いた。
僕が最近感じてる「スキルの境界の変化」はこういうことだ！ - assertInstanceOf('Engineer', $a_suenami)
あるスキルと別のスキルの間にはそれぞれ近さ/遠さがあって、その近いものをまとめた一連のグループが「職種」として定義されると思っているのですが、世の中の変化によってそのグループは変化すると思うのです。当然そのとき、自分のコアスキルの活かし方が変わるし、境界の向こう側にあったはずものを身につけないと自らの専門性が立ち行かなくなったりするのではないかと。
さらに最近思うのはこの境界線を超えるとそこにはきっと別の「チーム」があって、そこはある程度堅めのコミュニケーションが必要だと思う。スクラムのように対話を中心としたコミュニケーションでアジリティを保って問題を解決していければそれはすごくいいことだけど実際にそれが可能なのはそこにいるメンバーのスキルがある程度近い場合だけだと思っていて、境界線を超えた向こう側のスキルの持ち主との間のコミュニケーションはもう少し堅めのドキュメントが必要だったり、形式的な業務フローが必要なのではないかと思っている。
その流れを最もよく表しているのが microservices ではないかと思っていて、以前読んでおもしろいと思った記事を一部引用させてもらう。
microservicesに分割する際に注意するべき5つのこと - Qiita
最初に紹介したcookpadの記事では、導入に「conwayの法則」が紹介されているなど、十分に意識されていたと思いますが、microservicesへの分解は、実のところ組織パターンの問題です。
ある程度大きなサービスになり、多くのメンバーが関わるようになると、領域別にチームが編成されることが多くなります。チーム間の調整コストが増大すると開発は遅滞しやすくなり、大きな変更をすることや継続的な改善を行うことが難しくなります。
スキル境界線の内側でエコシステムができる
アーキテクチャが変わり、スキルの境界線が変わると、その境界線の内側、つまり似たようなスキルセットを持った人たち同士でコミュニティが構成され、エコシステムとして機能するようになる。そのアウトプットは OSS かも知れないし勉強会やカンファレンスの類かも知れないしいろいろあると思うんだけど、いずれの形にしてもこれはその業界やその技術領域の発展にとても寄与していると思っている。
逆に言えばある組織がこのエコシステムを構成してる範囲と違う境界線を独自に引くのはこのコミュニティの恩恵を受けられないという意味でかなり辛いことだと思っていて、スキルの境界線がどこにあるのか、その結果どういうエコシステムが構成されているのかを意識し続けるのはとても重要なことだと思う。
