個人開発者（いわゆるフリーランス）と、中小企業の開発者は、ひとつのプロジェクトに掛かりっきりということがまずありません。いくつかのプロジェクトを掛け持ちすることになります。
前提
実は、大会社の開発者（システムエンジニアとかマネージャではなく）や派遣社員や契約社員の場合には、一定の期間一つのプロジェクトに拘束されるというのが常です。特に、派遣社員や契約社員はそうなのですが、中小企業というか20人ぐらいまでの小規模のIT会社の場合には、一つのプロジェクトに縛られることはまずありません。色々なプロジェクトを平行に動かす必要がでてきます。
というのも、
- 開発プロジェクトの規模が小さく、ひとつのプロジェクトに貼り付けにするほど予算がない。
- 請負開発を受注する場合、社員＝開発者が少ないので複数プロジェクトに配員せざるを得ない
という現状があります。発注側からみてフルタイムで働いているように見えて、内実は別のプロジェクトも抱えている、というのが現状ですよね。マネージャーや営業レベルだと複数のプロジェクトが動くのは普通なのですが、開発者の場合は複数プロジェクトというのは大手であれば稀だが中小であれば当たり前だったりします。
この認識を前提としていきます。
当然、個人開発者の場合も同じで、派遣や契約社員にならないのであれば、複数のプロジェクトが掛け持ちになるのが普通です。フリーランスなのでハンドリングを自分でやるのが中小の社員とは違いますが、マルチプロジェクト化します。
スクラム方式ではうまくいかない
基本的に、アジャイル開発スクラムの場合には、ひとつのプロジェクトに集中できることが前提となります（実際はどうなのかは別ですが）。自分の時間をコミットするので、2週間なりのスプリントができるし、そのプロジェクトの中で課題（バックログ）のやりくりをします。
ですが、先の中小や個人開発者の場合は、ひとつのプロジェクトに集中できるわけではないので、このスクラムの前提が崩れてしまいます。
と常々思っていたのですが、その理由が解説できそうなので、メモとして残しておきます。
理由はまさしく先に書いた通り、ひとつのプロジェクトに集中できない、つまりはコミット率が低くなってしまうので、スクラムの柔軟さが失われてしまうということです。なので、複数プロジェクトを掛け持ちしているメンバーがスクラムチームにいると失敗しがちですね。巷でいうスクラム開発が失敗したり、うまくいかないと思われている理由はこれでしょう。
マルチプロジェクトをマルチプロセス化する
ひとりの開発者が複数のプロジェクトを掛け持ちしていることを考えてみましょう。ここでは、経費精算とか社内での勉強会とか定型業務は別とします。一般的な開発プロジェクトのようにスタートとエンドが決まっているものを示します。
開発者が、A,B,C という3つのプロジェクトを掛け持ちしてる場合、複数の時間の使い方が考えられます。
- Aプロジェクトを終わらせて、Bプロジェクトを終わらせて、Cプロジェクトを終わらせる
- 1日を3分割してA,B,C のプロジェクトを少しずつやる
理想的なプロジェクトの形式で進めれば、どちらの方法もA,B,Cプロジェクトを終了させることができます。実際のところ、プロジェクトが1週間程度のものであれば、シーケンシャルにA,B,C と進めていったほうが早く終わります。頭の中でプロジェクトを切り替える必要がないのですから、それぞれの専任していると同じになります。
しかし、実情としては後者のようにA,B,Cのプロジェクトをちょっとずつやることになります。これは、各プロジェクトが長期に渡るのも理由なのですが、実際には途中に進捗会議があったり、客の回答待ちになったり、開発環境の購入待ちになったりします。その合間に別のプロジェクトをやったほうが時間効率がよくなる…ように見えるためです。
1日を3分割するのであれば、A,B,C の3つのプロジェクトを廻せそうですが、お客との会議や回答待ちなどを考えると、必ずしも1日を3分割にする必要はありません。むしろ無駄ができそうです。
なので、プロジェクトという単位ではなく、プロジェクトにプロセス/タスクという単位に区切ります。実際のところ単一プロジェクトであっても WBS/バックログ/チケット、という形で作業分割を利用するので、それと同じ状態です。ただし、複数のプロジェクトであり複数のタスク（プロセス）であるということが違います。
タスクを細かく分割すると、A,B,C のプロジェクトの切り替えでセットアップ時間（仕事の切り替え時間）が発生してしまいますが、そこは個人開発者の場合は休憩時間や昼休みなどを利用します。また、タスクに分けたときに、”タスクの途中でも切り上げられる” & “タスクの途中でもうまく再開できる” 仕組みを用意しておきます。理想を言えば、ひとつのタスクが仕上がるまで掛かりっきりになるのがベターではあるのですが、そこまでタスク/チケットを細かくできないことが多く、タスクの中の作業単位（TODOや箇条書き）で切り替えができるとよいです。
複数プロジェクトのタスクを渡り歩く
個人開発者であれば、身がひとつなのですから、Aプロジェクトのタスクをやっている間は、BプロジェクトやCプロジェクトのタスクはお休みなります。一見、マルチタスクで動いているようには見えますが（今後 AI エージェントの活用次第ではそれができるかもしれませんが）、個人の時間軸から言えばシーケンシャルにこなしているだけです。
この場合、A,B,Cの開発見積（予算、金額）はどうなるでしょうか？
プロジェクトの作業見積をする場合、大抵はプロジェクトに専任であることが前提となっています。スクラム方式で言えば、1か月20日8時間勤務ですから、160時間が基準値となります。
これを基準としたとき、A,B,C プロジェクトを掛け持ちする場合を考えてみましょう。
- Aプロジェクト 80h
- Bプロジェクト 40h
- Cプロジェクト 40h
という見積もりを立てることが多いですよね。プロジェクトマネージャーやプロジェクトリーダー役をやったときに、マルチプロジェクトになってしまった場合にはこんな感じに割り振ってしまいます。
大抵の場合、作業時間 x 単価ということになるので、AプロジェクトはBプロジェクトの2倍の予算が掛かります、とお客に説明するわけですが、果たしてそうなるでしょうか？当然のことながら、A,B,C のプロジェクトのお客さんは別々で、互いに顔を合わせることはありません。場合によっては、開発者が自分のプロジェクト（Aプロジェクトとか）に専任していると思っているかもしれません。そうです、いわゆる「官庁プロジェクトの開発者は3倍働く」わけですが、それはまた別の話。
割り振った時間や予算は2:1:1のように分割されますが、実績ではそうはなりません。計画上は2:1:1の比率になるのでしょうが。例えば、Bプロジェクトがちょっと遅れ気味の場合は、Aプロジェクトを少し抑え気味にしてBプロジェクトに力点を変えますよね。Cプロジェクトがさっくりと終わるようであれば、そのままA,Bプロジェクトに作業時間を割り振ってしまうことも稀でありません。そんな形で、A,B,C プロジェクトに費やす時間を開発自身が割り振り直してしまいます。
マルチプロジェクトが安全バッファとなる
過小見積をしてしまうと、A,B,C の3つのプロジェクトが炎上してしまって、どのプロジェクトも立ち行かなくなってしまいます。しかし、それなりに規模見積もりがあっている場合は、A,B,C の実績は平均値を上下する程度で済みます。平均を上下した場合、先のように他のプロジェクトにリソース（この場合は時間）を割り振ることができます。つまりは、CCPMのプロジェクトバッファと同じように、マルチプロジェクト自体が安全バッファとなるのです。マルチプロジェクトの場合は、プロジェクトごとにバッファを持たせる必要がなくて、マルチプロジェクト全体のバッファを持たせればよいということになります。これは個人開発者の場合は、土日祝日だったりするわけです。忙しいときは仕方がないので土曜日に少し足しておくか、という感じです。
制約理論的には、プロセスのバッファをひとつにまとめてプロジェクトバッファとしているのですから、複数プロジェクトのバッファをひとつにまとめて、マルチプロジェクトのバッファつまりは開発者自身のバッファということになります。つまりは、単一プロジェクトに掛かりっきりになるよりも、ある程度マルチプロジェクト化したほうが安全ということです。もちろん、同時に炎上しないように注意する必要はありますが。果樹園農家で、ひとつの果物に集中するのではなく、リスク分散して複数の果物を作るのに似てますね。
