こんにちは、お酒大好きエンジニアの飯田（@yo-iida）です。
現在は、エンタープライズ・新規事業開発グループという部署で、クラウドワークスのエンタープライズ向けの機能開発を担当しています。
我々のチームでは、通常のクラウドワークスのサービス開発ではなく、（グループ名そのままなのですが）クラウドワークスの新規事業やエンタープライズ向けの開発をメインで行っております。 ※エンタープライズや新規事業の説明については後述
具体的には、
です。
クラウドワークスの通常の開発はスクラムベースでチーム内にプロダクトオーナーがおり、プロダクトオーナーと施策の優先順位を決め、開発、リリース、効果検証、というような開発スタイルになるのですが、我々の場合はプロダクトオーナーが他事業部の責任者になります。
今回は、エンジニアチームが複数の他の事業部と横断的に仕事していく場合に、どのようなことが重要になるのかを、実際に私が体験したことを軸にまとめたいと思います。
エンタープライズや新規事業の位置付けについて
まず、クラウドワークスのエンタープライズ事業についてですが、この事業は法人顧客様向けに、クラウドソーシング活用の提案をさせていただき、様々なサービスを展開している事業になります。
基本的には、提案を行う営業と、クラウドワークス上で制作を進め納品物を作り上げるディレクターで構成された事業部になります。
直近ではエンタープライズで新規に立ち上がったリサーチ事業の機能開発を行いました。
また、新規事業として2015年4月に立ち上がったクラウドテックもクラウドテック事業部として営業やキャリアサポートのメンバーがいます。
これらの事業部は独立して事業目標を設定して動いており、エンジニアとは組織が分かれている上で、一緒に開発を進めている状況になります。
エンタープライズ・新規事業開発グループの関係図
他事業部と仕事を進める上での難しいこと
クラウドワークスの通常の開発はKPIごとのチーム編成となっており、チーム内にプロダクトオーナーがいるので、施策の優先度や開発リソースの配分は基本的にはチーム内完結で判断して進めることができます。
しかし、他事業部と施策を考える場合、施策の優先度は事業部の責任者でないとわかりません。
たとえば、営業のほうでどのような戦略で仕事を取りに行っているかや、ディレクターが現場で感じている課題感はエンジニア側からはなかなか見えづらいところだからです。
また、複数事業部とやりとりがある場合、事業部Aの最優先事項と、事業部Bの最優先事項のどちらを優先すればよいでしょうか？
これは経営的な視点で判断が求められる場合もあり、エンジニア側での調整が難しいケースです。
また、依頼の窓口が一本化されていない場合は、個別の担当者から五月雨的に依頼が来る場合もあり、このような場合は事業部内での優先度も判断しづらいケースもあります。
上記のどのケースも開発リソースが潤沢にある場合は問題になりませんが、開発リソースが限られてきたときにすれちがいが起きやすくなります。
課題は何なのか、どこにあるのか
これらの課題は、多くの会社で起こりうる課題だと思いますが、そもそもこの状態のなにが課題なのかを整理したいと思います。
組織間のすれちがいが起きてしまうパターンは、大きく2つだと考えています。
- 事業部側が納得いく説明がない中で開発側が依頼を断る
- リソースがない中で開発側が無理して事業部側依頼を受ける
つまりは誰かが不満を抱えてしまっている状態だと、事業的なドライブをかけたいと思ってもうまくパフォーマンスを発揮できないなど、会社全体としてももったいない結果につながる懸念があるということです。
どう解決していくのがよいのか
この課題に対してはいろいろな解決策が考えられます。我々はチーム内で議論を行い、我々はなぜここにいるのか、どうあるべきなのかというところから話し合い、考えを洗練させていくプロセスをとりました。
その中で我々のチームが出した解決策は、 エンジニアが、関わる事業部の事業目標や事業プロセスを理解し、現場との対話を通して積極的に関わっていくことです。
我々のチームでは、一体感をもって事業の発展に取り組んでいくために、具体的に下記のようなことに取り組みました。
- 事業部側メンバーにGithubを使ってもらう（仕様策定やレビューの効率化）
- 事業部側メンバーにスクラムの朝会に出てもらう（コミュニケーション活性化）
- エンジニアが事業部側の仕事をOJTで体験する（現場の課題をリアルに知る）
- 事業部側に事業背景や市場、ターゲット、競合分析などを解説してもらう（なぜやるのかを明確にインプット、当事者感の醸成）
- 事業数値の状況やクライアントの共有（施策優先度を考える上でのインプット増加）
朝会の様子
OJTでライティング案件のディレクションを教えてもらっています
これを行うことで、これまで他部署からの依頼という視点で考えていたものが、共通の課題として認識できるようになります。 部署が別だったとしても開発側と事業部側が同じ当事者、同じチームということを意識するようになります。
これはチームビルディングの上でとても重要なことだと考えていて、
- 施策の精度が上がる（仕様すり合わせの効率化や齟齬の減少）
- 開発の無駄がなくなる（最適な仕様や解決策をエンジニアから提案できる）
- トラブルが起こった時の助け合う雰囲気
といったメリットが生まれます。
このようなチームの状態を作れると事業的にはどんどん加速していくプラスのスパイラルを生み出せます。
その結果どうなったか
クラウドテックもエンタープライズのリサーチもエンジニア2人でプロジェクト開始から2ヶ月でプロダクトのリリースを達成しました。
事業側のすべての要望を普通に見積もると半年とか1年とかかかることはざらにあると思います。しかしながら、その中から本当に必要なことはなにかをお互いに歩み寄る形で絞り込んで、プロジェクトを走らせながら常に最適化を行うことで最終的にお互いにハッピーな結果にたどり着けたのだと思います。
実際に作ったものの具体的な成果では、それまで最長で納品まで1ヶ月ほどかかっていた案件を当日受注当日納品ができるようになったり、リリースから機能開発を重ね業界最短の支払いサイト*1を実現したりと、実際にクライアントやユーザーに価値を届けることに成功しています。
とはいえハードル高くないですか？
上では結果的にやったことを挙げましたが、一気に全部をやったわけではありません。
実際にはもっと些細なコミュニケーションからスタートしています。大事なことは課題に対して一緒な方向を向いて考えようという雰囲気です。
組織間のコミュニケーションは思っているよりも難しいものだと思います。
依頼したいと思ってもどう依頼していいかわからなかったり、依頼してもなかなかうまく作って欲しいものを伝えることができない。。
仲が悪いわけではないけど、なんか連携がうまくできてない感が漂ってしまっている。。
といった課題感をそれとなく共有していくところから始めるとだんだんアプローチが明確になっていきます。
チーム内からチーム外への波及
もしチーム内でできそうな解決策を試してみてうまくいけば、次はそれをアピールして広めていくことが大事です。
クラウドワークスでは社内のfacebookグループがあり、そこで社内トピックを共有する文化があるのですが、こういったところでうまくいった試みをちょこちょこアピールする活動をしていました。
だいぶ認知が進んだ結果、今では管理部門のメンバーまでGithubアカウントをもつようになりました。
参考文献
クラウドワークスではだいぶアジャイルの考え方が浸透してきており、自然とチーム内で実践するような体制になってきました。
弊社エンジニアの間でよく読まれている本はアジャイルサムライです。
- 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
- 購入: 42人 クリック: 1,991回
- この商品を含むブログ (254件) を見る
今回の記事で紹介したことは、アジャイルサムライの「チームをアジャイルにするためのコツ」で書かれていることを実際にチームビルディングの際にやってみたらこんなかんじ、という目線で参考にしていただけるとわかりやすいかと思います。
最後に
今回はエンジニア視点で部署間のチームビルディングを進める上で重要と感じたことを書いてみました。
ただ、まだ組織的な枠を超えられていない部分もあると考えています。
エンジニアがビジネスモデルを描いて事業的判断をできるようになったり、ディレクターや営業の人がプルリクエストを出して自らサービス改善したり、さらにはそれをリモートでできるようになる、そういった垣根を超えた仕事のやり方にチャレンジしていきたいと思っています。
クラウドソーシングのクラウドワークスでは常識にとらわれないフレキシブルな働き方を実現したいエンジニアを募集しています！
photo credit: Teamwork and team spirit via photopin (license)
