IT技術者が「上流」に出て行く理由
~IT技術者のための戦略・業務分析入門~
ウルシステムズ
林 浩一
2005/4/13
もしあなたが、IT技術の本質をつかみ、高度なアーキテクチャの設計ができ、その内容を関係者に説明し納得させられる力を持っているのなら、すでにコンサルティングに必要なスキルの大半は身に付いている。後は実践あるのみだ。経営者だって人の子。怖い人ばかりじゃない。勇気を持って踏み出してみよう(本文より)。
1. 顧客満足につながるシステム構築のために
1.1 そのシステムで本当にお客さまは満足しますか?
- PR -
あなたがプログラマなら、「いま、コーディングしているこのシステムは本当にユーザーが望んでいるのだろうか?」「作ったものは本当に役に立つのだろうか?」――、こんな疑問を感じた経験はないだろうか?自分が開発したものが使われ、喜んでもらえることは、技術者であれば誰でも願うことであろう。多くの場合、こうした疑問は、見習いの段階を終えて、技術者として自信が出てくるころからわいてくるようになるが、先輩や上司に聞いても納得できる答えが得られることはまずない。なぜなら、システム開発の現場には答えがないからである。
システムがお客さまの求めるものになるかどうかは、システム開発プロセスの中で上流と呼ばれる要件定義フェイズで決まると考えている方も多いだろう。しかし、多くの場合、それは正しくない。システムの基本的な構想や機能の大半が固まるのは、要件定義よりもさらに前の事業戦略立案や業務分析の段階なのだ。そして、この領域の仕事をするのは戦略コンサルタント、業務コンサルタントと呼ばれる人たちである。
では、彼らの作った要件を信じてシステム開発を進めていけばよいのかというと、必ずしもそうでもない。開発経験のないコンサルタントはシステムについて表層的な知識しか持ち合わせていないことが多く、彼らから渡される仕様ではシステムを開発できないことがよく起きるのだ。その結果、ただでさえ短い貴重な要件定義フェイズの期間が、非現実的な要件を、現実に合わせて調整するという作業に費やされることになる。多くの場合、前フェイズのプロジェクトは解散しているので、不明点があってもそれを埋める情報は得られない。しかも、この手戻りで消費された時間は確実に後の工程を圧迫する。こうして、使えないシステムがまた1つ世に出てゆくのだ。
1.2 IT技術者が視野を広げることが真の顧客満足に貢献する
お客さまに喜んでいただけるシステムを構築してゆくためには、事業戦略や業務分析とシステム開発の間の溝を埋めることが不可欠である。このためには、システム開発に関する一級の知見を持った技術者が、事業戦略や業務分析にまで視野を広げることが非常に重要になる。われわれは、システム構築の前工程に当たるこの領域のコンサルティングをビジネスモデリングと呼び、戦略コンサルタントとITコンサルタントの協業の下に体系的な取り組みを進めてきた。
本連載では、IT技術者の皆さんにシステム開発の前段で行われているビジネスモデリングのイメージを持ってもらうために、われわれが行ってきたコンサルティング事例を紹介していきたい。それぞれの案件で、どのような課題に対してどのような手段を講じ、その結果何が得られたかを、第一線で活躍しているメンバーに直接語ってもらう。戦略コンサルタントとITコンサルタントのそれぞれの視点を交互に示すことで、システムの要件が生まれる場所の実像を浮かび上がらせたい。
初回は、ビジネスモデリングについて理解してもらうための準備として、開発フェイズの前工程では、必ずしも現場のIT技術者が思っているようには物事が進んでいないということをお伝えしたい。別の法則が成立している世界なのである。そして、IT技術者がその世界に踏み出していくために、いますぐにでも始めておくべきことを示したい。次回は、戦略コンサルタントの仕事の進め方について基本を示し、その後、具体的な事例紹介へと進めていく。
2. ビジネスモデリングの世界
2.1 ユーザーは必ずしもお客さまではない
IT技術者としてキャリアの最初のステップは、定められた仕様を満たすことのできる、ちゃんと動くプログラムを作成するところから始まるだろう。ある程度、技術に自信が持てるようになったころから、システムを使うユーザーが見えてくる。そして、ユーザーにとって使いやすい画面構成や、業務が流れやすいような画面遷移を設計することができるようになっていく。「本当にユーザーが望むシステムを作っているのか」という問いは、十分にユーザーの意見が聞けず、使いやすいシステムに設計できている自信を持てないことをきっかけにして表れてくる。
ところが、実は、お客さまがシステムの使いやすさに関心がないとしたらどうだろうか?極端な場合、プログラムの品質さえも関心外だとしたら? 言い換えると、このシステムによって「便利になります」「レスポンスが良くなります」「業務が円滑に進みます」といったことがお客さまに評価されないことは珍しくないのだ(図1)。
|
図1 お客さまがシステムの使いやすさに無関心だとしたら? |
IT技術者がしばしばお客さまと思って打ち合わせをしているユーザーは、必ずしもお客さまではない。もちろん同じ場合もあるが、企業向けシステムでは、ユーザーとお客さまとは通常は一致しない。一般に、お客さまとは、商品にお金を支払ってくれる人である。つまり企業向けシステム開発の場合には、納入先となる企業の経営者に相当する。そしてユーザーは、システムを利用する人である。企業向けシステムの場合、ユーザーは納入先の企業の従業員になる。
2.2 お客さまの関心事はシステム自体にはない
経営者の最大の関心事はビジネスの成功にある。つまり、どれだけ売り上げを伸ばしてコストを下げるかにある。システムについての最大の関心事は、それによって必要な事業戦略の遂行や業務改革の実現を支援できるかどうか、そして、そのシステムが期待する効果に見合う費用で実現できるかどうかである。
これに対し、従業員の関心事は与えられた仕事をいかに効率的に進められるかにある。ビジネスモデリングからスタートするシステム開発の場合に陥りやすい落とし穴として、“現場の意見を聞いて行ったシステムの改善が必ずしも、経営課題を解決しない”というのがある(図2)。新しい事業にチャレンジをしようとする場合、それまでの業務は大幅に見直されるので、現場の意見に意味がないことすらある。そこまで極端でなくとも、現場のユーザーにとっての使いやすさが、高い優先順位を得られないことは多い。
|
図2 現場の要望ではしばしば経営を説得できない |
2.3 ITは経営課題を解決する主役ではない
現在、ほとんどの企業で、ITの助けを借りることなくビジネスを進めることはできない。しかし、ITが経営課題の解決の主役であることは少ない。激しさを増す競争を勝ち抜くために、企業の経営者はさまざまな課題を抱えている。課題を解決するための施策も多様である(図3)。製品ラインの見直し、製造コストの低減、在庫の削減、組織運営の見直し、新規事業の企画など、その多くは必ずしも新たにシステムを開発することだけでは解決しない。
|
図3 課題を解決するための施策は多様 |
システムは、どんな新製品を投入するかの戦略、どのように業務を改善すればコストが下げられるのか、そういった全体的な施策の一部として位置付けられる。言い換えると、こうした施策全体の構図の中での位置付けが見えない限り、開発しているシステムが意味のあるものかどうかは分からない。
2.4 それでもシステムなしには課題は解決しない
しかし、たとえシステムの要件が経営課題の解決に直結しなくても、それらを無視してよいはずはない。ユーザーの業務を円滑に支援できるシステムでなければ、結局課題は解決しないのだ。システムで実現できること、システムが当然満たすべき要件の十分な理解なしに、経営者だけを見てシステムを構想していくと、あっという間に非現実的な要件が出来上がってしまう。
こうしたシステム開発とその前工程との間の溝を埋めるには、戦略・業務のコンサルタントにシステム開発についての知見を高めてもらうのでも構わない。しかし、そんなコンサルタントはまずいないと思ったほうがよい。ご存じのように、IT技術者は十分な資質を持った人でも、最低5年程度経験を積まないことには一流のレベルに達することのできない高度な専門職である。上流のコンサルタントが、顧客満足のためといっても、そこまでしてIT技術知見を高める動機はない。
2つの世界のギャップが埋まらず、妙な仕様書を押し付けられて悲惨な目に遭うのは常にシステム開発の現場なのだ。顧客満足を高めるためにも、また、自衛のためにも、IT技術者こそが上流に出てギャップを埋めなければ、誰も代わりにやってはくれない。
3. 上流に踏み出すためにやるべきこと
3.1 ビジネスモデリングの標準言語JMLを身に付けよう
IT技術者が上流の世界とシステム開発の世界のギャップを埋めるために、いますぐにでも取り組むべきことは何だろうか? 筆者はそれを標準言語JMLと呼んでいる。これは、システム開発におけるUMLを、ビジネスモデリングに使えるように拡張した夢のモデリング言語……ではない。現実のコンサルティングで重要になる3つの要素の頭文字を取ったものだ。
(1) Japanese
日本で仕事をするのであれば、標準言語はプログラミング言語でもモデリング言語でもない。日本語である。正しい日本語とそれを用いたコミュニケーション力を身に付けることは何をおいても重要だ。コンサルタントには、ドキュメンテーションやプレゼンテーションなど、しっかりした日本語力が必要とされる場面は多い。とかく、IT技術者はコンピュータと対話するのは得意でも、人と話をするのが苦手という人も多いが、ここは努力のしどころである。別にしゃべるのが得意でなければいけないという意味ではない。口下手であっても、中身と熱意があれば通じるから心配は要らない。むしろ、きちんとした日本語が使えることの方が大切である。ドキュメントに書かれている日本語がおかしいと、経営者から頭が悪いんじゃないかと思われ、下手をすると内容まで疑われてしまうので、くれぐれも注意が必要である。
(2) Money
お客さまである企業経営者にとって、重大な関心事はお金、つまりいかにして利益を得るかである。ビジネスの仕組みが見えなければ、経営課題の意味するところが理解できない。バランスシートやP/Lの読み方などの最低限の会計知識を身に付け、また、日本や世界の経済動向について感度を高めておきたい。これらの目的は、日本語と同様、ビジネスの会話のベースを作るところにある。本や雑誌で身に付けた程度の知識で、お客さまに対してビジネス上のコンサルティングをやろうなどとは考えない方が身のためである。
(3) Logic
上流工程のコンサルタントが経営課題をシステムへの要件まで橋渡しするために使っている決め手のツールがロジカルシンキングである。コンサルタントは、経営者の問題意識を理解し、それを解決するための分析を行い、取るべき施策を提言するのが仕事である。ロジカルシンキングとは、論理的に物事を整理してゆくための考え方のことで、説得力がある手順や枠組みで、分析や問題解決を行い、報告書を作成してゆくための基礎となる。システム開発フェイズでも分析設計やプロジェクト管理などさまざまな場面で利用できるので、勉強しておいて損はない。
3.2 まずは一流のIT技術を身に付けよう
ここまで読まれて、よし、2つの世界のギャップを埋めるための知見を身に付けるために、すぐにコンサルティング会社に転職しようと考えた方がいるかもしれない。少し待ってほしい。その前にやることがある。いま求められているのは、経営課題の視点から、企業システム全体のアーキテクチャの妥当性を示せるほどの深い技術知見である。一級のIT技術知見がなければ、システムの理解が十分でないコンサルタントの仲間入りをするだけだ。
ビジネス知識はともかく、ロジカルシンキングやコミュニケーションの能力は、システム開発の現場でIT技術を深く追求してゆく中でも高めることができる。IT技術者が日ごろから相手にしているコンピュータは、実はロジックの固まりである。動作原理は形式論理と呼ばれるロジックであり、その上のプログラミング言語やアーキテクチャの理論のすべてに、数学と論理学が隠れている。IT技術者は、最もロジカルな環境で仕事をしているのだ。
システムを設計する際、コーディングの方針を決める際、デバッグを行う際に、どの方針がベストなのかを論理的に検討してみよう。関連する理論の基礎となる計算機科学についても勉強しよう。そしてチームメンバーや上司に、ただ結論だけ伝えるのではなく、なぜそうでなければいけないか説得力をもって説明することを心掛けよう。
もしあなたが、IT技術の本質をつかみ、高度なアーキテクチャの設計ができ、その内容を関係者に説明し納得させられる力を持っているのなら、すでにコンサルティングに必要なスキルの大半は身に付いている。後は実践あるのみだ。経営者だって人の子。怖い人ばかりじゃない。勇気を持って踏み出してみよう。「一流のIT技術者なら、上流工程でも一流の仕事ができる!」。