新しいツールに飛び付きがちな技術者よ、ビジネスマンとしての基本を軽んずべからず:特集:Biz.REVO〜開発現場よ、ビジネス視点を取り戻せ〜(4)
ビジネス視点に立った開発を行うには、一体どうすればいいのか? ビジネスにより貢献するシステムを開発するには、何から手を付ければいいのか? SIを手掛けるオープンストリームのCTOに技術者が心掛けるべき事柄について聞いた。
ビジネス視点に立った開発を行うには、一体どうすればいいのか? ビジネスにより貢献するシステムを開発するには、何から手を付ければいいのか? こうした課題に直面した際、技術者は得てして新しいツールやメソドロジに飛び付きがちだ。アジャイル開発、DevOps、高級言語、統合管理ツールなどなど……。
もちろんこうした道具は、適切な場面で適切に使いさえすれば、極めて大きな効果を発揮する。しかし言うまでもなく、道具はあくまでも手段に過ぎず、これを導入したからといって即座に開発生産性が大幅に向上し、ビジネスに貢献するITが実現するとは限らない。
オープンストリームのCTOを務める寺田英雄氏は、ツールやメソドロジうんぬん以前に、開発者が押さえるべき「基礎」こそが重要だと説く。そんな同氏に、ビジネス視点に立った開発を実現するために技術者が心掛けるべき事柄について聞いた。
現在はユーザー部門主導による個別最適アプローチが主流
編集部 「ITは今、ビジネスに十分貢献できていないのではないか?」という声をよく聞くのですが、開発現場の事情をよくご存じの立場から、こうした意見についてどう思われますか?
寺田氏 一概にはいえないと思いますが、これまで企業システムの企画・開発を主に担ってきた情報システム部門が弱体化しているという意味においては、確かにビジネスに貢献できていないといえるのかもしれません。実際のところ、弊社のSIビジネスも最近では、企業の情報システム部門よりもビジネス部門と直接仕事をさせていただく機会が多くなりました。
編集部 確かに、ビジネス部門が情報システム部門を通さずに、自ら直接システムの企画・導入に乗り出すケースが増えてきました。
寺田氏 同じパターンのシステムを全社で一気に展開するのであれば、確かに情報システム部門のような組織が一括して行うのが効率的でしょう。しかし、今はビジネス環境の変化が激しい時代なので、各事業部門のビジネスニーズにマッチしたシステムをとにかく早く立ち上げたいという要望の方が強いように思います。その結果、「社内システムの全体最適が多少犠牲になっても、やむなし」という考え方ですね。
編集部 今後は再び、全体最適の時代が訪れると見る向きもあるようですが。
寺田氏 確かに、揺り戻しは来るかもしれません。これまで企業システムのアーキテクチャのトレンドは、個別最適と全体最適の間を行ったり来たりしてきましたから。
ただし、個別最適と全体最適のどちらかが唯一の正解というわけではありません。どちらが適しているかは企業ごとの事情によって異なりますし、私たちもどちらか片方にこだわることなく、お客さまのビジネスにより貢献できると思われる方を提案するよう心掛けています。
編集部 少し前から、開発のスピード感を上げてビジネスの要請に迅速に応えるためのシステム開発手法としてアジャイル開発が注目を集めてきました。また近年では、DevOpsも大きな期待を集めています。
寺田氏 アジャイル開発もDevOpsも、特定の問題領域を解決するための手段としては極めて優れていると思います。ただし、一部では誤解に基づいた誤った用法も見受けられるように思います。
例えばアジャイル開発は、下流工程の仕様変更などには確かに強いですけど、これは決して「上流の設計をおろそかにしてもいい」ということではありません。この点を誤解して、上流設計をいい加減に済ませてしまったがために下流で多くの手戻り作業が発生し、結果として逆にスピード感を損ねてしまうケースが少なくありません。
変化の時代を生き抜くために「変化に強い技術者」を目指せ
編集部 一方、貴社のようなSI企業でシステム開発に従事している方々にとって、よりビジネスに貢献できるITを実現するために今足りないこととは一体何でしょうか?
寺田氏 先ほどと似た回答になるのですが、とにかく変化が激しい時代ですから、「変化に強い技術者」を目指すべきでしょう。技術の進歩は凄まじく速いですから、技術者も研鑽を怠らずに時代の変化に遅れを取らないよう常に努力する必要があります。
しかし一方で、技術を学ぶための機会や情報も一昔前と比べれば格段に増えていますから、誰もが高度な技術を手軽に学べる時代でもあります。つまり、よほど飛び抜けたスキルがない限り、技術力“だけ”で差別化を図れる時代ではないということです。
編集部 ある程度高い技術力は「持っていて当たり前」ということですね。
寺田氏 そういう時代にあっては、技術を学ぶための戦略も重要になってきます。例えば投資ではよく、リスク分散のために異なる業種、異なる国の株や債券に投資先を分散させますよね? 技術の習得もこれと同じで、1つだけの技術に絞るのではなく、自分が扱い慣れている技術とはまったく畑違いの技術も、いくつかピックアップして学習するよう周囲に勧めています。
こうすることで、自分が得意とする技術の位置付けや価値を相対化できるようにもなります。
編集部 なるほど。しかし、具体的にどのような技術をピックアップするべきかは、その選択や見極めが難しそうですね。
寺田氏 最初はあまり難しく考える必要はないと思います。自身の興味の赴くままに、普段から広く浅く情報をチェックする習慣を付けることです。
その際のコツとしては、ただ漠然と情報をチェックするのではなく、自分なりの視点(キーワード)を持って情報を見ることです。例えば、IoTに興味があるなら、技術だけでなく他業界の情報やスポーツの情報なども全てIoTという観点で眺めてみることで、見え方はかなり変わってきますし、新しい発想にもつながります。
私も普段から、5、6個のキーワードを基に最新トピックのニュースをチェックするようにしています。
あるいは、コミュニティを活用するのもお勧めです。今では、ありとあらゆる分野でコミュニティが組織されていますから、それらに積極的にアプローチして仲間になっておくと後々いいことがあると思います。
開発者に必要とされるコミュ力と一般に言われるコミュ力とは違う
編集部 ビジネスに貢献できるITを実現するためには、開発者がもっと積極的にビジネス部門とコミュニケーションを取るべきだとの意見もよく聞かれます。
寺田氏 そうですね。ビジネス部門とのコミュニケーションはもちろんですし、最近では国内の遠隔地や海外拠点、オフショア開発拠点など、地理的に離れた場所にいるメンバーと共同でリモート開発を行うケースも増えてきましたから、離れた拠点間でのコミュニケーション技術も今後ますます重要になってくるでしょう。
多くの技術者が誤解しているのですが、技術者が開発業務で必要とするコミュニケーション力とは、何も明るくお調子者に振る舞うことではありません。むしろ、口数は少なくてもいいので、物事を曖昧にせずに、明快な言葉を選んで、はっきりと相手に伝える技術の方がはるかに重要です。
また、「自分にはコミュニケーション力が不足している」と悩んでいる技術者の多くは、話す技術にばかり目が行きがちですが、むしろ初めのうちはお客さまの声をしっかり聞く方に注力した方がいいでしょう。
編集部 伝える能力は重要ですけど、それ以上に顧客の要望を聞きだす能力が大事だということですね。
寺田氏 その上で、口頭でのやり取りを通じて聞きだした内容を『文字化』する習慣を付けることも大事です。
打ち合わせの議事録をお客さまに見せたところ、「こんな意図で話したわけではない」とご指摘いただくことが、いまだに多々あります。確かに議事録作成はとても面倒な作業ですが、これを怠ってお客さまとのコミュニケーションロスを放置したままプロジェクトを進めてしまうと、結局は後になって大きな問題に見舞われてしまうのです。
編集部 ちなみに、コミュニケーションを効率化するためにツールを使うことは有効なのでしょうか?
寺田氏 今では、離れた場所にいる者同士で情報を効率的に共有できるツールがさまざま提供されています。それらの活用は、お客さまやビジネス部門、遠隔地にある開発拠点などとスムーズにコミュニケーションを図る上で極めて有効だと思います。
例えば弊社では、社員同士のコミュニケーションや情報共有にはSkypeやGoogle Appsを使っていますし、一部の社員はMarkdown記法などの新しい手法も取り入れ始めています。また、こうしたツールを社外のお客さまとのやり取りで活用するケースも増えてきていますし、企業内でIT部門とビジネス部門がチケットシステムを通じてやり取りする手法も、今ではかなり一般的になってきています。
開発者といえどビジネスマンとしての基本を軽んずべからず
編集部 「IT側がビジネスをもっと理解する必要がある」という点も、昔からよく指摘されてきました。
寺田氏 お客さまは世の中の変化に応じてどんどん先に行っているのに、こちらが「技術のことしかやりません」では、早々相手にされなくなります。やはりこれからは開発者もIT技術以外のこと、例えば世の中の動向やビジネスのスタイルなどについて知っておいた方が明らかに有利だと思います。
編集部 「業務知識が重要だ」ともよく言われますね。
寺田氏 これは確かにその通りなのですが、システム開発で必要な業務知識って、たとえ業界が同じでも各企業ごとにかなり異なることもあるんですね。従って新規のお客さまの場合には、一から学び直すしかないこともあります。そのためには単なる知識だけではなく、人と人との間の信頼関係を醸成できるようなコミュニケーション技術を磨くことも必要になってきます。
例えば業界動向などを普段からチェックしておいて、お客さまとお会いするときに「貴社の業界での立ち位置ってこんな感じですか」とか「貴社では先月こんな発表をされましたね」といったことを話せば、信頼感を徐々に勝ち取ることができます。
編集部 それは開発者だけに限らず、ビジネスパーソン全般に当てはまる話ですね。
寺田氏 おっしゃる通りです。結局システム開発も通常のビジネスも、基本が大事だということですね。セールスマンが営業成績を上げるために勉強するのと同じように、IT技術者も技術やビジネススキルを磨く必要があるということです。
IT業界では「これを取り入れれば全てが解決する」といったような“うたい文句”が相も変わらず大手を振るっていますが、「銀の弾丸」の話を引用するまでもなく、そんなものが存在するわけがありません。システム開発は知的な創造活動なのですから、ちゃんと考えて、言葉でしっかり表現しなくてはいけません。もし、これをしなくても済むというのであれば、システム開発は誰にでも簡単にできる取るに足らない仕事ということになってしまいます。
その一方で、「ビジネスに寄与する」という意味では、私たちはもっと謙虚になる必要があるのかもしれません。確かに「われわれが入れば確実にもうかりますよ」と自信満々に言えればいいのですが、技術しか知らない人間がそこまで言い切れることは、実際にはなかなかないと思います。
いくら最先端のツールやメソドロジを取り入れてみても、お客さまの話をしっかり聞いて、最大限に頭を使って良いものを作っていくという地道な取り組みがベースになければ、ビジネスに本当に寄与するITは実現できないと思うのです。
編集部 ありがとうございました。
関連特集:Biz.REVO−Business Revolution〜開発現場よ、ビジネス視点を取り戻せ〜
市場環境変化が速い近年、ニーズの変化に迅速・柔軟に応えることが求められている。特に、ほとんどのビジネスをITが支えている今、変化に応じていかに早くシステムを業務に最適化させるかが、大きな鍵を握っている。では自社の業務プロセスに最適なシステムを迅速に作るためにはどうすれば良いのか?――ユーザー企業やSIerの肉声から、変化に応じて「ITをサービスとして提供できる」「経営に寄与する」開発スタイルを探る。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門
ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。 - あらためて見直す、ITアーキテクトの役割
テクノロジ活用の在り方がビジネスに与える影響が増している今、ITアーキテクトの重要性もより一層高まっている。ではITアーキテクトとは何か? 大手SIer、TISのITアーキテクト、熊谷宏樹氏がその役割とポイントを現場視点で徹底解剖する。 - 初めての「アーキテクト」体験
アーキテクトとは、アーキテクトのように考え、アーキテクトのように振る舞う人のことである…… って、分かるような分からないような……。 - クラウド経済通のアーキテクトが必要な理由
群雄割拠のクラウドサービス。ユーザーが増えつつある状況で、顧客の声を生で聞き、現場を知る、国内クラウドサービスの中の人々が自社も他社も関係なく、よもやま話を展開。今必要なのは「クラウドの経済」通のアーキテクトだという。その理由は? - システム開発のトラブル、根本原因は何?
「作る人」と「使う人」でビジネスゴールが異なっていると、真に役立つシステムを開発するのは難しい。ゴールを一致させる一つの方法とは? - テスト自動化の3つの目的とROIの必要性、定義
テスト自動化の導入理由や効果測定をROIという観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを解説する連載です。