Da Vinci Studio 代表の吉川です。
Da Vinci Studio は、くふうカンパニーグループ内にある開発会社です。 グループ内外の受託開発の他、自社でもサービス開発に取り組んでいます。
異色なのはその成り立ちです。
くふうカンパニーグループはオウチーノ、みんなのウェディング、Zaim、RCUBEといった、もともと自社に開発組織を持ち自社で提供するサービスを持つ会社が集まりました。 そんな中で全く新規の会社として設立され、当初からグループ外の案件の受託を事業内容に入れて組織されました。
自社でしっかりとした事業体があるにも関わらず何故あえてリソースを他に割くようなグループ外の受託を始めたのでしょうか。
自立・自律する組織という考え方
前提として、くふうカンパニーはこの考え方を土台に据えています。 親会社はあくまで各事業会社を支援する立場であり、ユーザーの対面に立つ事業会社が主体的に意思決定をする。 お互い助け合いますし、グループ内での転籍・出向も積極的に行われていますが、グループ内の各社で人事制度などもバラバラです。
そんな中にある開発組織をどう設計するか。
開発者が成長・変化できるための土壌をつくる
Da Vinci Studioを考える際に一番重視したポイントがここです。
例えば会社で一つのアプリケーションのみを開発している場合、仮に個々の機能についてまかせられたとしても、全体の技術選定や設計、あるいはデザインのトンマナなどはトップに近い人間が判断することになります。トップのレベルが全体のキャップになってしまう可能性もありますし、トップのレベルが高かったとすればそれはそれで後進が最終判断をする機会が訪れない可能性もあります。 一方で判断の経験が浅いメンバーにいきなり新規事業等をまかせたとしても、開発プロセスの取捨選択がうまくできず迷走してしまっては誰もメリットがありません。
変化についても同様です。色々な案件を行う受託開発から、一つの開発に集中したいということで事業会社に転職する人もいますし、その逆もいます。 また自身のライフステージが変わったことで取り組む仕事も変えたいという人もいます。 できるだけ長く働いてほしいと考えるのはどこの会社も同じかもしれませんが、本人の志向性の変化は福利厚生だけではカバーできません。
その人のフェーズにあった開発の場が存在することが重要そうですが、どういった場があればよいのでしょうか。
開発プロセスにおける意思決定・判断ができる場を増やす
開発プロセスにおいては大小様々な粒度の意思決定が必要となります。
ひとつのメソッドにどの程度までの責務をもたせるのか、といったことも判断ですし、MVPをどのように定義するのかも判断です。 プロジェクトを進める、あるいは事業開発に近いことをやりたいのであれば、様々な案件で判断の経験を重ねることで引き出しが増えていくでしょうし、 ある特定技術の専門性を高めたい場合、その技術に絡む部分の判断を多くすることで専門性は高まるでしょう。
必ずしもすべての領域において判断ができる必要はなく、一人ひとりで見た場合は、軸となる領域は深まるように、隣接領域には幅が広がるように、 山なりの経験値を得ていくことで、より大きな判断ができるようになるはずです。
開発プロセスにおける取捨選択の精度を高める
判断とは、何かの選択肢を取捨選択することに他なりません。 取捨選択する精度が高まると、開発プロセスの時間が短縮されます。
同じアウトプットにかかる時間が短縮できれば、同じ時間内により多くの試行錯誤を追加して品質をより高めることもできますし、 逆に品質はそのままにアウトプットの数を増やすこともできます。
開発者、あるいは開発組織にとってアウトプットの品質はケースバイケースで一義的に決めるのが難しいポイントですが、 同じアウトプットにかかる時間を短縮することは一義的にプラスに働くことが期待できます。
判断力を高めるために必要なもの
判断判断言っていますが、ランダムに決めてしまえばそれは判断ではなく賭けです。
設計を行う際は、ベストプラクティスとされるものを知っていればそれを利用するべきですし、それがなくとも自身の開発経験から近しいものを組み合わせることで的はずれなことに時間を使うことはなくなるはずです。 何かエラーでハマってしまったという際も、エラーメッセージをちゃんと読むのは当然ながら、そもそもこの構成でXというエラーは起こり得ないので、可能性としてはYかZだ、という風にアタリをつければ、闇雲に色々変えて試すよりはるかに効率が良いはずです。
そのためには
- スキルセットや知見の幅を広め、あるいは深める
- それらを活用して判断を行う機会を増やす
ということを念頭に置かなければなりません。
幅を広げるという意味では、幅広い種類の開発案件があると良さそうです。であれば受託開発という形が向いていそうですね。 受託開発の方が新しい技術に取り組みづらい・・というイメージを持つ人もいるかもしれませんが、 自社開発で運用年数が増えると気軽にリプレイスはできませんし、例えばフロントをReactにしたいと思っても事業メリットが無いためそこにリソースを割きづらい・・・ということもあります。 新規で開発する場合はそういった縛りがありません。そのため必然的に新規が増える受託の方が新しい技術を導入しやすいと考えています。 もちろんあまりにピーキーな技術を試すのは憚られますが、それは自社サービスでも同じはずです。
ただこれは表裏一体で、長年の運用を経ることで様々な応用ケースが発生しやすいのは自社サービスです。新規の場合はミニマムで開発する場合が多く、その場合シンプルな構成で済んでしまいます。 それが時間を経ると当初のユースケースでは対応できないためフレームワークの拡張を行ったり自社で何かしら開発したりと複雑になっていきます。そういった場面でしか得られない経験もあるはずです。
受託開発と自社開発の機能を併せ持つ組織
Da Vinci Studioでは冒頭に述べたようにグループ内外の受託と自社開発を行っています。 グループ内事業の既存の年季が入ったサービスもありますし、グループ外で運用されていたシステムを引き継ぐケースもあります。 またグループ内・外においてスクラッチで開発を始めたものもあります。
ただそれらだけだとカジュアルに新規技術を試しづらかったり、あるいはディレクション等まで入る場合にある程度要求レベルも高くなるため（それが良い人ももちろんいます） 自社開発しているものでそこをカバーしています。
例えばリーダーサポートのもと様々な開発案件の実装を行い、その後受託案件で一つのプロジェクトをリードする経験を得る。 あるいはプロジェクト横断で特定の技術領域についてカバーしていく。といった様々な場ができてきます。
自身のロールを宣言する
さらにこういった経験の場を最大限に活用するため、評価制度にも少し工夫があります。
Da Vinci Studioの目標設定フォーマットは
- 組織の中で自分が解決すべきIssue
- そのために担うRole
- 具体的に担えている状態
という3つから構成されており、Approveされた後に毎月これらに対応する形で実績を追加していきます。 なおこれらはGitHub上でプルリクエストを出し、上長でなく全員が見えてコメントできる形をとっています。
初めてこのフォーマットでやるメンバーは面食らう人も多いのですが、それでも出てくる自身のRoleは千差万別です。 例えばRailsについてのスキル・知識を増やすというメンバーもいれば、アプリもサーバーサイドもシームレスに開発できることを目指すメンバーもいます。 しっかりと言葉にすることで、本人だけでなく周囲もそのメンバーの志向性を認識します。 周囲が認識していることで、そのRoleに関連するアサインがされやすくなりますし、相談やトピックも集まりやすくなります。
出る杭は引っこ抜いてエースに
ここまで成長軸を考えているのは、それこそが最終的に開発組織のパフォーマンスを最大化すると考えているためです。 プロダクト開発がうまく進む場合は、組織体制やテクニック的なところももちろんあるでしょうが、やはり中心となるキーマンが存在する場合が多いと考えています。 その人が入るだけで何故かプロジェクトがうまく進む、という人を見かけたことはあるのではないでしょうか。 それはおそらくその人が高い専門性を持ち、固有の専門性を活用して判断できるからだと思います。
もちろん採用で連れてくるという手はあるのですが、そのプロダクトや組織課題にぴったりマッチする人材が見つかることは稀だと思っています。 近しい人は見つかるかもしれませんが、その場合には組織がその人を中心として多少なりとも再構成される必要があります。
つまりいずれにせよ組織は成長・変化できる土壌がなければどこかで行き詰まってしまう可能性が高いということです。
そこで、成長・変化する土壌を最大限に形成するために、あえて既存の開発組織とは別に立ち上げたのです。
実際のところ、当初は実験的な意味合いも含まれていましたが、今となっては当初の規模より3倍ほどに開発者も増え、また様々な開発組織の土壌が混じり合い始めています。 まだまだ課題もありますが、すごい開発者集団になれるように日々頑張っています。
社外へのアウトプットの場をつくる
さてさて場をつくるという意味では、社外へアウトプットしていく経験も重要ですね。 ということでDa Vinci Studio ブログが始まりました。 今後Da Vinci Studioのメンバーが得た経験をどんどんアウトプットしていきたいと思います。
これからどうぞよろしくお願いいたします。
