QCDの死角

失敗の正体

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

エンジニアの真実

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

成功の境界

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

コスパの本質

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

まとめ

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

関連記事

運用の昇華

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

続きを見る >

オオカミ少年化の弊害

SE常駐の負連鎖

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

常駐要請の心理

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

対症療法の克服

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

脱属人化の施策

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

まとめ

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

続きを見る >

開発の遅延「技術的にはできます」の罠

素人仕様と開発遅延

なぜ、システム開発の進捗が悪いのか?
それは、ずばり素人が考えた仕様を開発者に伝えてしまうからである。
すべての原因ではないが、もしシステムのユーザー側の現場担当者や営業担当者がシステム仕様を決めている場合は、ほとんどの場合で満足のいくスピード感はだせていない。

潜む技術的負債

システム仕様さえ伝えていれば、きちんと動くものを作ってくれるので、あとはスピードを上げるだけ。と考えているようであれば、技術的負債が溜まっていることに気付けていない。非エンジニアが決して理解できない技術的負債の怖さは、開発スピードが遅いということだけではない。開発者側から見てシステムが複雑になっていて、メンテナンス性も低い状態になっている。

「できます」の罠

非エンジニアには技術的負債は見えないし説明もわからないことと思う。しかし、技術力でカバーしてくれているから、きちんと動いているのだと思っているなら、それは実は技術力ではない。
「技術的にはできます」このような言葉を聞いたことはないか?
システムエンジニアは「できない」と言えない。「できないことはない」ということが価値なので、素人が考えたシステム仕様でも、言われた通りに作ってしまう。

持続可能な開発へ

システムエンジニアから「技術的にはできます」を聞いたときは、いったん立ち止まるべきである。
エンジニアには、様々な影響範囲や未来のメンテナンス性への懸念などが見えている。これを必要以上のコストだと考えるのか、必要コストと考えるのかで、技術的負債は変わる。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言える。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いが、業務に関する知識は乏しい。
システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきだが、そんな万能な人は多くはない。だから、その間を取り持つ人間が重要なのである。

続きを見る >