CHAPTER 01
会社員として、月70時間の残業現場にいた。
もとは会社員でした。月70時間を超える無賃残業、雑務に追われて本来の仕事が満足にできない日々。心を病んでいく同僚を、いくつも見送りました。
現場の実情を捉えきれない経営施策と、最前線の人たちを大切にしない仕組み。違和感はやがて、確かな怒りに変わっていきました。
「最前線の人が報われない仕組みを、誰かが作り直さないといけない。」
01ストーリー
なぜ「改善」にこだわるのか
弊社代表の原体験から、現在の「デモ先行開発」というスタイルに至るまでの記録です。
CHAPTER 02
「一人DX」から始めた、自分への弔い合戦。
残業地獄から抜け出すため、独学でプログラムを書き始めました。最初はExcelとちょっとしたスクリプト。それでも同僚が驚くほど時間が浮き、頼られるようになるうちに、「改善欲」が止まらなくなりました。
苦手な人でも楽に使えるように。操作工数を、シンプルに。スマホでも、タブレットでも。── このとき染み込んだ三つの基準が、いまも私たちの設計原則です。
CHAPTER 03
会社を辞め、IT現場へ。副業も含めて何十社の改善を。
会社を辞めてプログラマーに転身。本業と並行して副業でも業務改善案件を引き受け、結果として何十社もの現場に関わりました。
そこで見えてきたのは、業界の構造的な問題。営業、要件定義、プログラマーがバラバラに動き、改善への思想や熱量がずれたまま、成果物もそのままずれていく。── ミーティングと仕様書だけでは、「理想像」は絶対に共有できない、と確信しました。
「思想と熱量がずれたまま、成果物だけ揃うはずがない。」
CHAPTER 04
動くデモを見せたら、すべてが変わった。
試行錯誤の末にたどり着いたのが、契約前に動くデモを“内見”していただく「デモ先行開発」でした。
納得感がまるで違う。理想像が事前に見える分、納品物とのズレが起きない。ミーティングも開発もスムーズに進み、お客様も、私たち作り手も、ストレスがほとんど消えました。
営業・要件定義・実装を一人で貫くことで、思想と熱量のズレもゼロに。これが、改善マニアのやり方になりました。
CHAPTER 05
人の時間に、余白を作る。
「改善マニア」という社名は、ただのコンサルやSIerとは違う、マニアを名乗るほどの本気のコミットメント表明です。
同業者から「やりすぎでは？」と言われるくらい、使い手の立場に立った利便性にこだわる。システムの都合に人を合わせるのではなく、人の都合にシステムを合わせる。
そうして空いた時間を、本来やるべき仕事と、人生のための余白に変えていく。── それが、私たちが業務改善を続けている理由です。
「人の時間に、余白を作る。」
── 私たちが日々の仕事で大事にしている姿勢は、次の3つの行動規範にまとめています。
