要件定義のアプローチ

要件定義の基本

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

規模別の要件定義

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

要件定義の本質

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

対話型要件定義

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

まとめ

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

関連記事

システム開発の混迷

営業依存の弊害

業務システムがうまくいかないのはベンダーやSEの問題だけではない。SEを取り巻く環境もシステム開発には重要である。業務システム開発を依頼するベンダーであれば営業担当者が挟まる。日本の縦割り社会の中で営業担当者は非エンジニアである場合が多く、プロジェクトの成功が目的ではない場合がある。

役割の細分化

SEをプロジェクトマネージャーとしている場合も注意が必要である。日本ではシステムエンジニアは細分化されておらず、建築でいうと参加者の全員が職人という扱いであることが多い。システムに関わる人全員がSEとしてしまっている間違いである。

開発の本質

SEやベンダーのプロジェクトマネージャーはそれ自体がプロジェクトと考えていることも多く、ビジネスとしてのプロジェクトとして捉えることができていないことがある。本来はビジネスが中心にあって、その中に業務システムが位置するはずである。それが見えているか否かで、業務システム開発の成功の確率は変わるのである。

相互理解

逆に、システムのことはSEに任せているというような場合も注意が必要である。システムのプロジェクトを経験したことがある、というだけでは、システムに関連するプロジェクトを成功させるのは困難である可能性が高い。プログラミングの経験がなければ、SEやベンダーが持つ心境を察することができないからである。最も重要なことはシステム導入時のイメージである。

まとめ

欧米では当たり前のように、間接的に関与する売上や利益の向上を管掌する部門や役職があるが、日本では良くも悪くもロジカルであり、数字がなければ行動に移せない厳密なルールがある。

続きを見る >

SEのいうバッファとは

バッファの真意

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

不確実なバッファ

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

知識の不足

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

本質のバッファ

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

まとめ

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

続きを見る >

なぜベトナムは比較的ライトウェイトなWeb開発に向いているか

導入

Web開発は様々な分野が存在しますが、ベトナムは比較的ライトウェイトなWeb開発に適していると言えます。本記事では、Web開発のいくつかのカテゴリについて検討し、ベトナムでのオフショア開発の適性について評価します。

カテゴリ1: 古典的なホームページ開発

古典的なホームページ開発について考えます。現在でも、完全なスクラッチでのホームページ開発が行われることもありますが、一般的にはWordPressなどのフレームワークが使用されることが多いです。このカテゴリについては、利点と欠点がありますが、ベトナムがオフショアに向いているかどうかは、まずは中立的な評価となります。

まず欠点から述べると、デザイン要素が大きいために海外での開発には向いていないと言えます。企業のウェブサイトや商品紹介ページ、ランディングページなどは、マーケティングの観点からデザイン要素が重要です。これらはウェブ開発やHTMLの問題ではなく、デザインの問題であり、プロジェクトの規模的に技術的な開発とデザインの分野が結合していることも多いです。このようなプロジェクトを海外にアウトソースすることは適切ではありません。ベトナムであろうと他の国であろうと、同様の理由が当てはまります。また、ベトナムの開発会社が日本語に堪能であっても、最も難しい分野を外国人に依頼していることを考えるべきです。

一方で、利点について考えましょう。デザインとウェブ開発の分業体制が進んでおり、古典的なホームページ開発の事例は少なくなってきています。従って、ある程度の分業体制が整っている場合は、一部をベトナムにアウトソースすることは合理的です。具体的には、デザイン部分を日本国内で行い、コーディングのみをベトナムで行う方法が考えられます。また、WordPressの記事やショッピングのCMSにおける商品加工など、既にデザインがテンプレート化されている場合もあります。Webは様々な使い方ができるため、適切な開発方法を選ぶためには、日本国内でキャリアのある人材を選択することが重要です。しかし、開発のシステム化を進める企業にとっては、一部の工程をアウトソースすることは有益です。

カテゴリ2: アプリケーションのウェブインターフェース

次に、アプリケーションのウェブインターフェースについて考えます。システムの本質的な価値はデータベースにありますが、検索や編集、書き込みなどにウェブ技術が使用されることは一般的です。また、これはスマートフォンアプリの開発にも大きく関連しています。特にビジネス用途のスマートフォンアプリは、実際にはサーバーやデータベースへのウェブインターフェースに過ぎないことが多いです。

このような開発においては、ベトナムが向いています。デザイン要素や言葉の使い方についてあまり心配する必要がなく、英語で開発しても大きな影響はありません。正確な判断基準を明確に整理できることが、現実的には最も簡単です。過去には、ウェブをシステムのインターフェースとして使用する方法には多くのノウハウが必要でした。例えば、JavaScriptを使ってカレンダーをポップアップさせたり、メールの文字化けに対処するための独自のルールが存在しました。しかし、Bootstrapなどのライブラリ化により、これらの問題は解決されました。そのため、ベトナムのエンジニアの若さや素早さを活かして、新しい技術を学びながら開発を進めることが可能です。

ただし、このような開発には継続性がないという問題もあります。長期間にわたって使用されるシステムではありますが、このような仕事には継続性が求められません。したがって、最適な解決策が存在しない場合でも、状況に合わせて適切な方法を見つける必要があります。

結論

ベトナムは比較的ライトウェイトなWeb開発に向いていると言えます。古典的なホームページ開発においてはデザイン要素が重要であり、海外にアウトソースすることは適切ではありません。しかしその開発工程において分業化や標準化がすでになされている場合は、オフショア開発を検討することは有益でしょう。また、ビジネス用途のアプリケーションのウェブインターフェースにおいては、ベトナムのエンジニアが若さと素早さを活かして開発を進めることができます。
これらの開発においては、WordPressやBootstrapなどのツールやフレームワークを活用することで効率的な開発が可能です。企業のシステム開発においては、オフショア開発の一部を活用することで生産性を向上させることができるでしょう。

続きを見る >