QCDの死角

失敗の正体

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

エンジニアの真実

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

成功の境界

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

コスパの本質

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

まとめ

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

関連記事

オフショア開発の変遷と現状

オフショア開発のコストダウン目的

オフショア開発における主要な目的は、プロジェクトの総コストを削減するために人件費を削減することです。日本の開発者の人件費が高いため、ベトナムの開発者と置き換えることで財務的なコストダウンを実現してきました。ただし、外国に発注するということは、品質の低さと言葉の壁という2つの問題がつねにつきまといます。

内部コストと労働者の負担

人件費の削減は財務上のコストダウン効果を直接的に実現しますが、品質の低さや言葉の壁といった問題は現場の労働時間や精神的な負担として現れる内部コストです。これらの内部コストは労働者に転嫁され、営業側が値引きを行い開発現場の労働に影響を与える仕組みとなっています。オフショア開発に対する開発現場からの評判の悪さは、このような直接的な感覚から生じていると考えられます。

品質の向上と言語の壁

品質の低さや言葉の壁は改善の兆しを見せています。20年前と比較すると、通信手段や開発ツールが進歩しました。チャットやビデオ会議、画面共有などの技術が利用できるようになりました。また、クラウドやソースコードの共有などの管理システムも進化しました。言語の壁も同様で、ベトナムにおける日本語の理解力や日本人における英語の能力は向上しています。さらに、機械翻訳の進歩により、外国語を交えながら技術的な会話が容易になりました。

品質と納期の重要性

オフショア開発において品質と納期は重要な要素です。納期を守り、仕様を満たすことが最終的な評価基準となります。優れた開発チームやツールの活用は重要ですが、納期の達成と仕様の達成が果たされなければ、プロジェクトは失敗となります。

新たなオフショア開発の戦略

オフショア開発におけるコストダウンの戦略は、技術の進歩を活用する方向に進んでいます。開発手法として、ウォーターフォール型ではなくジャイルやOSS的な手法を導入することが求められています。また、国際的な標準的なツールやバージョン管理などの利用も重要です。さらに、コミュニケーションの円滑化も不可欠です。言葉の問題だけでなく、コミュニケーションの円滑化は人間によって担保されます。

オフショア開発の変遷において、品質やコミュニケーションの改善は見られますが、人件費の差によるコストダウンは限界に近づいています。技術の進歩を取り入れた新たな戦略の導入により、より効果的なオフショア開発を実現することができるでしょう。

続きを見る >

ローコードとは何か

ローコード開発の基本

ローコード開発とは、従来のプログラミングで必要だった複雑なコード記述を大幅に削減し、視覚的なインターフェースを使ってアプリケーションを構築する開発手法である。ドラッグ&ドロップや設定画面を使って、まるでパズルのピースを組み合わせるように機能を実装できる。これにより、プログラミング経験が少ない人でも短期間でアプリケーションを作成することが可能になった。従来なら数か月かかっていた開発が、数週間で完成することも珍しくない。

注目される背景

現代企業が直面するデジタル変革(DX)の波により、業務システムの迅速な構築・改善が求められている。しかし、IT人材不足は深刻化しており、従来の開発手法では変化の速いビジネス要求に対応しきれない。また、コロナ禍を経てリモートワークが普及し、業務プロセスのデジタル化が急務となった。こうした背景から、非IT部門でもシステム開発に参加できるローコード開発が注目を集めている。市民開発者と呼ばれる現場担当者が直接システムを構築することで、真にビジネスニーズに合致したソリューションを素早く提供できるのである。

具体的なメリット

ローコード開発の最大のメリットは開発スピードの圧倒的な向上である。従来の開発では要件定義から運用まで半年以上かかっていたプロジェクトが、1〜2か月で完成する。また、専門的なプログラマーを雇用する必要がないため、人件費を大幅に削減できる。さらに、ビジネス要求の変化に応じて素早く修正・拡張が可能で、従来のシステムのように大規模な改修を必要としない。ユーザー自身が開発に関わることで、仕様の齟齬が生じにくく、より実用的なシステムが構築できる点も大きな魅力である。運用保守も簡単で、長期的なTCO削減にも貢献する。

導入時の注意点

ローコード開発を成功させるには、適切な用途の見極めが重要である。単純な業務アプリケーションや社内システムには最適だが、高度な処理や複雑なアルゴリズムが必要なシステムには向かない。また、開発者のスキルレベルに応じた段階的な導入が必要で、いきなり複雑なシステムから始めると失敗リスクが高まる。セキュリティやガバナンスの観点から、適切な開発ルールやレビュープロセスの確立も欠かせない。さらに、従来のIT部門との連携体制を構築し、技術的なサポート体制を整えることで、より効果的なローコード活用が実現できる。

まとめ

ローコード開発は、DX推進において極めて有効な手段である。開発スピードの向上、コスト削減、そして現場主導でのシステム構築を可能にする。ただし、適切な用途選択と段階的な導入アプローチが成功の鍵となる。企業の競争力向上のため、ローコード活用を検討してみてはいかがだろうか。

続きを見る >

SEのいうバッファとは

バッファの真意

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

不確実なバッファ

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

知識の不足

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

本質のバッファ

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

まとめ

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

続きを見る >