記事

要件定義の問題点

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。

AIで何ができるのか 前の記事 開発費用値下げの危険性 次の記事

関連記事

記事

SEのいうバッファとは

バッファの真意

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

不確実なバッファ

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

知識の不足

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

本質のバッファ

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

まとめ

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

続きを見る >
記事

ノーコード・ローコード比較

新たな開発手法

近年、ビジネスのデジタル化が加速する中で、ノーコード・ローコードツールが注目を集めている。従来のシステム開発では専門的なプログラミング知識が必須だったが、これらのツールを使えば、非エンジニアでも直感的な操作でアプリケーションやWebサイトを構築できる。開発期間の短縮やコスト削減が可能になることから、スタートアップから大企業まで幅広く導入が進んでいる。

主要ツール

ノーコードツールの代表例としては、Webサイト構築に強いBubbleやWebflow、業務アプリ開発に適したKintoneやAppSheet、自動化に特化したZapierなどがある。Bubbleは柔軟性が高く複雑な機能も実装可能だが、学習コストはやや高めである。Webflowはデザイン性に優れ、マーケティングサイトに最適だ。Kintoneはデータベース管理に優れ、日本企業での導入実績が豊富で、承認フローなど日本の業務習慣に対応している。一方、ローコードツールではMicrosoft Power AppsがOffice 365との連携に強く、OutSystemsは大規模エンタープライズ向けで基幹システム開発にも対応可能である。料金体系も月額制からユーザー課金制まで多様で、自社の規模に合わせた選択ができる。

両者の違い

ノーコードとローコードの最大の違いは、カスタマイズ性と技術的な介入度である。ノーコードは完全にコード記述なしで開発できる反面、複雑な要件には対応しきれない場合がある。ローコードは基本的な部分は視覚的に構築しつつ、必要に応じてコードを追加できるため、より高度な機能実装が可能だ。選択時のポイントは、開発したいシステムの複雑さ、既存システムとの連携要件、将来的な拡張性、そして社内の技術リソースである。シンプルな業務アプリならノーコード、基幹システム連携が必要ならローコードが適している。

導入のポイント

ノーコード・ローコードツールの導入を成功させるには、いくつかの注意点がある。まず、無料プランで試用し、実際の業務フローに合うか検証することが重要だ。また、ベンダーロックインのリスクを考慮し、データのエクスポート機能やAPI連携の可否を確認すべきである。セキュリティ要件も見逃せない。特に顧客情報を扱う場合は、各ツールのセキュリティ認証やデータ保存場所を確認する必要がある。さらに、導入後の運用体制も計画的に整備し、社内でのツール活用スキルを育成することが、長期的な成功につながる。

まとめ

ノーコード・ローコードツールは、企業のDX推進を加速させる強力な手段である。適切なツールを選定し、自社の課題に合わせて活用することで、開発コストを抑えながらスピーディーにシステムを構築できる。まずは小規模なプロジェクトから始め、成功体験を積み重ねながら展開していくことを勧める。デジタル化の第一歩として、ぜひ検討すべきだろう。

続きを見る >
記事

予算ブレの原因

開発の変動要因

システム開発は長期にわたることが多く、また未来の不確実性の中で予算を策定しなくてはいけないことがある。セキュリティーをはじめ動作環境の変化や人員の欠如、予期していなかった仕様の発覚などが原因だ。

目標変化と予算

進捗率は目的地が明確に設定されていれば数字を負うことで予算達成率を算出することができる。しかし、目的地が近い遠いのは無しではなく、根本的な目的地がなくなったり、複数になったりすることがシステム予算の策定の難しいところである。

計画型開発法

システムに未来を見ることができればブレない、見えないことをすべて調査の上で着手できれば確実な予算と実行が可能である。進捗率の報告が可能になる。フォーターフォールモデルなのでコストがかかることと時間がかかることの覚悟が必要だ。途中での方向修正は原則できない。

柔軟な開発手法

逆に低予算で早く導入するなら、見えにくくなるデメリットがある。状況によって対応を素早く変化させる必要があるため進捗率を算出しにくい。アジャイル開発と呼ばれるものであり、社内開発であることが理想である。途中で出てくる条件に対しても柔軟に方向性を変化させることが可能である。

まとめ

アジャイル開発で予算を立てるときは、1.5-2.5倍くらいを目安に余裕を持って設定することを推奨する。

続きを見る >