株式会社K.Platinum 清水洋太
「新しい管理システムを導入したい」
そう相談をいただいた案件で、私たちが最初にお伝えした答えは「まだ作らないほうがいいと思います」でした。結果として、その会社の残業は新システムなしで減りました。
エンジニアとして働いていると、「要件はこうです。あとはお願いします」という入り方の仕事に何度も出会います。決まったものを、決まったとおりに作る。もちろん大切な仕事です。ただ、しばらく続けているうちに、こんな疑問が湧いてきませんか。
「そもそも、この機能って本当に必要なんだろうか」
弊社のプロジェクトは、その疑問から始まることが少なくありません。今日は、K.Platinumのエンジニアが顧客の現場でやっている「業務整理」という仕事についてお話しします。派手さはありませんが、私たちがいちばん面白いと思っている工程です。
「システムを入れれば解決する」とは限らない
弊社はITコンサルティングを主軸に、提案活動から課題改善、システム開発、リリースまでを一気通貫で支援しています。この「提案活動から入る」というのが、実はかなり効いています。
よくある構図として、業務コンサルの会社は戦略や提案までを担当し、システム会社は決まった要件を開発する、という分業があります。この分業自体が悪いわけではないのですが、あいだに落ちるものがあります。「現場で本当に何が起きているか」という情報です。
提案の場でお客様がおっしゃる課題は、たいてい「症状」です。「月次の集計に時間がかかる」「担当者しか分からない作業がある」「二重入力が多い」。これらは確かに困りごとですが、そのままシステム要件に翻訳してしまうと、たいてい高くつきます。集計が遅いからといって集計システムを作っても、そもそも入力の仕方が人によってバラバラなら、根っこは何も変わらないからです。
現場で聞ける情報は、資料には載りません。「この項目、実は誰も見ていないんです」「この承認は形だけで、実際は電話で先に確認しています」。こうした一言が、要件を半分に減らすこともあります。逆に、資料に一行も書かれていない例外処理が、月末に全員を残業させている原因だったりもします。
だから私たちは、いきなり設計に入りません。まず現場に行って（あるいはオンラインでつないで）、担当者の一日を見せてもらいます。どのファイルを開き、どこからどこへ数字を写し、何を判断しているのか。この段階でエンジニアが同席することに、大きな意味があります。業務の話を聞きながら「それは自動化できます」「それは仕組みを変えたほうが早いです」と、その場で技術的な当たりをつけられるからです。
実際にやっていること：一日の動きを、付箋で一本の線に並べ直す
ある製造業のお客様の話をします（守秘の都合で、内容はぼかしてお伝えします）。
ご相談の入口は「特定業務の工数が超過していて、残業が減らない」というものでした。当初、社内では新しい管理システムの導入が検討されていました。金額にすると、それなりの投資です。
私たちがまずやったのは、担当者数名にヒアリングをして、業務の流れを一本の線に並べ直すことでした。誰が、いつ、何をトリガーに、どの作業を始めるのか。手を動かしている時間と、待っている時間を分けて書き出す。付箋を並べるような、本当に地味な作業です。
ヒアリングで意識しているのは、「何にお困りですか」と漠然と聞かないことです。先に業務の始まりと終わりだけを紙に書いておき、「この間を教えてください」とお願いする。範囲を区切ると、相手も答えやすくなります。この進め方は、業務フロー作成のセオリーとしてもよく紹介されています。
すると、時間の大半を食っていたのは、システムがないことではありませんでした。同じ内容を複数の形式に転記していた工程と、後工程の担当者が前工程の完了を待っている時間でした。前者は既存ファイルの様式を揃えてマクロを組めば片付き、後者は作業の順番と受け渡しのルールを変えるだけで解消できるものでした。
結果として、このときはまず新しいシステムを作らずに改善を実施しました。工数は目に見えて下がり、そのうえで「では本当に仕組みとして持つべきものは何か」を、あらためて一緒に考えることになりました。
この案件で印象に残っているのは、整理を進めるうちにお客様側の担当者の方が、こちらより先に改善案を出してくださるようになったことです。流れが目に見える形になると、いちばん詳しい人はやはり現場の方なので、当然といえば当然かもしれません。私たちの役割は、答えを出すことよりも、答えが出せる状態に情報を並べ直すことなのだと実感しました。
こう書くと「システム会社なのに開発しなくていいのか」と思われるかもしれません。でも、順番を守ったほうが結果的に良いものが作れる、というのが私たちの実感です。整理されていない業務をそのまま写し取ったシステムは、使われないまま残ります。
こういう現場、面白そうだと思いましたか？
K.Platinumでは、要件を受け取るところではなく、要件が生まれる場所から関わるエンジニアを募集しています。
→ エンジニア募集中！仕事の進め方と条件を見る
この仕事で身につくもの：陳腐化しない「分解する力」
ここまで読んで、「それはエンジニアの仕事なのか？」と感じた方もいるかもしれません。私は、これ以上ないくらいエンジニアの仕事だと思っています。
業務整理をやると、要件定義の解像度が変わります。「なぜこの機能が必要か」を自分の言葉で説明できる状態で設計に入れるので、仕様の揺れが減り、手戻りが減ります。要件定義では「実現すること」だけでなく「実現しないこと」を決めるのが肝心だとよく言われますが、業務の流れが見えていないと、この「やらない」の線引きが感覚論になります。お客様と議論するときも、機能の話ではなく目的の話ができる。これは一度体験すると戻れません。
もうひとつ変わるのが、技術の選び方です。業務の制約を分かっていると、「ここは多少泥臭くても確実に動く方法でいい」「ここは将来まちがいなく変わるから、変更しやすい作りにしておく」といった判断が、自分の中で根拠を持ってできるようになります。流行っているからその技術を選ぶ、ということがなくなります。
そして、この経験は積み上がります。転記・待ち・属人化といった詰まり方は業界をまたいで似ているので、一度「流れを分解する」感覚を掴むと、次の案件で立ち上がりが早くなります。技術スタックの知識と違って、陳腐化しにくい資産です。
弊社では、入社してすぐの方にいきなり「一人で現場を整理してこい」とは言いません。まずは先輩と一緒に議事を取り、業務フローを起こすところから入ってもらいます。そこから提案書づくり、設計、開発、リリースまで、同じ案件のなかで工程をまたいで関わっていく。担当領域が縦割りではないので、「上流だけ」「実装だけ」で止まらないのが特徴です。
整理したあとは、ちゃんと作る ── 「作らない」と言えるのは、作れるから
念のため補足すると、私たちは「整理して終わり」の会社ではありません。むしろ、自社で開発まで対応できることが業務整理を成り立たせています。
「それはシステム化したほうがいい」と判断したとき、その場で実現方法とおおよその規模感を提示できる。逆に「これは作らないほうがいい」と言えるのも、作る側のコストを分かっているからです。業務・IT・マネジメントの三位一体で、業務整理から業務改善、システム化、AI導入まで一貫して見られること。これが弊社の強みだと考えています。
開発の進め方も、ここ数年で大きく変わりました。設計ドキュメントの下書き、コード生成、レビューの一次チェックといった工程では生成AIを積極的に使っていて、以前と比べて手を動かすスピードは何倍にもなっています。だからこそ、空いた時間を「何を作るべきか」を考えることに使えるようになりました。ツールが進化するほど、業務を理解している人の価値は上がっていくと感じています。
おわりに ── 「何を作るべきか」を、一緒に決める側へ
「言われたものを作る」から一歩出て、「何を作るべきかを一緒に決める」ところまで踏み込みたい。そう思っているエンジニアの方に、弊社の現場は面白いはずです。
必要なのは、特別な資格でも、コンサル経験でもありません。人の話をちゃんと聞けること。分からないことを分からないと言えること。そして、目の前の困りごとを「どうにかしたい」と思えること。技術は、そのための道具として存分に使ってもらえます。
原則リモート、フルフレックスで、働き方も柔軟です。ただ、いちばんお伝えしたいのは、ここには自分の担当範囲を自分で広げていける余地がある、ということです。少人数の会社なので、手を挙げれば任されます。
一緒に、現場の「その人の一日」を見に行ってくれる方をお待ちしています。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。