出版

サービス一覧

公開ソフトウェア

YouTube 動画公開中

トランジット株式会社では、法人・個人を対象とした 研修を提供しております。 プログラミングやシステム開発、データサイエンス 生成AI活用、人工知能など 現場の経験に基づいた、実践的な内容となっております。 興味がある方は、概要欄のリンクから詳細をご覧ください。 また、今回の動画が少しでもためになったという方は 是非、チャンネル登録と高評価の方、よろしくお願いいたします。 それでは、また次回の動画でお会いしましょう。 今回はありがとうございました。 トランジット株式会社: https://trans-it.jp/ ◾️【データ活用の落とし穴】相関関係と因果関係の違い こんにちは。今回は、ビジネスや日常のニュースを見るときに非常に重要な「相関関係」と「因果関係」の違いについて解説します。 「データがあるから正しい」「グラフで連動しているから原因はこれだ」と思い込んでしまうと、間違った対策をしてしまったり、ニュースのミスリードに気づけなかったりします。 今回は、身近なニュースや昔よく耳にした言説、そしてビジネスの実例を交えながら、データの裏に隠れた「第3の要因（交絡因子）」の見破り方を整理していきます。 まず、2つの違いをシンプルに整理します。 相関関係とは、「一方が増えると、もう一方も増える（または減る）」という、連動している状態のことです。 一方で因果関係とは、「一方が原因で、もう一方が結果として起きている」という関係を指します。 ここで最も重要なルールは、「相関関係があるからといって、因果関係があるとは限らない」ということです。 一見すると関係があるように見えても、実は裏に別の要因が存在しているケースがたくさんあります。これを統計学では「擬似相関（ぎじそうかん）」、その隠れた要因を「交絡因子（こうらくいんし）」と呼びます。 具体例① まずは、この手の話でかなり有名な事例です。 ある地域のデータを調べたところ、『アイスクリームの売上が増える時期ほど、水難事故の発生件数が増える』という強い相関関係が見つかりました。 もしこれを『因果関係』だと勘違いしてしまうと、どうなるでしょうか？ 『水難事故を減らすために、アイスクリームの販売を禁止しよう！』という、おかしな対策を打つことになってしまいますよね。もちろん、アイスクリームを食べることが事故の原因ではありません。 ここには、『気温の上昇（夏）』という隠れた第3の要因が存在しています。 夏になって気温が上がるからアイスが売れ、同時に夏だから海や川で泳ぐ人が増えて水難事故も増える。 このように、背後にある共通の原因によって見かけ上の相関が生まれる現象を『擬似相関（ぎじそうかん）』と呼びます。」 具体例② 次の例です。 例えば、昔「朝食を食べない子はすぐキレる」「朝食を抜くと非行に走りやすい」といった話を耳にしたことはないでしょうか。 実際にデータを取ると、「朝食を食べないこと」と「情緒が不安定・非行傾向があること」には相関が見られることがあります。 しかし、これは「朝食を食べさせさえすれば、キレる子どもがいなくなる」という単純な因果関係なのでしょうか。 ここには、「家庭環境や親の関わり方・生活習慣」という交絡因子が隠れている可能性が高いです。 家庭環境が不安定だったり、親が多忙で生活リズムのサポートが難しかったりすると、朝食を用意できない状況になりやすく、同時に子どもの生活や精神面へのケアも行き届きにくくなる。 つまり、直接の原因は朝食そのものではなく、その背景にある生活環境かもしれないわけです。 具体例 ③ もう一つ、メディアのニュースで私がかつて見た例を挙げます。 数年前、海外で人種差別への抗議運動が活発化していた時期に、一部のワイドショーや報道で「感染者数が多い地域ほど、人種差別の抗議運動が頻発している」といったデータが紹介されることがありました。 これを聞くと、「運動の集会が感染を広げているのではないか」あるいは「感染状況への不満が運動を引き起こしているのではないか」といった因果関係を想像してしまいがちです。 しかし、ここにも強力な交絡因子があります。それが「その地域の人口規模（大都市かどうか）」です。 大都市であれば、そもそも人が密集しているため感染者数が多くなります。そして同時に、人口が多く多様な人が集まる大都市だからこそ、抗議運動の規模や件数も多くなる。 両者を結びつけていたのは直接の因果ではなく、単に「大都市である」という共通の要因だった可能性があります。 具体例 ④ この見落としは、企業のデータ活用でも日常茶飯事です。 例えば、あるECサイトで「メルマガを頻繁に開く顧客ほど、購入金額が高い」というデータが出たとします。 ここで「メルマガを増やせば売上が上がる！」と判断して配信を連発した結果、顧客に嫌がられて解約やブロックが急増してしまう……という失敗です。 実際には、「もともとそのブランドが大好き（ロイヤルティが高い）」という顧客だからこそ、メルマガも読むし、商品もたくさん買うというだけだったりします。 相関関係だけを見て手を打つと、期待した効果が出ないどころか、マイナスに働くことすらあります。 では、データやニュースに騙されないために、どうすればよいのでしょうか。ポイントは次の3点です。 ・時間の順序（原因は結果より先にあるか？） ・隠れた第3の要因（交絡因子はないか？） ・逆の因果（原因と結果が逆ではないか？） 時間の順序を確認する 原因は必ず結果よりも前に発生している必要があります。 隠れた第3の要因（交絡因子）を疑う 先ほどの「家庭環境」や「人口規模」のように、両方に影響を与えている共通の背景がないかを考えます。 因果が逆ではないかを考える 「AだからB」ではなく、実は「BだからA」ではないかと疑ってみることです。 データ分析ツールやAIは「相関」を自動で見つけてくれますが、それが本当に「因果」なのかを見極めるのは、私たち人間のリテラシーにかかっています。 今回は、相関関係と因果関係の違い、そして交絡因子の存在について解説しました。 日常のニュースやビジネスのレポートを見るときは、ぜひ一歩立ち止まって「その裏に隠れた第3の要因はないか？」と考えてみてください。 それでは、今回の動画は以上となります。
【ビジネス基礎】相関と因果の違いをわかりやすく解説！データ活用の落とし穴と3つの対策
トランジット株式会社では、法人・個人を対象とした 研修を提供しております。 プログラミングやシステム開発、データサイエンス 生成AI活用、人工知能など 現場の経験に基づいた、実践的な内容となっております。 興味がある方は、概要欄のリンクから詳細をご覧ください。 また、今回の動画が少しでもためになったという方は 是非、チャンネル登録と高評価の方、よろしくお願いいたします。 それでは、また次回の動画でお会いしましょう。 今回はありがとうございました。 トランジット株式会社: https://trans-it.jp/ ◾️# AI時代にプログラミングは本当に必要なのか？ こんにちは。 トランジット株式会社の田中です。 今日は、 「AI時代にプログラミングは本当に必要なのか？」 というテーマでお話しします。 最近、本当によく聞かれる質問です。 「ChatGPTがプログラムを書いてくれるなら、もうプログラミングを勉強しなくてもいいですよね？」 「プログラマーはAIに仕事を奪われるんですか？」 皆さんはどう思いますか？ 実は私は、この質問自体が少し違うと思っています。 今日は、その理由をお話しします。 # AIは本当にすごい まず最初にお伝えしたいのは、 「AIは本当にすごいです。」 私も毎日使っています。 例えば、 ・プログラムを書く ・エラーを直す ・コードをきれいにする ・テストコードを書く こういったことは、本当に得意です。 10年前だったら数時間かかっていた仕事が、数分で終わることもあります。 ですから、 「AIによってプログラミングが大きく変わった」 これは間違いありません。 # でも、一つ勘違いがあります ここで皆さんに質問です。 システム開発とは何でしょう？ 「プログラムを書くこと」 そう思った方も多いかもしれません。 でもそれだけではありません。 ① 問題を見つける (企画) ↓ ② 何を作るか決める (要件定義) ↓ ③ どのように作るか決める。(設計) ↓ ④ プログラミング ↓ ⑤ テストする ↓ ⑥ 運用・改善する これ全部が、システム開発です。 プログラミングは、この中のたった一つの工程なんです。 # AIが得意なのはどこ？ では、この中でAIが一番得意なのはどこでしょう？ 答えは、 ④ プログラミング です。 もちろん、 テストを手伝ったり、 設計を提案したりもできます。 でも、 「会社の本当の課題は何なのか」 「何を作れば解決するのか」 これはAIだけでは決められません。 # 料理に例えてみましょう 料理で考えると分かりやすいです。 システム開発が料理だとすると、 プログラミングは 包丁で材料を切る作業 に近いです。 昔は、 包丁で切るのが一番大変でした。 だから、 包丁が上手な人が評価されました。 でも今は、 フードプロセッサーがあります。 切る作業は、とても速くなりました。 では、 料理人は必要なくなったでしょうか？ もちろん違います。 何を作るのか。 誰に食べてもらうのか。 どんな味付けにするのか。 最後に盛り付けるのか。 そこは、まだ料理人の仕事です。 システム開発も同じなんです。 # では、プログラミングはもう勉強しなくていい？ ここも誤解されやすいところです。 私は、 目的によって答えが違う と思っています。 例えば、 「自分で家計簿アプリを作りたい。」 「趣味でゲームを作りたい。」 このくらいなら、 AIだけでもかなり作れる時代です。 一方で、 お客様から仕事を受けるプロになるなら話は別です。 AIが書いたコードを 「これで安全です。」 「これで品質は大丈夫です。」 と判断する責任があります。 だから、 プロはプログラミングを理解している必要があります。 ただし、 それだけでは足りません。 --- # AI時代に一番価値が上がるもの 私は、 これから一番価値が上がるのは プログラミングではなく、 システム全体を考える力 だと思っています。 ・お客様の困りごとを理解する ・本当の原因を見つける ・最適な仕組みを考える ・将来まで考えて設計する ・品質を保証する こういった仕事は、 まだ人間が中心です。 むしろ、 プログラミングがAIによって効率化されたからこそ、 こういう力の重要性は以前より高くなっています。 # まとめ 今日、一番お伝えしたかったことがあります。 それは、 プログラミングとシステム開発は同じではない。 ということです。 AIによって、 プログラミングは大きく変わりました。 でも、システム開発そのものがなくなったわけではありません。 むしろ、 プログラミング以外の工程の価値は、 これからますます高くなるでしょう。 ですから、 「AIがあるからプログラミングは不要」 でも、 「これまでどおりプログラミングだけ勉強すればいい」 でもありません。 これから必要なのは、 システム全体を考えられる人。 そんな人が、AI時代でも活躍し続けると思います。 ================================================== 【エンディング】 見積チェック 無料相談 受付中 最後までご覧いただきありがとうございました。
「AIがあるからプログラミング学習は不要」←これ、本当ですか？
もし今、 ・見積もりをもらったけど高いのかわからない ・提案内容がよくわからない ・初めてシステム開発を発注するので不安 そんな状況でしたら、お気軽にご相談ください。 トランジット株式会社では、システム開発だけではなく、 「本当に作るべきか」 というところからご相談をお受けしています。 場合によっては、 「今は作らない方がいいですよ」 とお伝えすることもあります。 御社にとって本当に良い選択肢を一緒に考えます。 お問い合わせは概要欄のリンクからどうぞ。 この動画が参考になった方は、ぜひ高評価とチャンネル登録をお願いします。 また、 「こんなテーマを解説してほしい」 というご要望があれば、ぜひコメント欄で教えてください。 それではまた次回の動画でお会いしましょう。 ありがとうございました。 トランジット株式会社: https://trans-it.jp/ ◾️そのシステム、本当に必要ですか？IT発注で失敗しない5つの確認事項 ① なぜ？ ② いくら？ ③ 誰が？ ④ どこまで？ ⑤ 本当に必要？ こんにちは。トランジット株式会社の田中です。 ITシステムの導入や開発を検討していると、 「この見積もり、高いのか安いのかわからない」 「提案内容が難しくて、何となくOKしてしまった」 「システムを作ったけれど、思ったものと違った」 そんな経験や不安をお持ちの方も多いのではないでしょうか。 今日は、ITの専門知識がなくても使える、 「ITベンダーに発注する前に確認すべき5つの質問」 をご紹介します。 この5つを知っているだけで、システム導入や開発の失敗を大きく減らすことができます。 ぜひ最後までご覧ください。 【なぜ失敗が起きるのか】 IT発注でよくある失敗 ・高くついた ・思ったものと違う ・誰も面倒を見ない まず最初にお伝えしたいことがあります。 私はITベンダーが悪いと言いたいわけではありません。 多くの会社は真面目に仕事をしています。 ただし、発注する側と開発する側には、どうしても知識の差があります。 情報の差 ベンダー ↓ 詳しい 発注者 ↓ わからない 例えば車屋さんで、 「この部品は交換した方がいいですよ」 と言われたとき、 本当に必要なのか。 適正価格なのか。 判断できる人は多くありません。 ITも同じです。 その結果として起きるのが、先ほどの3つです。 まず一つ目。 高くついた。 本当はもっと安くできたかもしれないのに、比較も判断もできないまま契約してしまう。 二つ目。 思ったものと違う。 発注者は当然入っていると思っていた機能が、実は見積もりに含まれていなかった。 三つ目。 誰も面倒を見ない。 納品後に不具合が出たけれど、誰が対応するのか決まっていなかった。 私はこれまで多くのIT相談を受けてきましたが、ほとんどのトラブルはこの3つに集約されます。 そして面白いことに、これらは技術知識がなくても防げます。 必要なのは、正しい質問をすることです。 今日はそのための5つの質問をご紹介します。 ================================================== 【質問① なぜその提案なのか？】 ① なぜ？ その提案の理由は？ 最初の質問です。 「なぜその提案なのですか？」 例えば、 「このシステムを導入しましょう」 「このサービスを使いましょう」 と言われたら、 必ず理由を聞いてください。 良いベンダーであれば、 ・なぜそれを選んだのか ・他の選択肢は何か ・メリットとデメリットは何か を説明できます。 例えば、 「御社の規模ならこの方法が最も安く運用できます」 「既に利用しているシステムとの相性が良いです」 などです。 逆に、 「うちはいつもこれです」 「これが一番良いです」 だけで終わる場合は注意が必要です。 本当に御社に最適なのか。 それともベンダーが得意だから提案しているだけなのか。 そこを見極めるためにも、 「なぜですか？」 を必ず聞いてみてください。 ================================================== 【質問② 金額の内訳は？】 ② いくら？ 見積 ↓ 内訳を出してください 設計 開発 テスト 2つ目はお金の話です。 見積書に、 「システム開発　一式　500万円」 と書かれていたら、 その500万円が高いのか安いのか判断できますか？ 普通はできません。 だから聞いてください。 「内訳を教えてください」 です。 例えば、 ・設計 ・開発 ・テスト ・導入支援 それぞれにどれくらいの時間がかかるのか。 何にお金がかかっているのか。 それを確認します。 私はむしろ、内訳をしっかり出してくれる会社の方が信頼できると思っています。 なぜなら、 何にどれだけ時間がかかるのかを説明できるからです。 逆に、 システム開発　一式 500万円 だけの見積もりは注意が必要です。 後から、 「それは別料金です」 というトラブルにつながることがあります。 【質問③ 誰が面倒を見るのか？】 ③ 誰が？ 作った後は？ ・運用 ・保守 ・相談 3つ目は非常に重要です。 作った後の話です。 システムは作って終わりではありません。 むしろそこからがスタートです。 家も建てた後に、 ・修理 ・メンテナンス が必要ですよね。 システムも同じです。 使っているうちに、 「ここを少し変えたい」 「不具合が出た」 「ログインできなくなった」 ということが起こります。 そのときに誰が対応するのでしょうか。 誰が対応しますか？ いくらですか？ これを確認してください。 さらに確認してほしいのが、 ・保守契約はあるか ・月額いくらか ・バグ修正は有償か無償か ・ソースコードは誰のものか です。 特にソースコードは重要です。 ベンダーしか持っていない場合、 他社へ乗り換えたくてもできなくなることがあります。 ================================================== 【質問④ どこまでやるのか？】 ④ どこまで？ やること やらないこと ○ 含まれる × 含まれない 4つ目です。 実はITトラブルの多くは、お金の問題ではありません。 認識のズレです。 発注者は、 「当然入っていると思った」 ベンダーは、 「頼まれていないと思った」 こういうことが頻繁に起こります。 例えば、 スマホ対応が含まれていると思っていた。 データ移行が含まれていると思っていた。 マニュアル作成が含まれていると思っていた。 でも実際には見積もりに入っていなかった。 こういうケースです。 だから確認してください。 今回どこまでやるのか。 どこから先は追加料金なのか。 そして必ず文書に残してください。 口頭だけの約束は後から解釈が変わります。 ================================================== 【質問⑤ 本当に必要なのか？】 ⑤ 本当に必要？ もっと安く 小さく 始められない？ 最後の質問です。 これは一番大事かもしれません。 「本当に必要ですか？」 です。 もっと言うと、 「もっと小さく始められませんか？」 です。 私は受託開発会社ですが、 実はお客様に、 「まだ作らない方がいいですよ」 と言うことがあります。 なぜか。 Excelで十分な場合があるからです。 市販サービスで十分な場合もあります。 まずは小さく始めてみる。 本当に必要になったら開発する。 その方が成功するケースは少なくありません。 良いパートナーは、 システムを売る人ではありません。 問題を解決する人です。 だからぜひ聞いてみてください。 「もっと安く始める方法はありませんか？」 と。 ================================================== 【まとめ】 失敗を防ぐための5つの質問 ① なぜ？ ② いくら？ ③ 誰が？ ④ どこまで？ ⑤ 本当に必要？ 今日の内容をまとめます。 ① なぜ？ → なぜその提案なのか理由を聞く ② いくら？ → 金額の内訳を確認する ③ 誰が？ → 作った後の保守やサポートを確認する ④ どこまで？ → やること・やらないことを明確にする ⑤ 本当に必要？ → 小さく始める方法がないか確認する そして、最初にお話しした3つの失敗。 高くついた ↓ ①②⑤ 思ったものと違う ↓ ④ 誰も面倒を見ない ↓ ③ この5つの質問は、専門知識がなくてもできます。 そして、この5つにしっかり答えられる会社であれば、かなり安心して任せられると思います。 逆に曖昧な回答しか返ってこない場合は、一度立ち止まって考えた方がよいかもしれません。 IT発注は家づくりと同じです。 作って終わりではなく、そこから長い付き合いが始まります。 だからこそ、最初の提案段階で誠実に向き合ってくれる会社を選ぶことが大切です。 ================================================== 【エンディング】 見積チェック 無料相談 受付中 最後までご覧いただきありがとうございました。
【システム開発】初めての発注でも失敗しない！プロが教える5つのチェックリスト
トランジット株式会社では、法人・個人を対象とした 研修を提供しております。 プログラミングやシステム開発、データサイエンス 生成AI活用、人工知能など 現場の経験に基づいた、実践的な内容となっております。 また弊社では法人を対象としたデータ分析のサービスも提供しております。 トランジット株式会社は創業以来、データ分析システムの開発と共に 常にデータと向き合ってきた会社です。 みなさまの会社のデータ、専門家の観点から調査・分析いたします。 興味がある方は、概要欄のリンクから詳細をご覧ください。 また、今回の動画が少しでもためになったという方は 是非、チャンネル登録と高評価の方、よろしくお願いいたします。 それでは、また次回の動画でお会いしましょう。 今回もどうもありがとうございました。 トランジット株式会社: https://trans-it.jp/ ◾️弊社ソフトウェア Present Pilot のご紹介 10年の講師経験から、 「講義中に欲しかった機能」を1つにまとめました。 描画、補足表示、画像呼び出し、時間管理。 講義の流れを止めず、説明に集中できる講義支援ツールです。 講義中に、 　「今の画面へ、その場で補足を書き込みたい」 　「質問に合わせて、さっきの図やコードをすぐ見せたい」 　「時間を確認したい。でも講義の流れは止めたくない」 そんな“説明の止まり”を減らすために設計されています。 描画、補足表示、画像呼び出し、タイマー表示を1つに統合。 複数ツールを切り替えることなく、講義のテンポを維持できます。 ■ 主な機能 ① 画面へ直接描画 　スライドやアプリ画面へ、その場で補足を書き込み。 　説明したい瞬間を逃しません。 ② 自動で消える補足表示 　一時的な強調や注意書きを表示。 　説明後は自動でクリアできます。 ③ 画像・資料を即表示 　質問や受講者の反応に合わせて、必要な資料をすぐ呼び出せます。 ④ タイマー・時計表示 　説明を中断せずに、残り時間や現在時刻を確認できます。 ⑤ 講義進行に特化した統合操作画面 　講義中によく使う操作を、1つの画面へ集約しています。 ■ こんな方におすすめ ・プログラミング・データ分析系講師 ・ライブ感のある研修・セミナーを行う方 ・受講者の反応を見ながら柔軟に進行したい方 ・スライドだけでは説明しきれない講義を行う方 ■ 安心して使える設計 オフライン環境でも利用可能。 描画内容や画像データが外部送信されることはありません。 ■ ご利用環境 ・デスクトップPC向けアプリ ・デュアルディスプレイ環境推奨 現在は Windows版のみ Microsoft Store で販売中(500円) ですが、近日中に Mac版もリリース予定です。 https://apps.microsoft.com/detail/9p0w48jdxc62?hl=ja-JP&gl=JP
講義が止まらない｜講義支援ツール Present Pilot
トランジット株式会社では、法人・個人を対象とした 研修を提供しております。 プログラミングやシステム開発、データサイエンス 生成AI活用、人工知能など 現場の経験に基づいた、実践的な内容となっております。 また弊社では法人を対象としたデータ分析のサービスも提供しております。 トランジット株式会社は創業以来、データ分析システムの開発と共に 常にデータと向き合ってきた会社です。 みなさまの会社のデータ、専門家の観点から調査・分析いたします。 興味がある方は、概要欄のリンクから詳細をご覧ください。 また、今回の動画が少しでもためになったという方は 是非、チャンネル登録と高評価の方、よろしくお願いいたします。 それでは、また次回の動画でお会いしましょう。 今回もどうもありがとうございました。 トランジット株式会社: https://trans-it.jp/ ◾️【1. 導入：言葉の定義を疑う】 みなさん、こんにちは。 今回はちょっとだけ昔の話です。 コロナの時期、毎日のようにニュースで「今日の感染者数は〇〇人でした」という言葉を聞いてきましたよね。 実はここに、データサイエンスの視点から見ると非常に大きな「言葉の落とし穴」があります。 テレビで当たり前のように使われている「感染者」という言葉。 実はこれ、正確には「陽性者」のことなんです。 「陽性だったら感染してるんでしょ？」と思うかもしれませんが、統計学的に計算してみると、この2つには驚くほどの差があることがわかります。 今日は、1,000人に1人が実際に感染しているという状況を仮定して、シミュレーションしてみましょう。 【2. 検査の精度を設定する】 まず、PCR検査のスペックを一般的な数値で設定します。 ・感度（感染している人を正しく陽性と判定する確率）：70% ・特異度（感染していない人を正しく陰性と判定する確率）：99% 「99%も正確なら、ほぼ完璧じゃないか」と感じますよね。 では、この条件で10,000人を検査したときの結果を見てみましょう。 【3. 10,000人を検査したシミュレーション】 10,000人のうち、1,000人に1人が感染しているので、 ・実際に感染している人：10人 ・健康な人：9,990人 となります。 まず、感染している10人を検査すると、感度70%なので、 ・7人が「陽性」と出ます（これを真陽性と呼びます） ・3人が「陰性」と出ます（感染しているのに見逃された「偽陰性」です） 次に、健康な9,990人を検査します。特異度が99%なので、1%は間違えて「陽性」と判定されてしまいます。 ・9,990人の1% ＝ 約100人が「陽性」と出ます（感染していないのに陽性と出る「偽陽性」です） さあ、結果をまとめてみましょう。 【4. 陽性だったとき、本当に感染している確率は？】 検査の結果、「陽性」と出た人は合計で何人でしょうか？ 本物の感染者7人と、健康なのに陽性と出た100人を合わせて「107人」です。 テレビはこの107人を「今日の感染者」として報道します。 しかし、この107人の中で、本当にウイルスを持っているのは7人だけです。 計算してみましょう。 7 ÷ 107 ＝ 約6.5% 驚くべき結果です。 もしあなたがこの検査で「陽性」と言われても、実際に感染している確率は、わずか「6.5%程度」しかありません。 残りの93%以上の人は、実はただの「健康な陽性判定者」なんです。 【5. 陰性だったとき、実は感染している確率は？】 逆に、「陰性」と出た人の中に、こっそり感染者が混じっている確率はどうでしょうか。 陰性と出た合計人数は、偽陰性の3人と真陰性の9,890人を合わせて「9,893人」です。 3 ÷ 9,893 ＝ 約0.03% こちらは非常に低いですね。陰性判定の信頼性はそれなりに高いと言えます。 【6. 結び：なぜ「言葉のすり替え」が怖いのか】 なぜこれほど直感とズレるのでしょうか。 それは、そもそも「感染していない人の数」が圧倒的に多いからです。 99%という高い精度の検査でも、分母が巨大だと「1%のミス」が「本物の数」を簡単に追い越してしまうのです。 テレビが「陽性者」を「感染者」と呼び替えることで、私たちは実際のリスクを過大評価してしまっている可能性があります。 データは嘘をつきませんが、その解釈や、使われる言葉一つで、私たちは簡単に事実を見失います。 「テレビの言う『感染者』は、本当に『ウイルスに感染している人』のことだろうか？」 そう一歩立ち止まって考えることが、情報に振り回されないための第一歩です。
「感染者」と「陽性者」は同じじゃない？ニュースの言葉をデータで考える
トランジット株式会社では、法人・個人を対象とした 研修を提供しております。 プログラミングやシステム開発、データサイエンス 生成AI活用、人工知能など 現場の経験に基づいた、実践的な内容となっております。 また弊社では法人を対象としたデータ分析のサービスも提供しております。 トランジット株式会社は創業以来、データ分析システムの開発と共に 常にデータと向き合ってきた会社です。 みなさまの会社のデータ、専門家の観点から調査・分析いたします。 興味がある方は、概要欄のリンクから詳細をご覧ください。 また、今回の動画が少しでもためになったという方は 是非、チャンネル登録と高評価の方、よろしくお願いいたします。 それでは、また次回の動画でお会いしましょう。 今回もどうもありがとうございました。 トランジット株式会社: https://trans-it.jp/ ◾️「なんとなく経営」の末路｜勘に頼らず、同じ失敗を繰り返さないための「データ駆動」入門 データ駆動とは? 勘だけに頼らない経営のはじめ方 ― 小さな会社こそ、データを味方にしよう ― データ駆動という、ちょっと難しい言葉が出てきましたが 今回は会社の意思決定のお話です。 みなさんの会社では、 こんな決め方をしていませんか？ 「たぶん、これがいいだろう」 「去年はこれでうまくいったから」 「なんとなく、これが正しい気がする」 実はこれ、多くの会社で行われているごく普通の決め方です。 そして実際、経験や勘というのはとても大切なものです。 長年やってきた経験と勘というのは馬鹿にできなくて ときとして、鋭い判断ができることもあります。 ですが―― それだけに頼っていると、同じ失敗を何度も繰り返してしまうことがあります。 今日は、その問題を解決する考え方、 「データ駆動」 について、専門用語なしでわかりやすくお話しします。 難しい話はしませんので、安心して聞いてください。 では、なぜ「経験」と「勘」だけではうまくいかなくなるのでしょうか。 たとえばこんな場面です。 ある商品を出したけれど、あまり売れなかった。 そのとき、 「景気が悪かったからだろう」 「タイミングが悪かった」 こう考えて終わっていないでしょうか。 もちろん、そういうこともあるでしょう。 ですが、本当の理由は別のところにあるかもしれません。 値段が高かったのかもしれない。 宣伝が足りなかったのかもしれない。 お客さんが欲しいものと違っていたのかもしれない。 でも――数字や記録が残っていないと、後から振り返ることができません。 つまり、 なぜ失敗したのか。 なぜ成功したのか。 それが分からないのです。 そして分からないまま、また次の判断をしてしまいます。 これが、勘だけの経営の弱点です。 ■経験や勘だけの判断 ● 理由が残らない ● 振り返れない ● 再現できない では、 「データ駆動」とは何でしょうか。 難しい言葉に聞こえますが、やっていることはとてもシンプルです。 「記録を残して、それを見て判断する」 ただそれだけです。 たとえば―― 毎日の売上。 来店した人数。 問い合わせの数。 広告を出した日。 こういうものをきちんと記録しておく。 そして、何かを決めるときにその記録を見ながら考える。 これが、データに基づく意思決定、つまりデータ駆動です。 ここで大切なのは、特別なシステムも、AIも、最初は必要ないということです。 まずは、「記録する」それが第一歩です。 では、データ駆動を始めるために必要なことは何でしょうか。 実は、たった3つです。 3つだけ覚えてください。 ■ データ駆動 ● 記録→判断→改善 1つ目。 「データを取る」 つまり、 記録することです。 たとえば、 毎日の売上。 商品ごとの販売数。 問い合わせの数。 Excelでも、紙でも構いません。 高価なシステムはいりません。大切なのは、続けることです。 1日だけやっても意味はありません。毎日少しずつ、続けることが何より大事です。 2つ目。 「データを見て判断する」 つまり、見て考えることです。 たとえば、 売れている日はいつなのか。 売れていない日はいつなのか。 何をした日に売上が伸びたのか。 こうしたことが少しずつ見えてきます。 すると、 「なんとなく」ではなく、 理由を持って決めることができるようになります。 これが、会社を強くする大きな一歩です。 そして3つ目。 これが一番大事です。 「振り返って改善する」 です。 この方法はうまくいったのか。 もしうまくいかなかったなら、どこを変えればいいのか。 これを考えて、次に活かす。 そしてまた記録する。 この繰り返しが、会社を少しずつ強くしていきます。 いきなり大きく変わる必要はありません。 少しずつでいいのです。 ですが、確実に良くなっていきます。 ここまで聞くと、「うちには難しい」 そう思う方もいらっしゃるかもしれません。 ですが、最初はとても小さくていいのです。 おすすめは、「1つだけ決める」ことです。 たとえば、毎日の売上だけ記録する。 来店人数だけ記録する。 問い合わせ数だけ記録する。 1つでいいのです。 最初からたくさんやろうとすると、続きません。 だから、1つだけ。 それを、毎日続ける。 これだけで、会社の見え方が少しずつ変わってきます。 そして、 慣れてきたら、もう1つ増やす。 さらに慣れたら、もう1つ増やす。 最初はできることから・・・小さなことから始める。 この順番が、成功する会社のやり方です。 では最後に、今日の話をまとめます。 これまで多くの会社は、経験や勘で意思決定をしてきました。 場合によっては、それでうまくいくこともあります。 ですが、それだけでは、再現することができません。 なぜ成功したのか。 なぜ失敗したのか。 それが分からないまま、進んでしまいます。 そこで必要になるのが、「データ」です。 やることは難しくありません。 たった3つです。 記録する。 見て考える。 振り返って改善する。 この3つを続けることで、会社の判断はどんどん良くなっていきます。 そして、失敗は減り、成功は増えていきます。 まずは、明日から1つだけ。何かを記録してみてください。 そこから、データ駆動の経営が始まります。 それでは、今回の内容はここまでとなります。
「なんとなく経営」の末路｜勘に頼らず、同じ失敗を繰り返さないための「データ駆動」入門
トランジット株式会社では、法人・個人を対象とした研修を提供しております。 プログラミングやシステム開発、データサイエンス、生成 AI 活用、人工知能など 現場の経験に基づいた、実践的な内容となっております。 興味がある方は、下記 URL のページをご覧ください。 トランジット株式会社: https://trans-it.jp/ ◾️その平均ズレてます/感覚の真ん中は平均じゃない 平均値のわな みなさん、こんにちは。 今日は「平均値のわな」というテーマでお話しします。 この動画は ・統計が苦手な方 ・数字を見るとちょっと不安になる方 ・ビジネスや教育でデータを扱う方 そんな方にぜひ見ていただきたい内容です。 まず最初に、 統計には「代表値」と呼ばれるものがいくつかあります。 代表値というのは、 「たくさんのデータを、1つの数字で代表させるとしたら、どれにするか」 という考え方です。 その中で今回扱うのは以下の3つです。 ・平均値 ・・・すべてを足して個数で割る ・中央値 ・・・真ん中の順位の値 ・最頻値 ・・・一番多く出てくる値 この3つです。 それぞれを、 感覚的なイメージで説明してみます。 まず「最頻値」。 最頻値は 一番高いところです。 ヒストグラムを思い浮かべてください。 山の一番てっぺん。 一番たくさん出てくる値。 それが最頻値です。 次に「中央値」。 中央値は 面積を二分する場所です。 小さい順にデータを並べて、 ちょうど真ん中にくる値。 「人数で見たときの真ん中」 これが中央値です。 そして「平均値」。 平均値は 釣り合う場所です。 シーソーをイメージしてください。 全員の重さを均等に分けて、 ちょうどバランスが取れる場所。 それが平均値です。 ここがとても重要なポイントです。 もしデータの分布が 左右対称だったらどうなるでしょうか。 この場合、平均値、中央値、最頻値 この3つは、 だいたい同じ値になります。 ところが、 分布が左右どちらかに偏っていると、 この3つはズレてきます。 これが「平均値のわな」が生まれる原因です。 具体例を見てみましょう。 日本人の年収です。 日本人の年収の分布は、 実は左に寄った分布をしています。 どういうことかというと、 多くの人は比較的低い年収帯に集中している 右側に、ものすごく高い年収の人が少数存在している こういう形です。 このときの代表値を見てみましょう。 ・平均値：460万円 ・中央値：407万円 ・最頻値：300万円〜400万円の間 この3つは、すべて違う値になっています。 ここで、よくある話があります。 「日本人の平均年収は460万円です」 これを聞いて、どう感じるでしょうか。 正直に言うと、 460万円って、結構高いな と感じる人も多いと思います。 なぜこんなことが起きるのか。 理由はシンプルです。 ものすごく稼ぐ人が、平均を引き上げているからです。 極端な例を出しましょう。 孫正義さんのように、 何十億、何百億と稼ぐ人がいます。 こういう人が数人いるだけで、 平均値は一気に跳ね上がります。 でも、 私たちの「感覚としての真ん中」はどこでしょうか。 それは、 中央値や最頻値に近いことが多いです。 つまり、 ・平均値＝釣り合いの数字 ・体感の真ん中＝中央値・最頻値 必ずしも一致しない、ということです。 ここが今日一番伝えたいポイントです。 平均値は、決してウソではありません。 でも、万能でもありません。 平均値は 「データの性質を知らずに使うと、誤解を生む」 これが「平均値のわな」です。 ビジネスでも、教育でも、報道でも、 ・平均売上 ・平均年収 ・平均学力 こういった言葉は、たくさん出てきます。 そのときに、 「どのような形の分布だろう？」 「中央値はどうだろう？」 「最頻値はどこだろう？」 と一度立ち止まって考えてみてください。 数字を疑うというより、 数字の意味を正しく扱う。 これが、 統計リテラシーの第一歩です。
その平均ズレてます。感覚の真ん中は平均じゃない
トランジット株式会社では、法人・個人を対象とした研修を提供しております。 プログラミングやシステム開発、データサイエンス、生成 AI 活用、人工知能など現場の経験に基づいた、実践的な内容となっております。 興味がある方は、下記 URL のページをご覧ください。 トランジット株式会社: https://trans-it.jp/ ◾️生成AIって何ができる？専門知識ゼロでも分かる超入門 AIで業務はこう変わる。今話題の生成 AI とは? こんにちは、トランジット株式会社の田中です。 今日は「生成AIとは何か？」「生成AIで何ができるのか？」を、お伝えします。 最近いろんな場面で“AI”という言葉を聞くようになりましたが、「実際に何をしてくれるの？」「どう使えばいいの？」と感じている方が多いと思います。 今日は、専門知識ゼロでも理解できるように、本質だけをシンプルにお話ししていきます。 まず、生成AIとは何か。一言でいうと、 「文章、画像、音声、動画などを“作り出す”AI」です。 従来のAIは、与えられたデータを分析して「分類する・判断する」が中心でした。 たとえば、スパムメールの判定や顔認証、売上予測などですね。 それに対して生成AIは、“新しいものを生み出す”ことができます。 例えば、 ・文章を作る ・アイデアを出す ・メール文を書いてくれる ・画像やイラストを生成する ・プログラムを書いてくれる など、人間が時間をかけていたクリエイティブな作業もAIが行えるようになりました。 ChatGPT、Microsoft Copilot 、Claude、Google Gemini などが代表的な生成AIです。 では、次に生成 AI を使うメリットです。 メリット①：圧倒的なスピード 10分〜1時間かかっていた作業が、AIでは30秒で素案ができます。 メリット②：発想の幅が広がる 「こんな考え方もありますよ」と、別視点のアイデアを提案してくれます。 メリット③：ミスが減る 文章の論理チェックや誤字脱字の確認もできます。 メリット④：一人が“チームの力”を持てる ライター、デザイナー、プログラマーなど複数の役割をAIが代わりに担ってくれます。 小さな会社・個人の生産性は大きく向上します。 つづいて、生成 AI を用いる上での注意点です。 AIを安全に使うためには次の3点に注意が必要です。 ・間違った情報を生成することがある ・個人情報や機密情報は入力しない ・著作権に注意が必要（特に画像生成） 基本的には「AIの出力は素案。判断は人間」が正しい使い方です。 生成AIは、計算で電卓が使われるようになったように 今後はつかうのが当たり前の世の中になります。 上手に使えば、 ・時間短縮 ・生産性向上 ・アイデアの拡張 など、仕事にも生活にも大きな価値をもたらします。 難しい技術ではなく、誰でも使える道具です。 ぜひ、今日から少しずつ触ってみてください。
生成AIって何ができる？専門知識ゼロでも分かる超入門
トランジット株式会社では、法人・個人を対象とした研修を提供しております。 プログラミングやシステム開発、データサイエンス、生成 AI 活用、人工知能など現場の経験に基づいた、実践的な内容となっております。 興味がある方は、下記 URL のページをご覧ください。 トランジット株式会社: https://trans-it.jp/ ◾️DXとはなにか？ツール導入では成功しない理由と、組織のマインドセット 【オープニング】 こんにちは。トランジット株式会社の田中です。 今日は「DXとはなにか？」を、解説します。 まず最初に伝えたいのは、DXは「ITを入れれば成功する」わけではありません。 むしろ、DXの9割は“人と組織”の問題で失敗します。 この動画では、DXがなぜ難しいのか、そして成功している企業は何が違うのかをお話しします。 【DXの定義】 DXとはDigital Transformation、デジタルによる変革のことです。 「デジタル技術を使って、ビジネスや組織のあり方そのものを変えること」が本質です。 紙をやめた、Excelからシステムに移行した、クラウドを導入した。 これらはDXではなく、単なるデジタル化・IT化です。 DXは“変革”が目的で、ツールは手段にすぎません。 【よくある誤解：IT導入＝DXではない】 日本企業で非常に多い誤解が「ツールを導入したからDXが進んでいる」というものです。 RPAを入れました。AIを導入しました。 こういう話はよく聞きますが、業務のやり方が変わっていない企業はたくさんあります。 ツール導入はDXの入り口ですが、DXそのものではありません。 【DXが失敗する理由】 DXが失敗する最大の理由は技術ではありません。 技術が原因で落ちるのは1割程度です。 9割は「人と組織のマインド」が原因でつまずきます。 なぜなら、人は慣れたやり方を変えたがらないからです。 新しいシステムが入っても、結局Excelに戻る。 改善提案を出すと「余計なことをするな」と言われる。 属人化していて、担当者が辞めた瞬間に使われなくなる。 こうした文化が残っている限り、DXは絶対に成功しません。 【なぜマインドセットが必要なのか】 DXとは“考え方を変える活動”だからです。 「今までのやり方が本当に最適なのか？」と問い直し、 業務そのものを作り替えていく必要があります。 そのためには、組織全体に「変わっていこう」という姿勢が必須です。 トップだけがやる気でもダメ。 逆に現場だけが頑張っても続きません。 トップ・管理職・現場の三者が、 「小さく試して、改善しながら前進する文化」を共有しているかどうか。 これがDXを成功させる土台になります。 【成功事例：スシロー】 スシローはDXの代表的な成功企業です。 ポイントは「現場×デジタルの融合」です。 AIを使った食材ロス削減。 回転レーンの流量をデータで最適化。 客数予測をAIでおこない、廃棄を大幅に削減。 オペレーションも見える化され、従業員の負担が減りました。 何より重要なのは、現場スタッフがデジタルを自分ごととして扱える文化があったことです。 つまり、組織として“変わることに前向き”だった。 これが本当の成功理由です。 【成功事例：病院】 病院のDXも非常に効果が出ています。 電子カルテの統合、患者案内のデジタル化、動線の最適化。 これにより看護師の残業が大幅に減り、患者の待ち時間も減少しました。 「仕事が楽になる」ことを現場が実感できたことで、 スタッフがデジタルを積極的に使うようになりました。 ここでも成功要因は、技術より「現場が納得し、文化が変わったこと」です。 【成功企業の共通点まとめ】 DXに成功している企業には共通点があります。 ・現場を巻き込む文化がある ・失敗を許容する ・小さく試す ・属人化をやめる ・トップが変わる姿勢を示している これらはすべて「マインドセット」に関係するものです。 ツールは後からいくらでも変えられますが、 文化が変わらなければDXは一歩も進みません。 【DX成功の4つの要素】 ここまでを踏まえて、DX成功に必要なマインドセットを4つに整理します。 トップがまず変わる姿勢を見せること 属人化しない仕組みづくりを意識すること 小さく試し、改善する文化を作ること ツールは目的ではなく手段だと理解すること これが企業のDX成功を下支えします。 【まとめ】 DXとは「デジタルによる変革」です。 デジタルは確かに大事ですが、 その前に「変革を受け入れる組織のマインドセット」がなければ成功しません。 技術よりも文化のほうがはるかに重要です。 自社のDXをどこから始めるべきか迷っている方は、 よければ一度ご相談ください。 トランジット株式会社では、システム開発だけでなく、 「作って終わり」ではない、活用支援まで伴走します。
DXの9割は人で決まる/ツール導入だけでは絶対に上手くいかない理由
チャンネル登録
ビジョン図鑑に掲載されました

お知らせ

  • 「ビジョン図鑑」にインタビュー記事が掲載されました (2026年10月16日)
  • HUPO で発表しました (2026年10月1日)
  • ASMS で発表しました (2026年6月6日)
  • 二度目の出版『AIと勉強する HTML & CSS + JavaScript』が発売されました。 (2026年2月3日)
  • YouTube チャンネルを公開しました (2025年11月21日)
  • 日本生化学会大会で発表しました (2025年11月5日)
  • お客様のところで講師紹介ビデオを作成していただきました。 (2025年9月25日)
  • AOMSC 2025 @石垣島 で発表しました。 (2025年6月25日)
  • アンドエンジニアから取材をうけました。 (2025年1月25日)
  • ASMS2024@アナハイム で発表してきました。 (2024年6月10日)

    • 最新投稿

  • .heic ファイルを一括で .jpeg に変換してみた。 (2025年1月30日)
  • API を用いてAmazon の商品画像を取得してみた。 (2024年3月10日)
  • JavaScript で郵便番号検索をやってみた。 (2024年3月10日)
  • WordPress でカスタム投稿とカスタムフィールドを追加してみた。 (2024年3月10日)
  • プログラミング学習5つのコツ (2024年3月9日)
  • 書籍『世界トップリーダー1000人が実践する時間術』 (2024年3月3日)
  • Stable Diffusion を使って Python で絵を描いてみた。 (2024年3月2日)
  • Java で JSON を扱ってみた。 (2024年2月18日)