IT業界30年以上｜システム開発会社の経営者｜ベンチャー2社のIT担当役員を兼務し、発注側と開発側を同時に経験｜「頼んだ内容」と「できたシステム」がズレる理由を発信していきます｜YouTube「システム開発のリアル」
Joined October 2026
- Tweets115
- Following34
- Followers25
- Likes39
開発会社が「担当が替わったので、もう一度教えてください」はNG行動。お客様は担当者個人に発注したのではなく会社である。要望だけでなく、過去の提案や見送った理由も引き継ぐ。担当交代のたびに同じ説明や判断を求めないよう、社内で情報を共有しておくことが大切です。
発注者からの曖昧な依頼を、そのまま引き受けない。要件定義でも大切な姿勢。ただ「分かりません」と返すだけでなく、どこが不明かを整理し、例や選択肢を示して確認する。すぐに答えられないことは、調べる内容と回答期限を伝える。発注者の意図を具体化する工夫を、開発側からも示したいです。
会議に責任者が出席していても、承認が取れたとは限らない。システム開発の打ち合わせでは、「何を、誰に判断してもらうか」を明確にしておく必要がある。
例えば画面の確認でも、立場によって確認する内容は異なる。
① 現場の担当者には、業務が成立するか
必要な情報を確認できるか、入力できるか、例外処理にも対応できるか。実際に操作するユーザーの確認がなければ、想像で判断することになる。
② 業務の責任者には、部署をまたぐルール
営業と経理の要望がぶつかった場合、どう調整するか。開発者の判断だけで片方を採用せず、お客様側で調整する責任者を明確にする。
③ 決裁者には、予算と開発範囲
今回どこまで作り、何を次回に回すか。費用や納期に影響する選択は、その権限を持つ人に判断してもらう。
会議の最後には、決定事項、未決事項、次に回答する人と期限を確認する。議事録にも、個人の意見と正式な決定を区別して残す。
出席したこと、説明を聞いたこと、承認したことは、それぞれ別。その場で何が決まったのかを、参加者間で確認することが大切です。
開発案件を紹介していただいたときも、お客様だけでなく、紹介者の信用を預かっている。受注したら終わりではなく、差し支えない範囲で経過や結果を報告する。技術や価格に加え、こうした対応の積み重ねが、次も紹介したいと思ってもらえる信用につながりますね。
仕事をもらい続けるために絶対に必要なもの。
それは『筋を通すこと』。
この意味を全く理解しないまま独立し、消えていく奴は本当に多い。
「技術があれば仕事が取れる」
「安く出せば仕事がくる」
「誰から仕事をもらおうが自由」
一時的には、売上が立つこともある。
だが、田舎は特に横の繋がりの狭さや、情報の回るスピードは本当に早い。
意味の分かっていない奴は静かに、
「あいつは筋も道理も通せない奴」と認定され、その信用を取り戻すには、尋常じゃない時間と労力が掛かる。
「義理や人情」、「愛や恩義」を舐めた奴は、いずれその世界から静かに退場させられる。
最後に生き残るのは、常に『本当の意味で筋を通し続けれる者』だけです。
「いくらでも保存できます」は、発注者にとってうれしい話。確かにデータ自体の保存コストは非常に安くなった。しかし、データが増えれば管理の手間も増え、バックアップや運用にも費用がかかる。システムの提案は、想定するデータ量や保存期間、その場合の運用費用も示す。導入費だけで判断してもらうのではなく、使い続けるための費用まで説明することが大切です。
人の力を借りて乗り越える。経営者・管理者の大切な視点。仕事が増えても、できる人がすべて抱えれば、その人の時間が会社の限界になる。誰に何を任せ、どう支えるか。個人の頑張りだけに頼らず、チームで仕事をする。属人化しない状態をつくりたいです。
「仕事は、一番忙しい人間のところに集まる」
仕事を惹きつけたいなら、自ら限界の渦中に飛び込み、意地でも回し倒す奴の元にしか、デカい話も儲かる話も転がり込んではこない。
忙しい奴というのは、更に忙しくなる。
だが本物はそこで音を上げない。泥臭く知恵を絞り、プライドを捨て、人の力を借り、修羅場を意地でも乗り越えて行く。
その極限の摩擦によって初めて器が押し広げられ、さらに桁違いの仕事が舞い込んでくる。
そこから沢山の人に出会い、多くの人間を動かし、必然的により大きな資本が必要になり始める。
会社も事業も、そうやって膨大な重圧をねじ伏せながら巨大化していくものです。
「仕事に追われたぐらいで、一々被害者面をするな。自分から獲物を追うように仕事を追い回してみろ。その圧倒的な熱量と覚悟が全てを好転させ、替えの利かない一生の財産となる」
暇を貪る二流に成り下がるでない。
己の器を極限まで拡張し、押し寄せる荒波を乗りこなし、圧倒的な仕事量を惹き寄せてみろ。
15分かけて入力した内容が、戻るボタンで全部消えた。ユーザーは操作を間違えることもある。正しい手順だけのテストでは、こうした場面を見落とす。保存できるかだけでなく、誤操作で入力内容が失われないか、やり直しの負担を減らせるかも確認しておきたいです。
理論を省くのではなく、学ぶ順番を変える。エンジニアの育成でも、まず小さく作り、動く仕組みを調べる学び方はある。ただし「AIで動いた」で終わらせない。なぜ動くのか、変更するとどうなるのかまで確かめることで、理解につなげたいですね。
通知を増やしたのに、誰も対応しない。要件定義で「関係者へメール送信」とだけ決めていると、届いた後の業務が抜けてしまう。
例えば承認待ちの通知なら、次の4つを確認しておきたい。
① 誰が対応するか
情報を共有する人と、実際に承認する人を区別する。「関係者全員」に送るだけでは、誰が対応すべきか曖昧になる。
② 判断に必要な情報を確認できるか
通知を受けても、対象の申請を探し直すようでは手間が増える。通知から申請内容や判断に必要な情報を確認できるかを考える。
③ 対応されなかったらどうするか
いつまで待ち、期限を過ぎたら誰に再通知するか。担当者が不在の場合の代理も決めておく。
④ 対応状況を確認できるか
誰が対応中で、処理が完了しているかを確認できるようにする。重複対応や、処理済みの案件への再通知も防ぐ。
テストも「メールが届いた」で終わりではない。受け取った人が処理を完了できるか、対応されなかった場合に次の人へ引き継げるかまで確認する。
通知は業務を進めるための手段。送信機能だけでなく、通知後の対応まで含めて要件を定義することが大切です。
権限を厳しくした結果、現場で管理者アカウントを共有し始めた。担当業務を自分の権限で完了できなければ、別の方法に頼ることがある。権限表の確認だけでなく、各担当者が一連の業務を行えるかも検証する。制限を設けるだけでなく、業務が成立する権限設計が必要です。
エンジニアの独立でも、実績と信用は独立してから積み始めるものではない。技術力だけでなく、約束を守る、問題を早く伝える、最後まで対応する。「またこの人に頼みたい」と思ってもらえる仕事を、目の前の案件から積み重ねることが大切ですね。
本当に独立して成功したいなら、雇われの時に「伝説」をつくっておけ。
「独立したら本気を出す」
「今の会社は評価してくれないから独立する」
そう言って飛び出す奴の99%は、市場の荒波に飲まれて静かに消えている。
他人の金や看板を使わせてもらっている環境ですら圧倒的な結果を出せない奴が、何も無しから始まる荒野で勝てるわけがない。
雇われの枠をブチ破るレベルで伸し上がり、社内外に「伝説」と「揺るぎない信用」を残した人間だけが、独立した瞬間にロケットスタートを切れる。
守られた環境で無双できない奴に、サバイバルは不可能です。そして、ちょっと小金ができたら、すぐに道を逸れる。
本当の意味で自由を手に入れたいなら、まずは目の前の環境で圧倒的なテッペンを獲ってみろ。
顧客固有の業務に最適化したソフトが低価格で作れる未来。そのためには、何を作るべきかの要件定義が最も重要になることは間違いないです。手戻りの原因は、いつも実装より要件です。
私はSaaSを提供しているだけの企業は、今後徐々に競争力を失ってそれこそSaaS is Deadになると思ってますよ。
これは企業が既存のSaaSを自社開発で置き換えるという話ではなくて、新興企業が、顧客固有の業務プロセスに最適化されたソフトウェアを、従来の受託開発とは比較にならないほど低価格なイニシャルコストで、場合によってはSaaSに近い価格帯で提供するようになる未来が数年後来るでしょう。
そうなれば、顧客がわざわざ自社の業務を汎用SaaSの仕様に合わせる合理性は薄れていきます。
もちろん、汎用SaaSを使うことがメリットである場合はあると思うが、業務ドメインが深く、企業ごとの独自性が強い領域ほど、この変化は顕著になるでしょう。
検索機能は仕様通り。でも、ユーザーは取引先を見つけられない。「株式会社」を省くと検索できない設計なら、こうしたことが起こる。整えたテストデータだけでなく、利用者が普段どのように探すかも確認する。仕様を満たすことと、業務で使えることは同じではありません。
会社の売却は、経営者の引退だけを意味するものではない。IT企業でも、事業の成長や次の挑戦につながる選択肢になり得る。経営者自身の希望に加え、事業や社員にどのような可能性が広がるか。会社を持ち続けることだけにこだわらず考えたいですね。
リリースの打ち合わせで「問題があれば戻します」。その手順だけでなく、戻す判断まで決めているか。
事前に確認したいのは、次の5つ。
① 何が起きたら戻すか
主要な処理が動かない、データに不整合があるなど、切り戻しが必要となる条件を具体化する。
② いつまでに判断するか
切り戻しにも時間がかかる。業務開始に間に合わせるには、作業時間から逆算して判断期限を決めておく必要がある。
③ 誰が判断するか
開発側とお客様側の責任者を明確にする。当日連絡が取れることも確認しておく。
④ 切り替え後のデータをどう扱うか
新しいシステムで受け付けた注文や入力データは、元に戻すとどうなるか。プログラムを戻すだけで済むとは限らない。
⑤ 戻した後に何を確認するか
システムが起動するだけでは不十分。必要な業務を再開できることまで確認する。
戻す手順があっても、判断する人や条件が曖昧なら、障害発生時に協議が始まってしまう。
「戻せること」と「必要なときに戻す判断ができること」の両方を、事前に確認しておくことが大切です。