![見出し画像](https://assets.st-note.com/production/uploads/images/43685977/rectangle_large_type_2_922a1a0468e3ab8a81b5411334eb4fc2.png?width=1200)
短期プロジェクトってなんでつらくなっちゃうんだろう?
BtoBのプロダクト開発において、期限(a.k.a 納期)つきの短期プロジェクトに遭遇します。
そこにアサインされるとつらい経験が多くて、短期プロジェクトってなんでつらくなっちゃうんだろう?ということを考えました。
短期プロジェクト誕生秘話
短期プロジェクトとは、短い期間でミッションクリアをめざすものなので、その背景には急がなければいけない事情が必ずあります。
思いつく限り「事情」を列挙すると・・・
- 今期目標の売上が達成できなさそうだから、顧客を獲得するために手を打ちたい
- このままだと近い将来バグが発生することが目に見えている
- 顧客の離脱を防ぐために顧客の要望を実現させたい
- いまこの機能が死んでいるから
- 顧客と約束しているから
- 将来的に負債になることがあきらかなのでここで一度整理したい
- 倒産のリスクを回避したい
なんだか香ばしいですね笑
急がなければいけないのは緊急だからです。
つまり、今優先して取り組まなければ経営に悪影響を及ぼしうると考える主体がいて、短期プロジェクトが誕生します。
危機的状況に「対処する」ことへの虚無感
経営に直接的であれ、間接的であれ響いてきそうな状況があって、それを脱したいという背景は十分にプロジェクトを動かすに値すると思います。
ただ、危機的状況を脱するときに「短期プロジェクトで脱する」という手段をとった場合、どうしても近視眼的に対処しようとする力学が働くんじゃないかと思いました。
なぜなら、時間的なリソースが限られているという条件下では、いろいろ諦めて納期内にミッションを達成することに全力を尽くさざるを得ないと思うからです。
腰を据えて抜本的解決にいどみたいけれど、時間がないから対処療法でミッションクリアを目指す、というパターンです。
「いろいろ諦める」の"いろいろ"の中には、その後のプランも含まれている場合が多いです。
つまり、未来はどうなるかわからないけれど、今はこのミッションを達成しようという思考回路になってしまう。
私は、そこにむなしさを感じ、それでいいの?と思ってしまいます。
短期プロジェクトを達成して、その場をしのげたとしても、結局同じ状況がまたやってきてつらくない?というちょっとやな感じの見方をしてしまいます。
モチベーションがあがる短期プロジェクト
ではモチベーションを高くたもてる短期プロジェクトってどんなものかなーと考えると、モデルを変えるプロジェクトなんじゃないかと思いました。
「改革」にイメージが近いですが、危機的状況を脱するために組織構造を変える、ビジネスモデルを変える、システムのアーキテクチャを変える、運用方針を変えるなどなど、未来が変わるようなものはやる気が出ます。
それは短期ではできないんじゃない?
モデルを変えるようなプロジェクトは、別の言い方をすれば先に出てきた「抜本的解決」です。
「それができれば苦労はしない、そんな余裕がないから短期プロジェクトでしのぐしかないんじゃないか」という声が聞こえてきそうです。
私もそう思います。
現実は厳しい。
そこで、私の最近の作戦は「長期的な目線を取り入れた短期プロジェクトにしちゃう」です。
危機的状況をしのぎながら、未来を変えられるプロジェクトを目指したい。
例えば「顧客の離脱を防ぐために顧客の要望を実現させたい」「顧客と約束しているから」という短期プロジェクトは、それだけでは正直テンションさがります。
どんどん要望を受け入れていけば、付け焼き刃的な機能が増えていき、プロダクトは複雑になっていきます。
顧客の離脱を防ぐことがミッションであれば、howは要望実現だけではありません。
「この機能が3ヶ月後までにないと正直使い物にならない」という言われ方をしているのであれば、3ヶ月で実装をめざすのではなくて、顧客にとって重要なイベントはなんなのかを整理するプロジェクトにすべきかも、とかを考えます。
3ヶ月間ときに泥臭く3ヶ月後のイベントに向けて支援しつつ、そのイベントがサービスにとって重要なものなのかどうかを判断するためのレポート作成を進める、などができないかを考えたいです。
これは運用における負債になる可能性も高くって、「去年は手伝ってくれたから当然今年も手伝ってくれるよね」ということが毎年発生するかもしれません。
だからこそ、適切にイベントの重要性を判断し、顧客の本当に求める機能を見極めるための判断材料をそろえておきたいです。
そして、毎年手伝うのか、費用対効果が悪すぎるのでやめるのか、機能として実装するのかをジャッジしたい、と私は思います。
ここでのポイントは、顧客から要望があったからすぐ実装する"しのぐための短期プロジェクト"から、ユースケースのモデリングのためのユーザ観察という"長期目線なプロジェクト"に転換するという点です。
長期的にメリットがあるかどうかを考える
短期プロジェクトがつらくなっちゃうのは、それが消耗戦になる可能性が高く、根幹となるサービスの成長に寄与するのかどうか怪しいからです。
長期的に考えて、やっておけばメリットがあると思えるようなプロジェクトに取り組めるようにいろいろ工夫することが大事なんじゃないかなーと思いました。
この記事が気に入ったらサポートをしてみませんか?