ビープラウドの受託開発は、こうやって始まります ― アサインMTGを中心に
「依頼したあと、どんな人が・どんな体制で進めてくれるのか」
受託開発を検討されている方から、よくお聞きする声のひとつです。何をつくるかは相談の中で見えてきても、それを「誰と、どう進めるのか」は、外からはなかなか見えません。ここがイメージできないことが、不安の正体になっていることは少なくないようです。
受託開発は、大きく2つを固めながら始まります。ひとつは「何を・いくらでつくるか」。もうひとつが「誰と・どんな体制でプロジェクトを進めるか」です。
前者は見積りや要件定義として語られることが多い一方、後者の体制づくりは、外から見えにくく、あまり語られません。けれど実際には、ここで「手の空いた人が割り当てられる」のか「プロジェクトに合わせて組まれる」のかが分かれ、そのあとの進み方を大きく左右します。
そして、この体制をどう組むかにこそ、会社ごとの考え方や特色が表れます。何を大切にしてチームを編成するか、誰がどう決めるか。その違いが、プロジェクトの進み方に効いてきます。
ビープラウドが特に時間と人をかけているのが、この「体制づくり」、なかでも誰をどのプロジェクトに充てるかを決めるアサインの工程です。ここの初動を整えておくことが、その先の進めやすさにつながると考えているからです。
この記事では、ビープラウドが開発を始める前に何を整えているのかをご紹介します。
「体制づくり」を整える3つの工程
この記事で掘り下げるのは、「誰と・どんな体制で進めるか」です。 もうひとつの「何を・いくらでつくるか」は、別記事「ビープラウドの見積りの考え方」などでご紹介しています。
開発に入る前に整えるのは、具体的には次の3つです。
アサインミーティング ― プロジェクトに合う体制を検討する
キックオフ ― 目的や進め方を関係者でそろえる
オンボード ― 開発に集中できる環境を整える
この記事では、なかでも体制の土台を決めるアサインミーティングを中心に掘り下げます。キックオフとオンボードも欠かせない工程ですが、その多くはプロジェクトごとにかたちが変わるため、ここでは考え方を中心にお伝えします。
なお、これらを「いつ」行うかはプロジェクトによってさまざまです。ただ、どんな進め方であっても、開発に入る前に体制と進め方を整えるという考え方は変わりません。
アサインミーティング ― 毎週開いている、体制の検討会
体制づくりの中心は、毎週開いている「アサインミーティング」という検討会です。 ここで、誰をどのプロジェクトに充てるかを検討・議論しています。
アサインを決めるのは、マネジメント層
ビープラウドでは、各プロジェクトのアサインを検討する場を、週に1度の定例として持っています。参加するのは、マネジメント層です。技術的な妥当性と、組織としての妥当性を、同じ場で一緒に見ています。
手が空いた人を後から割り当てるのではなく、新規プロジェクトも進行中のプロジェクトも毎週この場に並べ、そのつど最適な体制を検討し直す。これが、ビープラウドが続けている基本のやり方です。
プロジェクトとの相性を、3つの観点で見る
ご相談いただいた内容と、メンバーとの相性を見るときに、私たちが意識しているのは次の3つです。
技術スタックとの適合 ― 使う技術やフレームワークにどれだけ慣れているか
業務ドメインの経験 ― その業界やサービス領域での経験や理解
チームでの動き方 ― プロジェクトの進め方やコミュニケーションのスタイルとの相性
技術が合うだけでは、プロジェクトはうまく進みません。ドメインへの理解、そしてそのチームの中での動き方まで含めて、相性を見ています。
メンバー同士の組み合わせも見る
個人とプロジェクトの相性に加えて、メンバー同士のバランスも見ます。
経験のバランス ― チーム内での経験年数の組み合わせ
専門性のバランス ― 得意領域に偏りすぎがないか
ソフトスキルの得意・不得意のバランス ― 補い合える組み合わせになっているか
特に最後のソフトスキルの観点は、ハードスキルだけでは見えない大切なところです。たとえば、関係者との調整やコミュニケーションを得意とするメンバーと、設計・実装にじっくり集中したいメンバーを組み合わせる、といった具合です。「合わせる」のではなく「補い合う」組み合わせになっているかを見ています。
個人の希望や展望も判断材料にしている
アサインで見ているのは、プロジェクト側の要件だけではありません。メンバー本人の希望や展望も、大切な判断材料です。
ビープラウドでは、メンバー一人ひとりとのキャリア面談を定期的に行っています。年間の展望や関心のある技術、これから挑戦したい領域などを率直に話す場です。必要に応じて1on1を追加で実施することもあり、そこで得た情報が、毎週のアサイン定例の議論に反映されています。
そうして決定したアサインは、本人に理由を含めて共有します。最終的な意思決定は本人の希望を踏まえて行われます。
発注側にも、エンジニアにも意味がある
このアサインの仕組みは、お客さまにとっても、私たちエンジニアにとっても意味のあるものです。
発注側から見れば、「人を充てがわれる」のではなく「プロジェクトに合う体制を組んでもらえる」ということ。エンジニア側から見れば、キャリア面談で話した展望が、アサインの判断材料に入っているということ。もちろんタイミングによっては全ての条件が理想通りに当てはまるわけではありませんが、状況に合わせて最も良い状態を目指す体制が組まれていきます。
キックオフ・オンボード ― 開発に集中できる状態を、開発前につくる
体制が固まったら、「開発に集中できる状態」を開発が始まる前につくります。 その仕上げが、キックオフとオンボードです。
キックオフ ― 共通の地図を持つ
キックオフでは、お客さまと私たちで、プロジェクトの目的・役割分担・連絡方法・変更時の進め方などをそろえます。最初に共通の地図を持っておくことで、「あとから認識がずれていたことに気づく」という状況を減らすことができます。
オンボード ― 開発前に環境を整える
オンボードでは、開発を始めるために必要な権限・環境・ドキュメント・現状把握を整えます。開発が始まってから「環境が用意されていない」「権限がなくて進められない」となると、せっかくの初動の勢いが止まってしまいます。だからこそ、開発前にひとまとまりの時間を使って整える、というスタンスです。
プロジェクトに合わせて、かたちを変える
ただ、このキックオフとオンボードは、プロジェクトによってかたちが変わります。たとえば、要件定義と実装で契約が分かれているプロジェクトや、人数が段階的に増えていくプロジェクトでは、一度きりのイベントではなく、フェーズごとに繰り返し行われることもあります。プロジェクトの規模や進め方に合わせて、この設計は柔軟に組み直しています。
共通しているのは、「開発に集中できる状態を、開発前につくっておく」 という考え方です。
受託開発を進めるなかでは、要件定義のフェーズですり合わせていくことも多く、初動の段階だけですべてを決めきれるわけではありません。それでも、最初に体制と進め方の前提がそろっていると、そのあとのすり合わせは格段にやりやすくなります。私たちが初動を大切にしているのは、そこに大きな違いを感じているからです。
最後に ― 相談の前に知ってほしいこと
受託開発で何より不安なのは、「お願いしたあと、ちゃんと進むのか」が外からは見えないことだと思います。
ビープラウドでは、開発を始める前の体制づくりと立ち上げを、いくつもの観点から検討しています。それは、初動を整えておくことがその先の進めやすさにつながると、これまでの経験から実感してきたからです。
もし「相談してみたいけれど、その先がイメージできなくて踏み出せない」と感じている方がいたら、この記事が一歩を踏み出すきっかけになればうれしいです。気軽にご相談いただければと思います。
そして、ここまで読んで気づかれたかもしれませんが、この体制づくりは「お客さまのため」であると同時に、「メンバーが力を発揮できるチームをつくる」ことでもあります。アサインで一人ひとりの希望や展望まで見ているのは、その両方のためです。もし、つくる側として「こういうチームで働いてみたい」と感じてくださった方がいたら、ぜひ採用ページも覗いてみてください。
