Yoshiaki Hayashida
システムやAIの、作る前・買う前・替える前の判断を整理します。
製品を売らない立場で、今のシステムで足りる範囲を先に確かめ、足りない分だけを作り、少人数で回る手順まで設計します。
特定の製品や実装方法を前提にせず、現在の業務、既存システム、データ、予算、運用体制を確認し、選択肢と判断条件を明確にします。
こんな判断をするときに
- 提案や見積が届いたが、自社の仕事に合うか判断しにくい
- 長年使ってきたシステムを、直すか入れ替えるか迷っている
- 作った担当者や会社に頼れず、修正・保守の先が見えない
- 注文や伝票の手入力が、システム導入後も減らない
- 部署ごとの数字が合わず、Excelでの照合が続いている
- 生成AIで社内資料を活用したいが、何から試すべきか分からない
- 取引先のセキュリティ質問票と、今の管理状況を突き合わせたい
- 部署ごとにツールが増え、残すものを整理したい
- 発注の判断が担当者頼みで、在庫の負担が増えている
- システムを新しく作るか、既製品を使うか決められない
- 内製化したいが、開発・運用・判断のどこを社内に持つべきか決まっていない
- 試作・検証をどこまで行えば、本格投資の判断ができるか決めたい
誰に相談するとよいか
相談先によって得意なことが異なります。何から始めるか決まっていない段階でも、必要な確認の内容によって相談先を選べます。
| 公的な無料相談窓口 | 課題の大まかな整理、支援制度や製品の情報収集、事業者の紹介 |
|---|---|
| 製品会社・開発会社 | 製品の仕様や導入方法の確認、具体的な開発・改修・保守の依頼 |
| このサービス | 現場の整理と技術的な選択肢の調査・比較、今の仕組みで足りる範囲の確認、必要な分だけの作成、少人数で回る手順の設計 |
最初のご連絡では、対応できる内容かを確認します。実際の調査・検証・作成については、対象と費用を個別に合意した上で進めます。
なぜこれが必要なのか
常に必要ではない。でも、決めるときには必要になる
システムやAIに関する技術的な判断は、毎日発生するとは限りません。
一方で、新しいシステムを入れる、既存システムを替える、AIを使う、内製する範囲を決める、といった場面では、その判断が数年先まで影響することがあります。
そのため、専任の技術責任者を常時置くほどではなくても、判断が必要なタイミングだけ技術的な視点が必要になることがあります。
判断理由が残らないと、同じ調査や比較、確認を繰り返す
案件や担当者が変わると、個別の成果物は残っても、
- なぜこの方式を選んだのか
- 何を比較したのか
- 何を理由に見送ったのか
- どの条件が変われば見直すのか
といった判断の経緯が分散しやすくなります。
それが残っていないと、
- 同じ調査や比較をやり直す
- 過去の担当者やベンダーへ確認する
- 以前却下した案を別担当者が再度検討する
- 当時の制約と現在も有効な制約を区別できない
- 必要以上に現状維持する
- 逆に、残すべき制約まで捨ててしまう
といった余分な時間・費用が発生します。
この支援では、判断材料・選択肢・決めた理由・見直す条件・まだ分からないことを、次の判断に使える形で残します。
実装や製品選定の前に、選択肢を分けて考える
開発会社は、決まった目的をシステムとして実現することに強みがあります。製品会社は、自社製品を使った解決方法に詳しいです。
どちらが問題ということではありません。
その前に、
- そもそも新しく作る必要があるか
- 既存製品で足りるか
- 今は導入せず、先に記録を取るべきか
- どこまでを外部に任せるか
を決める段階があります。
この段階では、特定の製品・ベンダー・実装方法を前提にせず、選択肢を比較することが役立つ場合があります。
製品販売や紹介手数料を前提とせず、この判断部分を切り出して整理します。
技術判断に関わってきた領域
システム・データ・AIの設計開発では、要件を整理し、実現方法を比較し、技術や費用の条件を踏まえて構成を決め、実装・運用までつなげてきました。
現在は、その経験をもとに、導入や改修を進める前の技術的な判断部分を独立した支援として提供しています。
AIシステム
- 複数のモデル・プロバイダ・実現方式の比較
- 要件ごとの費用の試算
- 予算内で成立する構成の整理
- 検証から実装・運用まで
データ基盤
- データパイプライン・基盤構成の技術選定
- 利用者との要件の整理
- 処理要件とクラウド費用を踏まえたETL構成の最適化
新規プロダクト開発
- 抽象的な要望を、検証可能な課題への整理
- 検証方法と実現方法の設計
- 結果を踏まえた仕様・構成の決定
- 実装・運用まで
相談後に残すもの
テーマに合わせて、次の内容を文書にまとめます。単一の「正解」だけを返すことは約束しません。
- 現在確認できていること
- 判断に必要な確認項目
- 選択肢
- 条件によって変わる次の対応
- 現時点で判断できないこと
- 判断するために次に取るべき情報
- 現時点で自分ならどうするか
例:
- Aの条件なら既製サービスを使う
- Bの条件なら小さく開発する
- Cが不明なら3か月記録を取ってから判断する
という条件分岐を残します。これは、将来条件が変わったときに再利用できる判断材料にするため。
判断の前提や理由、未確認事項、システム構成や変更の記録を、顧客側で参照できる形に残すことを重視しています。担当者や支援先が変わった場合にも、その後の検討や改善を引き継ぎやすい状態を目指します。
進め方
相談内容に応じて、必要な資料や関係者を確認し、判断に必要な範囲を決めます。
- 状況・目的・制約の確認
- 既存資料・システム・データの確認
- 必要な関係者へのヒアリング
- 選択肢と条件分岐の整理
- 判断材料の文書化
テーマによって期間・確認範囲は変わります。
判断に必要な調査・比較を基本とし、必要な場合は限定的な技術検証や実装についても、対象と費用を別途合意して検討します。
判断と販売を分けるために
- 特定製品の販売は行っていません。
- 紹介手数料を前提とした提案はしていません。
- 特定ベンダーへの発注を前提にしていません。
- 実装を前提とした判断整理は行っていません。
- 「作らない」「今は待つ」「既存機能で足りる」という結論もあり得ます。
- 採用代行・申請書類の作成代行・常駐や緊急対応は行っていません。
関連する記事
相談内容を送る
相談したい内容と、現在わかっている範囲をご記入ください。
相談の送信は契約ではありません。