記事

QCDの死角

失敗の正体

システムの失敗は見えないことがある。ブラックボックスであるがゆえに隠せてしまうからである。失敗かどうかの線引きができないところがシステム構築プロジェクトの難しいところである。

エンジニアの真実

もしかしたら、エンジニアが都合の悪いことは隠していることがあるかもしれない。しかし、決めつけてしまうとエンジニアはへそを曲げてしまう可能性がある。隠しているつもりはなくても隠れていることもある。

成功の境界

失敗の線引きは、納期が遅れることであろうか。バグが多いということであろうか。実は、状況によって一概に言えないのである。QCDという言葉があるが、品質と費用と納期のバランスを上手にとったとしても成功か失敗か、すぐにはわからないのがシステムという無形物である。

コスパの本質

コスパという言葉があるが、かけるコストに対して、どれだけのパフォーマンスが出せるかが問題となる。システム開発では、コストからやりたいことを計算するのではなく、やりたいことを明確にしたうえで、コスト内でリッチ度合いを調節することが重要である。

まとめ

システム開発においては、失敗が見えにくいため、失敗しないように見えるのかもしれない。失敗しないことは、成功であるということでもない。時間が経つにつれて失敗を感じることもあり得るのである。

システム開発の混迷 前の記事 効率化の誤解 次の記事

関連記事

記事

要件定義のアプローチ

要件定義の基本

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

規模別の要件定義

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

要件定義の本質

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

対話型要件定義

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

まとめ

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

続きを見る >
記事

デジタル化の誤解：効率化の落とし穴

デジタル化は効率化を保証しない

デジタル化と聞くと、多くの人が効率化を期待する。しかし、たとえばFAXで受け取った紙の受注をOCR（文字認識）でデジタルデータ化し、データベースに保存しても、それは単なるデジタル化に過ぎない。デジタル化を行うだけでは本質的な効率向上は望めず、業務フローの見直しがなければ効果は限定的だ。

非効率なフローをそのままデジタル化するリスク

最も大きな問題は、業務フローを見直さずにデジタル化を行うことだ。従来の手作業のフローをそのままデジタル化すれば、かえって作業が煩雑化し、時間がかかることもある。特にITに疎い権限者が意思決定を行う場合、このような失敗はよく見られる。「デジタル化＝効率化」と誤解し、実際には逆効果となるケースも少なくない。

俯瞰できないシステム担当者の問題

システム担当者やシステム会社が、俯瞰的な視点を持たない場合も問題だ。業務フローを把握せず、指示通りにデジタル化を進めれば、非効率なシステムが出来上がる。ユーザー部門は「IT化で逆に効率が悪くなった」と感じ、最悪の場合、システムが欠陥品だと誤解されることもある。業務の流れを把握し、適切にデジタル化を進めることが必要だ。

生成AI導入の失敗例

生成AIの導入に関する相談も増えているが、その多くは「期待通りに動かない」という内容だ。その原因は、多くの場合、AIが本来必要ない箇所に導入されていることだ。たとえば、ただのデータ管理であれば、生成AIではなくRDB（リレーショナルデータベース）のほうが合理的だ。効率を上げるには、AIの利用が本当に適切かを見極める判断力が必要だ。

まとめ

「ITが分からないから任せる」という姿勢はリスクが高い。ITを知らない人がIT化を進めるのは、決算書を読めないのに経営をするのと同じだ。業務フローを理解し、技術を正しく活用するには横断的な視点と経験が不可欠だ。

続きを見る >
記事

野良アプリは排除すべきか？

「便利」の裏にある現場IT

シャドーITとは、企業の情報システム部門が認知・管理していない状態で、現場の判断によって導入・利用されるIT資源を指す。具体例としては、LINEやGoogleドライブ、Excelマクロなど、日常業務の中で自然発生的に使われるツールが挙げられる。これは企業としての統制外にある一方、現場の即応性や利便性を追求した工夫の結果でもあり、単なるルール違反と一括りにはできない。ゆえに、これを「排除すべき野良アプリ」として扱うことが妥当かどうか、慎重な見極めが必要である。

IT部門を飛び越える理由

現場がシャドーITを使う背景には、既存システムの使い勝手の悪さや、IT部門の対応の遅さといった事情がある。業務は待ってくれない以上、迅速な判断や情報共有のために、現場が自ら使いやすいツールを選ぶのは自然な流れである。たとえば、社内の共有フォルダではなくGoogleドライブを使ったり、煩雑な申請フローをExcelマクロで簡素化したりといった工夫は、業務効率の向上に寄与している。現場がスピードと柔軟性を求める限り、IT部門の枠組みに収まらないツール活用は今後も続くはずだ。

シャドーITのリスク

便利な一方で、シャドーITには深刻なリスクも存在する。まず、セキュリティが担保されていないツールの使用は、情報漏洩やマルウェア感染といったリスクを高める。また、IT部門の管理外にあるため、データの一元管理ができず、連携の取れないシステムが乱立することで、かえって非効率になることもある。最悪の場合、コンプライアンス違反や内部統制の崩壊を引き起こす可能性も否定できない。利便性の裏には常にリスクが潜んでいるという現実を直視する必要がある。

市民開発と再定義

ただし、シャドーITの存在は、現場が自らITを活用しようとする前向きな姿勢の表れでもある。近年ではDXの進展に伴い、「市民開発」や「ローコード開発」など、現場主導のIT活用が注目を集めている。従来は否定されてきたシャドーITも、企業変革の一端を担う可能性を秘めている。IT部門がすべてを統制するのではなく、現場と協力しつつガバナンスを効かせる視点に立てば、シャドーITは排除すべき“野良”ではなく、むしろ育てるべき“創造”として再定義できるはずだ。

まとめ

現場の柔軟性と全社最適を両立させるには、両者を理解した経営の舵取りが欠かせない。「排除」ではなく「共存」の設計に踏み出すことこそが、企業のDXを推進するための鍵となる。

続きを見る >