「エンジニアリング至上主義」時代の終えんに開発現場で今すぐできることとは：特集：Biz.REVO～開発現場よ、ビジネス視点を取り戻せ～（2）

リーンやアジャイルプロセスは「アプリケーション（ソフトウェア）」を作るためのもの。ビジネスにおけるIT活用が高度化・複雑化する現在、「システム」開発現場には、より大局的なIT観が求められている。

» 2014年09月26日 18時00分公開

　「よりビジネスに貢献できるITを」。もはや言い尽くされた感もあるテーマだが、ITがかつてないほど企業のビジネスに深く組み込まれている今日、ITにいかにビジネス視点を持ち込めるかが、そのままビジネスの成否に直結する時代になった。特に、市場環境の変化スピードが速くなる一方の昨今、ビジネスを裏で支える企業システムの整備には、かつてないほどのスピード感が求められるようになった。

　しかし、自社の基幹ビジネスを支えるに足る品質や機能、独自性を備えたシステムを構築するには、それなりの時間とコストが掛かる。その結果スピード感が損なわれてしまい、ビジネス側の要請とIT側の都合との間に大きな溝が生じてしまっているのが現状ではないだろうか。

　では、こうした時代にふさわしい、価値の高いシステムをビジネス環境の変化に即して迅速に開発する方法は、果たしてあり得るのだろうか？本稿では、この困難なテーマに挑み続けているグロースエクスパートナーズビジネスソリューション事業本部本部長執行役員鈴木雄介氏に、企業システムの開発現場がビジネス視点を取り戻すために必要なこととは何かを聞いた。

「エンジニアリング至上主義」時代の終えん

編集部　昨今、ビジネスにおけるITの重要度は増す一方であるにもかかわらず、企業システムの開発現場とビジネス部門との間の距離はますます広がっているように感じます。開発者はエンジニアリングの視点にとらわれるあまり、ビジネスの視点をどうしても失いがちなのかもしれません。

グロースエクスパートナーズビジネスソリューション事業本部本部長執行役員鈴木雄介氏「基幹システムを作っていたころのITはユーザー企業の情報システム部門に『コスト』として見られていました。いまは、営業戦略を担うサービスを作る『投資対象』としてのITが必要とされています。それには、基幹システムとの連携を全体的に考えつつ、ユーザー企業の事業部門にROI（投資利益率）を示す必要があります」

鈴木氏　過去の経緯を振り返ってみると、1990年代から急速にビジネスにおけるITの適用領域が広がった結果、アプリケーション（ソフトウェア）の開発者が一気に脚光を浴びました。こうした「アプリケーション中心主義」「エンジニアリング至上主義」の時代は2010年ごろまで続いたのですが、その後時代は急速に「全体最適化」の流れへと移り変わりつつあります。

　それまでは、個々のアプリケーションを開発するための要素技術が注目を集めていたのですが、ITの利用がだんだん成熟化・広域化し、ITが企業インフラ、あるいは社会インフラとして捉えられるようになるに従い、全体最適の観点に立って「どんなシステムを作り、その結果何を得るべきか」という、より大局的なIT観が一般的になってきたわけです。

編集部　なるほど。長らくエンジニアリング至上主義の時代が続いていたのが、いつの間にか社会の要請がそれを追い越していたということですね。そうした現状認識を踏まえた上で、今日のシステム開発の現場は、具体的にどのような課題を抱えているとお考えですか？

鈴木氏　複数の問題領域があると思います。開発作業そのものにおける課題はもちろんですが、計画の精度の問題や、そもそもの企画がまずいということもあります。これら個々の問題領域には、それぞれ対応した解決策が用意されています。

　例えば、企画の問題に対してはリーンが、計画に関してはアジャイルプロセス、そして実装作業についてもさまざまなメソッドが提唱されています。しかし、これらは全て「アプリケーションを作るための技術」です。企業システムを構築する場合には、これだけでは不十分です。

「アジャイル開発」と「リーン」の関係（記事『書籍でたどる「リーン」の本質』より引用）

編集部　なぜアプリケーションを開発するスキルだけでは、企業システムをうまく構築できないのでしょうか？

鈴木氏　企業システムは、一つのアプリケーションだけで完結しているわけではありません。多数のアプリケーションが絡み合い、連携しながら動いています。従って、これら全体を全社的な観点から適切に設計し、全体最適を図る必要があります。

　極端な話、全体最適の立場に立った場合には、個々のアプリケーションの個別最適を犠牲にすることもあり得るわけです。しかし、これまでエンジニアリング至上主義が長らく続いたため、個々のアプリケーションを開発するための技術は高度に発達したものの、企業システムを全体最適の観点から設計できるスキルやメソッドが不足しているのが現状だと思います。

　これは、いわば「古くて新しいテーマ」で、以前から「エンタープライズ・アーキテクチャ」というキーワードで議論されてきたり、あるいは最近では「エンタープライズ・アジャイル」のような新たな手法も提唱されてきたりしていますが、現時点ではまだ明確な成果を挙げるところまでは来ていないと思います。

ファシリテーターとしてのITアーキテクトの役割

編集部　こうした現状を打破して、全体最適の観点から企業システムを捉えられるようになるためには、具体的にどのような取り組みが求められるとお考えでしょうか？

鈴木氏　開発現場はどうしても、プロジェクトやアプリケーションの単位で仕事を進めますから、開発者個々人に「全体最適の観点から動け」といっても酷だと思います。なので、プロジェクトマネージャーや情報システム部門がリードして、アプリケーションごとに閉じてしまっている現在のシステム開発のカルチャーを変えていく努力をするべきだと思います。

編集部　よく「海外企業は経営トップがITの価値を深く理解しているので、全社的な観点から迅速にトップダウンでIT施策を実行に移せる」などと言われますが。

鈴木氏　それは確かにその通りだと思いますが、日本企業の場合はやはり現場が強いですし、業務現場にこそ優秀な人員が多くいるので、現場の各部門が一堂に会して、すり合わせを行いながら正解を導き出していくというプロセスが合っていると思います。

　そこでまずは、そうした調整や話し合いのプロセスやルール、あるいは部門横断型の調整組織を設ける必要があります。ここで重要な役割を演じるのが、ITアーキテクトです。ITアーキテクトは全体最適の観点から各部門の利害を調整しながら、システムの方向性を決めていく役割を担うのです。

編集部　ITアーキテクトは調整役なのですね。一方で、ITコンサルタントのように「あるべきシステムの姿」を主体的に提案していく役割もあり得るかと思います。

鈴木氏　コンサルタントの役割は、すでに世の中にある正解、より具体的に言えばIT導入・活用のベストプラクティスをティーチングすることにあります。かつての企業システム開発は、定型業務を個別にIT化することが主でしたから、それぞれの業務や業界のベストプラクティスに詳しいことは非常に価値が高かったのです。

　しかし、企業におけるIT活用が極めて高度化・複雑化し、各企業が独自の価値をシステムで実現しようとしている今日では、すでに世にあるベストプラクティスよりも、「まだ世の中に存在しない、自社にとってよりベターな解」を皆で見つけることの方が重要です。そしてそのために必要なのはティーチングではなく、ファシリテーターなのです。

編集部　そのファシリテーターとしての役割を果たすのが、ITアーキテクトなのですね。では、そうした役割を果たすためにITアーキテクトに求められるスキルとは一体どのようなものでしょうか？

鈴木氏　システムの実装経験があり、テクノロジを深く理解していることが必須だと思います。逆に、お客さまのビジネスを完全に理解している必要はありません。現代の企業システム開発はステークホルダー（利害関係者）が増えて複雑化しているので、ビジネス上の課題解決策は彼ら自身に考えてもらうしかありません。

　ITアーキテクトは、ステークホルダーからビジネス上の利害関係を引き出し、それをテクノロジ側の視点から整理して、調整すべきことを明確にします。単にアプリケーション上の機能だけではなく、インフラ面や運用面の話題になることもあるでしょう。そうすることで、ステークホルダー同士の調整を推進（ファシリテート）するのです。

　SIerでありがちな『それはビジネス側で調整して、結果を教えてくれ』という姿勢ではうまくいきません。その結果がテクノロジ面での致命的な問題を含んでいると再調整になってしまい無駄が多くなります。むしろ、ステークホルダーのビジネス上の問題意識に立ち入って、それをテクノロジ面から整理して調整する、ぐらいの動き方が必要です。

開発現場で今すぐできることとは？

編集部　開発者個人にとっては、ITアーキテクトを目指すことがビジネス視点を取り戻す道につながるということでしょうか？

鈴木氏　開発現場が本当にビジネス視点を取り戻すためには、開発者個人の取り組みはもちろん重要ですが、やはり先ほど述べたように、組織としての取り組みが本質だと思います。また、必ずしも開発者全員がITアーキテクトを目指すべきだと考えているわけでもありません。

　かつて、企業システムが今日ほど大規模でも複雑でもなかった時代には、全ての開発者がある程度ビジネス視点を持つ余裕もあったかもしれませんが、現代の企業システム開発は高度な分業体制なくして回りません。従って、ITアーキテクトを目指す人もいれば、他の役割を担う人もいてしかるべきだと思います。

　問題は、ITアーキテクトの役割を果たせる人が現状では圧倒的に少ないことと、そもそもITアーキテクトを必要とする場面がないということだと思います。

編集部　では、そんな中あえてITアーキテクトを目指したいと考えている方には、どんなアドバイスを贈りますか？

鈴木氏　ITアーキテクトになることは、それまでエンジニア同士で固まっていた世界から、ビジネスの人たちが主役の世界に出ていくことを意味します。そうなると、それまでエンジニア同士では当たり前のように通用していた言葉は、全く通用しなくなります。ITのことを話すのに、エンジニアの言葉ではなく、ビジネスの言葉で話さなくてはいけなくなるわけです。まずは、エンジニアの世界で培ったこだわりやプライドは、一度きれいさっぱり捨て去るべきでしょう。

編集部　それは、かなり勇気がいることですね。

鈴木氏　そうでしょうね。異なるカルチャーの人々とスムーズにコミュニケーションが取れるようになるには、まず自分を変えて相手の懐に飛び込んでいくことです。「相手を変える」というのは、とても難しいことですからね。ただ、たとえ相手を変えられなくても、コミュニケーションを通じて「相手の“視野”を変える」ことで、考え方をこちらに近づけることはできます。

編集部　「相手の“視野”を変える」とは、一体どういうことなのでしょうか？

「お客さま要求する機能はシステム全体の3分の1、非機能要件は3分の2を占めるのではないでしょうか」

鈴木氏　例えば、システムの機能のことにばかり目が向いている人に対して、「その機能は不要だ」「その機能を実現するにはコストが掛かる」と正面切って反論しても、話がこじれるだけです。そうではなく、例えば「なるほど。ではその機能を実現した場合、メンテナンス性はどうなりますかね？」「いい機能ですけど、セキュリティについても考えてみませんか？」といったように、機能とは別の観点、例えば非機能要件を提示してあげるのです。そうすると、相手もシステムを見る視野が広がって、自分がこだわってきた機能について客観的な判断を下せるようになります。

編集部　いろんな場面で応用できそうなコミュニケーションテクニックですね。

鈴木氏　お客さまは大抵、特定の機能にこだわりを持っていますが、それは往々にして一面的に過ぎません。そこで、システムの性能やメンテナンス性、セキュリティといった非機能要件の観点をさりげなく提示することで、多面的な観点を導入するのです。

　このような形で非機能要件の観点を持ち込むことは、ビジネスユーザーとのコミュニケーションを円滑に進める上で極めて有効なテクニックなので、一度試してみることをお勧めします。