NCDCの十川です。こんにちは。
DX（デジタル・トランスフォーメーション）にはシステム開発が欠かせません。しかし、DXのためのシステム開発は従来のシステム開発とは性格が異なるので、従来のやり方をそのまま適用することはできません。
（ここではDXの定義を簡単に「既存のビジネスモデルにとらわれず、新しいデジタル技術を活用することによって、新たな価値を生み出していくこと」とします）
今回はDXにおけるシステム開発の進め方と、誰がそのキーマンとなるのかについて書いてみたいと思います。
目次
DXのシステム開発は正解が見えないまま進む
なぜDXのためのシステムには従来のシステム開発のやり方が適さないのか？
それは「新たな価値を生み出していく」取り組みであるDXは、基本的に「これまで自社でやったことのないような取り組み」になるからです。
従来のシステム開発の多くは、最初に細かく要件定義をして、ベンダーに指示を出し、最後にベンダーからの納品物が最初に決めた仕様を満たしているかを確認するというウォーターフォール型の開発で行われています。それは、はじめから「こういうシステムがあれば良い」という正解がわかっている前提でのものづくりだと言えます。
しかし、システムを新しくするだけでなく、ビジネス面においても“既存のビジネスモデルにとらわれず、新たな価値を生み出していく”という変革が起きるDXでは、あらかじめ「こういうシステムをつくればいい」という正解がわからない状態でシステム開発にも取り組んでいく必要があります。
そのため、試行錯誤や、途中での方向転換ができるような開発の進め方が重要になります。
そうした背景もあって、近年、リーン・スタートアップや、アジャイル開発といった手法が注目されています。
従来のシステム開発の中心はPM
次に、DXのためのシステム開発のキーマンについてです。
従来のシステム開発ではプロジェクトマネージャー（PM）がとても重要な役割を担っていました。
PMはQCD、つまり品質（Quality）、コスト（Cost）、納期（Delivery）が計画通りに進むように計画を立て、プロジェクトが予定通り進んでいるのかレビューや、状況に応じた調整を行います。
ウォーターフォール型の開発では、要件定義が完了した時点でその後の開発からテストフェーズまでの見積もりを行いますので、もともと想定している予算の枠に収まるように要件を絞り、要件定義後は予算や納期に影響がでないように、新しい要件や変更要求を管理していくことになります。
しかし、DXのシステム開発は前に述べた通り、“最初から正解がわかっているわけではない”という問題があります。そのため、最初にすべての要件を細かく定義してしまうことは、むしろ無駄を生む危険があります。
また、追加開発で予算の枠を超えないように、できるだけ新しい要件や変更要求は抑えるという管理の方針は、「試行錯誤や、やりながら方向転換できる進め方」という考えと矛盾してしまいます。
このように考えると、従来のシステム開発に慣れたPMを中心としたプロジェクトの進め方はDXには適さないといえます。
DXにおけるシステム開発のキーマンとは？
では、誰を中心に、どのような進め方をするのが良いのでしょうか？
従来のシステム開発のやり方は、要件定義時には事業部門からも人員が参加しエンジニアと協力して要件定義を行いますが、開発フェーズに入ると事業部門の人員はあまり関わらなくなります。
しばらく経ってから受け入れ試験に参加するまで、事業部門の人員は問い合わせ対応くらいにしか登場しないケースが多いのではないでしょうか。
一方で、DXのためのシステム開発では、要件定義・開発・試験のサイクルがもっと短い間隔で行われます。
要件定義と開発も並行して進むようなものだと考えていただくのがいいと思います。
そうすると、最初の要件定義が済んだらしばらくはPMとベンダーに任せっきりになるという、従来のシステム開発の進め方にはなりません。
具体的にいうと、まず「このようなサービスで本当に顧客やビジネスパートナーにお金を払ってもらえるのか」、「このツールを使うことで本当に社員の業務効率は改善するのか」など、ある程度範囲を絞って検証したいことを決めて、短い期間でそれに必要な機能だけを開発します（たとえば３ヶ月程度でひとつのテーマの開発・検証を終える）。
その結果を受けて（ある程度の成果が見えてプロジェクトを先に進めることになったら）、次に必要な機能の開発や、前フェーズで作った機能の修正を行います。 こうした３ヶ月程度のサイクルを何度も繰り返すことで、徐々にシステムを作り上げていきます。
このような進め方を実現するには、まず何から検証すべきかを計画し、必要なタイミングで必要な機能の優先順位付けを行い、実際にそれを開発するとしたらどのくらい大変なのか、どのくらいの費用がかかるのかを見積もりながら、随時「やるか、やらないか」を判断していく必要があります。
コストについても、どんどん変更要求がでてきますので、その都度判断し、場合によってはプランを変更する必要が出てきます。
そのためには「まず社内で要件を整理して資料をつくり、ベンダーに見積もり依頼をして、２週間後に見積もり結果がもらえる」というスピード感では遅すぎます。
「やるか、やらないか」の判断を行う者が随時、直接エンジニアと会話しながら、作業のボリューム感を把握する必要があります。
こうした進め方で中心的な役割を担う人物は、該当するサービスについてビジネス面のことがわかっている必要がありますし、テクノロジーについてもある程度の知識が必要になります。
つまり「システム開発に特化した管理者」ではなく、「ビジネスとITがわかる舵取り役」の方が、プロジェクトの中心を担うのに適していると言えます。
役職で表すと「プロダクトオーナー」と言われるポジションが、このようなシステム開発でとても重要な役割を果たすのです。
（プロダクトオーナーの要件は次項に書きます）
プロダクトオーナーのポジションを誰に任せるべきなのか？
では、そのプロダクトオーナーは誰が務めるべきなのか？
プロダクトオーナーは下記の要件を満たす自社の社員がベストです。
- この取り組みのために時間がしっかり取れる。
前述した進め方で、随時判断をする立場になると、結構時間をとられます。 - ビジネス面から正しく優先度の判断ができる。
サービス、プロダクトやその顧客のことを深く理解していることが必須です。例えばそのサービスの企画をしている人などが主な候補となります。 - 技術について、ある程度の判断ができる。
自分でプログラミングなどができるスキルはなくてもかまいませんが、エンジニアと協力して何が大変で、どういうやり方なら簡単にできるのかを判断できる必要があります（たとえ今はできなくても、エンジニアを下請けではなくパートナーとして協業できるようになっていく必要がある）。
こうして条件を挙げると、「そんな人居ないよ！」と思うかも知れませんが、DXの取り組みそのものが前例のない作業の連続になる可能性が高いため、DXの取り組みとともにプロダクトオーナーを育てていくという考え方ができるのではないでしょうか？
DXに取り組みながら、プロダクトオーナーも育てる
現時点では適任者がいないという場合は、たとえば以下のようなパターンでプロダクトオーナーとなる社員を育てながらDXに取り組んでみてはいかがでしょうか。
企画部門・事業部門出身者
企画部門や事業部で企画を担当している社員を担当している社員に、企画だけではなくその後の開発プロセスにも参画させる。上司は彼、彼女にそのための時間を与える必要がある。
システム部門出身者
システム部門や、情報子会社でビジネスマインドを持っている社員に機能の優先順位付けや方向転換をクイックに行うための権限を与える。彼、彼女がシステム以外の面でも判断や指示出しをしやすいよう協力も行う必要がある。
以上、DXにおいてはプロダクトオーナーがキーマンだということ、そのための人員をどのように確保すべきかがおわかりいただけましたでしょうか？
NCDCではDXを推進するためのプロジェクト支援や、コンサルティングを行っています。サービス企画の段階からシステム開発まで、プロダクトオーナーに寄り添ってDXの取り組みが上手くいくようにご支援いたします。
デジタル分野の知見や人的リソースが足りないという場合は、コンサルティングをしながら将来的に社内の人員だけでプロジェクトを仕切れるように人材育成にもご協力することが可能です。
DXについてお悩みのある方は、お気軽にご相談ください。
