R&D の構造的な難しさ

23 June, 2025

R&D の構造的な難しさ

SI のノウハウは世にあふれているけれども、Web や IoT を扱う研究開発プロジェクトの独特さはあまり聞かない。ここ数年の経験をまとめておく。

仕様があいまい

ウォーターフォールではマーケットから要求を吸い上げ、仕様を決めて機能を作り、それに合わせて UI やデザインを実装してきた。

R&D プロジェクトには定まった仕様があまりない。課題解決できれば、手段は問題にならないという考え方になっているからだ。目的の達成を重視するので、細かい挙動は実装依存でよいという割り切りになっている。

SaaS 以降との親和性

この進め方は SaaS に似ている。業務に合わせてシステムを作るのではなく、技術に合わせてシステムを作り、業務をシステムに合わせる、という進め方だ。これは、スマートフォンが牽引してきた仕組みで、テクノロジーで実現できることによって機能が決まっている。最近では、この仕組みをウェアラブルデバイスが後押ししている。

期待の拡大と制限

未知の領域で広く大きな可能性を見つけることが目的だから、R&D は成果の規模も大きい方がいい。スコープも大きい方がいいから、R&D が扱うプロダクトにも多様な機能が求められがちになり、システムは複雑になっていく。

一方で R&D プロジェクトは短期的な利益を生まないので、複雑さが増すとプロジェクトメンバーへの負担が増えていく。開発リソースがコストを圧迫し、使える時間も有限なので、最終的には R&D のゴールが開発リソースの上限によって決まることになる。

結末

プロジェクトがゴールに至るまでに課題解決の度合いを少しでも高めようとするので、ぎりぎりまで開発を続けることになる。受託開発のように、先を見越して計画的に所定のタスクを消化して、終盤の大変さを和らげようとすることはできない。全力で走り続けて、たどりついたところがゴールとなる。

心構え

SI でずっとやってきたような、厳密に分担し責任範囲を明確にするような動きがしにくい。自社や自分を守っても、プロジェクトの進行に貢献しないからだ。スピードを落とさずに、まず試してみて結果を確認し、またトライを繰り返すという態度で臨みたい。

また、トライに対する失敗について責めるようなことはしたくない。できないことはもともと不可能だったし、想定より時間がかかったのは本当にそれだけの時間が必要だったからで、予見できなかっただけにすぎない。それを責めるような座組にしないことが重要だと思う。