Yoshiaki Hayashida

システムやAIの、作る前・買う前・替える前の判断を整理します。

システム・データ・AIの設計開発経験をもとに、導入・改修・内製化などを進める前の技術的な判断を整理します。

特定の製品や実装方法を前提にせず、現在の業務、既存システム、データ、予算、運用体制を確認し、選択肢と判断条件を明確にします。

相談内容を送る これまでの記事を見る

こんな判断をするときに

なぜこれが必要なのか

常に必要ではない。でも、決めるときには必要になる

システムやAIに関する技術的な判断は、毎日発生するとは限りません。

一方で、新しいシステムを入れる、既存システムを替える、AIを使う、内製する範囲を決める、といった場面では、その判断が数年先まで影響することがあります。

そのため、専任の技術責任者を常時置くほどではなくても、判断が必要なタイミングだけ技術的な視点が必要になることがあります。

判断理由が残らないと、同じ調査や比較、確認を繰り返す

案件や担当者が変わると、個別の成果物は残っても、

  • なぜこの方式を選んだのか
  • 何を比較したのか
  • 何を理由に見送ったのか
  • どの条件が変われば見直すのか

といった判断の経緯が分散しやすくなります。

それが残っていないと、

  • 同じ調査や比較をやり直す
  • 過去の担当者やベンダーへ確認する
  • 以前却下した案を別担当者が再度検討する
  • 当時の制約と現在も有効な制約を区別できない
  • 必要以上に現状維持する
  • 逆に、残すべき制約まで捨ててしまう

といった余分な時間・費用が発生します。

この支援では、判断材料・選択肢・決めた理由・見直す条件・まだ分からないことを、次の判断に使える形で残します。

実装や製品選定の前に、選択肢を分けて考える

開発会社は、決まった目的をシステムとして実現することに強みがあります。製品会社は、自社製品を使った解決方法に詳しいです。

どちらが問題ということではありません。

その前に、

  • そもそも新しく作る必要があるか
  • 既存製品で足りるか
  • 今は導入せず、先に記録を取るべきか
  • どこまでを外部に任せるか

を決める段階があります。

この段階では、特定の製品・ベンダー・実装方法を前提にせず、選択肢を比較することが役立つ場合があります。

製品販売や紹介手数料を前提とせず、この判断部分を切り出して整理します。

技術判断に関わってきた領域

システム・データ・AIの設計開発では、要件を整理し、実現方法を比較し、技術や費用の条件を踏まえて構成を決め、実装・運用までつなげてきました。

現在は、その経験をもとに、導入や改修を進める前の技術的な判断部分を独立した支援として提供しています。

AIシステム

  • 複数のモデル・プロバイダ・実現方式の比較
  • 要件ごとの費用の試算
  • 予算内で成立する構成の整理
  • 検証から実装・運用まで

データ基盤

  • データパイプライン・基盤構成の技術選定
  • 利用者との要件の整理
  • 処理要件とクラウド費用を踏まえたETL構成の最適化

新規プロダクト開発

  • 抽象的な要望を、検証可能な課題への整理
  • 検証方法と実現方法の設計
  • 結果を踏まえた仕様・構成の決定
  • 実装・運用まで

相談後に残すもの

テーマに合わせて、次の内容を文書にまとめます。単一の「正解」だけを返すことは約束しません。

例:

という条件分岐を残します。これは、将来条件が変わったときに再利用できる判断材料にするため。

進め方

相談内容に応じて、必要な資料や関係者を確認し、判断に必要な範囲を決めます。

  1. 状況・目的・制約の確認
  2. 既存資料・システム・データの確認
  3. 必要な関係者へのヒアリング
  4. 選択肢と条件分岐の整理
  5. 判断材料の文書化

テーマによって期間・確認範囲は変わります。

相談内容を送る

判断と販売を分けるために

関連する記事

note — 記事一覧

相談内容を送る

相談したい内容と、現在わかっている範囲をご記入ください。

相談の送信は契約ではありません。

フォームを別の画面で開く