TOKI|発注と開発をつなぐ人 (@toki_bridge) header
TOKI|発注と開発をつなぐ人 (@toki_bridge) profile picture

IT業界30年以上|システム開発会社の経営者|ベンチャー2社のIT担当役員を兼務し、発注側と開発側を同時に経験|「頼んだ内容」と「できたシステム」がズレる理由を発信していきます|YouTube「システム開発のリアル」

Joined October 2026
叱ったらミスが減ったように見えた。実は、報告が減っただけかもしれない。開発現場で不具合の報告を受けたら、まず何が起き、どこに影響し、今どんな対応が必要かを確認する。原因と再発防止は、事実を整理してから話し合います。
仕事ができない人を、必要以上に追い詰める上司がいるけど、あれは指導でも何でもない。強く責められるほど人は萎縮する。緊張で思考が止まり、普段ならできることまでできなくなり、さらにミスを重ねる。それを見てまた責めて、完全に悪循環なのよ。 相手の成長を考えているというより、自分のストレスを部下にぶつけているだけに見える。
6
会議ではA案、チャットではB案、仕様書は先週のまま。「共有しました」だけで、仕様は決まっていない。 変更依頼を受けたら、次の4つを確認しておきたい。 ① 相談と決定を区別する 「こうできませんか」は、実現可否の質問かもしれない。依頼した人に採用を決める権限があるかも確認する。 ② 影響を確認してから判断してもらう 変更する機能だけでなく、費用、納期、テストへの影響も整理する。入力項目を一つ増やす場合でも、一覧やCSV出力などへの影響を確認する。 ③ 決定内容を仕様書へ反映する チャットに決定事項が残っていても、開発者が参照する仕様書が古ければ認識は揃わない。どの資料のどの版が最新かを明確にする。 ④ 作業とテストへ反映する 資料の修正だけで終えず、実装する担当者へ伝え、作業内容とテスト項目も更新する。 決定日と承認者も記録し、相談中の案と確定した仕様を区別する。 関係者全員に会話の履歴を読み解いてもらうのではなく、何を作るかが分かる状態に整理することも、変更管理の重要な仕事です。
16
TOKI|発注と開発をつなぐ人 retweeted
この整理、わかりやすい。結局、個人情報をどう守るかの前に「どこまで持つべきか」を先に決めないと、対策は後追いになり続ける。設計の段階でその判断をできるかどうかが、組織の本気度が出るところなんだよな。
「またか」で済ませてはいけない規模が来た。
ニトリで最大3,762万件。 相次ぐ個人情報流出に対し、システムを設計・構築する私たちは何を変えるべきなのか。 つい先日までPHPの脆弱性が話題になっていたが、そこに対応したからといって終わる話ではない。不正アクセスの手法は多様であり、対策を続けてもリスクをゼロにはできない。 そこで、今後考えられる3つのシナリオを整理してみた。 ① 個人情報を持たない選択 
そもそも、本当にその個人情報が必要なのか。
商品を配送するECサイトなら住所は必要だが、そうでないサービスで住所や生年月日、性別まで収集する必要があるのだろうか。
企業のマーケティングに利用するためという理由もある。しかし、それは企業側の都合である。
必要な情報だけを収集し、利用が済んだら速やかに削除する。保存が必要でも、常時ネットワークにつながっている必要があるのかを考える。
個人情報を大量に持つことを前提としない、新たなマーケティング手法やサービスが生まれる可能性もある。 ② 個人情報を専門サービスに預ける選択 
情報流出のニュースで「クレジットカード情報は含まれていない」という説明を目にする。
カード情報は外部の決済サービスで管理し、自社システムでは保有しない方式が広く使われている。
同じように、住所や生年月日なども専門サービスで管理し、必要なときだけ利用する仕組みが、さらに広がるかもしれない。
もちろん、そのサービスが攻撃されれば被害は大きくなる。集中管理には別のリスクもある。 ③ 個人情報流出に慣れてしまう社会 
もう一つ考えられるのが、情報流出そのものに人々が慣れてしまうというシナリオである。
弾道ミサイル発射のニュースも、本来は一大事だが、繰り返されるうちに以前ほど驚かなくなった人もいるだろう。
個人情報流出も同様に、またか、で済まされるようになるのではないか。
これは避けたい未来である。 3つのうち、①と②はシステムの作り方を変える選択肢であり、③は警戒すべき社会の変化である。 もちろん、従来の脆弱性対策や監視、運用管理が不要になるわけではない。 しかし、個人情報をどう守るかだけでなく、そもそも何を、どこまで持つべきなのか。 SIerやシステム構築関係者は、設計段階から考え直す必要があると思います。
1
6
561
深夜のシステム切り替えでは、誰が作業するかに加え、異常が起きたときに誰が中止を判断するかも決めておく。お客様側の判断が必要なら、深夜でも連絡がつく責任者を決める。中止する条件と判断者は、作業手順とあわせて事前に確認します。
エンジニアあるある「深夜作業」 
顧客「作業は深夜でお願いします」
SE「立ち会いはどなたが?」
顧客「うちは定時で帰ります」
1
2
49
TOKI|発注と開発をつなぐ人 retweeted
「またか」で済ませてはいけない規模が来た。
ニトリで最大3,762万件。 相次ぐ個人情報流出に対し、システムを設計・構築する私たちは何を変えるべきなのか。 つい先日までPHPの脆弱性が話題になっていたが、そこに対応したからといって終わる話ではない。不正アクセスの手法は多様であり、対策を続けてもリスクをゼロにはできない。 そこで、今後考えられる3つのシナリオを整理してみた。 ① 個人情報を持たない選択 
そもそも、本当にその個人情報が必要なのか。
商品を配送するECサイトなら住所は必要だが、そうでないサービスで住所や生年月日、性別まで収集する必要があるのだろうか。
企業のマーケティングに利用するためという理由もある。しかし、それは企業側の都合である。
必要な情報だけを収集し、利用が済んだら速やかに削除する。保存が必要でも、常時ネットワークにつながっている必要があるのかを考える。
個人情報を大量に持つことを前提としない、新たなマーケティング手法やサービスが生まれる可能性もある。 ② 個人情報を専門サービスに預ける選択 
情報流出のニュースで「クレジットカード情報は含まれていない」という説明を目にする。
カード情報は外部の決済サービスで管理し、自社システムでは保有しない方式が広く使われている。
同じように、住所や生年月日なども専門サービスで管理し、必要なときだけ利用する仕組みが、さらに広がるかもしれない。
もちろん、そのサービスが攻撃されれば被害は大きくなる。集中管理には別のリスクもある。 ③ 個人情報流出に慣れてしまう社会 
もう一つ考えられるのが、情報流出そのものに人々が慣れてしまうというシナリオである。
弾道ミサイル発射のニュースも、本来は一大事だが、繰り返されるうちに以前ほど驚かなくなった人もいるだろう。
個人情報流出も同様に、またか、で済まされるようになるのではないか。
これは避けたい未来である。 3つのうち、①と②はシステムの作り方を変える選択肢であり、③は警戒すべき社会の変化である。 もちろん、従来の脆弱性対策や監視、運用管理が不要になるわけではない。 しかし、個人情報をどう守るかだけでなく、そもそも何を、どこまで持つべきなのか。 SIerやシステム構築関係者は、設計段階から考え直す必要があると思います。
2
1
3
832
「またか」で済ませてはいけない規模が来た。
ニトリで最大3,762万件。 相次ぐ個人情報流出に対し、システムを設計・構築する私たちは何を変えるべきなのか。 つい先日までPHPの脆弱性が話題になっていたが、そこに対応したからといって終わる話ではない。不正アクセスの手法は多様であり、対策を続けてもリスクをゼロにはできない。 そこで、今後考えられる3つのシナリオを整理してみた。 ① 個人情報を持たない選択 
そもそも、本当にその個人情報が必要なのか。
商品を配送するECサイトなら住所は必要だが、そうでないサービスで住所や生年月日、性別まで収集する必要があるのだろうか。
企業のマーケティングに利用するためという理由もある。しかし、それは企業側の都合である。
必要な情報だけを収集し、利用が済んだら速やかに削除する。保存が必要でも、常時ネットワークにつながっている必要があるのかを考える。
個人情報を大量に持つことを前提としない、新たなマーケティング手法やサービスが生まれる可能性もある。 ② 個人情報を専門サービスに預ける選択 
情報流出のニュースで「クレジットカード情報は含まれていない」という説明を目にする。
カード情報は外部の決済サービスで管理し、自社システムでは保有しない方式が広く使われている。
同じように、住所や生年月日なども専門サービスで管理し、必要なときだけ利用する仕組みが、さらに広がるかもしれない。
もちろん、そのサービスが攻撃されれば被害は大きくなる。集中管理には別のリスクもある。 ③ 個人情報流出に慣れてしまう社会 
もう一つ考えられるのが、情報流出そのものに人々が慣れてしまうというシナリオである。
弾道ミサイル発射のニュースも、本来は一大事だが、繰り返されるうちに以前ほど驚かなくなった人もいるだろう。
個人情報流出も同様に、またか、で済まされるようになるのではないか。
これは避けたい未来である。 3つのうち、①と②はシステムの作り方を変える選択肢であり、③は警戒すべき社会の変化である。 もちろん、従来の脆弱性対策や監視、運用管理が不要になるわけではない。 しかし、個人情報をどう守るかだけでなく、そもそも何を、どこまで持つべきなのか。 SIerやシステム構築関係者は、設計段階から考え直す必要があると思います。
2
1
3
832
「自分で考えて」と任せたのに、案が出るたびに上司が作り直す。これが続くと、メンバーは次も上司の判断を待つようになる。開発現場で仕事を任せるときは、守るべき条件と、自分で判断してよい範囲を最初に伝えることが大切です。
「主体性のないメンバー」がいま存在するのは「時間をかけて少しずつ主体性を奪ってきた経営や人事や管理職」がいるからです。
1
5
193
業務フローのレビューで「違います」と言われたら、認識の違いを確認できたということ。図にしなければ、気づかないまま開発に進んでいたかもしれない。要件定義では、きれいな図を作ることより、お客様と業務の認識を合わせることが目的。修正が図で済む段階で、食い違いを解消したいです。
1
2
29
システム開発現場でも、若手がお客様との打ち合わせに同席しても、議事録を取るだけでは、自分の言葉で伝える経験は積めない。例えば、担当した機能の説明を一つ任せる。答えに詰まったら上司が補い、終わった後に一緒に振り返る。お客様と話す力は、小さな役割を任せるところから育てます。
コンサルで強いのは結局「顧客と話をつけられるやつ」なので、若者は作業だけじゃなくて顧客との対話を行う機会をなるべく与えたい ワイが直接やる事を減らす事で、ワイが仕事をしなくていい環境にも繋がるしいい事づくめなのだわ そうやって育つとすぐ他に行っちゃったり独立しちゃったりするのが難点ではあるのだけども…
4
33
システム開発会社から「保守も対応します」と言われた。それで、どこまで任せられると考えているか。 「保守」の範囲は、開発会社や契約ごとに異なる。以前の会社が対応してくれたことでも、今回の契約に含まれるとは限らない。 発注側が契約前に確認しておきたいのは、次の4点。 ① 何に対応してもらえるか 障害調査、操作の質問、データ修正、機能追加。どこまでが保守料金に含まれ、何が別料金になるのか。「困ったら何でも頼める」と考えず、具体的に確認する。 ② いつ対応してもらえるか 平日の日中だけか、夜間や休日も含むか。自社の営業時間と、開発会社の対応時間が合っているかも重要。休日にシステムが止まった場合、誰に連絡し、どのような対応を受けられるかを確認しておく。 ③ 「すぐ対応」とは何を意味するか 受付の返事をするのか、調査を始めるのか、復旧まで完了するのかは別の話。復旧時間を事前に確約できない場合もあるため、受付や状況報告の期限を確認する。 ④ 追加費用が発生する場合、どう進めるか 作業前に見積もりを確認できるか、誰の承認で着手するか。緊急時の扱いも決めておく。過去に一度無償で対応してもらったことが、次回も無料になる根拠とは限らない。 保守契約があることと、自社に必要な支援を受けられることは同じではない。 契約名や「対応します」という言葉だけで判断せず、自社の業務に必要な対応が含まれているかを確認することが大切です。
2
25
営業も事業部門も、役割に上下はない。営業を「接点づくり」と「提案」に分けると、それぞれに必要なスキルが見えてくる。Webサイト構築も、一人で企画からコーディングまで担える仕事だが、企画、デザイン、コーディングと工程を細分化したことで、コーディング専門の会社が生まれた。一つの仕事を分解してみることで見えてくることがありますね。
世の中営業を下に見る風潮があるけど、それは経営を分かっていない人。自社に営業組織がある人は営業の大切さを分かっている。営業はリード獲得と提案活動に分かれる。 ・提案活動は経験でカバーしやすい ・リード獲得ができる営業は希少人材 なので最近はリード獲得はマーケ組織が担うことが多い
1
3
265
AIで実装が速くなるほど、要件定義や顧客との調整の重要性は増す。一方で、AIが出した設計やコードを採用できるか判断するには、技術を深く理解している人も必要。お客様と何を作るかを決める力と、作ったものを技術的に見極める力。開発チームには、どちらも欠かせませんね。
もう人間がフルスタックエンジニアを目指す時代じゃないと思うんだよね。 だって、AIがすでにフルスタックなんだから。 技術は広く浅く理解しておけばいい。それよりも、要件定義、仕様策定、顧客折衝、マネジメント能力を磨くべし。 AIと同じ土俵で戦っても負けるのは目に見えている。
2
20
「なんか違う」で部下に修正を指示し、次も「やっぱり違う」。これでは上司の好みを当てる仕事になってしまう。画面のレビューなら、どの操作で迷い、何の情報が不足しているのかを具体的に伝える。修正が何度も往復するなら、指摘する側の説明も見直したいものです。
3
24
開発会社が「担当が替わったので、もう一度教えてください」はNG行動。お客様は担当者個人に発注したのではなく会社である。要望だけでなく、過去の提案や見送った理由も引き継ぐ。担当交代のたびに同じ説明や判断を求めないよう、社内で情報を共有しておくことが大切です。
3
26
発注者からの曖昧な依頼を、そのまま引き受けない。要件定義でも大切な姿勢。ただ「分かりません」と返すだけでなく、どこが不明かを整理し、例や選択肢を示して確認する。すぐに答えられないことは、調べる内容と回答期限を伝える。発注者の意図を具体化する工夫を、開発側からも示したいです。
上司対応の極意をリーダーに教わったんで、実際にやってみたら威力がすごい! 上司に振り回されなくなった。 仕事を十分に把握できたADHDにとって、これは意外と簡単だったな。上司の曖昧な依頼には、ちょっとでもわからないことがあれば全て「わからない」と言って、あとはとことん「具体的に説明」する。 これだけで上司の無責任で曖昧な物言いは跳ね返せる! ADHDが自由に仕事するためにも、これは必須の技術かも。上司に介入されなくなるから、自分の仕事に集中できる。
3
20
会議に責任者が出席していても、承認が取れたとは限らない。システム開発の打ち合わせでは、「何を、誰に判断してもらうか」を明確にしておく必要がある。 例えば画面の確認でも、立場によって確認する内容は異なる。 ① 現場の担当者には、業務が成立するか 必要な情報を確認できるか、入力できるか、例外処理にも対応できるか。実際に操作するユーザーの確認がなければ、想像で判断することになる。 ② 業務の責任者には、部署をまたぐルール 営業と経理の要望がぶつかった場合、どう調整するか。開発者の判断だけで片方を採用せず、お客様側で調整する責任者を明確にする。 ③ 決裁者には、予算と開発範囲 今回どこまで作り、何を次回に回すか。費用や納期に影響する選択は、その権限を持つ人に判断してもらう。 会議の最後には、決定事項、未決事項、次に回答する人と期限を確認する。議事録にも、個人の意見と正式な決定を区別して残す。 出席したこと、説明を聞いたこと、承認したことは、それぞれ別。その場で何が決まったのかを、参加者間で確認することが大切です。
3
48
開発案件を紹介していただいたときも、お客様だけでなく、紹介者の信用を預かっている。受注したら終わりではなく、差し支えない範囲で経過や結果を報告する。技術や価格に加え、こうした対応の積み重ねが、次も紹介したいと思ってもらえる信用につながりますね。
仕事をもらい続けるために絶対に必要なもの。 それは『筋を通すこと』。 この意味を全く理解しないまま独立し、消えていく奴は本当に多い。 「技術があれば仕事が取れる」 「安く出せば仕事がくる」 「誰から仕事をもらおうが自由」 一時的には、売上が立つこともある。 だが、田舎は特に横の繋がりの狭さや、情報の回るスピードは本当に早い。 意味の分かっていない奴は静かに、 「あいつは筋も道理も通せない奴」と認定され、その信用を取り戻すには、尋常じゃない時間と労力が掛かる。 「義理や人情」、「愛や恩義」を舐めた奴は、いずれその世界から静かに退場させられる。 最後に生き残るのは、常に『本当の意味で筋を通し続けれる者』だけです。
1
1
2
187
身近な人の努力が、自分も学ぶきっかけになる。開発現場でも、他のエンジニアが何を試し、どう仕事を改善したかを知る機会は大切。「あの人を見習え」と比較するのではなく、それぞれの工夫を共有する。自分も試してみようと思える機会をつくりたいです。
幼馴染の代表小島が岡山から灘を目指し猛勉強してるのを見て親に「塾に行かせて欲しい」と懇願。私は中学で200人中130位で学校の授業もついていけず。親には何も言われなかったけど小島を見て焦り始めて自発的に勉強を頑張り始めた。中2から頑張り高校受験もギリギリセーフ。ライバルからの刺激は大事
1
16
「いくらでも保存できます」は、発注者にとってうれしい話。確かにデータ自体の保存コストは非常に安くなった。しかし、データが増えれば管理の手間も増え、バックアップや運用にも費用がかかる。システムの提案は、想定するデータ量や保存期間、その場合の運用費用も示す。導入費だけで判断してもらうのではなく、使い続けるための費用まで説明することが大切です。
7
AI時代だからこそですね。
PHP5→8にしてくださいと言われても、アプリケーションコードなんかはまぁ頑張れば書き換えられると思うが、使っているフレームワークに互換性がない場合、結局ゼロから作り直した方が速いよねと言う話になるんだよな。正解挙動はあるんで、全く新しいもの作るよりは現代でば簡単だと思うよ。
6