誰をチームに置くか

この記事は英語の原文を日本語に翻訳したものです。原文: https://adoptingerlang.org/docs/team_building/on_the_team/

翻訳元: adoptingerlang/adoptingerlang 2025-12-18（コミット 899008f）

この章では、立ち上げ期のチームを成功に導くための最良の方法を見ていきます。ここで話すのはツールのことではなく、そのチームに誰を置くかということです。誰かを解雇したり入れ替えたりする必要はありませんが、今はほとんど持っていない領域の専門知識を新たに作り出す必要はあります。

主なアプローチは2つあります。専門家を中心に据える方法と、社内で専門知識を育てる方法です。リモートチームという話題も扱います。

どちらの場合にも通用する助言が一つあります。新しい技術、この場合ならErlangを学ぶことに前向きで意欲のある人を優先してください。学ぶ気のない人に無理強いすることはできませんが、学ぶ気のある人を後押しすることは十分にできます。

専門家を中心に据える

新しい技術や新しい事業領域の専門知識を得る最も簡単な方法は、たいていの場合、その専門知識を持つ人を雇うことです。残念ながら、これだけで問題が解決することはありません。あらゆることをその専門家に依存することになるからです。これはシステムを通るすべての変更のボトルネックを生み、専門家が休暇を取ったときには大きな停滞を招きます。

本節では、専門家を自力で見つける方法は理解している前提で話を進め、チームの構成や、そうした専門家に何を手伝ってもらう必要があるかを考えることに焦点を当てます。実際に人を採用する助けについては、その点をはっきりさせる「採用のしかた」の章を用意する予定です。

この文章を書いている時点で、業界の平均勤続年数は5年を下回っています。つまり、持続可能でありたいチームは、終わりの見えないまま専門家を次々と雇い続けることになります。秘訣は、最初の一人を見つけたあとは自前で専門家を育てることです。常にベテランや専門家を引き抜き続けてはまた辞められるよりも、若手を継続的に採用し、彼らが年月をかけて専門家として育っていくのを見届けられる会社のほうが健全だと考えます。

誤解のないように言っておくと、専門知識に反対しているわけではありません。むしろ逆で、専門知識はきわめて重要だからこそ、それを社内で生み出すことに注力すべきだと主張しているのです。従業員の成長を後押しする環境を用意できない会社は、それを用意する競合他社にいいように使われてしまいます。したがって、専門家を中心に据えるということは、その専門家がチームの残りを作り上げるパートナーになるということです。実のところ、チームの他のメンバーもこの点を意識し、正しい心構えを持って専門家から最大限のものを引き出せるようにすべきです。

これは専門家自身が十分に自覚し、時間をかけてあなたと話し合っておくべき役割です。専門家と、社内でErlangの学習に最も熱心なメンバーとで、ゆっくり始めるのが望ましいでしょう。最初の数週間、専門家の役割は主に、みんなが前に進むために必要な基礎知識を伝えることになります。これはたいてい入門書によくあるパターンに従います。基本構文とデータ型、再帰の教え方、小さなモジュールの書き方を教え、コードのテストのしかたを示したうえで、少しずつマルチプロセスとOTPビヘイビアを加えていくという流れです。

チームが基礎に十分慣れてきたら、長期的に書いて保守していってほしいシステムの最初のプロトタイプに着手してもらえます。ここで面白いやり方は、その最初のプロトタイプを純粋にトレーニングのための仕組みとして扱うことです。参加者全員が、このプロトタイプは本番に到達するためのものではないと理解しており、たとえ本番に到達したとしても、しかるべき経験を積んだ段階でまず作り直すことがロードマップの最優先事項になります。

とはいえプロトタイプは重要です。よく知っている題材を選ぶことで、それは実験場になり、従業員は言語やその癖に慣れるために自由に試行錯誤できます。これによって自分たちのドメイン知識を見直し、専門家にそれを教える機会が生まれる一方で、専門家のほうは、その知識をErlangの文脈と意味論の中でどう捉え直せるかを一緒に考えます。これがうまくいけば、両者の間に「教える側と教わる側」という関係ではなく、みんなが互いに教え合うという関係と信頼が育つでしょう。

このプロトタイピングの作業が進むにつれ、専門家はチームをより広く複雑な概念へと導いていくべきです。耐障害性を考慮した設計(supervisorツリーを適切に構造化するにはどうすればよいか)、OTPリリースのビルドとデプロイ、そして最終的にはパフォーマンスや本番環境でのデバッグに関する事項です。

私たちのお気に入りの実験の一つは、専門家がチームを導いて、できればチームがずっと取り組んできたプロトタイプを使いながら、自分たち自身のsupervisor構造を組み立てさせることです。

チームが洗い出したさまざまなコンポーネント(Webサーバ、コネクションハンドラ、エンコーダ/デコーダ、設定マネージャなど)から始め、それらをホワイトボードに描く
コンポーネント間の通信経路を描く。メッセージがやり取りされる箇所やネットワーク通信が発生する箇所を強調する
それぞれの通信経路について「これは頻繁に失敗しうるものか、失敗したときには何が起こるか」を問う。システムに障害が発生しうることをチームに意識させる
それぞれの障害について、各コンポーネントが保持している状態はどうなるべきかを問う。一時的なものか。失われてもよいか。どこかから再構築したり取得し直したりできるか
失敗しうるコンポーネントの上にsupervisorを挿入し、障害の発生後、各コンポーネントは予測可能で動的でない初期状態(supervisorから渡される初期引数)から始まると仮定する
コンポーネントを反復的に作り直し、再構成する。失うわけにいかない状態を、障害を予見しやすい箱の外に移し、再起動のたびにその情報がどう受け渡されるかを考える

この演習こそ、Erlangについて最も多くの「開眼」が起きる場面です。チームは突然、ソフトウェア設計へのアプローチ全体を作り直せるだけの理解が積み上がっていることに気づきます。Erlang仮想マシンとOTPフレームワークに固有の機能を使いこなすようになり、新しく手に入った選択肢を活かして違うやり方で構築するようになります。開発者の一部がErlangから離れて元の仕事に戻ったとしても、この構造化の経験を持ち帰り、以前の現場で活かすことになるでしょう。この経験を経てから、C#やGo、あるいはRubyの設計についての考え方まで変わったという話も耳にします。

チームが理解できたと思えたら、今の知識でプロトタイプを設計し直すよう全員に求めます。コンポーネントの一部はそのまま流用できるかもしれませんが、その多くを捨てることに何のためらいも感じる必要はありませんし、あなたもそう感じさせるべきではありません。ほぼ初心者だった頃に書いたものを、多少の経験を積んだ人たちが書き直すことになるのですから。ふり返りとして、プロトタイプで作ったものと最終的に実際の製品として出来上がったものを比較してみるのも興味深い作業です。

この学習実験を最後までやり遂げるには数か月かかることもありますが、数週間もすれば、専門家ではなかった従業員たちが徐々に自信をつけ、他の人を助け始める様子が見えてくるはずです。専門家は、自分の専門知識を広めてほしいとあなたが望んでいることを理解しているので、そうした振る舞いを後押しし、基本的な質問への対応を委ねていくべきです。そうすればチームはより成熟し機能するものへと移行していきます。人々はさまざまな話題について互いに教え合うようになり、専門家の専門知識が必要な場面は減っていき、おそらく厄介で稀な問題にのみ必要とされるようになります。そうなれば専門家は、より対等な立場でプロジェクトに参加するか、あるいは同じ技術の採用を望む他のチームへと移っていく自由を得られます。

どのように物事を進めるにせよ、専門家が折に触れてチームの他のメンバーと腰を据え、彼らが抱えているさまざまな摩擦点について尋ねる時間を作ってください。ツールや言語について何が煩わしいのかを洗い出しましょう。これはみんなが基準を見直し、物事を改善する助けになります。そうしなければ、新しく来た人は「そういうものだ」と思い込んでしまい、本来なら我慢しなくてよいはずの煩わしさを長く抱え込むことになりがちです。

専門家なしでチームを作る

専門家なしでチームを作るのは、間違いなく少し厄介です。不可能ではなく(自力で専門家になるしかなかった人たちもいます)、書籍や講演、フォーラム、チャットルームなど利用できるリソースもたくさんありますが、間違いなく難易度は上がり、コストもかさみやすくなります。専門家なしで進める最大のリスクは、誤った道や悪い方向にどれだけの時間を費やすことになるか分からない点で、早い段階での誤った学びは長く尾を引くことがあります。

これは結局のところ、通常の開発とそれほど変わりません。ただし今回は、そちらの方向に自ら進んでいくことになります。そのため、物事の構成の仕方を少し変えたくなるかもしれません。一人の専門家と意欲的なメンバーに絞るのではなく、専門家が担っていたような力学を再現するために、要件と役割をみんなに分散させることになります。

関数型言語の事前知識を持つ人を見つけてください。すべてを知っているわけではありませんが、すでに一歩先を行っています。また、自分で座って何かを掘り下げるのが好きな、自律的な学習者も見つけましょう。彼らの仕事は、本を読んでみんなより数週間先に物事を理解することです。文字通り、数週間だけ先を行くピアノの先生のようなものです。教えること、ドキュメントを書くこと、デモを準備することを楽しめる人も見つけたいところです。これはたいてい難しいので、見つからなければ持ち回りでその役割を割り当ててください。その人には、より広い範囲への情報発信、ドキュメントの保守、そして組織内向けの手早い「はじめかた」の整備を任せます。

全員が少しずつ開発に関わり、その言語の感触に慣れ、コミュニティに関わり、すでに存在するコードを活用するようにしてください。いくつか案を挙げます。

既存のコードを調べ、さまざまなライブラリとそのアプローチを紹介し合う。掘り下げてそれらがどう構造化されているかを理解する
あるオープンソースライブラリがなぜそのように動くのか分からなければ、issueで作者に尋ねたり、Slackやメーリングリスト、フォーラムの人に聞いたりする。本当の答えを手に入れ、それをみんなに示す
自分たちが書いたコードのコードレビューを行う。主な目的は、これまで合意していなかった事柄についてみんなで議論することにある。構文や整形の話も含まれるでしょうが、それよりも、どこまでドキュメントを書くか、標準としたいより良いテストのやり方といった話になることが多いはずです
行き詰まったときは、手早く話し合って、その問題を回避しうるやり方や、何を試してみるか、そして最終的にどう決断して先に進むかを見つける
実験報告を行う。チームの何人かが厄介な何かに取り組んだなら、報告して他のメンバーと経験を共有してもらう

オンラインで助けを求めることも大切です。回答が遅いこともありますが、いずれ得られます。StackOverflowも悪くはありませんが、Erlangのコミュニティを本当にうまく育ててきたとは言えません。より対話的な場(Slack、IRC、メーリングリスト、フォーラム)のほうが、参加が長続きし、本当に必要なものを見つけやすい傾向にあります。ある技術に不慣れな人は常にXY問題に陥る危険があり、それはあなたのチームも同じです。

どうしても乗り越えられない問題があるとき、あるいはもっと経験のある目で正しい方向に進んでいるか確認したいときは、コンサルタントやコンサルティング会社を1、2週間だけ雇い、最大の疑問に答えてもらい、最も明白な問題を解決してもらうという選択肢もあります。専門家を見つけて雇うより、こちらのほうが手間が少ない場合もあります。

リモートにするかどうか

Erlangとそのコミュニティが抱える問題は、雇う側が見つけられる人数よりも仕事を探している人のほうが常に多く、それと同時に、雇いたくても人を見つけられない企業もあるという点です。これは基本的に、Erlang開発者の地理的な分布とErlang企業の地理的な分布が必ずしも一致しないために起きています。Erlangの仕事を求める人とErlang開発者を求める人は、同じ場所に同じタイミングでいるとは限りません。

リモートワーカーを対象にすれば、専門家や熟練したErlangエンジニアを見つけるのはずっと楽になり、彼らは自分のネットワークを活かしてさらに人を連れてくることもできます。ただしこれは働き方の変化を伴います。2020年の世界的なCOVID-19パンデミック以降、多くのテック企業がすでに一度は試したことのある変化かもしれません。

したがって、この点についての最終的な選択は、あなたがチームを運営するうえでの好みから決まってきます。すぐにでも人材が欲しいなら、リモートワーカーを使ってチームにより早く専門知識を加える方向に傾くかもしれません。世界のほとんどの場所には、地元の市場で働いてくれるErlangの専門家がすぐに見つかるわけではないからです。市場の外にいる誰かにすぐ助けてもらうことで、すべてをゼロから自前の専門知識を育てる場合に比べて、時間とコストを大きく節約できることもあります。

こうした節約を実現するには、チームの働き方やコミュニケーションの取り方を変える必要が出てくるかもしれません。もし現在リモートワークや分散した働き方をしておらず、専門家だけがリモートになるのであれば、これは専門家自身にとっての課題にもなります。チームの中で自分だけがリモートであることは特に孤立感を覚えやすく、その人の満足度を保つのが難しくなることがあります。

この先どうするか

ここまで、専門家の助けを借りる場合と借りない場合それぞれについて、始め方と物事の構成の仕方を大まかに扱ってきました。いずれの場合も、学び、育成し、チームを成長させることに重点を置いてください。それは健全なパターンであり、リモートであっても全員が同じ場所にいるのであっても健全です。

こうした大まかな流れを踏まえたうえで、どちらのアプローチを取ったとしても導入していきたいプロセスや慣習の話に進んでいけます。