見出し画像

60代のリアル|第2幕、第14話【実録・無謀な事務仕事】理想のシステムはどこへ?「ノーコード」という選択と忍び寄る綻び


前回までのあらすじ

2027年の本番リリースに向け、ようやく要件定義の期間を終えた大型システム刷新プロジェクト。社内にはどこか安堵の雰囲気が漂う中、発表された開発スタイルは「アジャイル+プロトタイピング」という手法でした。

外部委託で進めるなら、途中で何度も確認や見直しを重ねる「スパイラル開発」というやり方のほうが、途中の確認作業は増えても、最終的に私たちが「本当に想像していた通りの、現場で使いやすいシステム」になるのではないかと思っていた私。

長年現場で仕事をしてきた実感があるからこそ、この進め方に一抹の不安を覚え、晴れやかな社内の空気とは裏腹に一人静かに胸騒ぎを覚えていました。



開発スピードの裏側——「ノーコード」という選択

2027年夏というターゲットに向けて、なぜこれほどまでに早いスケジューリングが可能なのか。その疑問に対する答えは、意外なところから明らかになりました。

今回の開発では、エンジニアが一からプログラミングのコードを書き上げるのではなく、あらかじめ用意された部品を組み合わせてシステムを構築する「ノーコード(No-code)開発」を採用する、という方針が示されたのです。

「だから、こんなにも素早い展開が可能なのか」

開発スピードの理由を聞かされ、一度はなるほどと納得しました。従来の開発プロセスに比べて大幅に時間を短縮できる手法だからこそ、会社はこのタイトなスケジュールを提示できたのでしょう。

しかし、納得と同時に、私の中にはうっすらとした疑問と不安が首をもたげました。

ノーコード開発は迅速な立ち上げに優れている反面、あらかじめ決められた枠組みの中でしかカスタマイズが効かないケースも少なくありません。

多種多様で複雑な業務を抱える私たちの現場において、その「枠」の中に収まりきるのだろうか?

現場の細かい運用や例外的な処理に、果たしてどこまで耐えられるシステムができるのだろうか——。

スピード感を重視する会社側の目論見を理解しつつも、手放しでは喜べない小さな引っかかりが、胸の奥に残ったままでした。


※ 【補足:ノーコード開発とプログラミング(コーディング)の違い】

★ プログラムをコーディングして作成する場合
 職人さんが一から木材を切り出して、自由自在にオーダーメイドの
 家具を作るようなイメージです。

 作り込みに時間と費用はかかりますが、現場の複雑な業務に合わせて
 「ボタンひとつで何でも処理できる」ような、小回りの利く使いやすい
 システムを作ることができます。

★ ノーコード開発の場合
 あらかじめ用意された既製品のパーツ(引き出しや棚など)を買って
 きて、積み木のように画面上で組み立てていくイメージです。

 コードを書かないため短期間で形にできる反面、あらかじめ決まった
 パーツの組み合わせしかできないため、現場の複雑な動きに合わせ
 づらく、かえって操作の手数が増えてしまうといったデメリットも
 あります。



打ち合わせの日常化と、パートとしての距離感

2024年秋~

プロジェクトが本格始動し、基本設計のフェーズに入ると、社内では連日のように打ち合わせが繰り広げられるようになりました。会議室の予約表には開発関連の予定がずらりと並び、周囲はどこか慌ただしい熱気に包まれています。

しかし、前段階の要件定義の時とは異なり、そこに私の姿はありませんでした。

パートである私は打ち合わせのテーブルから外れ、決定事項や進捗報告を後から受けるという立場へとシフトしていたのです。

以前の要件定義のフェーズでは、毎回のように会議に引っ張り出され、現場の細かい動きや課題を説明するために神経をすり減らしていました。その怒涛の日々を思い返せば、会議の輪から外れたことは、私にとって正直なところ救いでもありました。

「これで、本来の自分の実務にしっかりと集中できる」

重責から解放されたような、肩の荷がふっと下りる安堵感を覚えていたのも事実です。

ノーコード開発に対するうっすらとした胸騒ぎは抱えつつも、
「ここからは社員の皆さんや開発側の領分」と割り切り、私は与えられた自分のデスクで、静かに日々の業務へと向き直っていました。



第一弾プロトタイプ検証——戸惑いと、募る違和感

2025年~

やがて開発側から第一弾となるプロトタイプが上がってきて、社内での検証作業がスタートしました。

私は勝手なイメージとして、システムの基本的な動作テストは開発業者側で行い、私たちはプロトタイプを使って画面の操作性を確かめたり、
「実際のデータを入力したときに今までとどう違うのか」
を擦り合わせながら理想に近づけていくのだろう、と思っていました。

しかし、実際に渡されたのは、検証項目とテストの指示がびっしりと書かれた仕様書でした。

使い方もまだよく分からない状態のまま、まずは恐る恐る画面を触ってみることからスタートしたのですが、テストを進めるにつれ、検証に参加していた正社員の方々から困惑の声が上がり始めました。

「要件定義の内容は、コンサルタント会社やうちのシステム担当者から開発会社へ、最初から改めて丁寧に説明していたはずなのに……」

議事録にもしっかりと記録が残り、何度も共有していたはずの内容が、基本設計の段階で記載漏れとなり、そのままプロトタイプから抜け落ちてしまっていたのです。

さらに、実際に画面を操作してみると、あらかじめ決められたノーコードの仕様に縛られているせいか、これまでは1回で済んでいた操作なのに何度も画面を切り替えたり、クリックを重ねたりしなければならない構造になっていました。

「擦り合わせをして現場に合うものにしていく」
という期待とは裏腹に、渡された手順をこなすことすら一苦労で、使えば使うほど
「今の古いシステムより明らかに使いづらいのでは」
という疑問が膨らんでいきます。

「あそこまで丁寧に重ねていた説明や打ち合わせは、一体何だったのだろう……」

会議の輪から一歩引いた立場だからこそ、私は浮き彫りになっていく溝を冷静に、そしてどこか冷や冷やとした思いで見つめていました。

「ノーコードで早く作る」という会社側の都合と、現場のリアルな運用。その2つが全くかみ合っていないという事実が、少しずつ、けれど確実に形となって姿を現し始めていたのです。



🌿次回予告

プロトタイプ検証によって露呈した、現場の運用とシステムの決定的なズレ。 「使いやすくするための刷新」のはずが、どこか噛み合わないまま刻一刻と時は流れていきます。

そして、プロジェクトを取り巻く空気は、思わぬ方向へと大きく変わり始めます。

当初掲げられていた「2027年夏」という絶対のゴール。 そのスケジュールに、静かに、しかし決定的な陰りが差し始めようとしていました——。

次回、「狂い始めた歯車と、見直しへのカウントダウン」

どうぞお楽しみに。


▼ 第15話はこちらです。



▼ 第2幕の最初から読みたい方はこちらからどうぞ


▼ 第1幕から読みたい方はこちらからどうぞ


いいなと思ったら応援しよう!