開発現場のなやみってなんだろう
今回は、開発としての側面からディジタル化の意義について考えてみます。第2話では、経営としての側面でディジタル化の意義を考えてみました。その中で、組織の上位に行くほど、いいことしか伝わりにくいというお話をしました。原因の一つは『成果主義』の捉え方かもしれませんが、この手の議論はどちらかというとネガティブになりがちなので、開発プロセスにおける課題や見え方に泣き言を言うのでは無く、どうしたらバラ色の世界になるのか思考することにします。
さて、私の経験を振り返りながら設計者の悩みを考えてみます。開発は商品の仕様を決めることから始まります。新たな商品仕様はどのような市場ニーズから来たのか、それとも我々が持つ特別な技術、いわゆるシーズから商品として仕立て上げるのか。いずれにしても、同業他社と比較し『売れる』商品企画にしなければなりません。この商品企画を設計仕様に落とし込み、具体的な商品開発に入るわけですが、ここで様々な関門が待ち受けています。これら関門を突破し、手持ちのリソースと許されるスケジュール、費用で開発を進めていくことになります。開発現場の悩みは、一つではなく、これらプロセス全体でもあるし、プロセスの中に仕掛けられた個々の関門でもあります。
ディジタル化でなやみが解決するか
設計上の個々の課題は解決しなければならない開発そのものです。一方、部材調達から生産・販売、あるいは市場でのサービス、不幸にも故障したときの安全性に至るまで設計配慮、情報展開も開発部門に課せられることが多く、設計者の負担になっていることも多いと思います。
また、一つ一つのことが設計者あるいは設計チームの資質により出来映えが左右されてしまうのを補完するために部門全体や部門を超えた知見で完成度を上げるレビューが行われることも多いと思いますが、レビューの深さも人に左右されることも事実でしょう。ここまででも改革できそうな視点が多々見えてきます。
しかし、前述は開発プロセスとしてすでに組み込まれており、『できて当然』の事でしょう。第2話でお話しした、経営側の課題はできて当然のことは折り込み済みで、さらに＊＊＊という要求事項になるかと思います。例えば、少ないリソースで最大の効果を上げることを求められるなら、『＊＊＊』をどうすればいいのか。
- 従来と同じリソースで開発リードタイムを短くする
- 従来より少ないリソースで開発を可能にする
この二つは異なることを言っているようですが、実現手段は同じかもしれません。
重要なのは、経営側の要求をピンポイントで捉えるのでは無く、商品を開発・生産するプロセス全体を鳥瞰し、市場ニーズに沿った商品を高いで完成度市場に供給するまでの期間をどうやって短縮するか、という視点を持って、どこがボトルネックなのかを正しく把握することだと思います。
図1 アナログ思考をディジタル化する
開発の効率化、言い換えると『開発労働生産性の向上』と言えると思います。
個人の力量（技術力や時間の使い方などアナログな思考・行動）でなんとかしていた一つ一つを効率化あるいは、業務そのものを無くすためのボトルネックを正しく捉える。手段としてディジタル技術に投資、活用するとともに、プロセスを改革することが必要だと思います。そのためには、開発現場の課題を課題として単に報告するのだけでは無く、ポジティブな経営改革ビジョンとして発信することが肝要では無いかと思います。
図2 プロセス変化の視点
設計者が、経営感覚を持ち、経営者として自己を改革するビジョンと手段を打ち出すのです。
現状に満足するのでは無く、自己を磨き変化を恐れず革新し続けることが時勢を味方に付けることができるはずです。
次回は、ディジタル技術の一つとしてのシミュレーションについて考えてみたいと思います。
最後までお読みいただきありがとうございました。