相場の不在

誤解されるコスト削減

実はローコード・ノーコードツールを使えば、開発が必要なくなるので安くなるというのは正しくない。たしかに、ノーコードツールを社内メンバーでCMSを使ってソフトを作るという場面は開発費用はかからない。

CMSとはコンテンツ・マネジメント・システムの略で、たとえばWebサイトのコンテンツを構成するテキストや画像、デザインなどを非エンジニアがプログラミングをせずに作成や管理できる仕組みのことである。ローコードツールはそれに加えて少しのプログラミング知識でシステムやツールを作成できることである。

開発手法の選択基準

断じてローコード開発だからといって安いわけではない。開発手法の特性による得手不得手を上手に使い分けるからトータルとして価格が安くなるということである。非エンジニア営業の金額調整という意味での判断でローコード開発を選択する場合は失敗することがある。

システム導入の本質理解

ローコード開発でも、システム導入の目的や条件が本質的にわかっていなければ、仕様要件のブレによって結果としてトータルが安くなることはない。これはローコード開発ということが問題なのではなく、フルスクラッチ開発であっても、SaaSと利用する場合であっても同じことが言える。

負債の危険

本来ローコード開発が適さない場合にも関わらず無理やりに合わせることで、プログラム部分の複雑性が増し、技術的負債となって大きな問題になっていく。結果として安くはならず、ローコード開発のメリットであるメンテナンス性までも損なうため、トータルで考えると高くなる。

まとめ

お客様の予算内で考えないといけないので、といった口癖があれば注意が必要である。クライアントの言いなり状態であれば、無理な要求は開発における仕様だけではないだろう。金額を含めた総合的な判断ができる人が、結果としてローコード開発を選択するわけである。

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

要件定義の基本

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

規模別の要件定義

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

要件定義の本質

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

対話型要件定義

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

まとめ

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