総合要求定義のあいまいさが人材不足を引き起こす
前回は2015年問題の原因として、ユーザー企業のスクラッチ開発偏重姿勢を取り上げた。スクラッチ開発が多いため、IT企業側は受託開発が多くなる。受託開発要員が自社内で不足しているのであれば、人材余裕のある海外や国内の地方の人材を活用すればよい。しかし、活用できていないのが実態だ。
なぜ、活用できないのだろうか? 今回は、そのユーザー企業側原因を探り、解決策を提言する。
常駐型受託開発を望むユーザー企業のIT部門
日本のユーザー企業は前回見たように、スクラッチ開発を好む傾向が強い。そのため、受け手側のIT企業の売上の大半は受託開発が占めている。
情報サービス産業協会の調査では、売上全体の90.5%を情報サービスが占め、その39.5%がSIサービス、ソフトウェア開発が23.9%を占めている(図表1参照)。売上全体で見ると、SIサービスが35.7%、ソフトウェア開発が21.6%、合計57.3%になる。情報サービスの中のSIサービスにはSIの中のハードウェア販売は含まれないため、その中身はソフトウェア受託開発であると推察できる。従って、日本のIT企業の売上高の6割近くは受託開発であると言える。
受託開発には大きく2つの方法がある。持帰り型と常駐型である。
持帰り型とは、ユーザー企業の書いた要求定義書をIT企業に渡し、IT企業は自社に戻って自社内で開発を行う。IT企業は自社内に開発環境を整備する必要があるが、社内で他のプロジェクトに従事している社員からアドバイスを得たり、与えたり、複数のプロジェクトを兼務することも可能であり、1人あたりの開発効率を上げることができる。また、著作権を留保したソフトウェアの再利用や自社開発方法論を活用してさらに開発効率を上げることができる。ネットワークを活用すれば、人件費の安い海外や遠隔地に自社オフィスを設置することも可能であり、コスト削減を図ることもできる。
これに対して、常駐型は顧客のオフィスに常駐し、顧客の環境で開発作業を行う。直接顧客からの指示で作業を行うと派遣になってしまうが、実際には顧客と密に相談しながら開発を行うことが多く、口頭で顧客から依頼を受けることも多い。
また、常駐する技術者はその顧客の仕事しかできず、他のプロジェクトに従事している自社社員からアドバイスを得たり、与えたりすることも少なく、自社の持つソフトウェアや開発方法論も活用できないことが多い。また、顧客オフィスの近くに居住させる必要があり、遠隔地に自社オフィスを持つと出張費がかさむため、顧客本社の多い都市圏に本社を置くIT企業も多い。
日本の受託開発の大半は常駐型であると推察できる。なぜなら、持帰り型受託開発であるオフショア開発やニアショア開発が活用できていないからである。
なぜ、オフショア開発が活用できないのか
日本のIT人材が不足しているのであれば、海外のIT人材を活用すればよい。ところが、海外のIT人材を活用するオフショア開発の活用は進んでいない。IT人材白書2013によれば、2007年~2011年にかけて横ばい状態が続いている(図表2参照)。オフショア開発の活用の阻害要因としては、言語と文化の違いが挙げられる。
言語の異なる海外で開発を行うためには、要求定義書に対する解釈の違いや誤った理解が発生しないように、言葉を明確に定義し、詳細な記述が必要になる。日本人の開発者を前提に書かれた要求定義書をそのまま翻訳したのでは、あいまいな部分が多く、解釈の相違や誤った理解を生みやすい。海外の開発者に開発を依頼するには、海外開発者が読むことを前提にして書かれた要求定義書が必要になる。
文化の相違も大きな障害になる。納期や品質に対する意識は国ごとにより異なる。求める内容は全て文書化し契約する必要がある。「言われたことしかやらない」と海外技術者を批判する方がいるが、「言われたこと以外はやっていけない」という文化を持つ国は多い。やってほしいことは契約条項に入れないと実施されない。
これら言語や文化の違いが海外IT人材の活用を難しくしているのであれば、同じ言語・文化を持つ国内の地方にあるIT企業を活用すればよい。ところが、地方のIT企業を活用するニアショア開発もあまり活用されていない。
なぜ、ニアショア開発を活用できないのか
ニアショア開発の活用が進めば、本社を東京に置く必要はなく、地方に本社を持つ企業が多くなるはずである。
ところが、前掲の情報サービス産業協会の調査では、IT企業の本社の66.5%は東京にあり、千葉・埼玉・神奈川を加えた首都圏には、73.5%のIT企業の本社がある(図表3参照)。まさに一極集中状態にある。
もちろん、情報サービス産業協会に加盟している企業が大企業中心であり、地方のIT企業の中には、地元本社だけではなく、東京に東京本社を置いている企業もあるので、そのまま実態として捉えるのは問題だと思うが、東京を中心とした首都圏に集中していることに変わりはないだろう。
特に、ニアショア開発の拠点として取り上げられることが多い北海道・沖縄だが、ここに本社を持つ企業は1.7%しかない。これらの企業もニアショア開発しているかどうかは分からない。以前、沖縄に本社を持つIT企業の社長から次のようなことを聞いたことがある。「社員の家族から怒られたことがあります。家族がいる沖縄で働かせたいから、あなたの会社に入れたのに、娘は東京のお客さまの仕事で東京へ行ったきり帰ってこない。これでは、東京の会社に入れたのと同じだ」と。
なぜ、ニアショア開発は活用されないのだろうか? ニアショア開発を行うためには、要求定義書を明確に記述する必要がある。同じ日本人に開発を委託するので、オフショア開発よりはハードルは低いが、やはり、あいまいさのない要求定義書を書く必要がある。あいまいな部分があると、内容の確認を頻繁に行う必要があり、顧客との距離の遠さがマイナス要因になる。最悪、十分な確認をせずに開発をしてしまい、作り直しになることもある。
あいまいさのない要求定義書が書けないために、持帰り型開発よりも常駐型開発がユーザー企業で好まれ、そのため、開発効率は上がらず、IT企業のIT人材不足を引き起こしているのだ。
要求定義のあいまいさを排除するためには
要求定義のあいまいさをなくすためには、要求の構造を理解したうえで、要求をモレダブリなく整理し、論理的な文章にまとめる必要がある。
(1)要求の構造を理解する
要求分析のための知識体系に「BABOK(Business Analysis Body Of Knowledge)」がある。カナダに本部があるIIBA(International Institute of Business Analysis)が策定したビジネスアナルシスのための知識体系である。この中で、要求は4種類に分類されている。
- ビジネス要求:組織の目的、目標またはニーズを概要レベルで定義した要求
- ステークホルダー要求:ステークホルダーのニーズを定義し、または、ステークホルダーがソリューションとどのように関わるかを定義したもの。
- ソリューション要求:ビジネス要求とステークホルダー要求を満たすために必要なソリューションの特性を表す。ソリューション要求は、機能要求と非機能要求に分かれる。
- 移行要求:現在の状態から、将来の状態に移行するために、ソリューションが必要とする能力を定義したもの
また、ビジネス要求、ステークホルダー要求、ソリューション要求は図表4のような因果関係を持つ。要求が発生した場合には、要求がどの要求なのかを分析した上で、因果関係の前にある要求を明らかにする必要がある。例えば、ソリューション要求の場合には、ビジネス要求、ステークホルダー要求が明らかになっていないと、何のため誰のために必要となされているのかが明らかにならず、あいまいな要求になってしまう。
(2)論理的な文章力を身に付ける
論理的な文章とは、筋道が通っていて、全体の内容が整理されており、読み手にとって分かりやすい文章のことである。決して、理屈っぽい文章のことを言っているのではない。論理的な文章を書くことのメリットは、書き手の伝えたい内容が正確に読み手に伝わり、誤解が少なくなることにある。
論理的な文章には、最適な構造がある。米国のコンサルティング会社マッキンゼーの編集者であったバーバラ・ミント氏は、著書「考える技術・書く技術」の中で、ピラミッド構造を提唱している。これに基づき、マッキンゼー日本支社の編集者であった照屋華子氏、岡田恵子氏が「ロジカル・シンキング」(両氏の共著)、「ロジカル・ライティング」(照屋氏の単著)という本を書きベストセラーになったため、この本はロジカル・ライティングの元祖と言われている。
ピラミッド構造とは、人間の脳がニューロン・シナップスによるネットワーク構造(ピラミッド構造)を採っていることから、これに類似した構造で文章を書けば、読み手にとって分かりやすい論理的な文章を書くことができると考え、作り出した文書構造である。
ピラミッド構造では、文章は大きく導入部と本文に分かれる。導入部は「Situation(状況)」「Complication(複雑化)」「Question(疑問)」「Answer(答え)」の4つに分かれており、この順番で書く。本文は主ポイントを頂点としたピラミッド構造であり、階層ごとに縦の関係と横の関係を持つ(図表5参照)。縦の関係は質問と答えの関係にあり、横の関係には演繹的な関係と帰納的な関係がある。これらを設計した上で文章を作成すれば、論理的な文章を書くことができる。
ユーザー企業が要求定義書を作成する際に、要求の構造を活用して整理し、論理的な文章構造に則って文章を作成すれば、あいまいさを排除することができる。これにより、IT企業の常駐型中心の受託開発を持帰り型に変えていくことが可能となり、海外や地方のIT人材活用が促進されIT人材不足を解消することができるのだ。



(図表4)要求の因果関係
(図表5)ピラミッド構造