この記事は、 BRIGHT VIE Advent Calendar 2017 - Qiitaの 23日目の記事になります。

今日は、数年前のお話ですが、個人的に経験したチーム開発での失敗や得られた知見などを記載しようと思います。

はじめに

今回お話するのは、とある新規開発案件において約2年間、案件の開発チームをまとめていたときのお話を少しだけ。
それまでは、ほぼ運用チームでインフラや案件の開発のサポートをメインで行っており、
また新規案件においても開発チームの中で一つのセクション担当（Webフロント担当だけとかサーバ担当だけとか）くらいで、
ガッツリ新規案件に取り組んだのは初めてだったので、力不足で失敗も多くとても迷惑をかけてしまいましたが、
自分にとってはとても良い経験になったのでその経験を簡単に記録できればと思っています。

なお、書き出すと結構ありそうなので、今回はチーム体制のお話にとどめておきます。

開発時期別の状況

開発当初のこと

新規案件とはいいつつ、フルスクラッチ開発ではなく、既にリリースされているサービスをブラッシュアップする形で開発する案件でした。
そのため、エンジニアチームとしては、自分も含め既存のシステムを少しでも経験したことがある人が半分以上をしめているようなチーム構成でした。

チーム全体としては下記のようなイメージ（ウル覚えですが）

そしてエンジニアチームとしては下記のような感じだったかと（人数は仮）

自分は緑色のポジションにいながら今後の成長も考慮して頂き、サポートを頂きながらエンジニアリーダーの立ち位置も半分兼任させていただくことになりました。

実際に行っていたこととしては、

プランナーやデザイナーの方など各セクションリーダーとのやりとり
PMの方とのスケジュール面での連携
サーバサイド、Webフロント、ネイティブ、インフラのタスク管理や調整
コードレビューやWebフロントの実装
外部とのやりとり
- ここには記載がないですが、外部企業様との協同案件
- 連携するSDKやサービスの外部担当者とのやりとりなども含む
スプリントの管理、チーム全体でのレビュー会やKPTの進行・KPT管理など
会社エンジニア組織を管轄する人とのやりとり

技術領域としてもWebフロントを得意としながらも、全てのセクションを見れる（ネイティブだけWebViewの拡張処理と課金部分のみ）状態でもあったので、各エンジニアセクション間の調整も合わせて担当をしていました。

まぁ当時は若さと元気もあったので、楽しくやっていましたが、今思うとこれだけでも何やら雲行きが怪しい感じがしますよね。
（そうです、当時は1日が8時間という感覚なんてなかったですからねー、若いって困ったもんです。。。）

なお、案件開始当初は、既存システムとの大幅な仕様変更や既存システムのブラックスボックな部分に悩まされながらも
ある程度内部を知っている人がいたからこそ、各メンバーも協力しつつ自発的に、より良くしていくために開発が進んでいました。

また、2週間を1スプリントとして成果物のレビュー会の実施やチーム全員でのKPTを行っていたこともあり、それぞれがチームの課題に向き合いながらもある程度良い雰囲気の中で開発をすることが出来ていました。
（月1回程度の焼肉会とか餃子会とか飲み会は楽しかった）

開発開始後、半年から1年頃までの期間のこと

ちょうどα版が出来て最初のレビューが行われていた頃でしょうか。
ある程度主要な機能が動くようになり、今後ブラッシュアップやβ版に向けた開発を進めていこうとした矢先、
組織変更に伴うメンバーの入れ替えや組織全体での退職者の増加などにより、
徐々にメンバーが入れ替わっていくことになり....

パートナーの皆様と協力して進めていた案件でしたが、
エンジニアチームに正社員としても自分しかいなくなるハメに...

そして、外部要因による遅延が確定したことも重なり一度チームが縮小する必要があったり、
組織同士の契約面のいざこざがあったり、もともと新規開発メンバーと運用メンバーが違う条件で進んでいた計画でもあったようなので、
運用メンバーへの入れ替えを行う必要があったりと、
どんどん入れ替わっていくメンバーに悩まされながらの開発に、チームメンバー一同困惑気味でした。

人数は仮ですが、下記のようなイメージで、各セクションごとに結構入れ替わりが起きていた感じです...

開発開始後、1年が過ぎた頃

チームとしては縮小しなければいけなかったが、機能のブラッシュアップを行う必要性があったり、
外部要因による遅延でもあったので、追加での開発が徐々におりてきたり、
仮データから本素材や本データに切り替えてからのデータ量が想定の3~4倍程度であることが発覚し、
システムとして動作に耐えられなかったりと様々な事象が重なり、
またチームとして拡大していくことに...

メンバーを増やして解決するわけじゃないのにメンバーを増やさないとどうしようも出来ないとか、
もうどんどんそこの見えない沼に落ちていく感じで、負のスパイラルに陥っていきました。

また、当時エンジニアセクションだけでなくチーム全体として長時間労働となっていたこともあり、（月の残業時間も100時間は普通に超えていたり）
体調不良でお休みが多かったり、午前中は人が少なかったりチーム全体としても良くない風土の中での開発が行われていました。

このような状況が半年以上続いていたこともあり、みな疲弊しているような印象でした。

そしてリリースを迎える

なんやかんやありながらも、ようやくリリースを迎えたわけですがもうそれはそれはカオスな状態で...

作りの部分や案件の状況などを知っていた自分が新しいメンバーの方とも直接やりとりしていたこともあり、
自分がボトルネックになることでエンジニアチームとしても回らない不健全な状態が出来上がってしまっていました。

イメージとしてはこんな感じで、人数は仮ですが当初整理したときはもっと手が伸びていたような...

　※ なお他のセクションリーダーの中にも同様な感じでかなり負担になっている人はいました。

この他に開発タスクを持っていたり、インフラも少し手を出していたりと
そりゃ回りませんよね...

唯一救いだったのは、新規開発時からずっと一緒にやってきており、
セクションリーダーとして動いて頂いていた方には本当に助けられ。。。

自分の進め方に対して良く怒ってくださる方だったのですが（自分の周りには怒ってくれる人があまりいなかったこともあり、怒られたい衝動にかられているときでもありましたw）、
メンバーが入れ替わったり追加開発のときでも完全にお任せ出来る良い関係の方でした。

そして運用

リリースして2ヶ月くらいが経つとまたメンバーの入れ替えが発生しました。
とはいえ、メンバーもそこまで多くなかったり、リリース時期という暗黒時代を過ごしたメンバーも多かったので、徐々にチームとしても立て直しながら（問題はありましたが）、良い方向にいきながら運用を行うことが出来ていました。

とまぁそんなこんなで、リリースを迎えたものの不具合が多くユーザの皆様にも大変ご迷惑をおかけしながらも運用と追加開発に追われる日々に取り組んでいたのでした。

結局何が問題だったの

「自分の力不足」といえばそれまでなのですが、やはり一番大きかったのはメンバーの入れ替えがたくさん発生したことと、その都度立て直しが出来なかったということかと。

エンジニアだけでも、通常の開発メンバーとしては6~8名程度、多いときで15名ほどのメンバーでまわしていましたが、約2年間で携わったメンバーだけで行くと40~50名ほどの入れ替えが発生してしまっている状況でした。
（他のセクションでも退職者や契約終了に伴うメンバーの入れ替えはありましたがここまで多くなかったです）

また、自分の当時の上長もこの短期間で3~4人くらい変わっていたこともあり、エンジニアリングのことを誰に相談すれば。。。という状況もまぁ言い訳になってしまいますが、あったなぁという印象です。

メンバーの入れ替えが発生した原因は様々ですが、どんな状況であれ自分の立ち位置としての反省は

【自立したチームにできなかったこと】
【任せきれず自分が雑用として色々とやってしまったこと】
- 「あ、じゃぁそれ自分がやっときますー」と返事することが多かったなど
【断る勇気】
- 外部要因を考えずに今の状態だけの見通しで「はい」と言っていたこと
- リスクや今後の変化を踏まえて「無理です」と言いつつ別案を提示出来なかったなど
【MTGなども多く、席にいないことが多かった】
- 当時のメンバーからは、質問したいのにいないから聞けないことが多かったと言われた
【チーム内解決ではなく組織として解決に動けなかった】
- チーム内で解決しなければという思いも強かった
- 組織課題も多い中で、うまく上司を使ったり、他のチームを巻き込むなどの活用できなかった

など、一言で言うと「色々と抱え込んでしまった」のが大きいのかなと振り返ってみて思います。
開発初期から携わっていたこともあり、変に各セクションの内部状況をある程度把握してしまっていたために、「この人に聞けば分かる」という状況の脱却を積極的に行わなかったことも良くなかったと思っています。

また、今回は開発はセクションごとに行っていたこともあり各セクション間の連携強化も徐々に薄れてしまい、メンバーの入れ替えによってそれぞれのセクションがどういった作りで動いているのかなどは把握できていなかった（する時間もなかった）ので、

アプリとWebが連携している部分で、どちらも調査したが原因が分からないときなど、「それやっぱアプリが問題じゃない？」「いや、これはWebが問題なんじゃ」とお見合い状況なことが起きていたり
「担当範囲外なのでこれ以上調査出来ない」 => 調査できる人が限られている

など、結局全てを触っていた「自分が調べる」というように動いてしまい、それが原因で他が動きにくくなりボトルネックになってしまったりと...

図で表すと、指揮官は一番後ろで全体の戦況を把握しどのように攻略していくか戦略を立てなければいけないのに、自らも戦術を駆使してタスクをこなしていく役割も担ってしまったのが最大の原因かと...

良い意味での強引さも自分には足りないなぁと感じました。

プレイングマネージャーを目指してやってみたことでしたが、結果的に多くの方に迷惑をかけてしまい、
チームメンバーや先輩方含め多くの方に助けられてなんとか開発を進めることができたことに感謝しかないです...
本当に関係者の皆様はご迷惑をおかけしました...

その後

それから数ヶ月、自分も案件からは離れていたのですが、たまたま携わっていた案件にメンバーとして少しだけお手伝いする機会がありました。

メンバーも状況もかなり変わっていましたが、このときも案件として結構ドタバタな状況だったようで

リーダーの人が色々と抱えすぎて、忙しすぎて、まわっていなくて連絡が取れない
案件の状況がわからないので、外部を含む関係性や何を優先して取り組めばよいかが見えない...
他のセクションと連携して改修したいんやけど、他のセクションの人今何やってるの...？お願いしていいの...

のようなことをメンバーの位置にたって感じることが出来、当時一緒に開発を行っていた方々もこのようなことを思っていたんだなぁと凄く感じることが出来ました。
（当時のメンバーにも普段からも良く指摘されたり怒られていましたが、都度工夫しながらも自分のボトルネックは解消できずにいました。。。）

今回、当事者になってみて別に細かいタスクや作業の指示などはいらないので

案件としてステータスは今どういう状況なのか
こういうことをやりたいと思っている

といったチームとして何をしていきたいかがわかれば、途中から入った身としても、ある程度自発的に考えて各関係者と連携して動いていけるので、外部的な要因となる情報ややりたいこと目指したいことの情報共有は頻繁に欲しいと凄く感じました。

あと本当にタスクの見える化は大事です。チームなんだから。。。

本当に理想を求めるなら

個人的には上記のように上から降ってくるような開発ではなく、エンジニア含めてチームみんなが、ただの「作業者」ではなく、一人の「クリエイター」として、それぞれが自立しながらサービスのことを考えて取り組んでいけるチームを目指したいと感じています。

そのためにもまだまだ未熟者ですが、過去の失敗から得られた経験をしっかり活かして日々苦戦しながら良いチームづくり組織づくりに取り組んでいけたらなと思っております。