ワナその2「方法論に過度に依存する」
新しいビジネスモデルを作り、それを実現するためのプロダクト開発を迅速に進めるにあたって、成功モデルを一般化した「フレームワーク」を採用するケースが増えています。「フレームワーク」は直訳すると「枠組」ですが、ビジネスプロジェクトの文脈であれば「方法論」とも言い換えられます。
ビジネスモデル構築の方法論であれば「ビジネスモデルキャンバス」や「リーンキャンバス」、アジャイル開発の方法論であれば「XP」「スクラム」などがよく知られており、コンサルティングやコーチングなどを通じ、対価を支払ってそのノウハウを社内に取り入れていこうとする企業も増えています。
もちろん、こうした方法論は、うまく活用できればいずれも有用なものですが、「まず、方法論ありき」でスタートするプロダクト作りには問題があると小野さんは指摘します。
「今、注目されているさまざまな『方法論』が登場する以前にも、優秀なプロダクトは数多く作られてきました。プロダクトを作っていく際に方法論を使うのは悪いことではありませんが、優秀なプロダクトを生みだすための必要条件として、方法論があるわけではない点に注意が必要です」(小野さん)
過度な方法論依存の弊害として、方法論に忠実であることを重視し、方法論に忠実であれば良いものが確実に作れると錯覚し、方法論そのものに傾倒していってしまうことが挙げられます。本来の目標は良いプロダクトを世の中に届けることであり、方法論のマニアになることではありません。
もう一つの弊害は、「ワナその1」とも関連するのですが「誰のどんな喜びに寄与するプロダクトか」を考えるプロセスを、おざなりにしがちになってしまうことだと言います。
「方法論にのっとって作業を進めることは、ユーザーの課題やプロダクトのあり方を突き詰めて考えることに比べれば、実は簡単です。競合分析でクロス表を作るというのも、昔からある方法論の一つですが、これはすぐに取りかかれる上に、分かりやすく結果が出るので、何となく『やった気になる』のです。でも、それで世に出るプロダクトは、たぶん、それほど魅力のない『普通』のものがほとんどだと思います。方法論の利点は、決まったやり方に従って進めれば、自分たちで考えるコストを減らせる点にあります。でも、ラクだからといって、それに依存しすぎると、新しい価値は生みだせません」(小野さん)
方法論をうまく活用するためには「どうしても必要な時にだけ使う」ことを意識すべきだと小野さんは言います。
「方法論が大きな効果を発揮するのは『やるべきこと、やり方が分からない』場合の指針として利用する場合です。逆に言えば『やるべきことが分かっている』ときにむやみに使うものではありません。もし、十分に考えて『誰のどんな喜びに寄与するプロダクトを作るのか』がすでに見えているのならば、あえて方法論を使う必要さえないケースも多いのではないでしょうか」(小野さん)
この記事は参考になりましたか?
- DXを目指す企業がプロダクト開発で陥りがちな「6つのワナ」連載記事一覧
- この記事の著者
-
柴田 克己(シバタ カツミ)
フリーのライター・編集者。1995年に「PC WEEK日本版」の編集記者としてIT業界入り。以後、インターネット情報誌、ゲーム誌、ビジネス誌、ZDNet Japan、CNET Japanといったウェブメディアなどの製作に携わり、現在に至る。現在、プログラミングは趣味レベルでたしなむ。最近書いているの...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
斉木 崇(編集部)(サイキ タカシ)
株式会社翔泳社 ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine(コードジン)」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine(エドテックジン)」...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
