QCDの死角

失敗の正体

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

エンジニアの真実

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

成功の境界

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

コスパの本質

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

まとめ

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

関連記事

ローコード導入判断基準

ローコード導入の必要性

近年、企業のデジタル変革(DX)において、ローコードプラットフォームの活用が急速に広がっている。従来の開発手法では時間とコストがかかりすぎ、変化の激しいビジネス環境に対応できないという課題が深刻化しているためである。特に日本企業では、IT人材不足が深刻な問題となっており、限られたリソースで最大の成果を上げる必要がある。このような背景から、ローコード開発は単なる開発手法の一つではなく、企業存続のための戦略的選択肢として注目されているのである。

導入メリット

ローコード導入により得られる最大のメリットは、開発期間の大幅な短縮である。従来のプログラミングで数ヶ月かかっていたアプリケーション開発が、数週間で完了できる事例が数多く報告されている。また、専門的なプログラミング知識を持たない業務部門の担当者でも、簡単なアプリケーションを自ら構築できるため、IT部門の負担軽減にもつながる。さらに、クラウドベースのプラットフォームが多いため、インフラ構築コストも削減でき、総所有コスト(TCO)の観点からも非常に魅力的な選択肢となっている。これらの要素が組み合わさることで、企業の競争力強化に直結する効果が期待できる。

導入判断の観点

一方で、すべてのプロジェクトにローコードが適しているわけではない。導入判断には慎重な検討が必要である。まず、プロジェクトの複雑性を評価する必要がある。単純な業務アプリケーションや社内ツールには適しているが、高度なセキュリティが求められるシステムや、大量のデータ処理を行うシステムでは従来の開発手法が望ましい場合もある。また、既存システムとの連携要件や、将来的な拡張性も重要な判断要素となる。組織の技術的成熟度や、ガバナンス体制の整備状況も考慮すべきポイントである。これらの観点を総合的に評価することで、適切な導入判断が可能になる。

成功のアプローチ

ローコード導入を成功させるには、段階的なアプローチが重要である。まずは小規模なパイロットプロジェクトから始め、組織の学習とプラットフォームの理解を深めることを推奨する。同時に、適切なガバナンス体制の構築と、セキュリティポリシーの策定も不可欠である。また、従来の開発チームとローコード開発チームの連携体制を整備し、知識の共有と技術的サポートを確保することが成功の鍵となる。さらに、継続的な教育プログラムの実施により、組織全体の技術力向上を図ることで、長期的な成功を実現できる。これらの取り組みにより、DXの目標達成により近づくことができるだろう。

まとめ

DXプロジェクトにおけるローコード導入は、適切な判断基準と実践的なアプローチにより大きな成果をもたらす。開発スピード、コスト効率、技術者不足への対応という観点から、多くの企業にとって有効な選択肢となっている。成功の鍵は段階的導入と適切なガバナンス体制の構築にある。

続きを見る >

オオカミ少年化の弊害

SE常駐の負連鎖

システム開発会社側の立場からすると、時間ばかり取るよくないクライアントはできるだけ減らさないと、他の優良クライアントに迷惑がかかる。特に横にいてくれないと進めることができないというニーズが、SE常駐の常態化してしまっている要因である。

常駐要請の心理

SEへの安心感の欠如が常駐しないといけない理由のひとつである。隣にいれば、何かあった時にすぐに指示が出せる。たとえば、サーバが止まったときにすぐに復旧させることが可能である。

対症療法の克服

隣にSEを常駐させて対応できてしまうがゆえに対処療法になってしまいがちである。本来であれば、サーバが止まらないようにすべきであり、リカバリのプランがしっかりと計画されていることが理想である。

脱属人化の施策

SE側も、すぐに復旧させられるからといった怠慢により、事前に問題や対策を考えておくといった準備を怠ってしまう。そう考えると、発注側のITリテラシーも非常に重要である。属人化しないように仕組化するにはどうするかを常に整理する意識を持つことが大切である。

まとめ

発注側は感情だけでプロジェクトを遂行すると、何かあった時に何でもSEを急かしてしまう。これによって、発注側はオオカミ少年化してしまうため、本当に急がないといけないときに対応が遅れてしまうのである。

続きを見る >

フルスクラッチは体力

開発手法の選択

フルスクラッチかパッケージか、最近ではSaaSなどもシステム構築の検討に入る。実は開発手法やツールよりも、どのようなシステムで、どれくらいの規模のシステム開発会社が担当するかが重要である。

SESのリスク

人数が多い会社であればあるほど安心感があってよいと安易に考えることは適切ではない。なぜなら、SE派遣やSESと呼ばれる人月(人工)単位で売り上げの経つ会社には技術の総合力がないからである。

技術の総合力

技術の総合力とは、SE作業やプログラミング作業などの1人で対応できる技術力を差すのではなく、システム構築やシステムの運用全般における最適手段を考えることができる能力のことである。

表層の即効性

SE派遣やSESの付加価値はその人単体のプログラミング能力に偏るため、一見対応がよく、何も問題がないように思える。しかし、これが技術的負債を作ってしまうひとつの要因でもある。

まとめ

フルスクラッチを考えるなら、SESを中心としないシステム会社で且つ人数規模も多い方がよい。安価にフルスクラッチでシステムを構築してしまうと、メンテナンスや運用でしっぺ返しが待っている。時間が経つごとにシステム保守費用が高くなるのである。

続きを見る >