開発者は、日々進行する業務を「タスク」や「課題」「イシュー」という単位にして、管理します。
ディレクションチームから、新たな機能開発の課題が生まれた時、それを課題トラッキングツールに作り、完了になるまでその業務をすすめていくことになりますが、この時ディレクションチームと開発チームで「完了」状態のイメージを揃えておかないと、この課題だけではなく、その次の課題の進捗にも遅延が発生します。お互いに、「完了」とは何かをより具体的にイメージしておくことが、開発をスムーズに進めることに繋がります。
「完了」とは何か
完了の定義は組織によって少しずつ変わってくるものだと思いますが、私が開発者に強くイメージしてほしい完了のイメージは、「もう作業をしなくていい状態」です。その課題に対して、もう何も考えなくてよくなったら、その課題は完了しています。
開発の進め方として
- 何か業務課題が見つかる
- 業務課題を解決させるために開発課題が生まれる
- コードを書いてテストする
- プルリクエストしてレビューする
- レビュー指摘箇所を直してマージする
- 検証環境に反映する
- 検証環境で動作検証し、不具合箇所の修正や調整をする
- 本番環境にリリースする
- 本番環境で動作検証する
- ディレクションチームに説明する
チーム編成や動作環境・開発手法の違いにより細かい所で違いはあると思いますが、おおよそこのような流れになります。
この中で、開発者は2-10まで担当することになると思います。動作検証に関しては、専用の検証チームや外注がいるかもしれませんが、検証中は開発者がのんびり待ってるわけでもなく、発見された不具合箇所の修正をしたり、サーバ側のデータを見て動作の確認をしています。
見積もりとタスク量
1. で業務課題が見つかり、2. で開発課題が生まれた時、ディレクションチームは業務課題の解決のために必要なコストの見積もりをします。コストの多くは開発時間で、開発には仕入れや材料が不要なため、単純な時間コストだけ聞く場合がほとんどです。「どれぐらいでできる？」と聞いてくるやつです。
その時、開発者は完了の状態をイメージしますが、そこでイメージするのは、多くは 3. が終了し、4. プルリクエストを出すタイミングでしょう。実際にそれで問題無い組織環境もあるかもしれませんが、TORICO や私がいままで所属していた企業では、「プルリクエスト出したら完了」とイメージするのは、関係者の考えている完了とは一致していないため、危険です。
ディレクションチームの完了条件
ディレクションチームが考える開発の完了した状態というのは、「開発成果が業務課題の改善に対して効果を発生し始める」時です。つまり、本番反映が終わりお客さんが使える状態になっている状態、ということです。
ディレクションをしている方は、開発者に「どれくらいでできる?」と聞いた時に「3日」と回答をもらったら、念の為に一度「開発着手してから3日で、お客さんが不具合なく完全に使える状態になっているか」を改めて聞いたほうが良いでしょう。開発者もそれを汲み取って、「本番環境で完全に動作する」と保証できる日程を答えなければなりません。必要以上に急いだり背伸びをする必要はな無く、大事なのは「本番環境で完璧に動作し、業務課題の改善に効果を発生している」状態を作ることです。そして、その状態にするためにどれだけの時間コストがかかるかの意識をなるべく正確に共有し、遠慮せずに伝える必要があります。
開発者の次の課題
コードを書いてプルリクエストを出した所で、開発担当者は一旦の区切りとなるため、そこまでを開発期間とイメージしがちです。わかります。実際はプルリクエストを出したら次の開発課題に着手することになると思うので、実際そうとも言えます。
ただし、次の開発課題を始めた後も、前の課題進捗は進むため、レビュー指摘箇所の直しだったり動作検証の不具合修正だったりで時間を使います。その対応を行っている時は、新しい開発課題は停止するので、新しい開発課題についても概ねのスケジュールを伝えているとしたら、遅延の原因になります。
別のタスクの開発時間を奪うような状態の課題は、「完了している」とは言えません。
そのため、「開発課題の完了」とは、その開発課題について何かを考慮することが無くなり、新しい開発課題に全力で集中できる状態をイメージすると良いでしょう。
本番環境て完全に動作する
さきほど、本番環境で完全に動作すること、ということを完了条件とする、と書きましたが、「完全に動作する」という文言に嫌悪感かある開発者もいるかもしれません。Windowsにも脆弱性があり修正パッチが月に何度も出ている、だから完全なんて保証できるものではない、という実例を話したくなるかもしれませんが、そういうことではないんです。本番リリースしたコードに不具合などのリスクがあることは、チーム全員もう知っています。
そうではなく、本番リリースにあたり自分の責任範囲でやることを全部かったか？ということを考えてほしいのです。もし、そこで「本番環境特有のある条件下でのある動作が検証できておらず、不安がある」と感じているのなら、検証するかチームに共有してください。リスクと時間を考慮して、チーム全体で対応策を考えられます。それらの細かい残件の対応を行い、もう確認すべき所は無い状態になり、「残課題はありません」と胸を張って言える状態が、もう作業をしなくていい状態であり、完全に動作する(かもしれない)状態です。機能リリースにはリスクがあり、不安があるかもしれませんが、検証を十分にやっているなら、具体的な理由のない不安は考えるだけ時間の無駄です。ダメな所がなければOKです。気にせず早くリリースしましょう。
実際のタイム感
おおよそですが、ウェブサービスの開発の場合は、プルリクエストを行うまでが、実際の開発進捗の半分ぐらいのイメージで良いと思います。コードを書きはじめて、プルリクエストまで3日だったら、検証と調整と本番リリースであと3日ぐらいかかる感覚です。
逆に、リリースしたい日がすでに決まっているのであれば、開発着手からリリース日までの半分のあたりで、一通りコードが書き終わってないといけません。リリース直前にコードが書き終わるイメージをしているのであれば、その開発課題のリリースは遅延します。
予定通りに完了できなさそうな時どうするか
完了タイミングを関係者に伝えているにもかかわらず、予定通りに計画が進まずに、進捗が遅延しそうな時はよくあります。
特にアプリケーション開発は、予期しない計算(計画)の連続であり、現代のアプリケーション開発で開発終了時刻を正確に見積もることは、正直に言うなら困難です。
現代のアプリケーション開発は、業務が十分に抽象化(自動化)されている現場であれば、作業時間を見積もれるような定形作業はまずありません。
もし、開発作業内に定形作業があるとすれば、それはロボット(スクリプト)にやらせることだからです。
アプリケーション開発というのは、誰もやっていない新しい課題への挑戦です。具体的には、他の開発者が開発したコードを目的のために計算して組み合わせ、求める計算結果を出させ、それを出力し記録する。というのがおおまかな流れです。他の開発者が開発したコードが、今求めているビジネス領域にどれぐらいマッチするかは誰もやったことが無く誰にもわからないため、未来に発生するトラブルを事前に知ることは不可能です。それどころか、ビジネス課題を解決するプロダクトの完成イメージさえ、開発着手時には十分決まっているわけではありません。コードを書いて、動作をチーム全員で試してから、ブラッシュアップしていくのが現代のアプリケーション開発です。
アプリケーション開発が実際にどのようなものか、未経験者に伝えることは難しいですが、例えば問題集のようなものだと考えています。達成するには全問正解する必要がありますが、問題集を開くまでは中にどのような問題が書かれているかはわからず、設問自体が自分の理解できる言語で書かれていない可能性もあります。ただし、問題集の厚みだけは見えます。その問題集を全問正解するまでの時間を、開発者は毎回見積もります。なので、見積もりはけっこうテキトーですし、楽観的に答えがちな人、悲観的に答えがちな人など、答え方に個性も出ます。(もし、それと似た問題集を解いたことがあるようであれば、似た問題集を全問正解するための見積もりはしやすでしょう。)
アプリケーション開発は、実際に書き始めてみないと難易度を理解するのは難しいため、開発途中で未知のトラブルに遭遇したり、方針の変更により、予定通り完了できない時もよくあります。
長期の開発案件でプロジェクトが予定通り進んでおらず、途中から助っ人を追加するとしたら、追加する人をよく考えて選ばないといけません。作業者より上位の人(部署リーダー等)であれば、大抵はうまくいきます。同僚の場合、(通常は別の課題を担当しているなどで) 現在の具体的な課題まで把握できていないとしたら、情報共有だけで1-2週間かかりそうです。実状をまったく知らない部外の開発者であれば、現状把握に1-2ヶ月程度かかることも考えられます。新規参加メンバーに情報共有をする場合、教えられる側はもちろん、教える側も大きな作業工数がかかりますので、新しい人を参加させ、開発のスタート地点に立たせるだけで大きな時間を使いますし、もし新規参加の方であれば、実状を把握してコードを書けるようになってから、支払った時間を回収できるだけの成果を出すことは非常に難しいです。
そのため実際にスケジュールの遅延がありそうな時は、スケジュールの計画を関係者で共有し、現行のメンバーで問題無い品質を達成するまで開発し続けるのが、おそらく最も合理的です。
予定通りに完了できなかった時にどうするか
次回の見積もり時に今回の反省点を活かした見積もりをするのは当然として、開発者はどうすれば早く開発できるかを常に考えていかなければなりません。自分の実力が 100 として、今回の開発は 99 しか出せてなかったのではないか? を自問自答してみて、 99 だったかも…ではだめです。 100 出せなかった原因を取り除き、次回は 100 を出してください。
最後に
開発課題の「完了」とは、「もう作業をしなくていい状態」であり「開発成果が業務課題の改善に対して効果を発生できる状態」です。
