記事

要件定義の問題点

はじめに

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

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

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

要件定義の丸投げ

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

無理な受注

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

人材紹介会社の利益構造

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

エンジニアの責任範囲

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

発注側の保身

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

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

関連記事

記事

SEのいうバッファとは

バッファの真意

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

不確実なバッファ

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

知識の不足

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

本質のバッファ

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

まとめ

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

続きを見る >
記事

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

新たな開発手法

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

主要ツール

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

両者の違い

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

導入のポイント

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

まとめ

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

続きを見る >
記事

開発の相場

相場の不在

フルスクラッチでのシステム開発に相場はない。相場とは商品が一般的に流通している商品など数が多い場合は、競争原理も働き、金額がある一定の範囲に収まってくるものである。

建築との差異

たとえば、一戸建て建築であれば、建物の規模と資材、それに加えて職人の人工で金額が決まる。フルスクラッチのシステム開発は、つまり極めて特殊な特注品を作るようなものであるため、システム開発に相場という概念が基本的にはないのである。

人件費の実態

システム（ソフトウェア）は一戸建てのように、基本的には材料費はかからない。システム開発の費用のほとんどは人件費である。大工職人の人工と同じように人月単価と呼ばれるSE1人が1ヶ月働く金額で相場を知ることができるのである。

工期の変動

建物を建てることと比べるとシステムやソフトウェアは無形の物となるため、1ヶ月の労働力を推し量ることは困難である。個人のプログラミングの早さによって、納期が早くなったり遅くなったりするのである。

まとめ

SEは過去のプロジェクト参画実績から、同じようなプロジェクトに何度も参画していれば手練れでスキルが高いと評価される。システムに関わる人材の評価が困難な点は、プロジェクトに参画する経験値と、本当の意味でのスキルが比例するわけではないことである。本当の意味でのスキルとはプロジェクトを成功させられるかどうかを指すのである。

続きを見る >