一つ前の記事で、開発者が開発するべきものは正しい 「変化」 と書きました。
私達が開発者として向き合うものは、事前に決められていない 「変化」 です。私達は進化に導く正しい 「変化」 の形を探し、仮定するところから始めて、仮定したらそれを素早く実現し、検証しなければなりません。開発するべきものは正しい 「変化」 です。
言うは易く行うは難しで、世の中にはこれが行い難いプロジェクトがたくさんあります。この記事では、そうしたダメなプロジェクトと、さらにダメな （ダメダメな） プロジェクトの陥りがちなパターンについて考えてみます。
背景が言語化、共有されない
何らか機能を追加、あるいは削除するなど、プロダクトを変更するには、必ずその背景があるはずです。背景とは、現状や現状の課題感 （問題点）、変更により達成したい目的などです。
企画、プロダクトオーナー、プロダクトマネージャーなど、呼称は様々ですが、プロダクトの変更に責任を負うべき人は、まずこの背景を言語化し、開発者に共有する必要があります。また、背景の共有が不足していると感じられた場合には、開発者からもこれを要求すべきです。
背景の分からない状態でその手段となる機能を開発している、文章にしてみるとそれがいかに滑稽な状態か浮き彫りになりますが、このような状態では開発に最適化や提案の余地はなく、自分達の携わっていることに納得感も得られません。
当たり前のことではありますが、この当たり前のことが当たり前にできないプロジェクトは非常に多いです。このパターンに陥る根底には、プロジェクトにおける開発を工業製品をライン生産方式で処理するかのごとく扱う、大きな誤解があるのではと見受けられます。
プロジェクトで開発するものは大量生産品ではなく一点物です。この場合、必要となる人材は与えられた工程をただ単にこなす作業員ではなく、自ら考えて主体的に動ける人です。プロジェクトのメンバーを誰一人として単なる作業員にしないためにも、背景の言語化、共有は強く意識すべきことの一つになります。
成果が測定、検証されない
背景に基づいて実際にプロダクトを変更した後には、その成果を測定し、課題感を解決したのかどうか、目的を達成したのかどうか、検証する必要があります。
経験上、プロダクトの初期開発のフェーズでは、最低限の機能を揃えることに追われるため、この点が疎かになりがちです。ただし、どのようなプロジェクトでも、中長期的にはプロダクトに関わる様々な数字を測定し、重要な数字についてはプロジェクトのメンバー全員で日常的に追いかけていくべきです。
成果を測定し検証することで、プロジェクトのメンバーは自分達の加えた変更がどのような成果をもたらしたのかを把握し、それを元にユーザーの思考や行動を想定し、次の打ち手を考えることができます。逆に、成果が測定、検証されないということは、つまるところユーザーのことを見ていないということです。
このパターンに陥るプロジェクトも非常に多いです。ただし、背景の言語化や共有を強く意識するほど、背景に厚みを持たせるためには数字が必要となるため、「背景が言語化、共有されない」 というパターンを脱却する過程で、同時に改善することがあるパターンとも言えます。
素早く開発できない
良いプロジェクトは、プロダクトの変更に際し、背景の言語化、共有から、実際に開発し、効果を測定、検証するまでの期間が比較的コンパクトです。同じ期間で他のプロダクトよりも多くの仮説検証を行えることは競争力の源泉となるため、素早く開発することが重要であることには疑いの余地はないでしょう。
バージョン管理がない、コードレビューがない、自動テストがない、ドキュメントがない、CI がない、テストエンジニアがいない、DevOps ナニソレ、などなど、素早く開発できないプロジェクトでは、素早く開発するためのプラクティスの導入に積極的でないパターンが多いです。
また、基本的にプロダクトの規模が大きくなるとコードの複雑性は増していくもので、その分リファクタリングやコンポーネント化の重要性も増していきますが、そのためのスケジュールが確保できず （されず）、いわゆるスパゲティな状態となり手に負えなくなっていくパターンもあります。
両方のパターンに共通して見受けられることは、プロダクトの変更に直接的に結びつかない作業への無理解です。プロダクトは一度変更すれば終わりではなく、変更し続けていくことが重要なはずです。にも関わらず、その場その場で変更することを優先し、変更しやすくすることを軽視する、この木を見て森を見ず的な判断の積み重ねが、いずれ取り返しのつかない規模の技術的負債として重くのしかかってくる場合があります。
こうしたパターンに陥ることを避けるためには、まず、素早く開発するためには素早く開発するための土台が必要であり、その土台を維持するためには相応の労力がかかる、ということを、プロジェクトのメンバー全員が理解し、また実際にそれを維持することを是とする合意 （文化） が必要になります。
なお、技術的負債を一定レベルに抑えつつ、適度なバランスで開発を進めることは、経験がないとなかなか難しいことです。技術的負債をゼロにすることが重要なのではなく、素早く開発し続けることが重要なので、開発者は常にそのバランスを意識して開発に向き合うのが良いと思います。
ここまでが、ダメなプロジェクトの陥りがちなパターンです。ここで列挙したパターンに陥っているという認識がプロジェクトのメンバー全員で既に共有できている場合、少しづつ改善していけば良いでしょう。偉そうに書いていますが、私の携わるプロジェクトでもダメな部分は当然ありますし、それを少しづつでも改善していくことが私の仕事の一つでもあります。
しかし一番問題となるのは、問題を問題と認識できる人が周りにいないというパターンです。この記事を読んでいるあなただけが問題を認識している場合、まずは声を上げましょう。社内の力関係などにより一人ではどうしても声が響かない場合、私を含め、開発コンサルティングを行っている方々に助力を求めるのも一つの手です。
プロジェクトを少しづつでも改善していくためなのに、声を上げても、手を尽くしても一向に響かない、そうしたプロジェクトはダメダメです。メンバーの声に耳を傾けず、良い方向に変えていく努力ができないプロジェクトに未来はなく、そうした環境に身を置き続けることは不幸です。早めに身を引く準備を進めることをオススメします。
“ダメなプロジェクトとダメダメなプロジェクトの傾向と対策” への1件のフィードバック