こんにちは。Loco Partnersのエンジニア、鈴木です。
本投稿では、開発体制向上のために弊社のエンジニアチームが取り組んで来た事例についてご紹介いたします。
期間としては2016年3月頃から始まり、随分改善されてきたという実感が持てたのがそれから約1年後のこと。
それらの取り組みの振り返りによって健全な開発体制の障害となりうるものの本質と、目指すべき理想の再確認を目的としています。
昔の我々と同じような悩みをもつチームの参考になれば幸いでございます。
当時の状況
要件定義、設計、見積もりが存在しない問題
当時の開発サイクルを振り返るに、以下のような状態でした。
エンハンスリストに案件を集約 -> ボードメンバーによる開発案件の決定 -> エンジニアアサイン -> 開発 -> リリース
このフローの大きな問題点は、要件定義、設計、見積もりのいずれも存在しなかったということです。
つまりエンジニアに渡った時点ではやりたいことのテーマは決まっているものの、要件定義はできておらず、設計もしていないのでタスクリストも見えず、よって見積もりもできず、しかしなぜか締め切りは決まっているという状況でした。担当エンジニアが決まってから締め切りまでの間に、要件定義と設計と開発が同時に走ります。
一番極端な例では、私に話が来た時点で既に締め切りが過ぎていたという例もありました。
差し込みまくり問題
開発の障害として大きなものの一つが、差し込み作業の常態化でした。
差し込み作業の種類には大別して二つあり、一つが開発スコープの変動です。
上記の通り要件定義がされていないので、開発スコープも決まっておらず、開発中ついでにこれも入れておいて、ついでにこのバグも直しておいて、と作業が追加されることがしばしば。なにをやればこの開発が完了なのかがまったく見えていませんでした。
そしてもう一つが、不具合対応やデータ出し、調査などの突発依頼です。
正確に言えば問題はこの依頼自体ではなく、これに対応するメンバーがいないために開発案件を抱えているメンバーが対応するしかないという状況です。こちらの依頼に対応した分、当然開発は遅れます。
Dのもたらす悪循環問題
QCDという考え方がありますが、当時開発案件に対する評価はほぼDのみだったと言っても過言ではありません。
そこでエンジニアはなんとか締め切りに間にあわせるべく、差し込みタスクの乱発を捌きながら、残業を重ねて場当たりコードを量産します。その締め切りとは前述のような要件定義も設計も見積もりもされていない状態で設定されたものです。
そして場当たりコードはメンテナンス性と堅牢性を犠牲にし、以降の開発の難度をあげる、という悪循環に陥っていました。
スピードの優先が正解となりうる状況、フェーズも存在するとは思いますが、QとCを天秤にのせたうえでの結論であるべきです。
不健全な開発体制がもたらす問題と、その本質
問題
前述のような状況下では、いくつもの害が発生していました。
プログラムのクォリティは低下し、メンテナンスしづらく不具合が発生しやすいものとなっておりました。
また要件定義に費やせる時間が不十分で、開発内容が関連する部署のコンセンサスをとれていない、そもそも周知できていないという問題も発生していました。
締め切りは差し込みタスクやメンテナンス性の低さにより遅延が常態化しており、ひどいものだと数ヶ月のプロジェクトが1年近くかかることもありました。スケジュールの見通しがたたないいため、長期の戦略を立てることも難しいような状況です。
問題の本質
これらの問題はそれぞれが絡み合い、悪影響を及ぼしあっていました。
しかし問題の根本はすべて同じ。 我々エンジニアが必要なことについて関係者にきちんと説明できていない ということに起因していました。
コードのクオリティについては我々が説明しない限りエンジニア以外には知るよしもなく、クォリティ担保のための体制についても、設計に基づいたスケジュールについても、エンジニアがいちばん詳しいのです。
なぜ設計が、時間が必要なのか、それらを得るための説明をしなければいけない。
その考えを根幹に、一つずつ対策を打っていきました。
課題に対する打ち手
開発フローへの要件定義、設計、見積もりの組み込み
まずは開発サイクルに確実に要件定義、設計、見積もりを組み込むようにしました。今では大体以下のような流れになっております。
エンハンスリストに案件を集約 -> 会議体による開発案件の決定 -> プロダクトメンバーアサイン・要件定義 -> エンジニアアサイン・設計&見積もり -> スケジュール策定 -> 開発 -> リリース
会議体にはプロダクトチーム、エンジニアチームのメンバーが参加し、仮組みのスケジューリングがされたあと、要件定義と設計、見積もりを経て初めてその開発の締め切りが決まります。
これにより無茶な締め切りとそれがもたらすプロダクトの歪みがかなり解消されました。
差し込みタスクの集約
上記のように開発フローへ要件定義、設計、見積もりを確実に組み込むことにより、開発スコープが変動することはなくなりました。そのおかげで、追加案件が出て来ても軽微なもの以外は別スケジュールで動くようになり、当初の計画に沿って開発を行うことが可能となりました。
さらに、それまで個々のエンジニアへ直接依頼のいっていた調査依頼、バグ対応などを一元管理すべく、Slackにbug-satチャンネルというものを設けました。
依頼者はGoogleフォームから内容や優先度、システム種別などを入力し、投稿するとSlackに通知されるという仕組みです。
また専任の対応者を1週間ごとの交代制で設定し、当番はその週は開発案件をもたないというルールで運用しております。これにより、手持ちの開発案件のみに集中できるようになりました。
その他Redashを導入してエンジニアを経由せずにデータ出しができるようにしたり、QAシートの準備や勉強会の開催など、問い合わせ自体を減らす取り組みも行っています。
プログラムの質向上とそのための時間の確保
今までの体制による負債は、今まさに返済しているところです。
新たな負債を抱えぬよう、複数人による設計レビューやコードレビュー、テスト項目レビューを実施したうえで新規開発を行い、加えてリファクタリングなど大掛かりな改善に取り組んでいます。
また月に一度CLEARと呼ばれるイベントを設け、エンジニアが好きな開発をしてよい日としております。ここで普段気になっていてもなかなか時間のとれなかった改善を行います。
改善活動を振り返る
重複になりますが、この開発体制の改善にあたって一番重要だったのは健全な開発に必要な事項について周りの理解を得るということでした。
無論今まで1週間でスケジュールがひかれていたものを2週間にしてください、と説き伏せるのは容易ではありません。事実改善前にも何度も同じような話はしてきましたが、中々伝わりませんでした。また新たに作ったルールを全社に浸透させるのも、中々に難しいことです。
ではどうするのか？根気強く、結実するまで説明するのみです。説明をして、少しずつ新たな取り組みをし、実を結んではまた新たな取り組みをして、それを繰り返しようやく改善されたと思えたのが我々の場合は1年ほどでした。
もちろんまだまだ課題はたくさんあります。未だに差し込みの作業が発生したり、エンジニアに直依頼が来ることもゼロではありません。
ただ解決のための方向性は既にチームに浸透していて、今後も根気強くひとつずつ改善していけるような気がしています。