企業独自のソリューションを展開するうえで、一番怖いのは属人化だ。

特定の誰かがいないと案件が回らない。特定の誰かの頭の中にだけ仕様がある。
特定の誰かが辞めたら、顧客との関係が切れる。

これは能力の問題ではない。構造の問題だ。

私たちはそこに気付き「アルバコネクト」という会社自体を、
一つのプロダクトとして設計しようとしている。
受託案件を回す組織ではなく、案件知見を蓄積し、
基盤へ変換し続けるプロダクトとして。その話を書く。

受託の属人化はなぜ起きるのか

案件ごとに状況が違うから、対応も人によって変わる。

優秀なエンジニアが担当した案件はうまくいき、そうでない案件はうまくいかない。

経験を積んだPMは顧客の空気を読めるが、新しいPMには読めない。

これが繰り返されると、組織の知見が「人」に蓄積される。

ドキュメントではなく、記憶に。プロセスではなく、勘に。

結果として、組織は個人の能力に依存し、個人が抜ければ組織が揺らぐ。

社員を「稼働要員」として雇っていない

アルバコネクトの考えは明確だ。

社員の価値は「手を動かす量」ではなく「仕組みへの貢献度」で測る。

稼働要員が欲しいなら、業務委託でいい。
社員を雇う理由は、案件の合間や案件の中で、再現可能な仕組みを組織に残せるからだ。

案件で成功したパターンがあれば、それをテンプレートにする。

失敗したパターンがあれば、それを防ぐプロセスを作る。

一人の経験をチームの資産に変換する。

仕組み化の方法論

仕組み化には、私たちが繰り返し使っている4つのステップがある。

1. 最適なやり方を見つける。

現場で実際にうまくいっているパターンを観察し、抽出する。

2. マニュアルにする。

仕事の目的、作業の手順、結果を評価する方法を明確に記す。

ここで重要なのは、手順だけでなく「なぜそうするのか」を書くことだ。

手順だけのマニュアルは、状況が変わると使えなくなる。

3. 数値化する。

KPIと評価基準を設定し、主観を排除する。「なんとなくうまくいった」ではなく、

「この指標がこう動いたから、このやり方は有効だ」と言える状態にする。

4. 改善する。

数値に基づいて仕組みを継続的にアップデートする。

仕組みは一度作って終わりではない。

このサイクルを回し続けることで、属人的な成功体験が再現可能なプロセスに変わる。

テンプレートは「手抜き」ではない

よく誤解されるが、テンプレート化・標準化は品質を下げるためではなく、品質の底上げのためにやっている。

Discovery成果物の6点固定（「要件定義を、独立した商品として売っている

」で書いた）もその一つだ。

案件ごとに成果物の形が変わると、品質のばらつきが出る。
テンプレートを固定することで、最低品質が保証される。
その上で、案件の個別性に応じてカスタマイズする。

提案書、見積書、プロジェクト計画書、振り返りフォーマット。
これらを標準化していくことで、「誰がやっても同じ品質」の土台ができる。

仕組み化するのは社内オペレーションだけではない

仕組み化したいのは、単なる社内の業務プロセスではない。

受託案件の中で得た知見を、顧客ごとの一回限りのノウハウで終わらせず、
再利用可能な方法論・テンプレート・意味構造・実装パターンとして蓄積することだ。

Discovery成果物の6点固定も、Meaning Mapという設計フレームワークも、
価値KPI設計の方法論も、すべて「案件を超えて使える共通基盤」として設計している。

そうでなければ、受託はいつまで経っても案件消化業のままだ。
案件をこなすたびにチームが消耗し、終わったら知見がゼロに戻る。

Palantirは政府向けの受託的な仕事から始まった。
だが、案件ごとに個別対応で終わらせず、共通基盤を育て続けた。
案件を通すたびに基盤が強くなり、次の案件の競争優位になる。
その構造を作ったから、SIを超えた存在になれた。

これは実は、汎用型知性を、最もローカルなデータと組み合わせる事で最適化し、
プラットフォームに還元するという、最も単純で早い方法だ。

アルバコネクトが現在目指しているのも同じ方向だといえる。
案件をこなす会社ではなく、案件を通じて基盤そのものを強くしていく会社だ。Discoveryの方法論、意味構造の設計パターン、エージェントの設計知見
——これらが案件ごとに蓄積され、圧縮され、次の案件で再利用される。
受託は全く最終形ではない。基盤を鍛えるための学習装置だ。

リモートファーストが機能する条件

リモートファーストが機能するのも、
知見を人の頭ではなくドキュメントとログに残す前提があるからだ。

アルバコネクトはリモートファーストで運営している。
東京・虎ノ門にオフィスはあり、別拠点もいくつかあるが、出社はチーム単位で行なう。

特にエンジニアリングチームなどについては、基本的にリモートで運営している。

ただし、リモートが機能するには条件がある。

ビジョンが全員に浸透していること。 

なぜこの会社が存在するのか、どこに向かっているのか。
この「太い幹」を全員が持っていれば、日々の判断で大きくズレることはない。

成果物とKPIで評価されること。 
オフィスにいる時間ではなく、
何が価値に繋がったか、何を作ったか、何が改善されたかで評価する。

非同期コミュニケーションの規律があること。 

ドキュメントに書く、議事録を残す、決定事項をログする。

「ビジネスが私たちに仕える」

アルバコネクトにおいて、組織運営で最も大事にしている考え方がある。

私たちがビジネスに仕えてはならない。ビジネスが私たちに仕えるのだ。

特定案件の都合で毎回プロセスを作り変えるのではなく、共通基盤の上に案件を通す。そうしなければ、案件は増えても組織は強くならない。仕組みを先に作り、その仕組みの中で案件を処理する。案件に合わせて組織を変形させるのではなく、組織の構造の中に案件を通す。

属人化を完全に排除できるのか

正直に言うと、完全には排除できない。

たとえば営業における人間関係の構築力は、どうしても属人的になる。
技術的な審美眼も、経験に根ざす部分がある。

属人化への対処は2つしかない。

A. 仕組みに変換する。 
その人にしかできない業務をマニュアル化・標準化し、誰でもできる状態にする。
これが基本方針だ。

B. 属人的スキルを認め、インセンティブで報いる。 
仕組み化が不可能な領域は、そのスキルに対して明確な成果報酬を設計する。
感情論ではなく、構造として処理する。

重要なのは、AとBのどちらを適用するかを意識的に判断することだ。
「なんとなく任せている」状態が、属人化の温床になる。

エンジニアにとって、これは何を意味するか

僕たちの組織では、エンジニアは「コードを書く人」ではなく、「仕組みを作る人」だ。

案件で見つけた成功パターンをテンプレート化する。

データパイプラインの構築手順を標準化する。

Discovery成果物の生成を半自動化する。品質チェックのプロセスを仕組みにする。

コードを書くことは手段であって、目的は「再現可能な仕組み」を組織に残すことだ。

一つの案件で学んだことが、次の案件の品質を上げ、その成果がチーム全体に波及する。自分の仕事が「消費」されるのではなく「蓄積」される。

案件を納品して終わるのではなく、案件を通じて基盤そのものを強くしていく。その仕事に面白さを感じる人と、一緒に働きたい。