要件定義の問題点

要件定義の基本

すべてをシステムで解決してしまおうとする要件定義には注意が必要である。システムの成功の可否は要件定義にかかっていると言っても過言ではない。しかし、十分に要件定義の時間を使ったにも関わらず、ITプロジェクトが失敗することがある。

規模別の要件定義

システム構築の規模によって、要件定義の粒度が変わる。小さなITプロジェクトの場合は要件定義をせずにプロトタイプを作りながらシステム構築を進めるといった方法がある。これをアジャイル開発、プロトタイプ開発と呼ぶ。

要件定義の本質

要件定義の粒度は時間を掛ければ細かくなるわけではない。ユーザー側でも要件定義を進めるにつれて、想定している機能の矛盾点が出てくることがある。この矛盾点を解消していくこと自体を要件定義としてはならない。要件定義はあくまで本質的なコアとなる部分から膨らませることが重要である。

対話型要件定義

要件定義フェーズで失敗するパターンは、ユーザー側との対話ではなく、システム会社側がヒアリングに徹する場合である。ユーザー側はITを利用してどのようなことができるかを知らない可能性が高いため、システム専門家がそれを鵜呑みにした仕様で要件を固めてしまうと、製造工程で無駄な工数が発生し予算をオーバーしてしまうことがある。

まとめ

本質的な要件をコミュニケーションによって、はっきりさせていく作業こそが要件定義と言えるのである。さまざまな視点から何度も繰り返し要件をなぞることで粒度が落ちていき、適切な要件定義書となる。何でもかんでもシステム化せず、オペレーションとの関係性を見合わせながら進めることが望ましい。

セクション1: 日本のソフトウェア開発人材不足の背景

日本のソフトウェア開発業界は50年以上の歴史を持ち、多くの経験豊富なエンジニアが存在します。しかし、現在の日本では開発人材の不足が深刻な問題となっています。この人材不足は、企業が即戦力となるエンジニアを安価で求めるという要望に由来しています。そのため、日本の人材不足はしばしば「即戦力を安く求める欲求」として揶揄されることもありますが、この言い方には一面の真実も含まれています。企業が効率的な開発を行うためには、即戦力のエンジニアが必要なのは当然のことです。

また、この人材不足の問題は、単に日本だけに限ったものではありません。他の海外でも同様の人材不足が起きています。したがって、オフショア開発を検討する際には、都合の良い人材を海外で見つけることができるという考え方は一部正解であり、一部誤解とも言えます。

セクション2: 日本とベトナムのエンジニアの特徴

日本のエンジニアは、特にWeb関連のエンジニアにおいては、1990年代からのキャリアを持つベテランが多く存在します。そのため、文字コードやバイナリ、組み込み技術など、古いOSや低レベルの知識を必要とする開発においては、日本の技術者は強みを持っています。一方、新しいフレームワークや概念の習得には、国民性よりも年齢が影響を与える傾向があります。そのため、ベトナムのエンジニアは若さを活かして新しい技術を素早く学ぶことが得意と言えます。

また、コンピューター業界においては、上流と下流、低レベルと高レベルといった言葉が中立的に使われますが、この意味において日本は低レベル開発に向いており、ベトナムは高レベル開発に向いていると言えます。そのため、バランスの取れたオフショア開発を行うためには、日本のエンジニアのジェネラリスト的な能力とベトナムのエンジニアのスペシャリスト的な能力を組み合わせることが重要です。

セクション3: 日本とベトナムの開発手法の違い

日本のソフトウェア開発では、納期を守るためにウォーターフォール型の開発手法が主流です。アジャイル開発が概念的には取り入れられつつありますが、完全にアジャイルな開発プロセスを採用しているケースはまだまれです。一方、ベトナムのソフトウェア開発は、日本の開発手法と大きく異なるわけではありません。基本的には納期を守るためのウォーターフォール型の手法が一般的ですが、OSSの影響を受けて開発手法が変化しつつあります。

日本の開発現場と比較して、ベトナムの開発手法の利点は、新しいフレームワークや技術の習得において素早い反応性を持つことです。ベトナムのエンジニアは若く、学習意欲が高いため、最新の技術に対する理解が早く、柔軟に対応できるという特徴があります。ただし、ベトナムの開発現場においては、アジャイル開発の完全な導入はまだ一般的ではないことに注意が必要です。

セクション4: 言語の壁以外の考慮すべきポイント

ベトナムのエンジニアを活用する際に言語の壁を乗り越えるためには、円滑なコミュニケーションを図ることが重要です。英語がビジネスコミュニケーションの共通語となっているため、日本の企業がベトナムのエンジニアとのコミュニケーションを円滑に行うためには、英語教育の強化や翻訳ツールの活用などが有効です。また、文化やコミュニケーションスタイルの違いも考慮すべきポイントです。異なる文化背景を持つエンジニア同士が協力する場合、相手の文化に対する理解や尊重が求められます。

セクション5: 成功へのカギはバランスと柔軟性

ベトナムでのソフトウェア開発のオフショアを成功させるためには、日本とベトナムのエンジニアの特長を組み合わせることが重要です。日本のエンジニアはジェネラリストとして幅広い知識と経験を持っており、プロジェクト全体の管理や技術的な統括を担当することが得意です。一方、ベトナムのエンジニアはスペシャリストとして特定の技術に精通しており、新しい技術の習得にも素早く対応できます。

オフショア開発においては、開発現場のバランスと柔軟性が求められます。例えば、日本のエンジニアがジェネラリストとしてプロジェクトを牽引し、ベトナムのエンジニアがスペシャリストとして特定の技術領域を担当する役割分担が効果的です。また、現代的な開発手法を用いることも重要です。ウォーターフォール型の手法に加えてアジャイル開発の一部を取り入れるなど、柔軟に適切な手法を選択することが目的達成（コストダウン実現）へのカギとなります。

バッファの真意

見積りや作業スケジュールに際して、エンジニアやシステム会社から「バッファである」という回答を受けたことはないか。システム会社が言うバッファとは保険を意味していることがほとんどである。

不確実なバッファ

非エンジニアは見積りのバッファを聞いたときに、無駄なのではないかと感じる。「念のため」に必要なバッファは、裏を返すと知識がないから調べないと分からないので不安であるという意味である。知識があり、「念のため」が必要なければバッファはないと考えられる。

知識の不足

ほとんどのシステム構築プロジェクトは、バッファが多いほうが知識がないのに見積りが高くなるという矛盾が発生することになる。そう考えると「バッファ」とは「無駄」に聞こえるかもしれない。

本質のバッファ

さて、このバッファについて本来あるべき姿を説明する。本当にやってみなければ分からないといった高度な技術を使うときに、未知の領域に関するスケジュールの影響を勘案し、計画された期間のことをバッファと見るべきである。

まとめ

単なるシステム構築プロジェクトにおいて「無駄を削ればよい」というのは非エンジニアから見ると合理的でコストの軽減にもなる。しかし、研究開発分野において無駄を削ることは必ずしも合理的ではない。発想が乏しくなるからである。