案件をこなすのではなく、基盤を強くする

企業独自のソリューションを展開するうえで、一番怖いのは属人化だ。特定の誰かがいないと案件が回らない。特定の誰かの頭の中にだけ仕様がある。特定の誰かが辞めたら、顧客との関係が切れる。これは能力の問題ではない。構造の問題だ。私たちはそこに気付き「アルバコネクト」という会社自体を、一つのプロダクトとして設計しようとしている。受託案件を回す組織ではなく、案件知見を蓄積し、基盤へ変換し続けるプロダクトとして。その話を書く。受託の属人化はなぜ起きるのか案件ごとに状況が違うから、対応も人によって変わる。優秀なエンジニアが担当した案件はうまくいき、そうでない案件はうまくいかない。経験を積んだPMは顧客の...

要件定義を、独立した商品として売っている

アルバコネクトでは、要件定義を本開発の付属作業ではなく、独立した商品として提供している。理由はシンプルで、ここを曖昧にしたまま始める開発は、ほとんどの場合あとで高くつくからだ。なぜ要件定義を切り出したのか受託開発の典型的な流れはこうだ。提案 → 受注 → 要件定義 → 設計 → 実装 → テスト → 納品。この流れの中で、要件定義は「受注後の最初のステップ」として扱われる。本開発に含まれる作業の一部だ。場合によっては提案段階で無料でやってしまうこともある。僕は100社以上のプロジェクトに関わってきて、この構造自体に問題があると気づいた。要件定義が「本開発の一部」として埋もれると、ほぼ必ず...

意味のインフラを設計するために、この技術スタックを選んだ

技術選定の話をしたい。ただし、これは「流行りのフレームワークを比較してみた」という記事ではない。解こうとしている問題の構造から逆算して、なぜこのスタックに辿り着いたのかを書く。そして正直に、今どこまでできていて、何がまだ解けていないのかも書く。問題の構造企業のデータは、CRM、ERP、Slack、メール、スプレッドシートに分散している。それぞれ「事実」としては存在するが、「意味」としては繋がっていない。KPIの定義が部門ごとに違い、意思決定のたびに「この数字、何を指してるんだっけ」という会話が繰り返される。アルバコネクトが構築しているのは、この「意味の断絶」を構造的に解消するインフラだ。...

東大で宗教を学んだ私が、AIスタートアップで「仕組みをつくる側」に回った理由

はじめまして。株式会社アルバコネクトで執行役員をしている宮澤です。この記事では、私がなぜこの会社にジョインしたのか、今ここで何をやっているのか、そしてこれからどんな人と一緒に働きたいと思っているのかを書きます。経歴だけ並べると「宗教学 → 野村證券 → AIスタートアップ」と、一見バラバラに見えるかもしれません。でも自分の中では一本の線でつながっています。その話をさせてください。宗教学とAI設計のつながり東大の文学部で宗教学を専攻しました。自分自身は無宗教ですが、「人はなぜ宗教を信じるのか？　宗教は人間に何を与えているのか？」ということに、純粋に興味がありました。いろいろな宗教を勉強する...