システムは「作る前」に8割決まっているという話

はじめに

「とりあえず作ってみましょうか」

この言葉は、前向きで、スピード感もあって、

一見すると正解に見えます。

ですが、システム開発の現場に長くいると、

この一言があとから一番高くつく場面を何度も見てきました。

• 作ったのに使われない
• 修正が止まらない
• 何のためのシステムか分からなくなる

こうした問題は、

作ってから起きたように見えて、

実はほとんどが「作る前」に決まっています。

よくある「失敗プロジェクト」の空気

使われなくなるシステムには、

驚くほど共通した空気があります。

• 誰のためのものか曖昧
• 現場と管理側で期待がズレている
• 「もう作っちゃったから」という諦め

誰かが悪いわけではありません。

むしろ、全員が真面目です。

ただ、

作る前に立ち止まる時間がなかった。

それだけで、

プロジェクトは少しずつ歪んでいきます。

「作りながら考える」は万能ではない

最近は、

「まず作って、走りながら考える」

という考え方が広く知られるようになりました。

このアプローチ自体は、間違っていません。

ただし、成立する条件があります。

• 何を検証するかが決まっている
• 小さく作っている
• 失敗しても戻れる

これがないままの

「とりあえず作る」は、

単なる行き当たりばったりです。

現場では、

修正の積み重ね＝改善だと思い込んでしまう。

でも実際には、方向が合っていないことが多い。

「作る前」に8割が決まる理由

では、作る前に何が決まっているのか。

tugiloが特に重視しているのは、次の3つです。

① 誰の、どの仕事を楽にしたいのか

「現場のため」「みんなのため」

この言葉では、何も決まりません。

• どの部署か
• どの作業か
• どの瞬間が一番しんどいのか

ここまで具体化できると、

システムの輪郭は一気にはっきりします。

逆に、ここが曖昧なまま作ると、

誰のためか分からないシステムになります。

② 何を変えて、何を変えないのか

システム導入＝全部変える、ではありません。

• 今のやり方でうまくいっている部分
• 無理に変えると混乱する部分
• 人がやったほうが早い部分

これを決めずに作ると、

現場はこう感じます。

「また新しいルールが増えた」

この瞬間、

システムは"外から来たもの"になります。

③ 失敗したときに戻れるか

どれだけ考えても、

システムは一発で正解にはなりません。

だからこそ、

• 元の運用に戻せるか
• 並行運用できるか
• 小さく試せるか

この設計が、作る前に決まっているかどうかが重要です。

戻れないシステムは、

現場を黙らせます。

要件定義より前にやるべきこと

「要件定義をしっかりやりましょう」

これは正しい。

ただ、tugiloでは

その前に必ずやることがあります。

• 現場の話を聞く
• 業務を紙に書き出す
• なぜ困っているのかを掘る

この時間を飛ばして要件定義をしても、

綺麗な資料はできますが、

使われるシステムにはなりません。

「作らない判断」も立派な設計

もう一つ、大切な話があります。

システム開発では、

作らないという判断も設計の一部です。

• それは運用で解決できないか
• ルールを変えたほうが早くないか
• 人がやったほうが安心ではないか

この判断をせずに作ると、

システムは"目的のない箱"になります。

作り始めると、引き返せなくなる

システムは、作り始めると、

• お金が動く
• 期待が生まれる
• 「やめる」が言いづらくなる

だからこそ、

本当に考えられるのは作る前だけです。

この時間をどう使うかで、

プロジェクトの8割は決まります。

それでも「作る」ことが悪いわけではない

誤解してほしくないのは、

作ること自体が悪いわけではない、ということです。

問題は、

• 何のために作るのか
• どこまで作るのか
• どう育てるのか

これを決めずに作ること。

作る前に考える時間は、

遠回りに見えて、一番の近道です。

まとめ

システムは、

作る前に8割決まっています。

• 誰のためか
• 何を変えるか
• どう戻れるか

この3つが整理されていれば、

システムは現場に馴染みます。

逆に、

ここを飛ばすと、

完成しても使われません。

関連記事

• AI導入がうまくいっている会社は「AIの話」をしていない
• ChatGPTを全社導入して失敗する会社、1業務だけで成功する会社
• 業務改善が進まない会社に共通する「ちゃんとしすぎ問題」
• AIに任せてはいけない仕事、任せたほうがいい仕事の見分け方