できるIT技術者はバイリンガルを目指そう

キャリア | スキル

» 2009/01/07

「うちではプログラマやSEの経験を積ませることなく、最初から要件定義だけできるコンサルタントを育成しようとしているんですよ」 　「賛成できませんね。システムの作りがわからない人の要件定義だと後工程が迷惑しますよ」 　「大丈夫です。システムの知識は数カ月かけた研修でしっかり身につけてもらいます」 　「その程度では無理でしょう。短期間でつけた表層的な知識ではものの役に立ちませんよ」 　「そこまでおっしゃる根拠は何ですかね？ このデコンストラクションの時代に、考え方古くないですか？」

　お久しぶりです。ウルシステムズの林です。今回も会話からはじめます。

　多少脚色していますが、これは、ある会社のITコンサルタントの育成に関わる人と私との会話です。ここで、「無理だ」と物わかりの悪いことを言っている方が私です。私は社内の教育や社外の教育サービスに関わっていることもあって、ときどきこのような議論に直面することになります。

　「考え方が古い」とか言われてしまうと、世の中の技術革新についていけない昔気質の職人にでもなった気分がしてきてちょっと考えてしまいます。最後の方に出てきた聞き慣れないカタカナ語は後で解説することとして、エンジニアライフをお読みの皆さんはどうお考えでしょうか？ 私の意見の方に賛成していただける方も多いと思うのですが、正面切って「根拠は？」と問われて、相手を説得できるような答えを示せる人はどれだけいらっしゃるでしょうか。

　エンジニアライフでは、後藤さんが、強力な「反アウトソーシング」の論陣を張られていましたが、私も共感するところ大です。最近、システム開発の仕事、特に企業システム開発の設計・実装の工程が軽く見られているように感じることが増えてきました。どうやら人数さえ集めれば誰にでもできる簡単な仕事だと思われているような節があります。

　現実には、システムの設計・実装は、第一級の緻密な思考能力と努力の継続がなければ一流にはなれない、極めて高度な仕事です。しかし、様々な理由で関係者以外には随分おかしな伝わりかたをしてしまっているようです。まったく困ったものです。冒頭に示した要件定義だけ行うコンサルタント育成というのも、その風潮と無関係ではないように思えます。

　今回はこのテーマを軸にして、システム開発の現場に「バイリンガルIT技術者」が求められているという話をしたいと思います。ここで「バイリンガル」というのは比喩的な表現で、ビジネスとシステムの両方の言葉がわかるという意味です。（※）

■経験ベースの説明の限界

　では、冒頭の「根拠」の話に戻りましょう。私としては、システムがどう作られるかがよく分かっていない人が要件定義をした場合、開発が失敗するリスクが非常に高くなるという説明をしたいところです。

　私は数多くの優秀なIT技術者に出会ってきましたが、1年や2年のシステム開発の経験で、頼りになるレベルの技術者になったという例はまず見たことがありません。いないことはありませんが、極めてまれです。普通は、才能があったとしても3年から5年くらいの経験がないと一人前とはいえないのではないでしょうか。それを、数カ月の研修くらいで、企業システムの作りが理解できるとはとても思えません。そして、システムの実装レベルでの実現イメージを持てていないコンサルタントの要件定義は信頼がおけません。その立場にいるコンサルタントの方は一生懸命やっているのだろうとは思うのですが、後工程についての十分な知識を持つIT技術者の助けなしに、ポイントを押 さえきれるはずがないのです。

　実際、最終的なシステムイメージを持たないコンサルタントによって作られた現実的ではない要件定義を、後工程でやり直す結果になった例を何度も見てきました。最近では、要件定義を行った一次請けの開発業者が、設計以降の工程を担当する二次請けの開発業者の技術水準に追いつけなくなり、行われている設計が要件に合致しているのかどうか判断できずに迷走してしまう例を見かけます。また、最終的にどのように作られるのかイメージを持てない人が要件定義を行ったときに、要件を絞り込むことができずに、拡大する一方になるようなことがよく起こります。

　このあたりの事情は、エンジニアライフの読者の皆さんには当たり前に思われることかもしれません。しかし、残念ながらこうしたIT技術者の経験ベースの説明に共感したり納得したりしてくれるのは、システム開発を経験した人だけです。経験に基づいた説明は、同種の経験をした人以外にはあまりピンとこないものなのです。

■コンサルタント視点からの発想

　かたや、要件定義の分業論の方はどうでしょうか？ ここでコンサルタントの視点からどう見えるかを紹介しておきます。

　おそらく多くの経営者や経営コンサルタントには、分業スタイルの方が理にかなっているように思えるはずです。一見すると、ウォーターフォール型の開発プロセスは「バリューチェーン」に見えます。バリューチェーンというのは、企業の活動を「付加価値を生む活動が連なっているもの」と捉える考え方です。この捉え方をすると、それぞれの活動の重点の置き方を変えることで、全体の競争力を高める戦略を立てることができます。つまり、自分の会社が他社と比べて最も得意な活動に重点を置いて、他の部分の比重を下げることで、競争力を高めることが考えられます。

　バリューチェーンの考え方に基づいて、ビジネスの構造を組み替える戦略が、冒頭の会話に出てきた「デコンストラクション」です。この1つの例がバリューチェーンの一部をアウトソーシングするというものです。この発想に基づけば、（利益率の高い）要件定義を担当するコンサルタントの育成だけを行い、後段の設計・実装工程は他の業者にお任せするということになります。ビジネス的には魅力的な戦略にみえます。このような、著名な理論などをベースにした議論の展開パターンは「フレームワーク」と呼ばれ、戦略系のコンサルタントの使うロジカル・シンキングの中でもとりわけ強力な手法です。

　いかがでしょうか？ 「なんだそりゃ？」「現実見て言ってるの？」と思われた方もいるかもしれません。私もコンサルタントの一人ではありますが、既に述べたように、この考え方には賛同していません。しかし、経営層にはこうしたビジネス戦略の説明の方が、先に示したIT技術者の経験ベースの説明よりも響くのです。なにしろ、「バリューチェーン・デコンストラクション」は経営の神様とまで言われるマイケル・ポーターに由来する霊験あらたかなフレームワークです。これに反論するには、個人の経験論を越えたアプローチが必要です。「マイケル・ポーターなんてやつは知らねえ。こっちの世界じゃ、神はトム・デマルコだ」などと言ってみたところで始まりません。

■ビジネスの言葉を話せる技術者へ

　理論的な話をするなら開発プロセスはバリューチェーンではないという議論をするのでしょうが、そんな小難しい話よりも効果的なアプローチがあります。それは、IT技術者がその実力をしっかり認識してもらうことです。つまり、十分な開発知見を持つIT技術者による要件定義の方が、結局うまくいくという結果を、経営層に理解できるような形で示していくことが大切です。結局、優れたIT技術者の価値をしっかり認めてもらうためには、相手の土俵、つまり経営者や経営コンサルタントの認識できる領域で存在感を見せていく必要があるのです。

　そのために重要になるのが、システム開発とビジネスの両方の言葉を話せるバイリンガルのIT技術者です。ビジネスの言葉とは、ビジネス上の意思決定のロジックを理解して、そこにいる関係者を説得することのできるコミュニケーション・スキルのことです。

　別に誰も彼もがコンサルタントを目指そうという短絡的な話をしたいわけではありません。前回のコラムで説明したように、ITコンサルタントは「ITの専門知識を用いて顧客の課題を助ける仕事」をする職業のことです。相性もあるのでコンサルタントへの転身は、必ずしも誰にでもはおすすめしません。コンサルタントではなく、システム開発のプロジェクトマネージャやアーキテクトという役割であっても、システム全体の成否に関わる提言や交渉を、ビジネスの側面も踏まえて行うことのできるスキルは役に立ちます。

　私の所属するウルシステムズの「ITコンサルタント」は、中途入社のメンバーがほとんどなのですが、コンサルティング会社出身者だけでなく、SIやソフトハウスのIT技術者出身のメンバーが多数在籍しています。私の部署でも、設計・実装工程に深い知見を持つIT技術者に、コンサルティングに必要なスキルを身に付けてもらった上で、様々なITコンサルティング活動を行ってもらっています。比較的多く行っているのは、要件定義支援、あるいは発注側プロジェクト管理支援という形で、発注側の要件と開発側の都合の両方を調整する役割を果たすタイプのコンサルティング活動です。

　こうしたこれまでの経験から、2つのことがわかってきています。

　１つは両方の言語を話せる媒介者がいれば、システム開発のコスト超過のリスクを抑えられるということです。プロジェクトの計画外のコストは、要件の認識違いによる手戻り 、要件の膨張、作業の遅延などをきっかけにして発生します。これらはいずれも、コミュニケーションが十分できていれば防ぐことのできる場合がほとんどです。ところが、発注側に開発経験がないためにプロジェクトの実態がわからずコントロールができない、反対に受注者がビジネス視点を踏まえた上での報告や提言のスキルを持っていないという状態では、なかなか十分なコミュニケーションをとることはできません。どちらの言葉も理解できる媒介者がいれば、手遅れになって問題が発生するリスクを抑えることができるようになります。

　もう１つはIT技術者の高いポテンシャルです。コンサルティングに必須のコミュニケーション・スキルを１つ挙げるとすれば、ロジカル・シンキングになります。ロジカル・シンキングとは考えを整理して説得力のある形に提示するためのテクニックです。書籍もいろいろと出ているのでどんなものかを知っている人も多いと思いますが、使いこなすためにはかなりの経験を蓄積する必要があります。ところが、IT技術者はもともと論理的な思考を求められることもあって、ロジカル・シンキングに親和性のある知識や経験をいろいろと蓄えています。個人差もあるので、一概には言えませんが、非常に速い速度で必要なコミュニケーション・スキルを身に付けることのできるIT技術者は珍しくありません。

■これからの主役はバイリンガルIT技術者

　現在も「システム開発を熟知しつつビジネス側面での議論もできる人」は、強く求められていますが、IT技術の空洞化が心配される中、この傾向は今後ますます強くなっていくと私は考えています。高いコミュニケーション・スキルを持つIT技術者の活躍が増えれば、経験をベースにした説明の説得力も重みを増していきます。

　ここで注意して欲しいのは、どちらの言葉もカタコトにしか話せないのでは、あまり評価されないだろうということです。コミュニケーション・スキルだけで、ITの深い知見がなければ、技術をあまり知らないコンサルタントが1人増えるだけです。一方で、相手の土俵に上がることのできるレベルのコミュニケーション・スキルも必要です。現在、システム設計・実装に携わっている皆さんは、ぜひ、技術の本質に深く踏み込んだ知識と経験の蓄積に努めてほしいと思います。合わせて、電子メールやドキュメントの作成、上司や顧客への説明、会議の司会など、人と関わる様々な場面を通して、ロジカル・シンキングをはじめとするコミュニケーション・スキルを磨いていきましょう。

　世の中、先行きが不透明になっていますが、技術の進歩が歩みを止めることも、企業におけるシステム開発の重要性が失われることもありません。ビジネスとシステムの2つの言語を自在に操ることのできる「バイリンガルIT技術者」こそ、これからのIT業界の主役になるはずです。

※経営者と技術者の両方の言葉を話すという意味での「バイリンガル」という表現は、筆者が初めて使うものではない。「仙石浩明CTOの日記：IT企業には技術者と経営者の両方と話せるバイリンガルが必要（2006年05月11日）」において、ほぼ同じ意味で使われている。