このコラムは、株式会社エル・ティー・エスのLTSコラムとして2019年4月から連載を開始した記事を移設したものです。
当コラムの最新の内容は、書籍『Business Agility これからの企業に求められる「変化に適応する力」（プレジデント社、2021年1月19日）』でご紹介しております。
ライター
ビジネスとエンジニアリングの距離を縮める
さて「事業への理解とオーナーシップ」を持ちつつ自社のデジタル基盤を考え抜くことが大切だとして、問題はこれを誰が行うのかということです。当然IT部門は中核になるプレイヤーですが、デジタル基盤の在り様が事業の影響を強く受けるのであれば、これはIT部門だけではなく、ビジネス部門とIT部門、そして経営者の三者が密なコミュニケーションの下で構築すべきものです。しかし、残念ながらこのような形でデジタル基盤への方針が議論されていることはまだ多くはないようです。これは単に「IT部門のビジネス部門とのコミュニケーションが欠けている」といった話だけではありません。
エンジニアだけではデジタル活用は実現できない
先日、ある金融業のIT部門から残念な話を聞きました。IT部門としてはさまざまなビジネス部門からの要望に基づいてIT導入のプロジェクトを進めます。しかし、ビジネス部門の中には自部門の要求で進めるシステム化にも関わらず、要件定義にもユーザー受け入れテスト（UAT）に協力してくれない部門があるそうです。要望（注意：要求と呼ぶには程遠い曖昧なものです）をIT部門に伝えたのであとはIT部門が責任をもって実現してくれればよい、これがその部門の認識とのことでした。またプロジェクトの遅延やトラブルを全てIT部門の責任にされてしまうことも悩みだそうです。あくまでもIT部門の主張なのでビジネス部門にも汲むべき事情はあるのかもしれません。ただこのようなデジタル導入におけるビジネス部門のオーナーシップ不足は私の経験の範囲でも頻繁に目にする光景です。総じてみれば、デジタル基盤の在り方を議論するはるか手前のところで、ビジネス部門側に自分たちもデジタル活用の一翼を担う存在であるという自覚が欠けていることが大半です。これではIT部門がビジネス部門とコミュニケーションの場を持ったところでうまく話が噛み合いません。
デジタル活用では技術そのものへの理解以上に、自社の事業や業務といったビジネスへの理解が大切になることは既にお話した通りです。長い間、デジタル導入プロジェクトの失敗要因の上位はデジタルソリューションの技術的な問題以上に、「ビジネスの方針が不明確」「ビジネス側からの情報が不足」「要求や仕様が不完全」「要求や仕様が変化」といったビジネス側の要求に起因すると指摘され続けています。しかも近年、プロジェクトマネジメントやエンジニアリングの手法が進化する中で、このような要求（要件）に起因する失敗は、比率としてはむしろ目立つ傾向にあります。
結局のところデジタル活用の鍵はビジネスそのものの理解と未来像にありIT部門だけが頑張ったところで限界があります。しかし、ビジネス部門の担当者が、デジタル技術の導入においては自らの役割が鍵だと認識できている会社がどれだけあるでしょうか。ほとんどの企業では未だ「デジタル活用はIT部門の仕事」という認識から抜けられていないのが実情です。2013年にJUAS（日本情報システム・ユーザー協会）が行った調査ではソフトウェア開発の上流工程にビジネス部門が積極的に参加すると答えた企業はわずか1割ちょっとです※1。ビジネス側（ビジネス部門）がこの工程に主体的に参加するほど、開発の成功率が高くなることは調査でも裏付けられているのですが、にも関わらずビジネス部門の姿勢はなかなか変わっているように見えません。
2013年にJUASが行った調査（企業IT動向調査2014）では要件定義に主体的に参加するビジネス部門の割合は12.5%である一方で、主体性のないビジネス部門は63.2%であり、圧倒的にビジネス部門の主体性が低いことが分かります。しかしビジネス部門に主体性のない会社でのシステム開発（100～500人月）の工期遅延割合は40%を超える一方で、ビジネス部門に主体性のある会社での割合は15%程ですから、ビジネス部門の参画割合がプロジェクトの成功に相関があることも分かります。
このようなビジネス部門の後ろ向きの姿勢にはさまざまな理由が考えられますが、幾つかは意外とシンプルなものに見えます。大半のビジネス部門には（そして経営にも）、そもそもデジタル導入においてビジネス部門が鍵となる存在であるという基本的な認識がありません。そのための意識付けや教育訓練の場はないのです。多くの会社のIT関連の教育はIT部門や周辺の関係者の範囲にとどまり、基礎スキルとして広く社員のITリテラシを向上させる活動まで踏み出せている会社は多くはありません。知る機会がなければ「デジタル技術のことはIT部門に任せる」という思考になってしまうのは仕方がないことのように思えます。
企業はビジネス部門のデジタルリテラシの底上げを
多くの日本企業はかつて、ビジネスプロセスのIT化をその企画から開発、そして運用までITベンダーに任せる体制をとってきたといった経緯があります。そのため、IT部門はビジネス部門以前に、まず自らの開発能力やプロジェクトマネジメント能力を高めることで精いっぱいというのが実情かもしれません。しかし、これからのIT部門は自部門のことだけを考えていては限界があります。このコラムの前半でも紹介したJUASの研究会活動で行った自動車会社へのインタビューの場では、ある会社のCIOの方が「デジタルがありとあらゆる業務に浸透した今、社内の情報基盤の全てをIT部門で構築するなどナンセンス」と前置きをした上で、次のようなことを仰っていました。
「これからのIT部門は（ネットワークや情報セキュリティなどの）デジタルインフラや基幹系などの大規模な取り組みの主管は担うが、各事業や業務の中小規模のデジタル化についてはむしろビジネス部門が主体的に推進できるように全社員のデジタルリテラシを底上げしたり、活動が頓挫しないように支援したりする役割にシフトしていくべきだ」
デジタルが急速に浸透する現在の企業環境の中では、このような考え方には大変説得力があります。
このような問題意識の中、私は先日、ある保険会社でユーザー部門の担当者がシステム要件定義の基本を学ぶ研修の講師を行いました。研修の目的はもちろんシステム開発の流れやシステム要件定義の手法を学ぶことですが、現実には数日の研修ですぐにユーザーが独力で要件定義をできるようになれるわけではありません。しかしこのような研修を受けてもらうことで、システム開発においてユーザーは決して“お客様”ではなく、自らもチームの一員であり、かつプロジェクト成功のための重要な役割であることを認識してもらうことはできます。実際のプロジェクトではIT部門や外部の専門家（コンサルタントやベンダー）が支援をしながら企画や要件定義の作業を進めていきますが、ビジネス部門のメンバーに一定の基礎知識とチームの一員としての覚悟を持ってもらった上で参画してもらうだけで、プロジェクトははるかに進めやすくなるのです。このような場で経験を積んだビジネス部門のメンバーは、各部門におけるIT推進担当として全社のITリテラシ底上げの一翼を担ってもらうこともできます。このようにビジネス部門の協力姿勢に悩みを抱えるIT部門は、まず「知ってもらう」という取り組みからはじめてはいかがでしょうか。
大切なのは広い知識を持った“T型人材”の育成
このようなデジタルの基礎知識を従業員全体に浸透させていくことで、最終的に育成したい人材像が“T型人材”です。アジャイル開発のコミュニティではよく聞かれる言葉で、考え方としてはさほど新しい概念ではありません。T型人材とは自らの核となる深い専門性と、他の専門性を持った人材と連携するための“広く浅い”さまざまな知識を併せ持った人材のことです。
ビジネス部門のメンバーの場合、Tの“縦棒”にあたる深い専門性は自らの担当業務と、これを他者に説明するためのビジネスアナリシスとなります※2。その一方で、Tの“横棒”にあたる広く浅い専門性としては、担当外の業務やガバナンス（内部統制や環境管理、輸出管理等）に関する知識、活用するソリューションの基礎知識や導入プロジェクトの進め方といったものが挙げられます。これがエンジニアの場合は、担当するソリューションに関する深い知識と技術力が“縦棒”にあたる深い専門性になり、“横棒”はビジネス部門のメンバーが担当しているさまざまな業務やガバナンスに関する知識となるでしょう。プロジェクトマネージャーを担うエンジニア（ないしビジネス部門の担当者）であれば、“縦棒”にはプロジェクトマネジメントスキルも必要となります。この他にも参画するメンバーの役割によってさまざまな“縦棒”と“横棒”の関係が存在します。
現実にはビジネスアナリシスはそれ自体がかなり高い専門性を必要とするため、日本でもこの専門性を“縦棒”に身に着けたビジネスアナリストの登場を期待したいところです。ビジネスアナリシスとビジネスアナリストについては第4~6回のコラムを参照してください。
なおアジャイル開発のコミュニティでは、このT型人材と同様に“クロスファンクショナルチーム”という考え方も提唱されています。クロスファンクショナルチームとは同じ目標の下にさまざまな専門性を持ったプロフェッショナルが集まったチームのことで、 “クロスファンクション”が成り立つ前提となるのが、参画しているメンバーが高い専門性を持ちつつも、他者の持つ専門性への一定の知識と敬意を合わせて持ったT型人材で構成されていることとなります。現在のデジタル導入では、一言でビジネス部門と言ってもさまざまな部門から異なる専門人材が集まります。また、テクノロジー側もソリューションを開発するエンジニアだけでなく、情報セキュリティの専門家や、UI（ユーザーインターフェース）の専門家など、さまざまな専門家で構成されます。それぞれの専門家が、自分の立場だけで好きなことを言っていてもプロジェクトは前に進みません。他のメンバーの専門性を理解し、全体のバランスを考慮しながら、取り組みの目標達成に向けて自分の専門性の立場から貢献していく必要があります。
手法論としてのアジャイル開発の導入はさほど本質ではない
“アジリティ”と聞くとアジャイル開発手法をどう捉えるとかということが気になる方もいらっしゃるかもしれません。確かに「スクラム」や「SAFe」といったアジャイル開発の手法を理解することは大切ですが、アジャイル開発が実効性を持つには、それ以前に「T型人材に支えられたクロスファンクショナルチーム」が機能している必要があります。アジャイル開発手法を形だけ導入しても、お互いの専門性への理解と敬意といった相互理解の基盤がなければコミュニケーションは円滑に進みません。むしろ必要なコミュニケーションを欠いた結果として、仕様の漏れや手戻りが多発してしまうでしょう。
そもそもウォーターフォール開発が“鈍足”になってしまう大きな理由は、プロジェクト関係者の相互理解が足りない中でも安全にプロジェクトを進めるためには、お互いが意図を理解し合うために文書の力を借りざるを得ず（必然的に文書化のための膨大な工数をかけざるを得ず）、また相互の誤解や認識漏れを防ぐためのさまざまなチェックやレビューの手続きが必要となってしまうためです。ユーザーとエンジニアの距離が近く、相互理解が進んでいれば開発手法としてウォーターフォール開発の考え方をとっていても、その運営はアジャイル開発で謳われる運営に近づいていきます。このような下地があれば手法としてのアジャイル開発の導入はそう難しいものではありません。もちろん手法としてのアジャイル開発を導入することで、T型人材やクロスファンクショナルチームを形成する呼び水にしたいとする考え方もあると思いますが、どちらにしても手法そのものの是非はあまり議論の本質ではないのです。
結局のところ、鍵は人材の育成とコミュニケーションの在り方にあります。そのような相互理解の基盤の上で、はじめて「IT部門とビジネス部門の定期的なコミュニケーション」といった施策も意味を持ちます。もし、その企業でデジタル活用がIT部門のみの問題となっている場合、それはデジタル技術が浸透した現在の企業経営を、経営者が理解できていないということです。デジタル技術を全ての社員が「自分事」として捉えられるような経営を目指していかなくてはなりません。
まとめ
第4~6回のコラムで「人の役割が実行から変革にシフトする中で、そのような環境変化に人材育成が追い付いていない」という話をしました。これはデジタルリテラシについても同じことが強く言えます。今、義務教育からプログラミングを必修にする動きもあります。学校教育でプログラミングを扱うことの是非はともかくとしても、基本的なデジタル技術の動作原理と導入プロジェクトの進め方を知ることは、社会人であれば必須スキルになりつつあります。一般的に企業の人材育成は業務遂行上の中核のスキル、つまりT型人材における “縦棒”の部分を如何に伸ばすということに注目されます。しかし専門性が細分化し、相互連携が取り組み成功の鍵となる今日では、“縦棒”以上に他者の専門性を学び、自らの専門性と橋をかける“横棒”の価値を軽視するわけにいきません。今後の経営では、このような“横棒”を伸ばすための育成の在り方を考えていかなければなりません。デジタルリテラシは全社員に求められる“横棒”のスキルの最たるものです。
とはいえ、現実には一人の人間が“横棒”を無限に学び続け、その知識を拡張し続けることは限界があります。“横棒”の中にも誰にでも必須な知識と、個人の志向や関心に応じて選択的に得る知識が混在します。後者の部分については、さまざまな人がそれぞれの関心に応じてさまざまな知識を得ることで、足りない知識をチームで補い合うことができます。ですから一言で教育と言っても、企業が研修としてしっかり教えるべきスキルもあれば、むしろ個々人が自主学習することで取得するスキルもあります。企業は単純に研修体系を整えるといったことだけでなく、個人がその関心事を満たすためのさまざまな支援、例えば活動費用の支援や自主学習時間の業務認定といった施策が求められます。このような学習支援としてはGoogleの20％ルールなどは特に有名ですが、近年ではパナソニックの例※3など、日本の大手企業も取り入れる動きがあります。もはや学習活動は「普段の業務が滞りなく進む限りにおいて、余った時間でなら勉強しても良い」という発想ではなく、普段の業務の一部として認めていく姿勢が必要となります。
パナソニックのR&D部門では「NiceTry!活動」として業務時間の10％を自由な研究活動として使って良いという制度を導入しています。（https://news.panasonic.com/jp/stories/2015/44373.html）
さて、ビジネスアジリティコラムの第7、8回は“ソリューション”をテーマに解説しました。ここまでをまとめると、次のようになります。
次回の第9回はビジネスアジリティにおける“組織”について解説したいと思います。次回も是非読んでください。
