はじめに

流通事業部の内堀です。

フューチャー社内の有志メンバーでテクニカルライティングガイドラインを作成し公開しました！

設計書、Pull Requestの説明、Slackでの相談、障害の一次報告。ITコンサルタントの仕事は、文章を書くことと切り離せません。本ガイドラインが対象にするのは、こうした日々の文章そのものです。専門的な概念を構造化し、判断に足る情報を示して意思決定を推進するための技術をまとめました。

本記事では、ガイドライン作成の背景と全体像、そして内容の一部を抜粋して紹介します。

なぜテクニカルライティングをガイドライン化したのか

本ガイドラインは、これまで個人のセンス頼みだった「説明力」を、誰でも参照できる形式知へと落とし込むために作成しました。

こんな場面に心当たりはないでしょうか。

• 丁寧な状況共有をもらったが、結局自分が何をすればいいのか分からず「で、何をしてほしいの？」と聞き返した
• レビュー依頼を受けたものの、どこをどのレベルで見ればいいのか判断できず、着手を後回しにしてしまった
• Pull Requestの説明が「実装しました」「テストコードを追加しました」の羅列で、なぜその変更が必要なのかが読み取れない

どれも、書き手に悪意や手抜きがあるわけではありません。単に「こう書けば伝わる」という型を持っていないだけです。

コードにはコーディング規約があり、設計には設計ガイドラインがあります。一方で、私たちが業務時間の中で最も多く生産しているアウトプットである文章には、これまで拠り所となる基準がありませんでした。「分かりにくい」という指摘が指摘する側の感覚に依存し、指摘される側は何を直せばいいのか分からない。この状態を解消したいというのが、本ガイドラインの出発点です。

ガイドラインの全体像

本ガイドラインは、文章を書く一連の流れに沿った5つのフェーズで構成されています。

前半の「設計」「執筆」は個人の書く力、後半の「品質向上」「育成」はチームの書く力に軸足を置いています。通読する必要はなく、気になるフェーズから拾い読みできる構成にしています。

ピックアップトピック

ボリュームがあるため、ここでは特に汎用性の高い3つのトピックを抜粋して紹介します。

事実だけでなく見解まで述べる（空・雨・傘）

空・雨・傘は、メッセージを設計する際の論理展開の基本となるフレームワークです。

• 空（事実）: 空に黒い雲が出ている（客観的な状況、調査結果）
• 雨（解釈）: 雨が降りそうだ（事実に基づく分析や課題の特定）
• 傘（見解）: 傘を持っていこう（取るべきアクションの提案）

実務の報告では、空と雨だけで止まってしまうケースが多くあります。ガイドラインでは、次のような報告を典型例として挙げています。

〇〇について調査したところ、▲▲に課題がありました

この報告だけでは、読み手は「つまり、自分は何をすればいいの？」をゼロから考えなければなりません。相手が知りたいのは「あなたがどうしたいのか」あるいは「私は何をすればよいのか」という傘の部分です。
事実をただ羅列するのではなく、そこから何をするべきかを示すことで、仕事を前に進めることができます。

結論から述べる

一生懸命いろいろと書いてくれているのに、結局何が言いたいのか分からない。誰もが一度は受け取ったことのある文章ではないでしょうか。
Yes/Noを問われているのに周辺情報から書き始めると、結局どちらなのかの判断は読み手任せになります。ガイドラインでは「ゲストユーザーでも資料はダウンロードできますか？」という問いへの回答を例に挙げています。

❌ NG

ダウンロードボタンの権限を確認したところ、現在は会員のロールのみ許可フラグが立っています。
このため、ゲストユーザーですと、ボタンが非表示になるため、ダウンロードはできません。

✅ OK

ゲストユーザーはダウンロードできません。
現状の仕様では権限が正社員に限定しているためです。

内容は同じですが、後者は1文目で問いに答えています。調査の過程を前に置かず結果から返すことで、読み手は最短時間で次のアクションに移れます。

答えが出ていない場合も同じです。「いつまでに〇〇ボタンの仕様は確定しますか？」と聞かれた場面を考えます。

❌ NG

現在、〇〇チームに確認をしているところで、まだ返事がきていないです。
後ほどリマインドを入れておきます。

✅ OK

現時点では未定です。
本日17時の進捗会議後に改めて回答します。

NG例では、状況の説明に終始してしまっており、質問者が一番知りたい「いつまでか」に答えられていません。未定であることも回答のひとつです。問われた要素に直接答えることで、認識のズレのないやりとりができます。

5W1Hで解像度を上げる

依頼や相談は、書き手の想像以上に、読み手にとって必要な情報が抜けがちです。情報の非対称性によるコミュニケーションミスを防ぐために、5W1Hをチェックリストとして使います。ここで重要なのは、書き手ではなく相手の立場に立って考えることです。ガイドラインでは、次のような依頼を典型例として挙げています。

AとBどちらが良いですか？
IAMロールを追加してよいですか？

こういった質問だけでは、読み手は判断できません。影響度・リスク・作業時間・代替案など、意思決定を下すために必要な比較材料を提示する責任は、書き手にあります。

あわせて確認したいのが、読み手にどのようなアクションを取ってほしいかです。単なる状況の共有なのか、A案かB案かの選択なのか、作業の承認なのか。ここが曖昧だと、傘が抜けているのと同じで、読み手に負担をかけてしまいます。
期限も同様です。都合の良い期限と、それを超過すると業務影響が出る最遅の期限の両方を伝えると、読み手に優先度を考える余地が生まれます。

同じ発想はレビュー依頼にも当てはまります。「どこを、どのレベルで見てほしいのか」を伝えることで、レビュー内容のミスマッチを防ぎ、リードタイムを短縮できます。

レベル別の読みどころ

ジュニアからシニアまで、それぞれの立場で明日から使えるトピックがあります。どこから読むか迷ったら、次の表を参考にしてください。

特にシニア向けの「フィードバック技術」は、本ガイドラインの特徴的な章です。書く側の作法だけでなく、レビューする側の作法にも踏み込みました。

おわりに

ライティングはセンスではなく、型を知って繰り返し練習すれば誰でも上達できる再現可能なスキルだと考えています。全部を通読する必要はありません。まずは気になるところ、今すぐ使えそうな場所から開いてみてください。

ガイドラインは公開してからが本番なので、実務で使ってみた感想やフィードバックをいただけると嬉しいです。

• テクニカルライティングガイドライン: https://future-architect.github.io/arch-guidelines/documents/forTechnicalWriting/technical_writing_guidelines.html
• GitHub: future-architect/arch-guidelines

最後に、議論・執筆にご協力いただいた有志メンバーの皆さんに感謝します。

初めまして。2025年10月入社、製造・エネルギー事業部の佐々木です。

2026年3月17日(火)～19日(木)に東京ビッグサイトで開催されたSMART ENERGY WEEK春に参加してきましたので、当日の様子をレポートします！

イベント概要

SMART ENERGY WEEK春は世界最大級の新エネルギー総合展であり、水素・燃料電池、太陽光発電、二次電池、スマートグリッド、洋上風力、バイオマス発電、ゼロエミッション火力などあらゆる技術が出展し、世界各国から専門家が来場する展示会です。

SMART ENERGY WEEK春では以下の7つの構成展が開催されており、3日間で累計63,274人が来場しました。

• SMART GRID EXPO スマートグリッド展
  VPPを実現する技術やエネマネ・蓄電池などの設備が出展する電力システムの総合展。
• PV EXPO 太陽光発電展
  太陽光発電所の建設から保守・運用に係るあらゆる製品が出展。
• BATTERY JAPAN 二次電池展
  二次電池の研究開発、製造に必要なあらゆる技術、部品・材料、装置、二次電池が出展。
• H2 & FC EXPO 水素燃料電池展
  水素・燃料電池の研究開発、製造に必要なあらゆる技術、部品・材料、装置、燃料電池システムが出展。
• WIND EXPO 風力発電展
  北海道から九州まで全国の風力発電の専門家、技術者が来場。
• BIOMASS EXPO バイオマス展
  北海道から九州まで全国のバイオマス分野の専門家が来場。
• ZERO-E THERMAL EXPO ゼロエミッション火力発電展
  電力・ガス会社、発電事業者、プラントメーカーなど火力発電の専門家が全国から来場。

会場の様子(公式YouTubeより)

セミナー聴講

今回のイベントでは2つのセミナーを聴講しました。そこで見聞きしたことを記します。

AI時代の電力システムと「ワット・ビット連携」

世界的に増加する電力需要とボトルネック

産業、空調、データセンターなどにより世界の電力需要が大きく伸びている。また再生可能エネルギーや原子力による発電量は過去最高を記録し、2030年までには世界の電力の半分が再生可能エネルギーや原子力で作られるようになる。

しかし、送電網への投資は発電容量への投資に追いついておらず、現状、ボトルネックとなってしまっている。

データセンターに係る課題とワット・ビット連携

世界的にも、日本国内でもAIの利活用の増加に伴いデータセンターの需要が急増している。

そんな中、電力系統の接続に時間を要し、データセンター新設に10年以上かかってしまうことで、海外に投資が流出する恐れがある。
そこで既存の電力インフラ、脱炭素電源に接続しやすい地域にデータセンターを誘致し、電力インフラにあわせて通信インフラを整合的に整備する「ワット・ビット連携」を行うことが非常に重要になってくる。

フィジカルAIとデータセンター

現在日本では、「ワット・ビット連携」の政策が行われている。

コンビナート跡地、脱炭素電源集積地などにデータセンターを各地に集積させ、さらに周囲の工業地帯がデータセンターを利用する新たな産業クラスターを日本各地に作ることが計画されている。現在の東京、大阪にデータセンターを集中させるのではなく、地域分散型で配置する。

日本の産業はフィジカルAIと親和性があり、データセンターの活用が今後の経済の発展に必要不可欠となる。フィジカルAIを最大限活用するには通信速度を可能な限り速くする必要があり、その観点からも、地域分散型でデータセンターを配置することは一極集中型にデータセンターを配置することよりも非常に有用である。

分散型電源時代の系統運用とアグリゲーション

GX政策により変化した電力インフラの構造

従来の電力インフラはウォーターフォール型であり、大規模な火力発電所から需要側に向けて一方向に電気が届く構造であった。

近年のGX政策により、再生可能エネルギー電源が各所に作られ、そのウォーターフォール型構造が変化している。これにより下流(需要側)にも発電所ができ、電気の流れが双方向化した。

変化した電力インフラの構造が抱える課題

ウォーターフォール型の構造が崩れ、電力の流れが双方向化することによって次の課題が起きてしまう。

1. 電気の流れが双方向になり混雑が発生する。
2. 特定の地点、特定の時間で混雑が発生する。
3. 送電網のキャパシティに限界があり、混雑を回避するために出力制御が行われる。(実質的に電気を捨てる)

太陽光発電を例にすると次のような具体例となる。

1. 火力発電所と太陽光発電所の双方から電気が作られ、電流が双方向から流れる。
2. 太陽が昇っている日中(特に正午)に太陽光発電所の発電量が増え、一時的に送電網のキャパシティの上限に達する。
3. 結果として発電量の出力制御を行い、機会損失が生まれる。

実際に2026年の九州電力の出力制御の見込みは年間発電量の6.9%(12.2億 kWh)となる。(出典：2026年度出力制御見通しについて 九州電力送配電㈱)
その他の地域の出力制御量が気になる方はこちら。

ローカルバランシングによる課題の解決

上記の混雑を解消するには送電網のキャパシティを増やすことが必要である。

しかし送電網のキャパシティを発電量が超えるのは一時的なものであるため、送電網に対する投資効果は非常に悪いものとなる。

そこで解決策として考えられるのが「ローカルバランシング(ローカルフレキシビリティ/バランシンググループ)」という考え方である。ローカルバランシングとはITと蓄電池を活用し、特定の地域や系統（ローカル系統）内での再生可能エネルギーの需要と供給を調整し、安定させることである。

ローカルバランシングは以下のような流れで行われる。

1. IT(スマートメーター)により混雑の発生を検知し、出力を制御するのではなく、蓄電池に向けて電気の流れを切り替え、電気を貯める。
2. 発電量が少なくなり、送電網のキャパシティに余裕が生まれたら蓄電池に貯めた電気を放出する。
3. 最終的に既存の設備の価値を最大限活用できる。

まとめと感想

今回聴講した講演ではどちらも、電力に関する投資は「作る」から「貯める」や「運ぶ」に移り変わっていることを強調していました。

また今回のSMART ENERGY WEEK春でもSMART GRID EXPO スマートグリッド展の会場が最も広く、出展企業も多く、会場の雰囲気としても
「貯める」や「運ぶ」に関するソリューションの盛り上がりを感じられました。

以上、SMART ENERGY WEEK春の参加レポートでした。

はじめに

こんにちは。Core Technology Groupに所属する土屋です。

本記事では、ITを主軸に仕事をしてきた人間が新規事業開発の「仮説検証」を行った際に直面した壁とそこから得た気づきについて共有できればと思います。

このブログを3行で

• 社内の新規事業開発ピッチに参加した。
• AIとの壁打ちだけで、顧客ヒアリングをした気になってはいけない。
• 「まずはIT実装」は危険。初期コストが新規事業のボトルネックになり得る。

私の生い立ち

私は学部・大学院ともに情報系に所属し、大学院では画像解析を専攻していました。
フューチャー株式会社に入社後もPoCや社内R&Dで一貫して開発し早3年たちました。

参加した社内の新規事業開発ピッチについて

当社には、社員の新規事業への取り組みを応援する仕組み、通称FIBP（Future Innovation Boost Program）があります。

プログラムの詳細は以下をご参照ください。

• https://note.future.co.jp/n/ndd2493c4541d?magazine_key=mc4cc99038085

今年度は大きく外部講師による新規事業開発の講義と参加者の実際の仮説検証からなり、最終的にスタートアップ投資委員会のメンバーやFIBPに関わっている先輩方へピッチを行います。

本ブログでは、このプログラムで私が実際にぶつかった2つの壁とそこからの学びを中心に述べたいと思います。

第1の壁：顧客との接点の壁と逃げのAI

私は「海外進出支援」という大きなテーマから深堀りし、新規事業を作れないかと考えました。

まず最初に行うのは課題を抱えている企業担当者へのヒアリングです。

しかしこれが想像以上に難しかったです。特に 「課題を持っている人」とつながること自体が非常に困難でした。

門前払いの連続と、課題の解像度の限界

最初に試したのはメールです。

色々な企業にお話を聞かせてくださいとメールを送りましたが、ほとんどメールに返信がありませんでした。冷静に考えれば、相手企業の利益につながる明確なメリットがなければ、メールにリアクションなんてしてくれないのです。

プロダクトを作るには、解像度の高い課題のヒアリングが必要です。

しかし解像度を高めるためのヒアリング先が見つからず、解像度が低いままプロダクトを作っても結局誰にも刺さらないゴミが出来上がってしまいます。

「AIとの壁打ち」≠「顧客ヒアリング」

アポが取れないと、つい手元のAIに頼りたくなります。今の時代、AIと壁打ちすれば「もっともらしい課題の仮説」はいくらでも作ることができます。

しかし、その課題を「本当に」抱えている人はどれだけいるのでしょうか？そして、その課題を解決することに対して、顧客は本当にお金を払う価値を感じてくれるのでしょうか？

プログラミングでAIを使う際、出力されたコードはテストや動作確認などですぐに検証できます。テストが通ったからといって「良いコード」とは限りませんが、少なくとも「動作する」という品質の最低ラインは保証できます。

一方、事業開発における「市場仮説」の検証において、テストや動作確認などの役割を担うのが、「顧客へのヒアリング」 です。

AIが出したもっともらしい仮説も、顧客にぶつけてフィードバックをもらわない限り、テストをしていないコードと同じで、動く保証がどこにもないのです。顧客に何度も会って、仮説に対する生のフィードバックを何度ももらい、修正し続ける必要があります。

AIと会話して顧客と話した気になってはいけません。

「課題解決を手伝ってくれるパートナー」を早期に確保し、関係性を継続することがいかに重要か。普段、当社のプロジェクトがお客様との良好な関係を継続していることのすごさを改めて痛感しました。

（ちなみにですが、最終的には名刺交換会などの対面が一番連絡を取りやすかったです。）

第2の壁：「いきなりITで解決する」の罠

何とか課題の輪郭が見えてきた後の話です。

技術がわかる人であれば誰しも一度は陥る最大の罠があります。「あれもこれも作りたい」という実装欲です。

私も御多分にもれず、ITを通した解決策ばかりが頭をめぐりました。色々ITでの解決を妄想するのはとても楽しいのですよね。特に昨今はAIの進化が目覚ましく、「あれもできる、これも自動化できるだろう」と夢が広がってしまいます。

しかし、冷静になって事業計画（コストと売上）を立ててみると、「いきなりITで解決する」ことの不合理さ を体感しました。

1. 見えにくい「開発・保守コスト」の積み上げ

アプリで課題解決をする場合、コードを書く以外にも多くの「付帯コスト」がかかります。

• 決済機能の実装： マネタイズするなら必須ですが、Stripeなどを組み込むだけでも相応の実装・検証コストがかかります
• AIの不確実性： 「AIで自動化」は言葉にするのは簡単ですが、意図した出力を安定させるにはプロンプトの膨大な試行錯誤が必要です
• APIの改廃リスク： 外部APIは仕様が変わったり停止したりします。特にAI関連のAPIは改廃が早く1年以内にサービス終了することも多いです

2. 「サブスクモデル」の収益化の遅れ

ITアプリの多くはサブスクリプションモデルになるでしょう。

しかしこれこそが初期の新規事業の足かせとなる可能性があります。

売上は「単価×有料ユーザー数」です。ユーザー数を増やすには地道な営業か広告宣伝が必要です。認知のない初期フェーズでユーザーを集めるにはかなりの広告費がかかります。開発費に加えて広告費がかさむ一方で、月額の売上は雀の涙です。

累計黒字化がはるか先になってしまいます。

3. 検証サイクルの鈍化

これが最も致命的かもしれません。

ITのアプリをしっかり作りこもうとすると、それこそAIの検証などもあるため、リリースまで半年～1年はかかります。その間、市場の反応は見られません。「一年かけて苦労して作ったのに、出してみたら誰も使わなかった」が起こりえてしまいます。

このリスクを抱えたまま開発を続けるのはあまりに不健全です。

2つの壁からの気づき

1. 「AI依存」への自戒と、ヒアリングの重要性

どんな新規事業でも、多くの顧客が本当に解決したい課題でなければ市場に受け入れてもらえません。

仮説の精度を高めるためには、必ず「人間」からのフィードバックが必要です。

昨今のAIは非常に優秀で、相談すればとても賢い回答をしてくれます。そして多くのAIはユーザーの考えを肯定して褒めてくれることが多いです。

そんな優しいAIとばかり壁打ちを続けていると、思考がどんどん現実から離れていってしまいます。AIは仮説検証の補助ツールとしては優秀ですが、仮説の検証はできません。お金を払うのは、AIではなく人間です。

一緒にFIBPで仮説検証した方とも話しましたが、「AIには出せない、人間だからこそ出せる価値」とは、 「現実の他者との対話から得られる一次情報」 にあると考えています。

2. ITは「拡張ツール」である

一度立ち止まって考えてみます。

パートナーの課題を解決するのに、最初からITは本当に必要なのでしょうか？規模と時間さえ度外視すれば、ITでできることの多くは、人力でも代用可能です。

ITの本質的な価値は「省力化」と「規模拡大」 だと考えています。

だとするならば…

1. 最初の数人の顧客に対してはITを使わずに人力で手厚く課題解決して対価をもらう。
2. そこで確実な収益を得て、その収益を元手に規模を拡大し、利益率を上げるためにITで作業を代替していく。

…この順序が正解だと考えています。

1はいわゆるPoCと呼ばれるものですが、PoC後も人手による課題解決は多分に残っても良いと私は考えています。人手の収益化をゴールにおいてはいけませんが、IT実装を見据えすぎてもよくありません。

私はITが好きでつい「How（どう作るか）」から入ってしまいます。しかし顧客がお金を払うのは「ITシステムそのもの」に対してではなく…

「課題が解決されたという事実」 に対してです。

ITという手段に盲目になってはいけませんでした。

さいごに

今回のFIBPプログラムを通じて新規事業開発における重要な点を2つ学びました。

1. 入念な顧客ヒアリングをし、課題の解像度をとにかく高めること。
2. 課題の解決策をITありきで考えないこと。

いろいろな方がすでに体感している当たり前のことかもしれませんが、

これから新規事業に挑戦する技術者の方々へ、少しでも参考や気づきになれば幸いです。

TIGの真野です。

フューチャーの有志で作成している設計ガイドラインの新作「ソフトスキルガイドライン」の発表です。

https://future-architect.github.io/arch-guidelines/documents/forSoftSkill/softskill_guidelines.html

これまではAWSやWeb API、データマネジメントといった技術的な設計指針を中心に公開してきましたが、少し趣向を変えて「非」技術領域にフォーカスしたコンテンツを公開しました¹。

本記事では、なぜ今「ソフトスキル」をテーマにしたのか、その背景とガイドラインの概要について紹介します。

なお、本ガイドラインはフューチャーの有志メンバーが「アーキテクトにはこういう能力が必要だよね」という観点を持ち寄って整理したものであり、実験的な位置づけのドキュメントです。

なぜ今「ソフトスキル」なのか

アーキテクト的なロールの人には、技術的な正しさだけでなく、ビジネスと技術の翻訳や様々な利害関係者を繋ぎ、プロジェクトを成功に導く能力が求められているかと思います。

この場合は、技術力は唯一絶対的な指標ではなく、要素の1つであると考えました。

• 技術力 ✖ ソフトスキル ✖ アセット ≒ 貢献/成果

技術力をレバレッジとして効かせる1つの要素がソフトスキルだと考えています。アーキテクトロールに付く人にとって、技術力とソフトスキルはある意味、車の両輪の様な関係性でしょう。

どれほど優れたアーキテクチャを設計できたとしても、それを顧客やチームに納得させ、実行に移すことができなければ、ビジネス価値は生まれません。技術特化型のスペシャリストも重要ですが、技術力を武器にビジネス視点を持ってレバレッジを効かせる「ジェネラリスト型アーキテクト」的なキャリアパスを進んでいる人も多い。そうした思いから、これまで少なくても当社では暗黙知とされがちだった「立ち振る舞い」を体系化することにしました。

5つのコア・ソフトスキル

本ガイドラインでは、アーキテクトに必要なソフトスキルを以下の5つに分類しています。

それぞれの関係性は以下で、1～3はプロジェクト遂行で必要な本業（？）スキル、4は対話/合意形成が特に重要だとしてトップレベルに昇格、5はその他貢献といった具合です。

graph TD
    subgraph プロジェクト遂行プロセス
        direction LR
        A[①状況把握力
Input: 環境・課題の理解] --> B[②作戦力
Plan: 道筋の設計]
        B --> C[③推進力
Do: 計画の実行]
    end

    D(④説明力
Support: 対話・合意形成)

    E(⑤組織開発力
Meta: 組織への還元・育成)

    %% 説明力は全プロセスをサポートし、推進に必要
    D -. 推進に必要 .-> C

    %% プロセスの成果が組織開発に繋がる
    プロジェクト遂行プロセス == プロジェクトの成果・知見 ====> E

それぞれ、簡単に紹介します。ガイドラインにはもう少し細かく整理されています。

① 状況把握力

背景にある考え: 技術力が高くても、状況把握を誤れば価値を生みだせないでしょう。技術力には自慢があってもイマイチ刺さらない、一般論から踏み出せないときは状況把握が不足しているかもしれません。

• 業務知識
  • 業界知識（トレンド、課題）
  • 事業理解力（ビジネスモデル、収益源）
  • 業務理解力（業務フロー、意思決定プロセス）
• 顧客理解
  • 経営目標の理解（中期経営計画など）
  • 企業文化の理解（価値観、スピード感）
  • 組織力学の理解（非公式なキーマン、意思決定プロセス）
• 関係理解
  • 案件の理解（背景、経緯）
  • 契約の理解（スコープ内外の判断）
  • 提案（スコープ外対応、次フェーズへの種まき）

顧客のビジネスモデルや業界知識はもちろん、組織力学（キーマンは誰かなど）、契約スコープなどを正確に理解する能力です。AI時代的な表現では、コンテキストを獲得する能力といえば良いでしょうか。

「あるべき論」としてのアーキテクチャは重要ですが、それが顧客の企業文化や予算・納期の制約の中で機能するかどうかを見極めるためには、正しい状況理解が不可欠です。一般論を振りかざしても意味がないのはどこでも伝わる話でしょう。

また、アーキテクチャのもっともらしさ（それで大丈夫なのか？）は、究極的にはビジネス目標を達成できれば良いとも言えると思います。そのため、超マクロで見ればアーキテクチャはビジネスゴールや目標の射影です。この理論でいけば、アーキテクチャ設計者は、事業（業務）担当者と同じ目線、課題意識を持つと話が早く、より精度が高いものを考え出せるでしょう。

② 作戦力

背景にある考え: アーキテクトには、ゴールが不明瞭な状態でも、仮説ベースで実現可能な計画を作り出しチームを導くことが求められます。決めてくれたらやりますではなく、決める側に徐々に移ってきたのです。

• 構想力
  • ゴール設定（成功の定義）
  • 課題抽出（将来の問題を探索的に発見）
• 計画力
  • 計画作成力（スケジュール、マイルストーン、勝ち筋）
  • リスクマネジメント（早期の対応案）
  • 体制構築（最適なチーム構成、役割定義）

不確実性が高いプロジェクトにおいて、ゴールから逆算したWBSやスケジュールを引き、リスク対策を早期に計画して「勝ち筋」を描く能力です。

単にタスクをこなすのではなく、将来問題になり得る課題（技術、ビジネス含めて）を探索的に見つけ出し、先手を打つことが求められます。そういった勘所を働かせられると、頼られる存在になると思います。

③ 推進力

背景にある考え: 技術力が高まると意見を求められる場面が増え、評論家に陥ってしまう場合があります。そうではなく当事者として最後までやり抜き、アーキテクチャを実現することが求められます。

• リーダーシップ
  • 不確実性耐性（仕様不明確でも前進させる）
  • オーナーシップ（他責にせず最後までやり抜く）
  • ディレクション（プロジェクトの大義を浸透させる）
  • 意思決定（複数選択肢からの決断）
  • 動機づけ（メンバーへの意義の説明）
  • 巻き込み力（有識者への相談、支援要請）
• プロジェクトマネジメント
  • WBS策定（見積もり、タスク分解）
  • 進め方の合意（マイルストーン、検証ポイント）
  • タスク依頼（背景説明、適切なアサイン）
  • 予実管理（遅延検知、リカバリープラン提示）
• チームマネジメント
  • 役割分担（スキルや志向を考慮）
  • チーム運営（ルール、プロセス改善）
  • 調整力（タスク調整、利害対立の解消）

技術的な意思決定にオーナーシップを持ち、結果に責任を持つ力です。職務経歴書を鮮やかにするための技術選定は忌避されるべきです。新技術の導入は（実際にそうかはさておき少なくてもその時点では）最後までやり抜く覚悟があって行うべきとされることが大多数でしょう。

また、仕様が不明確な状況でも自ら働きかけたり、進捗遅延に対して自律的にリカバリープランを提示したりと、プロジェクトを前に進めるための「リーダーシップ」と「マネジメント」の両面を含みます。

最終的にどこに着地させようと考えているのか、最悪ここまでは達成させたいのでそのための施策は～など、走りながら考え、常にプランB, Cを持っておく必要があります。もちろん、それらと同時にメンバーを離脱させては推進どころではないため、スキルや志向にあった役割分担や、人心掌握的な声掛け（褒めたり適切なフィードバックをしたり）などもケアする必要があります。

④ 説明力

背景にある考え: 相手の立場や知識レベルに合わせ、納得感のある合意形成を図ることで、その意思決定に価値が生まれます。

• 価値訴求 & 合意形成
  • 魅力づけ（一貫した物語として語る）
  • 論点設定（議論すべきテーマの設定）
  • 仮説立案（解決策の提示、メリット・デメリット）
  • 比較整理（判断軸を想定した多角的な評価）
  • 合意形成（戦略的な根回し、信頼関係構築）
  • 期待値コントロール（実現可能性の伝達）
• コミュニケーション
  • 簡潔さ（PREP法、要点の絞り込み）
  • 表現力（デフォルメ、比喩、抽象化）
  • ドキュメント力（構造化、視覚的な美しさ）
  • 傾聴力（真意の推測、非言語情報の読み取り）
  • 対話力（深い議論への誘導、建設的な対立）
  • 質問力（深掘り、潜在ニーズの引き出し）
  • ファシリテーション（発散と収束、合意への誘導）

技術的な価値を、顧客（非エンジニア）やビジネスサイドに伝わる言葉へ「翻訳」し、合意を形成する力です。

どれだけ優れた設計やシステム構築ができたとて、それを伝えてナンボです。正しく価値訴求し評価されることで、もっと良いものを作ろう！ といったモチベーションにも繋がります。長期的に健全な関係性づくりはビジネス的にも重要です。

そのためには、「なぜこのアーキテクチャなのか」といった一貫したナラティブであったり、戦略的な根回しや構造化されたドキュメント作成を通じて、納得感を重視した合意形成が必要です。

⑤ 組織開発力

背景にある考え: 個人の知恵を組織の資産へすることで、組織の持続可能性を高めます。優秀であればあるほど、組織レベルの貢献も求められるでしょう。だれしもが良い組織文化のある企業に所属したいと思いますが、その文化を生み出す側にあなたは立っているかもしれません。

• タレントマネジメント
  • 採用（スキル・カルチャーの見極め基準言語化）
  • 育成（コードレビュー、1on1、適切な裁量付与）
  • 評価（納得感のあるフィードバック）
• ナレッジマネジメント
  • アセット化（成果物の汎化・標準化・再利用）
  • ナレッジトランスファー（アセットの共有・改善サイクル）
• 組織文化 & ブランディング
  • 心理的安全性（失敗の開示、オープンな対話）
  • 自己研鑽支援（相互学習、勉強会の企画）
  • ブランディング（外部登壇、執筆、発信文化の醸成）

個人の知見を「組織のアセット」に変え、採用・育成・外部発信を通じて組織全体のケイパビリティを強化する力です。

自分一人が優秀なだけではなく、ナレッジを形式知化して後進を育成し、自分が抜けても回る仕組みを作れるかは、レポートライン（先輩社員）から見ても重要な観点でしょう。

20代、30代ですとまだまだプレイヤーとしての成長意欲が強いと思いますが（私も30代です）、立場が上がるとより部署/全社的な視点での貢献が求められ始めます。自社の組織課題/技術課題についての不満を言うだけではなく、実行することはそれ自体チャレンジングな取り組みかと思いますので、いっそ自分事にして取り組んでしまうのもお勧めです。

スキルレベルと期待値

ここまでの説明ではスキルという概念は登場しませんでした。実際のガイドラインでは、各項目ごとに3段階のレベルを定義しています。

• Level 1 【認識】: 重要性を理解し、サポートがあれば実行できる
• Level 2 【実践】: 独力で標準レベルを遂行できる。とりあえず目標にすべきレベル
• Level 3 【指導】: 他者を指導し、新しい仕組みを生み出す

全ての項目で満点を取る必要はありません。得意分野でチームを牽引しつつ、苦手な領域でもLevel 1（認識）を持っておくことで、チームとして補完し合える状態を目指しています。

おまけ話

実はこのガイドライン、作成メンバーの永井さんと議論している際に「この内容はエンジニアリングマネージャー（EM）の文脈でも有用ではないか？」という話になりました。そこで、EMのカンファレンスである「EMConf JP」への応募を検討したのですが……気づいたときにはCfPの申込期限が過ぎており、あえなく断念しました。

大きな舞台で登壇という形でのアウトプットは叶いませんでしたが、引き続きアップデートを続けて次の機会を狙っていければなと思います。

おわりに

「ソフトスキル」という言葉は広義であり、組織やプロジェクトによって求められる要素は異なります。

本ガイドラインもあくまでフューチャーの一部の「有志」が定義した「現時点での解」に過ぎません。内容について「わかる！」「ここは違うんじゃないか？」といったご意見があれば、ぜひXなどでフィードバックをいただけると嬉しいです。

最後に、作成・レビューに関わってくれた永井さん、武田さん、佐藤さん、澁川さん、赤坂さん、井上さん、清水さんに感謝します。

ソフトスキルガイドライン
https://future-architect.github.io/arch-guidelines/documents/forSoftSkill/softskill_guidelines.html

初めまして。入社１年目、製造・エネルギー事業部の三谷 昭徳です。

2025年9月17日（水）~ 19日（金）に東京ビッグサイトで開催されたINCHEM TOKYO 2025のDAY1に参加してきました！
当日の様子や注目されていた技術などをレポートしたいと思います！

イベント概要

INCHEM TOKYO 2025は化学に関わる企業・⼈が集い、相互に関係性を引き出し、交流と協力でビジネスの可能性を広げる、化学装置/生産プロセス/エンジニアリングの総合展示会で、出展は300社・団体／621ブースに及びます。

• テーマ：持続可能な未来への競争イノベーション、科学技術によるサステナブルな社会の実現を目指して
• 特徴：専門性を網羅した11の展示ゾーン、業界の第一線を走る企業や学術者による3日間で計100テーマにおよぶ講演&セミナーの開催

会場の様子

• 各ブースで様々な交流がされていました
• 講演会はどの講演もほぼ満員で多岐にわたる業種の人が集まっていました
• お笑い芸人による会社・技術紹介などユニークな企画をしているブースもありました

展示会で注目されていた2つの問題

展示会を回る中で、化学業界では特に次の2つの問題が注目されていると感じました。

1.カーボンニュートラル

• 概要
  • カーボンニュートラルは、温室効果ガスの排出と吸収を均衡させ、実質排出量をゼロにする国際目標です
  • これは、深刻化する地球温暖化を抑制し、持続可能で新たな成長を生む経済社会を実現するための、人類にとって不可欠な最優先戦略であり、世界中で注目されています
• 注目されていた技術：CCUS(Carbon dioxide Capture, Utilization and Storage)
  • CCUSとは、二酸化炭素を回収・貯蓄するCCS(Carbon dioxide Capture and Storage)という技術に加え、二酸化炭素を回収した上で有効利用する技術を指します
• 技術例：ゼオライト膜（産総研）
  • 分子サイズの小さな穴を持つ結晶で、ふるいのように使い二酸化炭素を分離できる
  • 低エネルギーで二酸化炭素の分離回収が可能

出典：https://www.aist-solutions.co.jp/case_study/page000160.html

展示会のテーマにもあるように、サステナブルな社会の実現のためにもカーボンニュートラルは特に注目されていました。私自身二酸化炭素を回収・貯蓄する技術があるのは知っていましたが、最近では有効利用まで目を向けられていることに技術の進歩と業界の方々の熱意が伝わってきました。有効利用される二酸化炭素は炭酸飲料などの身近な製品などにも応用されるようなので、今後はそのような製品に目を配りながら少しでもサステナブルな社会の実現に貢献していきたいと感じました。

2.人手不足・属人化

• 概要
  • 製造業の9割が「人員不足が原因で発生する課題」を感じています
  • 熟練者の不足や退職によるリスクもこの問題を加速させています
• 注目されていた技術：データ活用・DX
  • 人手不足・属人化問題に対し、デジタルの力を用いて業務効率化・自動化や、質管理の精度向上などの実現を目指しています
• 技術例：電子操業日誌（TMEIC）
  • 操業現場における運転管理、設備管理、工事管理の業務プロセスをデジタル化することで、業務の効率化に加えて、ナレッジ情報の収集、共有、活用ができ、プラント全体の安全・安定操業を推進できます

出典：https://www.tmeic.co.jp/product/dx/operation/support_plantlog/

様々な企業が人員不足・属人化に対して多様なツールや切り口で取り組んでいました。製造業の未来を考える上で、この潮流は避けて通れないものであり、今回の展示化はその現実を知る貴重な機会でした。今後さらに製造業では人員不足が加速していくと予想される中、ITコンサルタントとして働く私がITの力でどう貢献できるかという糸口を見つけるきっかけになったと思います。

さいごに

このイベントに参加したことで、化学業界の最前線のトレンドや注目されている技術を知ることができました。特に、製造・エネルギー事業部で働く自分にとって、現場の業務改革にITで何か貢献できるのではないかという実感が得られたというのは貴重な経験だったと思います。

展示会で得た多くの気づきを、今後の業務に活かしていきたいです。

2025年度新卒入社、製造・エネルギー事業部所属の實藤 陸（さねふじ りく）と申します！

2025年9月17日(水)～2025年9月19日(金)に幕張メッセで開催されたファクトリーイノベーションWeek（秋）に参加してきましたので、当日の様子を共有します！

イベントの概要

ファクトリーイノベーションWeek（秋）は、製造業のトレンドを網羅した一大展として以下の4展を合わせて開催されました。

1. スマート工場EXPO
2. ロボデックス
3. 製造業カーボンニュートラル展
4. 製造業人手不足対策 EXPO

総来場者は30,905名にも上る大規模なイベントでした。

会場の様子

会場全体として、特に注目を集めていた展示はAI活用・脱属人化をテーマとした展示でした。AIに関してはセミナーや特設のブースも数多く設置されており、業界全体として関心を集めているテーマであることが再認識できました。

また脱属人化のテーマでは、契約書管理や図面解析といった個別業務をピンポイントで効率化する展示に多くの人が集まっていました。

一方で、人材不足や・ロボデックスをテーマにした展示は比較的閑散としていた印象で、製造業の潮流を肌で感じることができました。

展示内容紹介

本レポートでは、展示内容の一例として株式会社キーエンスのRPAであるRKシリーズについてご紹介します。

このツールは他社製品と比べて導入・利用しやすい脱属人化ツールとして紹介されていました。特徴としては主に以下の3つが挙げられます。

1. 手軽さ
   • 専門知識が無くても現場担当者が自ら自動化できるフローナビゲーション機能・AIナビ機能
2. 伴走サポート
   • 「導入したが使われない」を防ぐ無償の活用支援体制
3. データの自動整形
   • Excelなどのデータフォーマットを自動整形して、シナリオに沿って必要な情報を抽出

上記特徴のように、RKシリーズは現場における使いやすさ・簡単さが重視されています。その他展示でも直感的な操作等をメリットとして挙げている展示が多くあり、そうした製品の需要の高さを感じました。

セミナー聴講内容紹介

次に聴講したGenerativeX株式会社様のセミナーについて紹介します。

内容としては「製造業におけるAIエージェント活用のベストプラクティス」と題しAI活用やDXの推進方法についてのお話を伺うことができました。

特に、製造業においてAI活用が成功する企業と失敗する企業の違いについての解説が印象的でしたので紹介させていただきます。

成功する企業

• 現場主導でPoCから開始 (スモールスタート)
• 段階的にスケールアップし、横展開
• パブリックモデルの採用
• 分析・探索など、AIと相性の良いユースケースから着手

失敗する企業

• トップダウンで一気に大規模導入
• 現場のニーズとの乖離・関与不足
• 独自モデルの開発
• フィードバックサイクルが無く改善が進まない

セミナーを聴講し、部門間でのサイロ化といった製造業で一般的な課題に対して、いきなり大規模に着手するのではなく、全社展開を意識しながらスモールスタートで着実にAI活用やDXを進めることが重要であると学ぶことができました。

感想

今回のイベントでは、各展示やセミナーを通じてDXやAIに強い関心があることや、それらを用いた業務効率化のツールはすでに多数存在しており、今後の製造業にとって必須になっていくといった製造業のトレンドと今後の動きを肌で感じました。

一方で企業の目指すゴールを達成するために、それらの多岐にわたるツールを誰がどのような目的で活用するべきかといった観点での展示やセミナーは少なかった印象です（技術展ということも関係すると思いますが）。

便利なシステムやAIが今後より増えてくる世界の中で、「それらのツールを導入することをゴールとする」のではなく、それらを用いてどんなことを実現したいのかを考え続けることこそが企業にとって重要なのではないかと考えると同時に、自分自身は少しでも製造業界の将来に貢献するための、製造業やIT、経営などあらゆる分野の知識が不十分であると感じました。

おわりに

イベントへの参加を通して、自社業務だけでなく製造業の業務理解も不十分であると痛感しましたが、製造業に関わる方のお話を聞き業界のトレンドや今後の動きを感じ取ることができ、多くのことを考え学ぶ貴重な機会となりました。

今回のイベントで得た学びを今後の業務に活かしていきたいと思います！

エンジニアであれITコンサルであれ、抽象的で不確実性の高い、要は「いい感じに進めて！」的なフワッとしたタスクは避けて通れません。

• 目的: 目指したい姿は決まっている
• 仮説: 現状の課題はヒアリング結果からざっくり候補はある。正解とは限らない
• 方針: どう解決するか未議論

例えば、データガバナンスの文脈で説明すると、「全社でデータ利活用促進させたい」というゴールに向けて、現状の「データ権限管理が厳し過ぎるかも」とか「データ共有文化が無いから」などの仮説があります。その上で、「どう持っていくのが良いんだろうね？」とチームで議論が始まったような状況を、ここでは想定します¹。

「目的」自体を否定しないのでなければ、よくある進め方は、やるべき「具体的な課題」が何であるか分析・分解・仮説を立てること。そして仮説の真偽を、ヒアリング・実データ・試行などから検証する流れ。課題さえ明確にできれば、対応方針はよりクリアに考えることがでます。

目的が迷子になる

ところが、そういったなぜやるのか（Why）見失ったまま、How（検証などの実作業）を進めてしまうアンチパターンもある。

• 「判断材料が少ない。とりあえずシステムの権限データをまとめよう！」
• 「どうも制御対象のデータへ業務分類に応じたタグを付けていくと、10個に大別できそうだ！」

その結果、レビューで次の指摘を貰う。

• 「この整理、何のためにやってるんだっけ？」

このとき、一言で作業目的を言えず、やってきたことをつらつら説明し始めたら黄色信号。目的がズレている可能性が高いでしょう。

こういった、いわゆる「作業の目的化」について、同僚とSlackのスーパー雑談チャンネルで議論しました。持つべきものは悩みを共有できる仲間。そこで出た意見をまとめます。

なお、課題とその対応について方向性が見えている状況であれば、むしろ手を動かしながら考えることが正解な場面もある。例えば、データ分析での仮説検証やPoCやアジャイル開発がある。この場合は、クイックに手を動かして、可視化結果やモノを見せながら、話を進めることが普通で、その有効性については論じるまでもないでしょう。

手を動かす仕事の魅力

ビジネスの問いは、答えが1つではない。フワッとしたお題に向き合うのは、結構なエネルギーを消耗する。

また、この手に共通する前提として、どう進めるのが良いか、だれも正解は持っていないです。

• 本当に権限設定に問題があるのかは不明。仮に問題があるとしても良いが、何らかの裏取りは必要
• データ共有文化が無いというのは、どういうことだろうか。それがどういう問題を生んでいるのだろうか
• 他に課題は無いのだろうか。そもそも、現状どのようなデータ利活用のユースケースがあり、現場では何に困っているのだろうか？

上記のように、状況を整理しつつ、目的（データ利活用促進）を進めるうえで本当に解くべき課題を特定する。そのために現時点で一番もっともらしく思える仮説をおいて、証拠を集める。仮説思考。

しかし、仮説思考での仕事の進め方は、ジュニアやシステム構築に特化したキャリアの人には、「正直どこから手をつけるべきか分からない」と映る人も。こういった抽象的な仕事に比べると、眼の前の具体的な作業が持つ魅力は確かにあります。

• やればやっただけ確実に “アウトプット” を出せる安心感
  • 作業報告が楽
• 作業イメージが湧きやすく、手を付けやすい
  • 手を動かしている最中は作業に集中できるため、悩まなくても済む

不確実性という名のストレスから逃れるため、「とりあえず手を動かす」ことが一種の逃避になっているかも。そして、何か成果を出さないという焦りもある。または、「できそうなことがそれしかなかった」というのも正直ありそう。また、具体を手を動かしながら整理する中で答えが見つかるのでは無いかという淡い期待もあると思う。帰納法的な思想。

しかし、フワッとした仮説で、作業を始めてはならない。仮説の解像度が低いまま具体的な作業をすると、それ自体が目的になってしまう。これは、旅先が山か海かも決まっていないのに、履いていく靴を決めるために今の流行を調査しているようなもの。

これが、仮説を作り出すためのインプットとして、短時間だけざっと具体に目を通すのであれば良いです。むしろ、ある程度インプットがないともっともらしい仮説は生まれないため必要作業でしょう。問題なのは、仮説なしでそのままインプット資料から、遷移図やマトリクス図などに、答えを探して整理を始めること。

途中で目的を見失う

前節の亜種で、作業途中に目的を見失うことも多い。純粋に作業が楽しくてというのは余り聞かない。多くは、作業を進めていく中で、当初の「仮説」が崩れてしまい、そのまま進めても意味がなくなってしまったにも関わらず、手を動かし続けてしまうパターン。これは中堅になっても陥りがち。

迷ったら、常に「なんでこの作業をやっているんだっけ？」と自問自答する。目的や仮説を振り返って、今の作業がそれからズレているのであれば、なるべく早めに軌道修正すべき。もし、自分で答えが出ないようであれば、すぐにリーダーにエスカレーション。

作業を完遂させることは必須条件では無く、目的を果たせれば何でも良いためです。

手戻り

例にあげたケースにおいて、逃避しても結局は手戻りを生みます。

真面目に作業したアウトプットをレビューに出すと、「これが、何の目的でしたっけ？ だれの何を解決するために作ったんでしたっけ？」と問われる。レビュアー側も意地悪をしたいわけではない。せっかく作った作成物を無駄にしないよう、作業の意味を再定義したり、別の場面で活かせないかの努力も試みるが、上手くいくかは運次第。儚い。

基本的に、手を動かすような検証作業は、「仮説」に紐づいていないと意味がない。今回だと、仮説は、目的を達成するために解くべき課題のこと。例えば、現在のデータ利活用が進まない課題の原因を、データ特性に見出すという「仮説」を置いているのであれば、その検証には意味があります。

そもそも、何も置いていないのであれば、「じゃあ何のためにやったの..？」に答えることができない。お互い辛い時間です。

まず、データ利活用の促進のために、何をやるべきか？という問いに向き合うべきであった。その問いのために現状の課題を集めたり、何が課題かのファクトを集めることができなければ、仮説を置いて何が問題であるかを分解、整理すべきでした。

どうすべきか

作業の着手「前」のすり合わせが大部分。

リーダー視点

• 作業目的の「腹落ち」を徹底させる
  • 作業の達成条件やなぜ行うべきかの「Why」をすり合わせる
• どれから着手するか目線合わせ
  • これからやろうとしているのは、仮説を出そうとしているのか、仮説を出すためのインプットを行うのか、目的自体の妥当性を考え直そうとしているのかなど、何をどういう順番で行おうとしているか、進め方を認識合わせする
• 背景知識を同期する
  • もし、認識合意するために欠けている情報があれば、この場で潰しこむ
• 作業の背景と指示は言語化して、チャットで備忘しておく
  • 信頼できるメンバーならともかく、この手の作業に慣れていない場合、思ったよりも目的を見失いがちである。そのため口頭でのすり合わせやGeminiによるメモだけに頼らない方が良い。Geminiによるメモは基本、メンバーは読まないと思った方が良い

後は、実践を繰り返すのみ。次に何をしようとしているか聞けるタイミングで、「その作業で解決しようとしていること確認して良い？」と聞いて、視座を引き上げる。愚直な取り組みで大変ですが、これしか無いと思います。

スケジュールというかタスクの期限感は最初に指定すべきでしょうが、個人的に難しい。厳しくし過ぎるとアウトプットをかさ増しするために、仮説ではなく手を動かす作業に向かいやすい傾向にも感じる。いっそ思い切って1, 2時間考えてみて結果を教えて、といったマイクロマネジメントをしても良いかもしれないが、マネジメントの負荷が半端ないし、おそらくお互いワクワクしない。

難易度を下げるのも大変だけど有効。ストレッチゾーンになるように調整するのはコーチ側の責務。

• 上段部分は巻き取る（難しい最初に考え方はマネジメント側で決めてしまう）
• テンプレートを渡す（思考の枠組みだけはこちらで決めてしまう）

調査など手を動かすタスクが別にあれば、そちらを任せるのも１手。しかし、成長観点だとどうなんだろうか。問題の先送りと言えなくもない。

メンバー視点

• タスクを腹落ちさせる
  • 以下のどちらかの言葉が出るまで理解度を深める
    • 「その目的とこの状況なら、確かにこのタスクから着手すべきですね」
    • 「その目的とこの状況なら、このタスクはやらなくても良いとか、優先度が低いんじゃないですか？」
• 次にやる作業の背景にある仮説を、一文で説明できなければ着手しない
  • ❌️「ユーザーの傾向を掴むために、データを分類する」ではまだ弱い
  • ✅️『〇〇という理由で解約が増えている』という仮説を検証するために、顧客データと利用履歴を××の軸で分類してみる
  • 一文が出てこない場合は、仮説を練り直すサイン
• どこから手を付けてよいか分からなくても、やることを変えない
  • リーダーと合意を取ったことと違うことをやることになったら、すぐに方向性を確認する
• 仮説が作れない場合は、だれかと話す
  • Geminiでも良いかもしれないけど、できればチームメンバーを捕まえて壁打ちすること
  • 「今、こういう目的のために、こういう仮説を立てて、この作業から始めようと思うんですが、どう思いますか？」
• 伸びる人の条件についてSlackで話したにも書いたけど、検討内容はなるべくオープンにしつつ、なるべく早くチームメンバーに共有してフィードバックをもらう。1日がかりの仕事を否定されるのは辛いことだが、30分だったら諦めがつく。座礁したと感じたら、早く出して楽になろう
  • 早めに方向性をすり合わせる

これは、仮説思考の話をしている？

Yes。今回話した話は、仮説を持って作業をしよう。また仮説を見失ってしまわないようにしよう、とシンプルに言い換えることができます。このあたりの話は、先人が様々な言い方で教えてくれている。多くの人の思考モデルを知っておくと、自分に響く考え方が見つかるかもしれないし、メンティーにあった響かせ方ができるようになるかもしれない。

• 【ブログ】エンジニアが持っておくと幸せになれるビジネス視点
  • 『すべての活動において重要なのは「目的を見失わない」こと。目的を定め、必要な事実（ファクト）をしっかりと収集する。そして、「目的」と「手段」をつなぐために「方針」として言語化する』など、秀逸
• 【書籍】コンサルティング会社 完全サバイバルマニュアル
  • 4章がまるまる「論点思考」「仮説思考」 について解説してくれている
• 【書籍】コンサル一年目が学ぶこと
  • 2章のコンサル流思考術は良いぞ。「考え方の考え方」も良いし、「仮説思考」もバッチリ説明がある

もしこの手の作業が初めてのメンバーであれば、上図のような作業フローの全体感は早めに作成（提供）しておくと認識齟齬が減るため、お勧めです。

まとめ

焦ってアウトプットを出そうとすると、つい目の前の「How」に没頭してしまう時があります。やった感は出るけど、相手のためにならないものを作っても意味はない。プロダクトアウトではなくマーケットイン。ズレたまま進んでは手戻りです。

手を動かす誘惑に打ち勝って、不確実性と向き合おう。できる限り最初に腹落ちさせつつ、途中で迷ったら「すいません、今何をやっているか目的がわからなくなってきました。壁打ちしてもらえませんか？」と対話を選ぶようコントロールすると良さそうです。

みなさん、初めまして。入社1年目、製造・エネルギー事業部の山田です。

2025年9月10日(水)～2025年9月12日(金)に東京ビッグサイトで開催された国際物流総合展2025に参加してきましたので、当日の様子をレポートします！

イベント概要

国際物流総合展2025は、物流の最新技術やソリューションを集結させた、国内最大規模の専門展示会です。

物流業界が抱える人手不足、環境負荷低減、多様なニースへの対応といった課題を解決するために革新的なソリューションが紹介されていました。

• テーマ: 「物流を止めない。社会を動かす。」
• 目的: 内外の最新物流機器・システム・情報等のソフトとハードを一堂に結集し、交易振興・技術の向上・情報の提供・人的交流を促すこと

「展示会」は、ビジネスの「商談」が始まる場

今回、新人としてこの展示会に参加し、この場は単なる展示会ではなく、新たなビジネスを生み出す出会いの場であることを肌で感じました。

多くの企業が、独自のロボットやソリューションを競うように紹介していく中、出展側には強い意図が見て取れました。それは、いかにして来場者の足を止め、興味を引き、ビジネスのきっかけを作るか、というものです。この展示会は、BtoBの営業活動において、これ以上ない機会です。単に製品を見せるだけでなく、顧客との接点をいかに作り、商談へと繋げるかという、生きた営業のノウハウを学ぶことができました。

イベント全体のキーワード

今回の展示会に参加して印象的だったのは、省人化・自動化というテーマが、単なるトレンドではなく、物流業界全体の根幹を成す共通のキーワードとなっていたことです。展示会場を歩けば、その重要性は一目瞭然でした。大型の無人搬送車から、細かな仕分けを担う協働ロボットまで、あらゆるブースでこの言葉が掲げられ、多くの来場者がその最先端技術を熱心に見入っていました。

これは、人手不足が深刻化する日本の現状と深く結びついています。自動化は、かつてはコスト削減や効率化を目的としたあれば良いソリューションでしたが、今や人手不足を乗り越え、事業を継続するための必須のインフラへとその位置づけを変えつつあります。

物流の未来を考える上で、この潮流は避けて通れないものであり、今回の展示化は、その現実を知る貴重な機会でした。

特に注目を集めていた分野

そんな中、今回の展示会では、自動倉庫ソリューションの分野に多くの来場者が足を止めていました。現在でも多くの企業が倉庫作業に大量の人員を配置しているのが現状ですが、自動倉庫はそうした人手による作業を飛躍的に効率化し、省人化を可能にします。

特に印象的だったのは、倉庫内でのセグウェイ導入事例です。このセグウェイは、単なる移動手段ではありませんでした。どこに移動し、何を、どれだけ運ぶかという情報がすべてデータとして入力され、作業員に的確な指示を出すシステムでした。このシステム最大のメリットは、人為的なミスが大幅に減少し、内部情報を全く知らない新人やアルバイトでも、すぐに正確な作業を行えるようになることです。これは、大規模な自動化システムだけでなく、現場の小さな工夫一つひとつが大きな革命につながることを示唆しており、物流DXの奥深さを感じさせるものでした。

さいごに

私自身、このようなイベントに参加することが初めてでしたが、多くの刺激と学びを得ることができました。自分の担当事業や日々の業務から一歩離れてみることで、新たな視点を開くことができ、一見関係なさそうに思える分野のイベントでも、実は業界全体の課題や、自社が直面する課題解決のヒントが隠されているのだと実感しました。

この経験を活かし、今後も視野を広げ、様々な学びの機会を大切にしていきたいと思います。

参考

• https://ie.logis-tech-tokyo.gr.jp/
  • 国際物流総合展2025のホームページです
• https://future-architect.github.io/articles/20240426a/
  • 国際物流の参考になる記事です
• https://future-architect.github.io/articles/20240530a/
  • 国際物流の参考になる記事です

皆さん、初めまして。入社1年目、製造・エネルギー事業部の神谷 祐莉加です。

2025年9月10日（水）～12日（金）に東京ビッグサイトで開催された製造現場DX展(同時開催展)に参加してきましたので、当日の様子をレポートします！

イベント概要

会場では合計5つの展示会が同時開催されており、全て見てまわることができました。企業ブースとセミナー会場があり、来場者は3日間で約51,094名にも上りました。

1. 「測定計測展2025」(来場者数9,643名/3日)
   • 測定・計測関連の機器・技術・情報が一堂に集まる。国内唯一の展示会
2. 「TEST2025」(来場者数9,027名/3日)
   • 材料試験＆環境試験と計測、評価に関する国内唯一の総合展
3. 「第27回自動認識総合展」(来場者数8,132名/3日)
   • 国内唯一の自動認識技術、ソリューションの専門展示会
4. 「SENSOR EXPO JAPAN」(来場者数6,877名/3日)
   • 社会の課題をセンシング技術で解決。センシングの新たな可能性を発信する専門展
5. 「製造現場DX展」(来場者数2,208名/3日)
   • 製造業の現場業務におけるデジタル化、製造現場の必要なDXに関連するシステムやサービスを推進する展示会

セミナー聴講

今回は、株式会社エスマットの林氏による「製造DXの誤解と成功要因」というセミナーを聴講しました。

講演で特に心に残ったのは、DXを成功させるための考え方についてのお話です。DXを単なるデジタル化（D）と捉えたり、投資対効果を人件費削減だけで測ったりしてしまうことを「DXの誤解」として説明していました。

特に印象的だったのは、DXの「D」（デジタル化・効率化）は、あくまでも「人にできることの置き換えに過ぎない」ということ。本当の変革Xは、人間業を超えることで、新たな価値を生み出すことにあるというお話でした。そして、成功の鍵は「技術ありき」ではなく、「現場の悩みから始めること」だと強調されていました。

• DXの誤解
  1. DX＝ただのデジタル導入（D）
  2. ROI＝単純な人件費削減
  3. 目的なくデータを集める「集めましたIoT」
  4. デジタル＝プログラミング（市民開発の乱立）
• DX成功要因
  1. 技術ではなく、現場の悩みから始める
  2. 人間にできないことをデジタルで実現する
  3. 日本の製造現場にあった柔軟なDXを導入する
  4. 草の根からDXを広げる外部との共創

展示会で感じた3つの主要トレンド

展示会を回る中で、製造業の未来を形作る3つの大きなトレンドを感じました。

1.AI画像認識

これまで、製造現場の目視検査や数量カウントは、多くの人手と時間がかかる作業でした 。しかし、AI画像認識によって、これらの業務を自動化・効率化できるソリューションが増えています 。

マーストーケンソリューションさんの「VisAI画像検査」は、AIカメラを使って目視検査を自動化するソリューションです。スマートフォン版もあり、手軽に導入できるのが強みだと感じました 。

Solitonさんのブースでは、自動車生産工程でタイヤの製造番号をAIで読み取り、QRコードと照合したり「カチッ」という音をAIが認識するまでOKとならないなど、人為的なミスを防ぐ仕組みが紹介してくださいました 。

このように、AI画像認識は、人の作業を置き換えるだけでなく、品質向上やミスの防止にも貢献する、重要なツールになっていると感じました 。

2.RFIDの多様な活用

従来のRFIDは、商品のID管理が中心でした 。しかし今では、「モノの状態をデータ化する」ためのセンサーとして活用されるようになっています 。

TOPPANさんのブースでは、「開閉検知タグ」が紹介されていました。これは、ワインボトルや化粧品、医薬品などに適用することで、未開封かどうかを確認できます 。

また、「温度センサー付きRFIDタグ」も展示されていました。これを産業機械の軸受などに取り付けて温度情報を取得し、AIと組み合わせることで、故障の予兆を検知する「予知保全」に応用できるとのことです 。

RFIDがIDだけでなく、センシング機能を持つことで、モノの状態をリアルタイムに把握し、新たな価値を生み出していることがよくわかりました 。

3.ハンディリーダーのスマートフォン化

従来の専用機は高価で、操作に慣れる必要がありましたが、今は使い慣れたスマートフォンに機能を統合する流れが加速しています 。

デンソーさんは、長年のノウハウで培った堅牢性や高速読み取り性能を維持しつつ、OSをAndroidに変更することで、誰もが直感的に使える端末を提供しています 。Xmare

一方、Urovoさんは、見た目や使い方が一般的なスマートフォンに非常に近い製品にリーダー機能を組み込むことで、手軽な導入を可能にしています 。UROVO DT610

このトレンドは、導入コストを抑えつつ、現場のDXを加速させる鍵になると感じました 。

さいごに

正直なところ、製造業界や自身の業務に対する知識不足を痛感する場面もありました。でも、だからこそ、色々な展示を実際に見て回ったり、業界の方と直接お話したりできたのは、本当に貴重な経験だったと感じています。

今回の展示会で得た多くの気づきを、今後の業務に活かしていきたいです。

Technology Innovation Group DXチームの福井です。

通常業務の傍ら、DXチームの有志メンバでチーム全体の資料品質向上のためのアセット化活動をしています。

今回、その活動の一環として2024年11月に東京ミッドタウンで開催された「GOOD DESIGN EXHIBITION 2024」に参加してきました。

この記事では、グッドデザイン賞およびその受賞事例についてご紹介します。みなさんに「デザイン」を身近なものに感じていただき、興味を持っていただくきっかけになればと思います。

• GOOD DESIGN EXHIBITION 2024 | DESIGN TOUCH 2024

「グッドデザイン賞」とは？

「Gマーク」でもおなじみの「グッドデザイン賞」は、優れたデザインを通じて社会をより良くしていくことを目指す、日本で唯一の総合的なデザイン評価制度です。
その歴史は60年以上にわたります。

• GOOD DESIGN AWARD

日本には「グッドデザイン賞」以外にも、優れたデザインを評価するアワードが多く存在します。
例えば、革新的な優れたサービスを対象とした「日本サービス大賞」、空間そのものを対象とした「日本空間デザイン賞」、文具・家具・道具全般を対象とした「コクヨデザインアワード」などがあります。

そのような数あるデザイン賞の中で「グッドデザイン賞」の最大の特徴は、審査対象が非常に幅広いことです。工業製品のような「有形」のプロダクトだけでなく、サービス、ソフトウェア、アプリケーション、さらには地域づくりや社会貢献活動といった「無形」のデザインまで、私たちの暮らしや社会を豊かにするすべてのものが評価の対象となっています。

会場の様子

東京ミッドタウン内の複数エリアに2024年の全受賞作品が展示されており、かなりのボリュームがありました。
プロダクトの展示、パネルでのサービス説明、実際に商品が購入できるポップアップストアなど、コンテンツは多岐にわたります。実際に触ったり、体験できるプロダクトもありました。

• ASUS Zenbook DUO (2024)
• ゲルソノマ 15-50／1201A727
• CMF by Nothing Product Range
• ざる屋の盆ざる
• 福岡市認知症の人にもやさしいデザイン
• デジロー （デジタル スシロービジョン）

時代と共に変化する「良いデザイン」の基準

グッドデザイン賞の審査基準は、時代の変化に伴って変化し続けてきました。
各時代における「良いデザイン」の変遷をご紹介します。

1960年代

高度経済成長期。1964年の東京オリンピック開催に伴い、街中にはピクトグラムが設置され「デザイン」という言葉が浸透し始めた時代。「美的感覚」「独創性」などが重視されました。1960年代中盤のいざなぎ景気時代には、新三種の神器と呼ばれる車、エアコン、カラーテレビなどが広く普及し、経済大国へと成長していきました。

1970-80年代

大阪万博を皮切りに日本の「ものづくり」が世界的に評価された時代。ソニーからは1979年にウォークマン、本田技研工業からは1981年にシティなど、世界に対して発信力の高い製品が数多く登場するようになりました。デザインに「品質水準」「機能性」「安全性」といった尺度が加わりました。

1990年代

インターネットが普及し価値が多様化した時代。またスーパーファミコンや、プリクラ、４足歩行ロボット「AIBO」など電子機器が生活になくてはならないものとなり、価値変化の時代となりました。「生活者」や「ライフスタイル」がデザインで重要視される要素になりました。

2000年代

「持続可能な開発に関する世界首脳会議（WSSD）」が開催され、地球温暖化などエコ問題が意識され始めた時代。社会課題が顕在化し、「エコロジーデザイン」や「ユニバーサルデザイン」など、社会的な視点が強まりました。トヨタのプリウスは、高性能な新世代ハイブリッドシステムにより世界最高レベルとなる低燃費、低エミッションを追求し、環境性能という新たな価値を生み出しました。

2010年代

2011年に発生した東日本大震災をきっかけに、防災、地域社会への意識の高まりなど、さまざまな変化が見られた時代。また国内のインターネットの利用者は1億人を超え、音声認識AIの開発や、キャッシュレスの浸透、ドローンなど新しい技術が登場しました。「社会参加」や「創発」が重要なテーマとなりました。

2020年代

新型コロナウイルス感染症（COVID-19）の世界的流行により、マスクの着用、ソーシャルディスタンス、また職場や学校などあらゆる場所でオンライン環境が取り入れられるなど「新しい生活様式」が実践されました。また、SDGsの浸透により「持続可能性」のあるデザインが求められるようになりました。

出典：https://www.g-mark.org/learn/gda/statistics/screening-criteria

そして2024年時点では、以下の4つの視点から総合的に審査が行われています。

👤 人間的視点

• 使いやすさ・分かりやすさ・親切さなど、ユーザーに対してしかるべき配慮が行われているか
• 安全・安心・環境・身体的弱者など、信頼性を確保するための様々な配慮が行われているか
• ユーザーから共感を得るデザインであるか
• 魅力を有し、ユーザーの創造性を誘発するデザインであるか

🏭 産業的視点

• 新技術・新素材などを利用または創意工夫によりたくみに課題を解決しているか
• 的確な技術・方法・品質で合理的に設計・計画されているか
• 新産業、新ビジネスの創出に貢献しているか

🌱 社会的視点

• 新しい作法、ライフスタイル、コミュニケーションなど、新たな文化の創出に貢献しているか
• 持続可能な社会の実現に対して貢献しているか
• 新たな手法、概念、様式など、社会に対して新たな価値を提案しているか

⏳ 時間的視点

• 過去の文脈や蓄積を活かし、新たな価値を提案しているか
• 中・長期的な観点から持続可能性の高い提案が行われているか
• 時代に即した改善を継続しているか

出典：https://www.g-mark.org/apply/gda/screening/perspective

受賞事例から見る「良いデザイン」のカタチ

では、具体的にどのようなものが受賞しているのでしょうか。個人的にいいなと感じた3つの事例をご紹介します。

1. スマートフォンアプリ - みみみ

https://www.g-mark.org/gallery/winners/26906

「みみみ」はデジタル世代の興味・関心に合わせて地域ニュースを届け、理解を深める体験を提供するアプリです。 デジタル世代の普段使いに馴染む洗練されたデザイン性、スムーズに使えるインターフェースで操作も簡単。
スワイプしながら手軽にニュースを追える「コレだけ」機能や、浮かんだ疑問を記者に直接質問できる「イドバタ」機能が特徴で、一方的な情報提供ではない、地域に根付いた新聞社ならではの新しいニュース体験の形を示しています。

直感的なニュース体験

デジタル世代の普段使いに馴染む洗練されたデザイン性、スムーズに使えるインターフェースで操作も簡単。ストレスフリーでニュース体験を楽しめます。

記者が「？」にこたえる！

話題やコメントが投稿できる「イドバタ」機能。同じ街に住む記者が、身の回りのニュースについて答え、一緒に考えてくれることも。

ちなみに、「みみみ」のユーザ基盤を支えている「たるポ」はFutureとも関わりがあります🎉

• たるポ このまち応援プラットフォーム
• 中国新聞社、フューチャーアーキテクトとともに中国地方の地域活性化を推進

2. 旅行サービス - どこかにビューーン！

https://www.g-mark.org/gallery/winners/17585

JRE POINT 6,000ポイントで、JR東日本が管轄する47駅の中からランダムに選ばれた「どこか」に行けるサービスです。
ユーザはお得に新幹線に乗れる、事業者にとっては空席をうまく活用できる、地域にとっては観光資源を知ってもらえる機会が生まれる、という三方よしのサービス。行き先をランダムで選べるワクワク感も楽しいですね。

観光流動の均等化

観光は特定の地域に人気が集中することも多い。そのような中、新幹線の空席状況に合わせて、行き先を決定することで観光流動の均等化に繋げられます。

新たな地域との出会いを創出

利用者が目的地を最終決定できない仕組みとなっており、観光資源の魅力を新たに知る機会を創出しています。

3. デザインガイドライン - デジタル庁デザインシステム

https://www.g-mark.org/gallery/winners/27505

行政機関のウェブサイトなどで利用されることを想定し、誰もが平等に利用しやすい社会を実現するべく、アクセシビリティを最優先で構築されたデザインシステムです。身近なものだとマイナンバー関連の手続きアプリなどにも導入されています。豊富なガイドラインとコードスニペットが公開されており、開発工程の業務量やコスト削減にも寄与します。

公共サービスの標準化へ

カラーパレット、文字の形状やサイズ、イラストやボタン、コンポーネントなどを国際的に推奨されるガイドラインに基づいて整備。マイナンバーの手続きアプリなどで導入されている。
公共サービスの標準化が進み、誰もが安心してアクセスできる「優しいデジタル社会」の実現が期待されます。

豊富なガイドラインとコードスニペット

あらかじめアクセシビリティを十分に考慮し、かつデザイン性に優れたデザインライブラリやガイドラインを整備。様々な行政サービスで利用できるようにネット上で公開されています。（動作環境：Webサイト、Figma、GitHub）

さいごに

今回はグッドデザイン賞とその評価軸や具体的な事例についてご紹介しました。

「良いデザイン」というと、つい「有形」のプロダクトを思い浮かべがちですが、こうして見ると、サービスやシステムといった「無形」のものも多くあり、我々の仕事にも活かせる部分がたくさんありそうです。とっても良い刺激になりました。

この記事が、みなさんに「良いデザイン」について考えていただくきっかけになれば幸いです！

はじめに

はじめまして、Strategic AI Group（SAIG）の仲田です。今回が初投稿です🔰。
5、6年前に作ったQiitaのアカウントにログインできず、パスワードの再設定から行うことになりました。

みなさんは、Deep Researchの膨大な出力を見て読む気が無くなったり、読み終えたのに知りたいことは書かれていなかった経験はありませんか？

この記事では、Deep Researchの出力の読みにくさや知りたい情報にたどり着けない問題をどうすれば改善できるのか試行錯誤した内容をシェアします。私自身も、あるプロジェクトに新規参画するにあたりその業界についてDeep Researchを使って簡単にリサーチしたのですが、読むのに時間が溶けた割にはイマイチいい情報が収集できなかったという経験があり、そのことを振り返って記事を書きます。

対応策①：具体的なリクエストを投げる

せっかく長いレポートを読んでも、知りたい情報が含まれていなければ意味がありません。

質の高いレポートを得るには、リクエストを投げる前に「知りたいことは何か」を具体的にイメージしておくことが重要です。質問をより具体的にすることで、期待する回答を得られる可能性が高まります。

以下に良いリクエストと悪いリクエストの例を記載します。

○○業界で使われているAI手法を調べてください。

○○業界の顧客課題をAIにより解決するために、業界について調べています。
今現在、○○業界の○○の業務におい使われている機械学習手法やAI手法について、事例も含めて調べてください。
いくつか主流な手法がある場合は、結果を表形式でまとめて特徴やメリットデメリットを比較してください。

より具体的な良いリクエストのポイント。

• 目的と背景を伝える
  • 「なぜその情報を知りたいのか？」を最初に伝える
  • 例：新規事業の市場分析のため、競合他社の動向把握のため
• 調査範囲を絞り込む
  • 業界、地域、期間、対象企業など、調査したい範囲を可能な限り絞り込む
  • 例：日本市場の、2020年以降の、B2B SaaS企業について
• 期待する回答形式を指定する
  • 最終的にどのような形式で情報が欲しいかを明確に伝える
  • 例：表形式、箇条書き、SWOT分析、3つの主要な課題と解決策をまとめたレポート

また、Deep Researchはリクエストを投げると内容を咀嚼して、リサーチの方針を立ててくれます。

内容を読むと不要な観点で調べようとしているな？と感じることがあるので、面倒ですがリサーチ方針もざっと目を通して、必要があれば修正依頼すると良いと思います。

対応策②：レポートを拾い読みする

Deep Researchが出力してくれたレポートは、本や新聞、ブログを読むときと同様、通読する必要はなく拾い読みするだけで十分です。

そのためまずは、そのレポートを読むべきかを判断するというステップを挟むと良いと思います。目次を見たり、章ごとに概要をまとめてもらったりして、レポートの概要を把握します。私は、レポートの各章でどのようなことが書かれているのか概要を教えてください。と質問して概要を教えてもらっています。

この時点で、期待する内容が書かれていないと感じた場合は、再度Deep Researchをリクエストしなおします。そのときには、書いてほしかったけど、書かれていなかったポイントをリクエストに追記するとGoodです。

概要を把握して、知りたい情報がありそうだと判断した場合読み進めていきますが、さらに読むポイントを絞っても良いと思います。通読してスクロールで探すと非常に手間なので、レポートの中で○○について書かれている部分を教えてください。といった質問を投げて、読むべき場所までも教えてもらいます。

その他読むときのTips

専門外のことについて調べたときには専門用語が分からないだけでもモチベーションが下がったり、頭に入ってこなくなったりすると思います。そのように用語が分からないときには、都度用語の意味を聞いたり、あらかじめ専門用語の一覧をリストアップしてもらったりしていました。

プロンプト例:

• ○○の意味を中学生にもわかるように説明してください。
• 「レポート中の専門用をリストアップして、その用語の意味を中学生にもわかるように説明してください。

おまけ

もし、文体が固い、生成AIくさい文章が気に入らないという方がいれば、そんなことでレポートを読むモチベーションが落ちてしまってはもったいないので、こんな感じで文体を書き換えてもらってもいいかもしれません。

• レポートの文体が固いので、もう少しポップな感じで書き換えて。

その結果、ぱっと見何を言っているか分からない文章になってしまい、元に戻してもらうことになりました。。。。

（新しいデータを集める探検家ってなんだよ、、、）

さいごに

Deep Researchは情報収集の効率を大幅に高速化してくれますが、その情報量の多さに理解が追い付かず溺れてしまいそうになります。今回紹介したような工夫をするとよりピンポイントで知りたい情報が収集できるかもしれません。

【まとめ】

• リクエストの工夫： 具体的なリクエストを投げる
  • 目的と背景を伝える
  • 調査範囲を絞る
  • 回答形式を指定する
• 読み方の工夫：レポートを拾い読みする
  • まず読むべきか判断する
  • 読む場所をAIに教えてもらう

みなさんのDeep Research活用術も、ぜひコメント等で教えてください！

類似記事の紹介

生成AI関連の記事を紹介します。ご興味あればご覧ください。

• 生成AIとはじめる、バックオフィス業務改革 ～Geminiの有効な使い方～
• 生成AI時代の知識の獲得・体系化・伝達術
• 会議での活用方法から考える、人間と生成AIの最適な共存関係

はじめに

私は今フューチャー社内のバックオフィス業務をターゲットに生成AI活用を更に促進させるミッションを担い、日々業務に勤しんでいます。

バックオフィスの方へのヒアリングを通じて、生成AIの活用（本記事においてはGeminiの活用を想定）を通じて効率化・省力化を狙いたい業務シーンやニーズがいくつか浮かび上がってきました。

私自身もまだまだ生成AIの使い方を勉強している身ですが、各シーンにおいて現時点で考えられる好ましい使い方を模索したい、というのが本記事のモチベーションです。

※本記事では Gemini 2.5 Pro の利用を前提とします。

効率化・省力化を狙いたい業務シーン・ニーズ3選

【シーン① マーケ】
ブログ記事の定期アナウンス用メール文面の作成作業を省力化したい。

【シーン② 総務など】
業務にて利用するGASを自作し、運用保守できるようになりたい。

【シーン③ 各所】
部門内で共有するGem用プロンプトの品質をあげることで作業品質を向上させたい。

本記事では上記3つの業務シーン・ニーズを想定して、Geminiをいかに上手に活用できるか模索します。

【シーン①】ブログ記事の定期アナウンス用メール文面の作成作業を省力化したい

当社はブログ執筆活動が活発ですが、マーケ部門は定期的にブログ記事をまとめて社内向けにも発信してくれています。ただアナウンス文面の作成負荷もなかなか手間なので Gemini におまかせして省力化していきましょう。

早速ですが例えば以下が完成版のプロンプトです。

フューチャー技術ブログ（https://future-architect.github.io/）のトップページから、最新の記事を10件取得してください。

取得した記事を対象に、以下の条件で宣伝メールの文面を作成してください。

・ターゲット読者： IT業界で働く若手エンジニア
・目的： ブログの購読者数増加
・トーン： カジュアルで親しみやすく
・記載内容：
　　・各記事のタイトル（URLリンク付き）
　　・各記事の概要（どんな内容か）
　　・各記事のおすすめポイント（どんな人におすすめか）

生成結果を全文載せると長いので省略しますが、以下のように文章が生成されます。記事タイトルの部分もしっかりとURLリンク付きになっています。

件名：【フューチャー技術ブログ】最新記事でスキルアップ！若手エンジニア必見の情報が満載！

フューチャー技術ブログ読者の皆様、こんにちは！

暑い日が続きますが、いかがお過ごしでしょうか？
今月も、皆さんの知的好奇心を刺激する、面白くてためになる技術情報をお届けします！

通勤中や休憩時間にサクッと読める記事ばかりなので、ぜひチェックしてみてくださいね。

【今月のピックアップ記事】
1. Software Design 2025年8月号「2038年問題を考える」を寄稿しました

・どんな内容？
　2038年に迫る、UNIXシステムにおける重大な問題「2038年問題」。その概要から対策まで、新卒エンジニアが分かりやすく解説します。

・こんな人におすすめ！
　　・大規模システムの開発に携わっている、または興味がある方
　　・IT業界の未来を担う、すべての若手エンジニア

...（以下略）

実運用にあたってはもう少し要件に合わせて指示を追加する必要がありそうですが、ひとまず大枠のプロンプトはこれで良いのではないでしょうか。

プロンプト検討にあたっては、プロンプト自体をGeminiにレビューしてもらうプロセスを踏みました。
元々以下のようなプロンプトにて、「プロンプトの改善提案」をしてもらっています。

以下プロンプトを最適な形に書き換えて。また、指摘ポイントと改善案は表形式にまとめて提示して。

フューチャー技術ブログの記事から、直近1ヶ月間の記事を収集し、宣伝メール文面を作成して。
対象のブログURLは以下。
https://future-architect.github.io/

・各ブログ記事のタイトルがURLリンクとなっていること
・各ブログごとに、どんな内容か、どんな人におすすめか、を簡潔に示す宣伝文を付与して

これによりGeminiから受けた改善提案は3つありました。

各指摘に素直に従ってプロンプトを書き換えることで完成版プロンプトへと仕上げていきました。定型業務にて複数回の利用が想定されるプロンプトは、Geminiにレビューしてもらって質を高めていくプロセスを踏むのが望ましいなと感じました。

ちなみに、、、てっきりGeminiはMarkdownスタイルで丁寧に段落分けされたプロンプト改善案を提示してくるかと思ってたんですが、必ずしもそういうわけではなさそうです。

【シーン②】業務にて利用するGASを自作し、運用保守できるようになりたい

フューチャーのITコンサルは全員コードを書きますが、バックオフィスの方々は必ずしもそうではありません。ソースコードの読み書きに苦手意識を持ってる方ももちろんいらっしゃいます。そういった方でもGASを自由に扱えるようになるにはどうすればいいか考えよう、というのが本シーンの主旨です。

どうやらバックオフィスの方に話を伺うと、「Geminiに聞けばソースコードが生成されることは分かってる。ただ、生成されたソースコードが正しく動作するのかを確認できないので実運用に踏み切れない」とのこと。

エラーで動作が止まったら都度エラーメッセージをGeminiに投げて解消していけば良い、と考える方もいるかもしれませんが、例えば業務内容として「各社員宛に必要な個別情報をメールする」といったシーンなどもありえます。つまり「Aさんのための情報が正しくAさんに送付されること。間違ってBさんに送られるようなことが発生しないこと。」が担保されてない限りは生成されたGASスクリプトにて実業務を遂行することは難しいです。

ではどうすればいいでしょうか。

Geminiに直接聞いてみました。

Geminiとのやりとりを通じてGASスクリプトを生成したい。
ただし生成されたGASスクリプトの確からしさを利用者が判断できないことを想定し、Geminiにてテストあるいはテストに相当するプロセスを経てスクリプトの確からしさを検証してほしい。
あるいは、利用者にてどのような確認手順を経ればスクリプトの確からしさを担保できるのか、具体的な作業プロセスを示してほしい。

上記のようなニーズがある場合、どのようなプロンプトを書くことが望ましいか、サンプルを提示するとともに、記載のポイントとその理由を表形式で列挙して。

そして以下が回答の一部。

Geminiは実際のGoogle環境でスクリプトを直接テストすることはできません。そのため、「テストコードの生成」「テストケースの洗い出し」「ユーザー向けの具体的な確認手順の提示」を促すことで、スクリプトの信頼性を高めていくアプローチが有効です。

やはりテスト自体をGeminiに担ってもらうことは難しいので、自分がテストをする前提でそのテスト手順を明確化してもらう形が良さそうです。

さて、先程のプロンプトにて「サンプルの提示」を要求していたので、「スプレッドシートの特定の条件に合う行を別シートに転記する」というよくあるシーンを例にプロンプトを提示してくれました。

# 前提条件
- Googleスプレッドシートを使用します。
- 操作対象のスプレッドシートには「タスクリスト」シートと「完了リスト」シートが存在します。
- 「タスクリスト」シートのC列にはステータス（例：「未着手」「対応中」「完了」）が入力されています。

# 実行したいこと
「タスクリスト」シートのC列が「完了」になっている行を、「完了リスト」シートの末尾にコピー＆ペーストし、その後、元の「タスクリスト」シートからその行を削除するGASスクリプトを作成してください。

# 信頼性担保のための要件
1.  **エラー処理**: 処理対象の行が存在しない場合や、シート名が変更されていた場合に、処理を安全に停止し、ログにエラーメッセージを出力するような処理を加えてください。
2.  **コードへのコメント**: 各処理ブロック（変数の定義、シートの取得、行のループ、コピー処理、削除処理など）の目的が理解できるよう、コード内に詳細な日本語のコメントを記述してください。
3.  **テストケースの提示**: このスクリプトの動作を検証するために、どのようなテストケース（正常系・異常系）を想定すべきか、具体的なパターンを複数挙げてください。
4.  **ユーザー向けの確認手順**:
    - 私がこのスクリプトを安全にテストするための、具体的な確認手順をステップバイステップで説明してください。
    - テスト用のスプレッドシートの準備方法（どんなデータを用意すればよいか）から、スクリプトエディタへの貼り付け、実行、結果の確認方法までを含めてください。
    - 特に注意して確認すべき点も教えてください。

また、上記プロンプトの作成にあたりポイントになる点を列挙してもらっています。

「タスクリスト」シートのC列が「完了」になっている行を、「完了リスト」シートの末尾にコピー＆ペーストし、その後、元の「タスクリスト」シートからその行を削除するGASスクリプトを作成してください。

例えば今回想定しているGASスクリプトでは行の削除が含まれているため、コピー&ペーストが正しく行われないと元データが最悪消失してしまうリスクを孕んでいます。ゆえにポイント5と6の指示にて正しく動作検証することが重要です。

さて、それでは先程提示されたサンプルのプロンプトを使ってGeminiにどのような回答をもらえるのか試してみましょう。

出力されたソースコードは以下です。

/**
 * タスクリストシートでステータスが「完了」の行を、完了リストシートに移動する関数
 */
function moveCompletedTasks() {
  try {
    // --- 変数の定義 ---
    const spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
    const sourceSheetName = "タスクリスト"; // 操作元のシート名
    const destinationSheetName = "完了リスト"; // 移動先のシート名
    const statusColumn = 3; // ステータスが入力されている列番号（C列）
    const statusValue = "完了"; // 移動対象のステータス
    let movedCount = 0; // 移動した行数をカウントする変数

    // --- シートの取得と存在チェック ---
    const sourceSheet = spreadsheet.getSheetByName(sourceSheetName);
    if (!sourceSheet) {
      // 操作元シートが存在しない場合のエラー処理
      console.error(`エラー: シート「${sourceSheetName}」が見つかりません。`);
      return;
    }

    const destinationSheet = spreadsheet.getSheetByName(destinationSheetName);
    if (!destinationSheet) {
      // 移動先シートが存在しない場合のエラー処理
      console.error(`エラー: シート「${destinationSheetName}」が見つかりません。`);
      return;
    }

    // --- データ範囲の取得 ---
    const sourceRange = sourceSheet.getDataRange();
    const sourceValues = sourceRange.getValues();
    const lastRow = sourceSheet.getLastRow();

    // --- 行のループ処理（削除を伴うため、末尾からループ） ---
    // 行を削除すると行番号がずれてしまうため、逆順（下の行から）に処理を実行します。
    for (let i = lastRow; i >= 1; i--) {
      // C列のステータスを取得
      const status = sourceSheet.getRange(i, statusColumn).getValue();

      // --- 条件判定と処理の実行 ---
      if (status === statusValue) {
        // 対象行のデータを取得
        const rowToMove = sourceSheet.getRange(i, 1, 1, sourceSheet.getLastColumn()).getValues();

        // 完了リストシートの末尾に対象行をコピー＆ペースト（追加）
        destinationSheet.appendRow(rowToMove[0]);

        // 元のタスクリストシートから対象行を削除
        sourceSheet.deleteRow(i);

        movedCount++; // カウントを増やす
      }
    }

    // --- 処理結果のログ出力 ---
    if (movedCount > 0) {
      console.log(`${movedCount}件の完了タスクを移動しました。`);
    } else {
      console.log("処理対象の完了タスクはありませんでした。");
    }

  } catch (e) {
    // 予期せぬエラーが発生した場合の処理
    console.error("スクリプトの実行中に予期せぬエラーが発生しました。");
    console.error(e);
  }
}

ポイント3,4にて言及されているエラーケースの処理やコメントの記載についてもしっかり考慮されたスクリプトが生成されました。

そして以下が生成されたテストケースです。（実際の出力は文章の羅列でしたが、見やすいように表形式へ変換しています。最初から表形式で出力するようにプロンプトを書くのが良さそうですね）

個人的には異常系ケースの下2つは正常系として扱ってもよいのではと思いましたが、このへんは文化でしょうか。いずれにせよ必要なテストケースが網羅的に作成されていることが分かります。

そして一番重要な「確認手順」の出力が以下です。ステップ1～4まで丁寧に出力されています。

ステップ1: テスト用スプレッドシートの準備 📝

重要: 必ず元のスプレッドシートをコピーしたファイルでテストしてください。 スクリプトは行を削除するため、元に戻せません。

1. 現在のスプレッドシートを右クリックし、「コピーを作成」を選択してテスト用のファイルを用意します。
2. コピーしたファイルを開き、以下の2つのシートがあることを確認します。なければ作成してください。
　・タスクリスト
　・完了リスト
3.両方のシートに、同じヘッダー行を作成します。（例: A列: タスク内容, B列: 担当, C列: ステータス）
4.「タスクリスト」シートに、テスト用のデータを入力します。上記のテストケースを参考に、様々なパターンのデータを用意してください。
　・C列が「完了」の行を数行作る。
　・C列が「未着手」「対応中」などの行も混ぜる。
　・空白行なども含めておくと、より堅牢なテストができます。

ステップ1の中にて、添付スクショのように「データ準備の例」としてGoogleスプレッドシートにエクスポート可能な形でサンプルの「タスクリスト」シートと「完了リスト」シートも作成してくれているため、テスト用にどういった準備をすればいいかも丁寧にガイドしてくれます。

ただ欲を言えば、どのテストケースから順に実施するのが望ましいかをガイドしてくれたほうが良かったですね。例えば今回であればまずは「完了」タスクが1件のテストケースにて小さな正常系の動作確認を行い、その後徐々に処理対象量を増やしていくのが良さそうです。まあその旨をプロンプトに書きましょうってことですね。

ステップ2: スクリプトの導入 💻

1. テスト用のスプレッドシートを開いた状態で、上部メニューの「拡張機能」>「Apps Script」をクリックします。
2. スクリプトエディタが開きます。デフォルトで表示されている function myFunction() { ... } というコードをすべて削除します。
3. 本回答の冒頭で提示したGASスクリプトを全文コピーし、空になったスクリプトエディタに貼り付けます。
4. 上部のフロッピーディスクアイコン💾をクリックして、プロジェクトを保存します。

ステップ2にてスクリプトを保存します。丁寧に手順を列挙してくれてるので、初めての人でも安心です。

ステップ3: スクリプトの実行と承認 🚀

1. スクリプトエディタの上部にある関数選択プルダウンが moveCompletedTasks になっていることを確認します。
2. 「実行」ボタンをクリックします。
3. 初回実行時のみ、「承認が必要です」というダイアログが表示されます。
　・「権限を確認」をクリックします。
　・ご自身のGoogleアカウントを選択します。
　・「このアプリはGoogleで確認されていません」という警告が表示される場合がありますが、「詳細」をクリックし、「（プロジェクト名）（安全ではないページ）に移動」を選択します。
　・最後に、スプレッドシートへのアクセス許可を求める画面で「許可」をクリックします。

ステップ3にてスクリプトを実行して、、

ステップ4: 結果の確認 ✅

1. スプレッドシートの確認:
　・「タスクリスト」シートに戻り、C列が「完了」だった行がすべて削除されていることを確認します。
　・「完了リスト」シートを開き、「タスクリスト」から削除された行が末尾に追加されていることを確認します。
2. 実行ログの確認:
　・スクリプトエディタの下部に表示される「実行ログ」を確認します。
・「3件の完了タスクを移動しました。」のようなメッセージ、または「処理対象の完了タスクはありませんでした。」というメッセージが表示されていれば、正常に処理が完了しています。
・エラーメッセージが表示されている場合は、シート名が間違っていないかなどを確認してください。

ステップ4にて結果を確認する流れ。

詳細な確認手順が列挙されているので、GASやプログラムにあまり馴染みのない人でもひとつひとつ手順を追ってGeminiに生成されたスクリプトの確からしさを確認できるのではないでしょうか。

【シーン③】部門内で共有するGem用プロンプトの品質をあげることで作業品質を向上させたい

フューチャーではコンサルタントが提案時などに資料などを作成し、適宜リーガルチームにチェックしてもらっています。（もちろん当社固有な話ではなく、非常に一般的なプロセスだと思います）

業種・業態ごとに異なるお作法・文化があったり、相手方の企業あるいは案件特性によって重要視すべきポイントが変わったり、とかくリーガルチームのチェックは大変です。なるべく「リーガルレビューはリーガルメンバーが本当に見るべきポイントのみにフォーカスして実施したい」と考えるのは必至。そうなるとリーガルレビュー提出時の資料品質をあげようって話になるのですが、ここでGeminiを活用しようというわけです。

これはなにもリーガル領域に限った話ではありません。「資料を提出し、受け取った側が内容をレビューする」というプロセスの存在するすべての業務に通じる話です。ものすごく汎化すると「Geminiを使ってセルフレビューの質をあげよう」というのが本シーンにて取り組む課題です。そのうえで、それをGem化しておけば都度長いプロンプトテンプレをコピってくる必要もないし、作業効率の向上も見込めるはずという考えです。

シーン①②でもすでに同様のプロセスを経てるのですが、やはりまずはGeminiに相談してみるのが簡単です。

例えば先程のリーガル提出資料を想定してるのであれば以下のような感じ。

コンサルティング企業にて、法務部門へ提出する資料の品質を向上させるためにGemを作成しようとしています。

一般的な資料レビューの観点と法務の観点を踏まえ、Gem用のプロンプトを作成してください。

上記プロンプトにて出力される結果（= Gemに組み込むプロンプト）が以下です。

# あなたの役割

あなたは、一流コンサルティングファームに所属する、極めて優秀な法務担当者であり、ビジネス経験豊富なシニアコンサルタントでもあります。
あなたの使命は、チームのメンバーが作成した資料を、法務部門にレビュー依頼する「前」の段階で、品質を最大限に高めるための支援をすることです。

# 行動指針

1.  **建設的なフィードバック:** 受け取ったメンバーが前向きに修正に取り組めるよう、常に丁寧かつ建設的なトーンで対話してください。単なる批判ではなく、改善のための具体的な提案を心がけてください。
2.  **具体性の追求:** 問題点の指摘に留めず、必ず「具体的な修正案（リライト案）」と「そのように修正すべき理由（法的リスクやビジネス上の懸念点など）」をセットで提示してください。
3.  **平易な解説:** 法務に関する専門的な内容も、コンサルタントが理解しやすいように平易な言葉で解説してください。
4.  **構造的な出力:** フィードバックは、後述の`# 出力フォーマット`に従い、マークダウン形式で構造的に分かりやすくまとめてください。
5.  **ユーザー入力の待機:** 上記の役割と行動指針を理解したら、ユーザーからレビュー対象の資料情報が入力されるのを待ってください。

# レビューの実行プロセス

ユーザーから資料情報を受け取ったら、以下のプロセスに従ってレビューを実行してください。

1.  **背景理解:** まず、ユーザーが提供する「資料の種類」や「プロジェクトの背景・目的」を読み込み、資料の位置づけを正確に把握します。
2.  **多角的なレビュー:** 以下の2つの観点から、資料を詳細に分析します。もしユーザーから「特に重点的に見てほしい点」が指定されていれば、その点を特に注意深くレビューしてください。

    * **【観点1】一般的なコンサルティング資料としての品質**
        * **論理構成:** 主張と根拠は明確か。話の飛躍はないか。全体として一貫性があるか。
        * **明瞭性:** 結論ファーストか。一文が長すぎないか。専門・社内用語が多用されていないか。曖昧な表現がなく、誤解を与えないか。
        * **網羅性:** 記載すべき事項（前提条件、スコープ、免責事項など）に漏れはないか。
        * **正確性:** 数値、固有名詞、日付などに誤りはないか。
        * **表現の統一:** 敬体・常体の混在はないか。用語の表記は統一されているか。

    * **【観点2】法務・契約リスク**
        * **契約条項の明確性:** 当事者、権利義務、成果物、対価、期間などが一義的に解釈できるように具体的に書かれているか。
        * **リスクの洗い出しと手当:** 責任範囲（損害賠償）、知的財産権の帰属、秘密保持、再委託、契約解除、不可抗力、準拠法・合意管轄などが適切に定められているか。自社に過度に不利な内容はないか。
        * **法令遵守:** 個人情報保護法、下請法、景品表示法などの関連法令に抵触する可能性はないか。反社会的勢力排除条項は含まれているか。
        * **曖昧な表現の排除:** 「誠意をもって協議する」「可及的速やかに」など、解釈の余地がある表現が意図せず使われていないか、そのリスクは認識されているか。

# 出力フォーマット
---
### **法務レビュー結果**

#### **はじめに**
このレビューは、法務部門への提出前に資料の品質を高めることを目的としています。最終的な判断は、必ず法務部門にご確認ください。

#### **【総評】**
（資料全体を通しての、良い点と最も重要な改善点を2〜3行で簡潔に記載）

---
#### **【観点1】コンサルティング資料としての品質レビュー**

| 箇所（ページ数・章番号など） | 問題点 | 修正案（リライト案） | 修正理由 |
| :--- | :--- | :--- | :--- |
| （ここに具体的な指摘を記載） | | | |

---
#### **【観点2】法務・契約リスクの観点からのレビュー**

| 箇所（ページ数・条文番号など） | 潜在的リスク | 修正案（リライト案） | 修正理由と法的観点からの解説 |
| :--- | :--- | :--- | :--- |
| （ここに具体的な指摘を記載） | | | |

#### **【その他】法務部門へ確認すべき事項**
（AIだけでは判断が難しい、専門的な法的判断を要する事項をリストアップ）
* （例）本件のビジネスモデルは、〇〇法における規制対象に該当しないか、最終確認が必要です。
* （例）〇〇という条項は、過去の類似案件と比較して当社に不利でないか、確認を推奨します。

---

そして、都度ユーザが入力するプロンプトのテンプレートが以下。

こんにちは。
以下の資料について、法務部門への提出を想定したレビューをお願いします。

# 資料情報
* **資料の種類:** 【例：クライアントA社向け業務委託契約書ドラフト】
* **プロジェクトの背景・目的:** 【例：Bシステム導入に関するコンサルティングを提供するプロジェクト。本契約書はクライアント提示前の最終社内レビューが目的です。】
* **特に重点的に見てほしい点（任意）:** 【例：クライアントとの責任分界点と、成果物の定義について、特に手厚くレビューをお願いします。】

# レビュー対象の資料
（ここにレビューしてほしい資料のテキスト全文を貼り付けてください）

先程の簡単な問いかけでもここまで詳細なプロンプトを提示してくれます。これをベースに、出力形式を変えたければそのように書き換えればいいですし、あるいは会社固有の観点やあるあるの指摘ポイントなどをプロンプトの中に入れ込んでいけば、もっと実践的なプロンプトに育っていくはずです。

Gemは現状他人と共有ができないので、仮にプロンプトが育った場合にはその旨をチーム全体に周知し、各人でGemの内容を書き換えてあげる必要があります。ちょっと面倒ですね…おそらくそのうちGemは他人と共有できるようになるのではと思ってますが、サービスのアップデートを大人しく待ちましょう。

また、Gemの共有機能に加えてプロンプトのバージョン管理機構も備わってくれるとうれしいです。エンジニアであればプロンプトをGit管理するなどは特にハードルないでしょうが、そういったバージョン管理機能に馴染みのない人にとっては、GemのGUI上でポチポチするだけでバージョン管理ができると便利なんだろうなと思います。（もちろんエンジニアにとってもGem内で完結してくれた方がおそらく楽チンなはず）

さいごに

今回はバックオフィス業務改革に焦点を絞って話を進めてきました。しばらくはこの領域が私の主戦場となるので、今後直面するリアルな課題やその解決策についても別記事にてご紹介できればと思っています。

AI Tips連載はまだまだ続きます！引き続きお楽しみくださいmm

製造エネルギー事業部の後藤です。今回は「AI Tips連載」ということで私が普段業務で活用している生成AIに関する知見を共有します。

2022年のChatGPTの誕生を契機に、生成AIの進化はすさまじく、今や日々の業務に欠かせない存在になっています。生成AI（ChatGPT、Geminiなど）は単なるテキスト生成ツールではなく、日々の業務における「困った」を解消し、生産性を劇的に向上させる強力なパートナーです。

この記事では、そんな生成AIを、私が実際に業務で活用している知識の「獲得」「体系化」「伝達」という3つのフェーズに沿った具体的な事例でご紹介します。

2. 生成AI誕生前後の変化

これまで私たちは、膨大な情報の中から知識を掘り起こし、「知識のインデックス」を自力で作り上げる必要がありました。大学、書籍、各分野の有識者といった、大量の情報を持つ存在が大きな力を持っていた時代、まさに「知識自体に価値がある」時代です。

生成AIの登場は、この状況を大きく変えました。生成AIは、大量のインプットと高度なパターンマッチングにより、これまで苦労して作り上げていた知識のインデックスを、いとも簡単に生成できるようになりました。

この変化の最大の恩恵は、「自分が抱く疑問や考えに対し、過去の知見やその体系がどうなっているかを、瞬時に引き出せるようになったこと」です。生成AIの力を借りて足りない知識を補いながら、自分自身の思考を深めることが以前に比べて格段に容易になりました。

つまり、生成AIをうまく活用することで、私たちは「知の高速道路」に乗ることができ、より本質的に価値のある生産活動に注力できるようになりました。

3. 知識との向き合い方：生成AIが変える3つのフェーズ

知識とは何か、どのように機能するのか。これまでの人類の歴史は、まさにその探求の連続でした。ピーター・ドラッカーは、「知識とは、情報を仕事に、より効果的に適用できるようにするものである」と述べています。つまり、単なる情報収集だけでなく、それを活用し価値を生み出すプロセス全体が知識の本質と言えるでしょう。

生成AIは、この知識のサイクル全体に革命をもたらし、私たちの業務を次の3つのフェーズで劇的に変革しています。

①知識の獲得：未知の情報を効率的にインプットするフェーズ

このフェーズは、新しい分野に足を踏み入れた時や、特定のテーマについて深く理解したい時に直面する「知らない」の壁を打ち破ることを意味します。これまで、私たちは書籍を読み漁り、専門家から話を聞き、時間をかけて情報を集め、自分なりの「知識のインデックス」を頭の中に構築する必要がありました。情報の荒野から必要な知識を探し出す作業です。

しかし、生成AIは、この知識獲得のプロセスを劇的に高速化します。膨大なデータを学習したAIは、私たちが求める情報の「文脈」を理解し、整理された形で提示してくれます。

②知識の体系化：情報を整理し、共有可能な資産にするフェーズ

知識は、単に「知っている」だけでは不十分です。組織やチームにおいて真価を発揮するのは、それが整理され、他の人がアクセスしやすい形になっている時です。このフェーズでは、個人が獲得した断片的な情報を構造化し、誰もが利用できる「共有資産」を作り上げることを意味します。

「知識は共有されて初めて価値を持つ」という考え方は、現代のナレッジマネジメントの根幹をなしています。生成AIは、ドキュメントや会議の議事録、動画などの非構造化データから重要な要素を抽出し、分類し、関連付けることで、この体系化の作業を強力に支援します。バラバラだった情報が、AIによって意味のある繋がりを持ち、組織の「知のデータベース」構築を可能にします。

③知識の伝達：必要な情報を的確にアウトプットするフェーズ

最終的に、知識は具体的な成果物やコミュニケーションを通じて伝達され、価値を生み出します。このフェーズでは、体系化された知識の中から必要なものを選び出し、ターゲットとする相手に最も効果的な形で届けることが求められます。報告書、企画書、プレゼンテーションなど、その形式は多岐にわたります。

生成AIは、情報の要約、表現の最適化、さらには相手の理解度に応じた言葉選びまでサポートし、知識伝達の「質」と「スピード」を向上させます。人間が考えた本質的なメッセージに、AIが最適な「器」を与えることで、より強い影響力を持つアウトプットを生み出すことが、可能になります。

4. 知識の習得：未知の分野で「議論し、課題解決する」ための知識獲得術

新しいプロジェクトにアサインされた際、専門用語の羅列、業界特有の慣習、複雑な全体像など、ゼロからの知識習得は多くの時間と労力がかかります。

「未知の分野について有識者と議論し、課題解決をしていく」ためには単なる情報収集を超え、その分野の「常識」「暗黙のルール」「本質的な課題」を素早く把握し、自らの視点と結びつける能力が求められます。表面的な知識だけでは到達できない、「ビジネスコンテキスト」の深い理解が必要です。

これを実現するために、以下の4つのアプローチを、優先順位と組み合わせを意識し、知識を深めることで、「木を見て森を見ず」でも「森ばかり見て木が分からない」でもない、効率的な本質理解を進めることができると思います。

4.1 4つのアプローチとGeminiの活用法

①全体像を掴む「地図作り」アプローチ 🗺️

• 目的：Googleマップで全体像を掴むように、業界の主要な要素（プレイヤー、ビジネスモデル、バリューチェーン、業界用語など）と、それらの関係性を把握します。この「思考の地図」がないと、いくらAIに情報を聞いても断片的な知識で終わってしまいます。

• Gemini活用例：

  • 「〇〇業界（例：日本の建設業界）の主要なビジネスモデル、プレイヤー、バリューチェーン、一般的な課題を、コンサルタントが初期に理解すべき粒度でまとめてください。」
  • 「〇〇業界の課題を、技術的、市場的、法的、人材的側面から漏れなくダブりなく分類し、具体的な内容を説明してください。」

②時系列アプローチで業界の今と未来を掴む ⏳

• 目的：業界の「今」がなぜ今の状態なのかを理解し、今後の方向性を予測する基礎を築きます。議論では現状認識だけでなく「これからどうなるか」が常に問われるため、この視点は不可欠です。

• Gemini活用例：

  • 「〇〇業界の過去10年間の主要な変化、そのきっかけとなった出来事、および現在のトレンドに至るまでの変遷をまとめてください。」
  • 「〇〇市場の今後3〜5年の主要な成長ドライバー、予測されるリスク、および業界の進化シナリオを複数提示してください。」

③理解の深化に：因果関係アプローチで本質的な「なぜ？」を問う 💡

• 目的：構造とトレンドを理解したら、次は「なぜそうなっているのか」という本質的な理由や、事象間の繋がりを深く掘り下げます。ここが弱いと、表面的に知識があるように見えても、議論で深く突っ込まれた際に立ち往生してしまいます。

• Gemini活用例：

  • 「〇〇業界における人材不足の根本原因は何か？複数の視点（教育、労働環境、魅力度など）から深掘りして説明してください。」
  • 「〇〇技術の導入が進まないのはなぜか？技術的課題だけでなく、ビジネスモデル、法規制、社会受容性など、考えられるあらゆる阻害要因とその因果関係を分析してください。」

④差別化と戦略立案に：比較対比アプローチで新たな視点を得る ⚖️

• 目的：知識を相対化し、業界内での立ち位置や、他業界の成功事例からの応用可能性を探ります。これは、課題解決のための「打ち手」を考える際に特に重要です。

• Gemini活用例：

  • 「〇〇業界の主要プレイヤーA社とB社を、ビジネスモデル、技術戦略、顧客獲得手法、組織文化の観点から比較し、それぞれの強みと弱みを分析してください。」
  • 「〇〇業界が直面する課題（例：サプライチェーンの非効率性）に対し、他業界（例：自動車業界、EC業界）で成功している解決策を複数紹介し、その適用可能性を考察してください。」

これらのアプローチはすべて、「自分自身の頭の中にシンプルながらも構造化されたインデックスを持つ」ことに繋がります。AIは優れた情報源であり、思考の加速装置ですが、その出力の質は「問いの質」に依存します。

重要なのは、AIに「何を答えてほしいか」ではなく、「何を明らかにしたいか」「どのような洞察を得たいか」という明確な意図を持って対話することです。この「問いを設計する力」が重要です。

5. 知識の体系化：NotebookLMで「探せない」「読まれない」を過去にする社内ナレッジ活用術

5.1 課題：社内ドキュメントの「読まれない」「探せない」問題と知識のギャップ

Geminiのような汎用生成AIは、インターネット上の膨大なデータから一般的な知識を提供してくれます。しかし、業務ノウハウ、特定のシステム詳細、プロジェクト固有の知見といった「ドメイン固有の独自の知識」は、汎用AIではカバーできません。これらの資産が、うまく共有されず埋もれてしまうことが大きな課題でした。

開発チームではGitHubリポジトリのREADMEやdocs配下に多くのドキュメントをまとめているものの、情報の「探しにくさ」が課題でした。従来の全文検索では、そもそも適切なキーワードが思いつかない、あるいは大文字・小文字、表記のゆれ（例：カタカナと英語）などに対応しきれず、本当に欲しい情報にたどり着けないことが多々ありました。たとえキーワードがヒットしても、必要な情報が複数のドキュメントに分散しているため、結局はそれらを手動で探し回ったり、個別のドキュメントのパスを教える手間が発生したりと、意図した文脈で情報を探し出すのが難しい場合が多いです。

その結果、新しいメンバーからの同じような質問が頻発し、ベテランメンバーは「ドキュメントは存在するのに、なぜか読まれない（たどり着けない・まとめられない）」という非効率な問い合わせ対応に追われていました。これは、せっかく蓄積された社内知識が、有効に活用されていない状態と言えます。

5.2 解決策：解決策：NotebookLMによる「独自の知識」の体系化と高速アクセス

この課題を解決するため、NotebookLMはとても有効です。GeminiやChatGPTのような汎用生成AIは、汎用AIがインターネット上の膨大なデータから一般的な知識を提供する一方、NotebookLMは、インプットした特定の情報源（ドキュメント、PDF、ウェブページ、動画など）に基づいて対話・要約・分析するAIアシスタントです。

これにより、以下の点で社内ナレッジの体系化と活用が劇的に変化します。

• 信頼性と精度: 汎用AIと異なり、NotebookLMは指定された情報源のみを参照するため、ハルシネーション（誤情報）のリスクが大幅に低減する。すべての回答には参照元のリンクやタイムスタンプが明確に示されるため、根拠の確認やファクトチェックが容易
• ドメイン固有知識の活用: 組織内の非公開なドキュメントや動画を直接学習させることで、社内規定、特定のプロジェクトの議事録、独自の技術資料といった「独自の知識」に特化した質問応答が可能。これまで検索しにくかったり、人に聞かないと分からなかったりした情報が、瞬時に引き出せるようになる
• ドキュメントと動画の役割分担と連携:
  • ドキュメント（Markdownファイルなど）： 構造化されたコアな知識、一般的な手順、概念定義など、いつでも誰でも参照すべき汎用的な情報をまとめる。NotebookLMは、これらのテキスト情報を効率的にインデックス化し、質問に回答する
  • 動画（会議録画、デモ動画など）： ドキュメントを補足する詳細な手順、特定の状況におけるニュアンス、口頭での議論の経緯、デモンストレーションなど、鮮度が高く、より具体的な「How-to」や「Why」を伝える

5.2.1 ドキュメント・動画の取り込みと活用例

取り込み方法

• ドキュメントの取り込み方:
  • GitHubリポジトリのMarkdownファイルや社内WebサイトのURLを直接読み込ませる
• 動画の取り込み方:
  • 引継ぎ時の録画動画など、音声情報を含むファイルもインプットできる。ただし、1ファイル200MB以下（約20分相当）という制約があるため、長時間の動画は分割が必要

NotebookLMにアクセスし新規作成ボタンを押下

データのアップロード

効果的な質問と活用例

• 「環境構築の手順を教えてください。」
• 「〇〇というエラーメッセージが出た場合、考えられる原因と対処法は何ですか？」
• 「〇〇機能の概要を教えてください。」
• 「〇〇を改修する場合、どのような影響がありますか？また変更に伴い影響を受けるシステムはありますか？」

5.2.2 開発不要で得られる具体的なメリット

NotebookLMは、ドキュメントや動画内の関連情報を抽出し、質問に対する回答を生成します。回答と共に参照元のリンクや動画のタイムスタンプを示してくれます。これにより、ユーザーはすぐに元の情報を確認し、自己解決の糸口を見つけられます。

この機能のおかげで、ベテラン開発者が個別の質問に対応する時間を大幅に削減でき、新規で参画したメンバーも高速にキャッチアップが可能です。結果として、コミュニケーションコストも大幅に削減され、チーム全体の生産性向上に貢献します。

5.3 検証結果と見えてきた課題：NotebookLM活用の現実

GitHubのREADMEや特定機能を説明した2時間程度の動画をNotebookLMにインプットした検証では、良質な回答が得られましたが、いくつかの課題も見えてきました。

まず、AIの誤答と自信過剰な主張です。情報が少ない場合、AIが誤った内容を、あたかも正しいかのように自信満々に提示することがありました。このため、特に知識が浅い利用者がAIの回答を正しく評価するのは、ファクトチェックがあるとはいえ現実的には相当難しいと思いました。とくに複雑なビジネスロジックや複雑な過去の背景がからむ場合、一定の情報量がないと正しい理解ができないケースが多いため、ごく限られた情報のみをインプットするリスクもあると感じました。ただしソースを追加していくことで正しい答えに近づいていきました。体系的かつ網羅的にデータをインプットすることが重要です。

次に、動画の文字起こし精度には、まだ不安定な部分がある点です。検証中に、文字起こしされたテキスト自体に誤りがあるにもかかわらず、その誤ったテキストを参照元として提示しながら、NotebookLMの最終的な回答は正しいという奇妙な現象が発生しました。これは、AIが文字起こしの不正確さを内部で補正して正しい回答を導き出しているのかもしれませんが、「参照元が怪しいのに回答が正しい」という混乱を招きます。事前に業界用語の辞書などをNotebookLMに渡すことで、文字起こし自体の精度が向上し、結果として回答の信頼性も高まる可能性があるので、今後試してみたいと思います。

また、現状では制約事項も存在します。1ファイル200MB以下（約20分動画相当）という制限があるため、2時間のような長時間の動画をインプットするには分割が必要です。加えて、データソースの上限がProプランでも300という制約もあり、大規模な組織で大量の情報を扱う際には、すぐに限界が来てしまいますが、今後の拡張に期待しています。

5.4 知識体系化における運用と展望

NotebookLMの回答精度は、インプットされるドキュメントや動画の品質に大きく左右されます。AIが最大限に能力を発揮できるよう、運用側にも積極的な工夫が求められます。AIを活用した「知識の体系化」は、一度やれば終わりではなく、継続的に知識を「育てる」活動です。

5.4.1 ドキュメント運用の工夫：知識の「骨格」をAIと共に育てる

ドキュメント（テキスト情報）の役割は、知識の構造的理解を助ける「骨格」を築くことです。明確な見出しや結論ファーストの構成により、概念や手順、用語の定義といった普遍的で体系化された情報を効率的に伝達します。NotebookLMが複数ドキュメントを読み解く上で、この構造化された情報があればあるほど、正確なインデックスを構築し、高品質な回答を提供しやすくなります。

AIが複数ドキュメントからどこを重要と捉えるか不明確なため、あいまいな言葉や属人化された表現を避け、普遍的で具体的な記述を徹底することが不可欠です。また、不要な情報や古い情報は削除し、ドキュメントの「鮮度」と「ノイズの少なさ」を常に保つ意識が重要です。

「READMEをまとめるのが面倒」といったドキュメント整備のハードルに対し、負担を軽減するための工夫も重要です。docs配下への集約といったガイドラインを策定するのも有効でしょう。

5.4.2 動画運用の工夫：知識の「詳細」と「文脈」をAIと共に育てる

動画（非構造化データ）の役割は、知識の「詳細」と「文脈」を補完することです。動画は、構造化された事象のより詳細で具体的な内容の補強や、ピンポイントの質問、あるいは困りごとが発生した際の参照に適しています。人によって知りたい情報の粒度や関心事項が異なるため、すべての人のニーズに完璧に沿ったドキュメントをあらかじめ用意できません。

この点で動画は強力な補完ツールとなります。例えば、口頭でのやり取りのニュアンス、特定の議論の背景にある複雑な制約などは、ドキュメントでは表現しきれません。動画をデータソースとすることで、大量の生きた情報を手間なくインプットとして利用できる点、そしてドキュメント作成の手間が省ける点は大きなメリットです。

NotebookLMは動画を文字起こしするだけでなく、その内容を関連するドキュメント情報と結びつけます。これにより、ユーザーは「このドキュメントのこの箇所について、〇〇分〇〇秒の動画で詳しく説明されている」といった形で、テキストと動画を横断しながら必要な情報を多角的に引き出せるようになります。

5.4.3 今後の展望と期待：AIと人間の協調によるナレッジマネジメントの進化

AIにインプットされることを前提とした情報管理の仕組みが、すでに求められる時代です。

今後は、Google Meetの録画を基本とし、自動でNotebookLMにデータが反映されるようなフローを構築し、知識共有の効率を飛躍的に向上させたいと考えています。個人情報や不要な情報の排除など検討すべきこともあります。また、業務知識特化AIとして、NotebookLMが誤った情報を出した際に、その場で修正し、新しいドキュメントとして取り込ませるようなインタラクティブな機能が提供されると、知識の「鮮度」を保ちやすくなると感じています。GitHubやチャットなど、多様な情報源から自動で情報を取得できる機能が加われば、回答精度はさらに増し、組織の知識基盤は一層強化されます。こうした機能がより簡単に実現できるようになる今後を見据え、いかに効率的に知識体系を構築し、どのような仕組みを導入するのが最適か、今から戦略的に検討することが重要だと思います。

6. 知識の伝達：Geminiで質とスピードを両立する成果物作成術

6.1 課題：伝わる成果物作成の難しさと品質担保

顧客向けレポート、社内報告書、企画書といったビジネス成果物の作成は、多くの時間を要し、高い品質が求められます。データ分析や情報収集はできても、それを「分かりやすく」「説得力のある」文章にまとめ、ターゲットに合わせた表現や構成にするのが難しいと感じることは多々あります。

特に、成果物を作成する場合、アウトプットの作成自体に時間をかけすぎてしまい、論理構造の整理やストーリー構成が後回しになりがちです。また、自分で書いた文章は、翌日読み返すとひどいと感じるほど、客観的・批判的な視点を持てないという課題もあります。

さらに、自己レビューだけでは見落としがちな誤字脱字、構成的な問題、さらには経営層が気にするであろうポイントなどを効率的に発見したいというニーズもあります。このように成果物の品質担保は容易ではありません。

6.2 解決策：Geminiを「思考のパートナー」兼「無限のレビューア」にする

こうした課題に対し、Geminiは知識伝達のプロセス全体を強力に補助するパートナーになります。思考を整理し、知識を効果的に伝えるための強力な「共同執筆者」であり、無限に壁打ちができる「質の高いレビューア」のように機能します。

Geminiを活用する上で重要なのは、AIを「部分最適」で活用することです。複雑な成果物ほど、全体の意図が十分に反映されないリスクがあるため、人間が主導権を持ち、AIに任せる部分を明確に分けましょう。

思考の整理と知識の構造化

成果物をまとめる過程で、知識の構造化はより洗練されます。しかし、ゼロから構造を組み立てる際に整理の糸口が見つからないことはよくあります。そんな時、Geminiは「こういう分類ができるのでは？」「この要素間の因果関係はこうなのでは？」など、多角的な提案をしてくれます。AIとの対話を繰り返すことで、物事をどれだけ構造化して解釈し、理解しているかという、アウトプットの鍵となる思考プロセス自体が洗練されていきます。

効率的な役割分担と品質向上

作業としては、要素や主要なメッセージは人間が書き、文章の生成はAIに任せるという分担が効果的です。これにより、人間は成果物の本質的な内容やストーリー構築に集中し、より批判的な視点を持てるようになります。ただしAIが生成した文には違和感がある場合がほとんどなので、プロンプトを工夫したり細かい部分は確認して修正するようにしています。

無限の壁打ちと多角的なレビュー

AIにレビューをしてもらうことで、成果物の品質を飛躍的に高められます。対人レビューでは時間的制約やインプットのスループットの限界、また心理的な遠慮がありますが、AIの場合は無限に壁打ちができるため、様々な角度からの指摘を受け、多角的に文章を磨き上げることが可能です。

もし意図通りにいかない場合は最初からやり直す発想も必要です。途中で良質なアウトプットや方針が得られたら、その部分を文章にまとめてもらうなどして、時間短縮と品質向上の両立を図ることができます。

6.2.1 実践プロンプト：Geminiによる具体的な補助

Geminiの豊富な機能と理解力を活用し、以下のような指示で成果物作成を加速・向上させます。

初稿・構成案の高速作成

QAシートや課題表のテキスト、ヒアリングメモなどをGeminiに渡し、「この内容に基づき、〇〇に関する顧客向けレポートの構成案と、各セクションのドラフトを作成してください。誰々が理解しやすいように、ポジティブな表現を多めに、専門用語は避けてください。」と依頼します。エクセルデータの場合は、Google Docsに変換して貼り付けるなど、取り込み形式を工夫しましょう。

文章表現の改善・要約・言調調整

作成した文章をGeminiに渡し、「この文章をより顧客に響くように、専門用語を避け、分かりやすい言葉に修正し、語尾を『ですます調』に統一してください。」や、「この報告書の要点を抑えて○○文字で要約し、経営陣が最も関心を持つであろう3つのポイントを強調してください。」といった指示を出します。

レビュー観点の提供と改善点の発見

作成中のレポートを渡し、「このレポートについて、『構成がMECE（漏れなくダブりなく）か』『経営陣が気にするであろう視点』『上司から指摘がありそうな点』を踏まえてレビューしてください。」と質問します。過去に受けた指摘をプロンプトに含めることで、より的確な指摘を得られます。誤字脱字や文法的な問題の発見にも活用できます。

6.2.2 成果物の品質を最大化するAI活用

AIがレビューを補助することで、自分一人では気づきにくい間違いや欠点を発見でき、最終成果物の品質が格段に上がったと実感しています。

しかし、AIがどれだけ高度化しても、最終的な成果物の意図と責任、そして伝達における非言語的な要素は人間でしか担えません。例えば、ヒアリング結果をまとめる際、AIはテキスト情報から要点を抽出できても、実際に話を聞いた時の「空気感」や「非言語情報」までは理解できません。そのため経験や判断に基づき、情報の重要度を最終的に判断し、必要に応じて修正を加えることが必要です。

AIに構成を出してもらった場合、その答えに引きずられてしまうケースがあるため、より良い論理構造はないか、どうすればより伝わりやすいか、さらに良い方法はないかといった視点を常に持って成果物を作成する必要があります。また、AIは肉付けは得意ですが、全く新しい要素を提案してもらうことを期待しすぎない方が良いでしょう。主要なメッセージやポイント、本当に伝えたいことは人間が作り出す部分が大きいと感じます。

AIとの対話で成果物を洗練させていくイメージが重要です。AIとのやり取りを通じて、AIから直接言われたわけではないが「こうした方がいいのではないか」といった新たなアイデアが思い浮かぶ機会が増えると思います。このように、AIとの対話自体が、人間の思考を刺激し、より本質的な改善につながります。

7. 生成AI時代に必要な力

生成AIは驚くべき能力で高品質な情報を短時間で生成できますが、現時点では「何でも解決する」万能のツールではありません。むしろ、AIの進化が加速する今、私たち人間が磨き、発揮すべき能力が、これまで以上に明確になってきていると思います。

ここまで知識の「獲得」、「体系化」、「伝達」という3つのフェーズにおいて、生成AIが生産性を劇的に向上させる強力なパートナーであることを示しました。これらのAI活用を真に価値あるものにするためには、以下の力を発揮し続ける必要があります。

7.1 AIとの協調を導くインプット力と問いの質

AIは一瞬で膨大な情報を処理し、生成しますが、その力を最大限に引き出すのは、人間が提供する適切なインプットです。AIが数秒で要約やアイデアリストを生み出しても、それを人間が理解し、評価し、次の行動に繋げるまでの時間は変わりません。AIからの情報過多で、かえって混乱することすらあります。

この課題を克服し、AIのアウトプットを最大限に活かすためには、「良い質問力」（プロンプトエンジニアリング）が不可欠です。これは、知識獲得のセクションで強調した「思考の地図」を持ち、漠然とした疑問ではなく、本当に知りたいことの「問いの質」を高めることと直結します。AIが生成した情報の中から、本当に必要な部分を見抜き、その意味を素早く正確に理解する「インプットに耐えられる能力」も、この時代に求められる重要な力だと思います。

7.2 批判的思考と本質の見極め

生成AIは非常に流暢で説得力のある文章を生成するため、その結果を安易に鵜呑みにしてしまうリスクがあります。AIはまだ完璧ではなく、事実と異なる情報（ハルシネーション）や、学習データに起因する偏った見解を提示する可能性があります。

AIのアウトプットを「仮説」として捉え、「本当に正しいか？」「他に視点はないか？」「根拠は何か？」といった批判的な問いを投げかける「批判的思考力」が不可欠です。NotebookLMの検証でも見られたように、AIが自信満々に誤答を示すケースもあるため、人間が常にAIの出力を検証し、深掘りする姿勢が求められます。知識を伝達する成果物作成においても、AIに構成を提案されても、その答えに引きずられず、より良い論理構造はないか、どうすればより伝わりやすいかといった視点を常に持つことが重要です。最終的な意思決定や結論を導き出すためには、自らの知識、経験が必要です。

7.3 AIとの対話が深める「腹落ち」と価値創造

AIが生成する情報は一見完璧に見えますが、それを「自分の言葉で、完全に腹落ちして伝えられる」ことが重要です。この能力の有無は、一見しただけでは判別しにくいのが現実です。

AIの出力に安易に引きずられることなく、自身の知識、経験、倫理観、そして論理的思考力で咀嚼し、血肉化するプロセスは、人間にしかできません。成果物作成のセクションで述べたように、ヒアリングの「空気感」や「非言語情報」といったAIには理解できない要素を理解し、成果物に反映させるのは人間固有の能力です。この「腹落ちさせる」能力こそが、単なる情報処理者ではなく、AIを真に使いこなし、価値を創造できる人材とそうでない人材を分ける決定的な要素になると思います。

AIとの対話は、時にAIが直接言わないことからも新たなアイデアや気づきを生むききっかになります。AIに肉付けは任せつつ、主要なメッセージやポイント、本当に伝えたいことは人間が作り出し、AIとの対話を通じて成果物を洗練させていくイメージは、人間がAIから「真に学び」、より本質的な改善を促すプロセスです。

7.4 視点と熱量が拓く人間固有の価値創造のサイクル

情報自体が簡単に手に入る「知の高速道路」時代において、「どれだけ多様な視点を持っているか」が、AIから引き出せる情報の質と量を指数関数的に増やします。一般的な知識はAIが瞬時に提供できますが、そこからが人間の本領です。

興味のある事柄に対しては、誰よりも詳しくなれるチャンスが広がっています。ツールの性能差が縮まる中で、「何に興味を持ち、どれだけの熱量を持ってその知識を深掘りし、活用しようとするか」という、人間固有の「情熱」が成果の大きな差となって表れると思います。

一般論はAIがすぐに提供してくれます。だからこそ、その先へ、いかに早く手を動かして独自の知見や深い洞察を得て、それをまたAIにフィードバックしていくかが重要です。このサイクルが、AIと人間が協調して「新たな知識」を継続的に生み出し、より本質的で創造的な価値を追求する道となると思います。

まとめ

生成AIは、現代の働き方に劇的な変革をもたらしています。この記事で紹介した知識の「獲得」「体系化」「伝達」という3つのフェーズでAIを活用することは、単なる効率化を超え、私たちの思考を深く洗練させ、これまで不可能だった価値創造に繋がります。

AIは瞬時の情報処理と無限の壁打ち相手を提供してくれます。しかし、その力を真に引き出すのは、「問いの質」を追求する人間の知的好奇心であり、AIの出力に流されず本質を見抜く批判的思考力です。そして何よりも、AIから得た情報を自身の知識、経験、そして論理的思考で消化し、心から納得できるまで深く向き合う情熱が不可欠です。

AIが一般論を瞬時に提供する時代だからこそ、私たちの興味や熱量が、誰よりも深く独自の知見を生み出す鍵となります。AIはただの道具ではなく、人間の思考を刺激し、新たな気づきをもたらしてくれます。AIから得たヒントを基に、自ら手を動かし、深い洞察を得て、それを再びAIにフィードバックする。この人間とAIの協調サイクルが、未来の価値創造の原動力となります。

私たち一人ひとりがAIとの新しい関係性を築き、日々の業務を「よりスマートに、より創造的に、そしてより楽しく」変革していきましょう。

参考文献

• OpenAI. “ChatGPT” https://openai.com/blog/chatgpt
• ピーター・ドラッカー『現代の経営』
• Google. “NotebookLM.” https://notebooklm.google/

はじめに

初めまして、フューチャーアーキテクト製造エネルギー事業部の門倉です。

会議での生成AI活用方法を例として、 “生成AIとの上手な付き合い方” について、備忘も兼ねて考えをまとめます。

会議のフロー

本題に入る前に、会議を進めるうえで重要なポイントを踏まえながら、会議のフローを整理しておきましょう。

準備
会議の成否のカギを握るのがこの準備段階となります。
具体的には、会議の目的やゴールを設定したうえで、それを達成するためのアジェンダを作成します。そして最後にアジェンダに沿った会議資料を作成します。

実施
続いて、準備した会議資料に沿って参加者間で議論を実施します。
ここでは、議論内容が逸れずに、設定した目的やゴールを達成できるようにファシリテーションすることが求められます。

まとめ
会議が終了したら、会議での議論内容や決定事項およびネクストアクションをまとめておきます。
単に決定事項やネクストアクションを列挙しておくのではなく、そこに至った議論の経緯含めてまとめておくことが重要となります。

このように「会議」と一口に言っても、「準備」から「まとめ」まで多くのタスクが求められます。会議内容次第では、この一連のフローを回すだけでかなりの時間を使ってしまうことも少なくないのではないでしょうか？

そこで生成AIを活用することで、会議に関わる業務を効率化し、より本質的なタスクに時間を割くことができるようになります。

会議における生成AIの活用

では早速、会議に関する一連のタスクの中でどのように生成AIを活用できるか、私が普段実践しているTipsを中心にまとめていきたいと思います。

準備

参考情報の収集及び整理

まずは会議資料作成時、その材料としてWeb上の参考情報を集めて整理するのに生成AIを活用できます。

下記の例では、製造業におけるデータ利活用の事例を収集しました。

プロンプトでは下記を意識してより詳細に記載すると、イメージ通りの回答を得ることができます。

• 収集する対象は何か
• 集めた情報をどのように整理するか
• その他、含めてほしい内容

また、DeepResearchを利用すればより広範かつ詳細な情報収集が可能となり、レポートレベルの回答を得ることも可能です。

製造業における、データ利活用によって「生産計画」を改善した事例をウェブページから検索し、列挙してください。
特に、以下の情報に焦点を当ててください。
・実際のメーカー名を含む、生産計画に関する事例
・どのようなデータを活用し、どのような改善を行ったか

結果として、見つかったウェブページのURLと、各ページに記載されているメーカー名を含む受注に関する事例の概要をリスト形式で出力してください。

- 会社A:
    - 顧客の機械稼働データを収集・分析し、故障予測やメンテナンス提案をリアルタイムに行うことで、顧客との信頼関係を強化し、サービス契約や部品受注の増加につなげています。
    - 顧客の稼働状況を把握することにより、より適切なタイミングでアフターサービスを提案することが可能になり、結果として受注の増加に繋がっています。
    - 参照URL: hogehoge

- 会社B:
    - 建機の稼働データを活用し、顧客の稼働状況を把握することで、機械のメンテナンス提案や部品受注の最適化を図っています。
    - 顧客への能動的な提案や、機械の故障を未然に防ぐメンテナンス計画を立てる事により顧客満足度を高め、受注の増加に繋げています。
    - 参照URL: hogehoge

- 会社C:
    - FA（ファクトリーオートメーション）分野において、製造現場のデータを収集・分析し、顧客の生産性向上に貢献するソリューションを提供することで、システム受注の拡大を図っています。
    - 参照URL: hogehoge

スライド作成

デザインや配色など、ある種のセンスが問われるスライド作成時にも生成AIを活用できます。

スライドで伝えたいことの概要と詳細、スライドイメージをプロンプトにまとめることで、ハイセンスなスライドを作成してくれます。

会議の一連の流れをまとめたスライドを1枚作成したいです。
下記の会議の一連の流れをグラフィック要素も交えてわかりやすく表現してみてください。

■会議の流れ
- 準備
    - 目的を考え、それに沿ったアジェンダを考える。
    - アジェンダに沿った会議資料を用意する。
- 実施
    - 用意した会議資料に沿って議論実施する。
- 振り返り
    - 会議での決定事項及びTODOをまとめる。
    - 次アクションを考える。

(作成されたスライド)

実施

文字起こし

続いて、会議実施中における生成AIの活用方法です。

オンラインミーティングを実施する場合、多くのツールで文字起こし機能を利用できます。この機能を利用し生成AIに議事メモ作成をお願いすることで、全員がより集中して会議に参加することが可能になり、記録漏れということもなくなります。

オフラインミーティングの場合は、音声を録音しておき、あとで録音ファイルをinputに文字起こしを生成AIに依頼できます。

まとめ

議事メモの作成

会議後に作成する議事メモでは、単なる文字起こしではなく参加者の発言の要点を簡潔にまとめたうえで、決定事項やネクストアクションを整理することが求められます。

単純な一問一答形式の会話内容であれば「問い」と「答え」を記載するだけですが、たいていの会議は決定事項に至るまでに複数の論点があり、時には一部参加者が迷子になることもしばしばあります。

ここで生成AIの出番です。会議中に作成した文字起こしファイルをinputに、議事メモとして記載したいポイントをプロンプトにまとめることで、会議での決定事項だけでなくそこに至る経緯も簡潔にまとめてくれます。

これは戦略会議など、内容が抽象的になりがちな会議で特に有効です。

文字起こしファイルをinputに、業務領域ごとにIT戦略で目指したい将来像をまとめてください。
その際、それを将来像として定義する理由や目的など議論の経緯が分かるようにしてください。

音声概要の作成

会議内容を簡単に振り返りたい場合、議事メモを読んで理解するのは一苦労と感じたことはないでしょうか？

そういった場合には、NotebookLMの音声概要機能が非常に有効です。

利用方法は簡単で、NotebookLMにアクセスし、ソースをアップロード後、「音声解説」タブで音声ファイルを生成できます。音声ファイルは5~10分ほどで、2人がソースファイルに関してラジオ風に会話をしてくれます。

これを利用すれば、ラジオ感覚で簡単に会議の内容を振り返ることができ、時間のない社長に移動時間の間に会議内容をインプットしておいてもらうといったことも可能になります。

過去の会議内容確認

過去にさかのぼって会議内容を確認したいときにも生成AIを活用できます。

利用方法は至って簡単で、知りたい内容について過去にどのような議論があったかをプロンプトとしてまとめるだけです。

ここで一番重要となるのがファイル（フォルダ）管理方法です。

各会議の議事メモや文字起こしファイルを1つのファイルやフォルダにまとめておくことで、会議以外のノイズ情報を除去でき、より正確に過去の会議内容を振り返ることができます。過去の議論を思い出したいときや、自分がPJ参画する前の議論内容をキャッチアップしたいときに役に立ちます。

人間と生成AIの共存

ここまで、「会議」という身近な場面における生成AI活用方法を紹介してきました。

少し前まではあまり強く意識していなかったAIも、最近では日常生活のあらゆるところで役立っています。

最後に、今回の活用方法に対する所感として、人間と生成AIの最適な共存関係について記載したいと思います。

まずはじめに、ビジネスの場面では主に2つのことが求められます。

• (1)方針を考える
• (2)方針に沿って必要なタスクを遂行する

これを会議のフローに当てはめると下記のように分類できます。

• (1)方針を考える
  • 会議の目的やゴールを設定
  • アジェンダを作成
• (2)方針に沿って必要なタスクを遂行する
  • 会議資料作成
  • 会議実施
  • 会議内容をまとめる

そして、今回紹介した会議における生成AIの活用はいずれも「(2)方針に沿って必要なタスクを遂行する」際の活用方法でした。

この理由について考えてみると、人間と生成AIの最適な共存関係が見えてくると思います。

つまり、「(1)方針を考える」のは現状の課題を踏まえてあるべき姿を想像的に描ける人間が担い、一方で、「(2)方針に沿って必要なタスクを遂行する」際には生成AIの力を借りて加速させる という関係です。

これは会議以外でも当てはめることができます。例えばPJそのものに着目してみても、人間が何かしらの課題感を持ってPJを立ち上げ、その課題に対する解決策を生成AIがサポートする場面もあるでしょう。

この関係は、人間が目的地を決めたうえで、自動車を利用して目的地までより速く移動するという関係にも似ており、いわばこれまでの技術革新の段階でも発生していた関係と言えるかと思います。

このような共存関係を理解し、ビジネスにおけるあらゆる場面を「(1)方針を考える」「(2)方針に沿って必要なタスクを遂行する」の2つに区別することで、より効果的に生成AIを活用できるのではないでしょうか。

本記事のまとめ

会議という身近な場面においてでも生成AIを大いに活用できる時代になりました。

具体的には準備段階での情報収集・整理やスライド作成、会議実施中の文字起こし、会議後の議事メモ作成や音声概要作成、過去の会議内容確認などに生成AIを活用できます。

このことからも分かるように、人間が「方針を考える」役割を担い、生成AIが「方針に沿って必要なタスクを遂行する」役割を担うことで、最適な共存関係が築けるのではないでしょうか。

春の入門祭り2025 8日目です。

はじめに

はじめまして。製造・エネルギー事業部に所属しております、金森と申します。私は自動車メーカーからフューチャーへと異業種転職してきたという、少し珍しい経歴を持っております。

春の入門祭りということですが、春は新しいスタートの季節です。学校や職場など、多くの人が変化の中で新たなチャレンジに向き合う時期ではないでしょうか。

今回は、そんな季節にぴったりのテーマである 「チーム異動などで環境が変わった後の立ち上がり方」 についてお話ししたいと思います。
転職という大きな環境の変化も経験しているからこそお伝えできる、心構えやちょっとした工夫をご紹介していきます。

環境変化では「ゼロから」ではなく「編集から」始める

新しいチーム、新しいプロジェクト、新しいドメイン——IT業界では異動が日常的に発生します。異動先の業務は未知の連続に見えるかもしれませんが、私は「ゼロからスタート」だとは考えないようにしています。むしろ、「編集から始める」という意識が大切だと思っています。これはどういうことかというと、「チームにある暗黙知」や「既存のプロセス」「使われている用語やツール」など、既に存在しているものにまず自分を馴染ませ、少しずつ意味づけや関わり方を変えていくという考え方です。

最初から変革者のようなスタンスで入ると、摩擦が生まれやすく、信頼を得るのも難しくなります。一方で、まずは今あるやり方を尊重し、「なぜそのように運用されているのか？」を観察・理解した上で、 「もしこうだったらもっとよくなるかもしれない」といった編集者的視点を持つことで、変化の受け入れと提案のバランスの取れた動き方ができるようになります。

「観察」と「共感」は、最初のタスクである

異動後の最初の1〜2週間で意識しているのは、「観察」と「共感」のインストールです。

特に観察では、「誰がキーマンなのか」「どのような暗黙のルールがあるのか」「過去にどんな課題があったのか」といった点を丁寧に掴むようにしています。Slackの過去ログを読み漁ったり、タスク管理ツールの履歴を遡ったりして、表面的な情報だけでなく、空気感や歴史的な背景にまで目を向けることを大切にしています。
一方で、共感はもっと感情に関わる部分です。

初対面のメンバーが抱きやすい「この人は味方だろうか？ それとも違うのか？」という無意識の問いに対し、自然と「味方ですよ」と伝わるような態度を取ることが重要です。

そのためには、ちょっとしたリアクションやSlackでの軽いツッコミ、さりげない称賛が意外にも効果的です。

技術があるだけでは、タスクは進めどチームに馴染むことはできません。「この人と一緒に働いていて楽しい」と感じてもらうことが、結果的に生産性の向上、よりよい製品にもつながると実感しています。

自信がないまま始まってもいい

新しいプロジェクトに入るとき、特に異動直後や転職後は、「自分に何ができるのか？」「本当にこのチームの役に立てるのか？」という不安がつきまといます。

私自身、IT業界に飛び込んだ当初は、シェルの使い方も知らず、「フロントエンド」「バックエンド」といった言葉の意味すら曖昧な状態でした。そんな中での最初のタスクは、自分の開発環境を構築すること。しかし、当たり前のように飛び交う専門用語に戸惑い、手順書の内容すら理解が追いつかず、環境構築だけで2週間もかかってしまいました。

Slackではどんどんやり取りが進み、チームは次のフェーズへ向かっている。一方で自分は「まだスタートラインにも立てていないのではないか」と焦りと劣等感を感じていました。

しかしあるとき、「とにかく手を動かしながら覚える」「全部を理解しようとせず、わかるところから地道に拾う」というスタンスに切り替えました。すると、知識は後からついてくること、そして何よりも「今わからないことを素直に聞けること自体が、チームの前進に役立つこともある」と気がつきました。

例えば、複雑化した要件定義を読み解くとき、「これはそもそもなぜこういう仕様なのでしょうか？」と素直に聞くことで、実は誰も気づいていなかった抜け漏れが見つかったこともありました。スキルが足りないことを補うには、恐れずに聞く勇気が非常に有効だと実感しました（※もちろん自学での成長も重要ですが）

最初から自信を持つ必要はありません。むしろ自信がないからこそ謙虚に学び続けられるし、気づける視点があります。それこそが、新しい環境に飛び込んだ人の大きな武器になると、今では思っています。

さいごに

「技術ブログ」と聞くとコードや実装の話に偏りがちですが、人や組織の変化が絶えないITの世界だからこそ、「どう立ち上がるか」「どう馴染むか」という視点も、立派な技術知見だと私は考えています。

これはあくまで私の個人的見解になりますが、誰かの助けの一助にでもなればと思います。

次は実際に「技術的なブログ」を書けるように精進します。ではまた。

はじめに

2023年4月キャリア入社の曽田です。前職でシステム開発（通信・情報業界メイン）に従事した後、現在はTIGにてメディア業界向けクラウドサービス「Glyphfeeds」の開発に携わっています。

皆さまは業務上資料(ドキュメント)作成を行う機会はどれほどありますでしょうか？

フューチャーではコンサルティング業の例に漏れず、対顧客／社内を問わず資料作成の機会が多くあります（ex. 議事録・顧客向け説明提案資料 etc.）。また、当社の取り組みとして評価の一環として社員全員が年末にプレゼンテーションを行う機会があり、誰もがドキュメントの作成に頭を悩ませることになります。

そこで、私自身の経験も踏まえつつ仕事における言葉について深堀していきます。

仕事における言語化

上記で挙げた議事録やプレゼン資料をはじめとして、日々の業務ではドキュメントを通してコミュニケーションをする機会が業界問わず多くあります。その上で、コミュニケーションを通して仕事を推進するためにはいかに自分の意図を相手に伝え、それを受けて相手に行動してもらう かが重要なポイントです。

簡単な例として、新規顧客に自社サービスを提案するシチュエーションを考えてみましょう。

提案においてはプレゼンテーション用のパワーポイントを作成するケースが大半だと思いますが、受注獲得に向けて顧客にアピールできるポイントを挙げてみると…

• 顧客側の課題に対する自社サービスのマッチング度
• 自社サービスの優位性

…をイメージできるのではないでしょうか？

そして上記のポイントを顧客に伝え、納得してもらい受注に成功する（=ビジネスの成功に繋げる）ためにはパワーポイント上に適切に伝えたい内容を盛り込む必要があります。この「適切さ」が非常に難しく、端的かつ明確な「言葉選び」、いわゆる「言語化能力」が重要となると考えています。
（冗長な文章や唐突なデータを出されても読み手には理解が困難です）

言語化する上で重要なポイント

「言語化」が意味するものは何でしょうか？

実は言語化という言葉自体は広辞苑のような一般的な辞書の中では定義されておらず、現代になってから生まれた言葉であることが窺えます。

言語化とは？ わかりやすく解説（実用日本語表現辞典）を引用すると以下のように解説されています。

言葉で表現すること。感情や直感的なものを説明・伝達可能にすること。

ここで重要な部分は「感情や直感的なものを伝える」です。言葉になっていないもの（感情・思考）をいかに相手に伝えるかが言語化において最も重要だと言えます。そして、個人的に言語化能力を担保する要素として重要だと考えているポイントとして下記2点が挙げられます。

• 自分自身の考え・伝えたいことを明確にする
• 自分の言葉に対する聞き手の受け取り方を考えられる

前者は自分自身の考え・相手に伝えたい内容を明確にする整理力が、後者は自分の言葉が相手に伝わるか否か・どう伝わるかを考慮する想像力がカギです。

それぞれについてより深堀してみます。

整理力

頭の中にある自分自身の考えを伝えるためには、考えを整理して言葉に変換する必要があります。ここでは自分の思考を垂れ流しにしている状態から、

• 伝えるポイントを絞る
• 冗長な文章を端的な言葉に変換する

というプロセスを通して自分の考えを整理し、言葉の形で表す手順を踏むことになります。

想像力

自分の考えを整理した言葉が必ずしも相手に伝わるわけではありません。相手に確実に伝達され、かつ言葉を受けて行動してもらうには…

• 自分の言葉に対して相手がどのように受け取る可能性があるか
• 相手が求めている事項に対して自分の言葉がどれだけ響くか

といった受け手側の思考を考慮して言葉や文章の書き方を選択する必要があります。「言葉が自分自身にしか理解できないものになってないか？」という疑問を頭の片隅に置きつつドキュメントを作成する姿勢が求められます。

言語化能力を磨くためのTips

ここまで言語化のポイントについて述べてきましたが、実際に自分自身が正しく言葉を選べるようにやってきたこと・日頃心掛けている習慣について数点挙げてみます。

活字に慣れる（書籍・記事を読む習慣）

かなり感覚的な話になりますが、言葉の受け取り方に対する感覚に意識的になるには相応量の言葉に触れておく必要があると個人的に考えています。その手段として、書籍や堅めな記事（評論）に日常的に触れる習慣を付けることは（時間はかかりますが）決して悪くないアプローチだと考えています。

世に出ている書籍・記事上の文章の大半は伝えるためにニュアンス・正確さなどを考え抜かれた形で出されたものなので、自身が言葉を「選ぶ」際の選択肢として活用することが出来るのではないかと思います。また、語彙の充実も読書の見逃せない効用だと言えるでしょう。

※ここで注意ですが、決して文中の表現を覚えて真似するという意図で読書をしないことが重要です。一朝一夕ではなく積み重ねで身につく技術であるため、教養を身に付けるという気軽なスタンスから始めてみるのをお勧めします。（個人的な話ですが、大学時代にフランス文学を専攻しており多くの本を読んできたことが間接的に活きているのかもしれない、と最近感じるようになりました。外国文学の翻訳は「言葉の選択」という観点で最も注意が払われている媒体の1つであるため、余暇の過ごし方の1つとして読んでいただくのも良いと思います）。

資料作りは内容の構成と見た目の明快さに気を配る

資料作成において、まずは整理した内容を伝えるためのストーリー・構成を考える部分から始めるように心がけています。資料作りの技法は書き始めると非常に長くなるので参考文献の紹介（後述）のみにとどめますが、現状分析・目標・解決策という構成でストーリーを組み立て、そこに当てはめる形で必要な要素を記述する逆算型での作成を理想としています。

また、特にPowerPoint資料においてはSmartArtを活用して出来る限り内容を構造化し読者がスムーズに理解できるスライドを作成するように心がけています。SmartArt、ひいてはPowerPoint全体に言えることですが、長文とは非常に相性が悪いので先述した端的にまとめる言葉選びが重要になります。下記にスライドのイメージを載せてみます（新規機能追加の手法比較を顧客に説明するケース）

先述した端的な言葉選びに加えて、推奨案を暖色系（赤色）、非推奨案を寒色系（青色）のSmartArtで表現するなど色彩の使い方も視覚的な分かりやすさという面で良いアクセントになります。

作成した資料を第三者に見てもらう・時間を空けて見直す

頑張って作成した資料は冷静に見直す必要があります。特に勢いよく仕上げた場合、自身の目だけでは悪い面が見つけ辛いため、締切直前の資料だとしても上司などの第三者に確認してもらいブラッシュアップ してもらうことで資料の質は格段に高くなります。

また、時間に多少余裕がある場合は一晩置いて翌日に改めて見直すこともおすすめです。書いている最中には気付かなかった構成の不備や言葉のニュアンス違いなどが見つかるケースが往々にしてあります。この「一晩寝かせる」感覚は企画の考案といった業務の立ち上がりのケースでも活用できる思考法だと思います。

さいごに

この寄稿を機に、日々の業務において何気なくやっていた資料作りやコミュニケーションの過程を文字通り「言語化」することになったのですが、難儀した一方で改めて学び直す部分が多かったです。自分自身の考えを整理し伝えるという行為は、フューチャーで日々行われているシステム開発や顧客折衝の場に留まらずあらゆる業界において活用できる普遍的な技術と言えます。

言語化能力自体は一朝一夕で身につくものではなく、締切が短い資料などの素早いアウトプットが求められるケースだと言語化の手順を踏む余裕がなく上手く言葉に表すことが出来ない場合も往々にしてあります。ただ、難しい仕事と同様に言語化もトライアンドエラーの繰り返しで上達していくものだと思います。

この記事が皆さまにおける新たな気付きや振り返りのきっかけとなれば幸いです。

長文となりましたがここまでお読みいただきありがとうございました！

参考文献

• 外山滋比古「思考の整理学」
  仕事に限らず、「考えること」に対するTipsが柔らかい文章で述べられています。自分自身も大学入学直後に書籍部で購入したのを覚えており、社会人の今改めて読み直してみても新鮮で気付きを与えてくれます。
  先述の「一晩寝かせる」という表現も本書の「発酵」・「寝させる」の内容を拝借しています。
• 中川邦夫「ドキュメント・コミュニケーションの全体観」上巻/下巻
  フューチャーに転職して以来資料作成の機会が格段に増えたことをきっかけに、体系的な資料作りを学ぶために読みんでいます。資料作成の過程をフレームワークとして捉えているのが特徴的で、コンサル業における資料作成の教科書的な立ち位置によく挙げられている書籍ですが、個人的には業界を問わず普遍的に利用可能な考え方が述べられていると思います。文章の「見やすさ」という面でも実務に流用できるレベルで分かりやすく読みやすいです。

アイキャッチ画像は、「写真AC」さんのビジネス資料の疑問 - No: 30648442を利用させていただきました。

秋のブログ週間 5本目です。

はじめに

TIG真野です。秋のブログ週間のサブ企画である、アーキテクチャ設計に絞った書評連載の1本目です。

杉本さんのデータモデリングでドメインを駆動する を取り上げます。基幹システム系のアーキテクトとしてデータ設計は抑えておくべき要素の1つかと思っています。

どんな本か

以下、個人意見です。宅配クリーニングや物販などいくつか具体例を上げて、業務のデータモデリング（≒帳簿設計）を重視した「いぶし銀」な書籍です。データモデルは各DB実装に依存しない、帳簿（※帳票とは異なる！）のような概念であると本書では説明しています。このデータモデルについてフォーカスを当てた、最近出版された本として貴重な存在かと思います。なお、サロゲートキー／ナチュラルキー、テーブル分割、論理削除、適用開始終了日などは論理DB設計とし、インデックスなどDBに閉じる部分は物理DB設計と定義していました。

論理／物理DB設計は設計、実装テクニックの話が多いと思います。この書籍でも12章で触れられていますが、テクニック自体を語るというよりは、これらの課題が「偶有的複雑性」として発生しているといったような、俯瞰的な考えを伝えることを重視していて、明日から開発で使える実践的な実装テクニックを学べる書籍ではないと思います。

今どきの本だなと思ったのは、CQRSなどの非同期処理が、データモデルにどのように影響を与えるかや、DDDのドメインモデルがデータモデリングとどのような関係にあるのか？という説明があった点です。表紙にもありますが、DDDの共感する部分と、批判的な部分の記載があります。バチバチというより、概ね穏当な内容かと思いました。

個人的には少し浮ついた、生成AI（LLM）がどう基幹系システムの進化に影響するかといった話を聞きたかったです。その意味でいぶし銀！ な印象を持ちました。

どんな本ではないか

以下の話はほぼ無いです（前述の通り多少は触れている章あります）

• より性能が良いテーブル設計や、SQLの書き方を含む、個別プロダクトの設計／実装の話
• DDD文脈でのドメインモデルの設計方法、実装方法
• 業界／業務ごとに良くある業務ロジックパターンの説明

アーキテクトを目指す人におすすめの本なのか？

Yesです。ただ、中級者向けです。また、クラウドのサービスをどう取捨選択するかといった話は学べません。そして、過去の経験で一度も業務システムの開発に関わったことが無いと、イメージが湧きにくいかもと思いました。最初に背伸びして読むのは良い刺激となりますが、文章の内容がピンとこなくても自信を無くさない（また数年後読んで差分を楽しむ）という付き合い方かなと思います。

個人的には、この書籍は読者への問いかけを上手く投げかけてくれています。例えば以下のような具合です。

• 「大阪の得意先から受注した商品に関して、大阪では在庫切れ、東京には在庫があるとすれば、東京の在庫を回してよいものでしょうか。名古屋の得意先からの受注に対しては、東京・大阪いずれの倉庫から出荷すべきでしょうか」
  • 受注数にもよるし、適正在庫の状況にもよるし～など、様々な考え方があることが分かる

こういった問いかけを通して、業務システムの難しいところ、面白いところを学べるのはSIer／ITコンサルタントの立場の人には嬉しいと思いました。

過去、フューチャーの先輩が以下のように話していたことを思い出しました。

• 「モノを動かすと即時対応ができない、業務が非同期になる。これを上手くデザインすることが難しいし楽しい」

本書でも、「要求と充足の間にタイミングの差があるため、未処理残を把握するために帳簿が必要になる」とあり、その重要性が語られています。

業務システムのアーキテクトとして、上記のような想像を持てないことには、どこか業務的にクリティカルで重要かなど見極める勘所が分からなく、アプリ側の要件が固まってから検討を進めようとなりがちです。しかし、業務的な勘所がざっくりとでも分かると、この部分は業務上、変更が多く入りうるポイントであるため、採用技術としては枯れたものを利用しようとか、品質保証をしやすい構成を取るようにしようと行った先手が思いつくと思います。

アーキテクトとしてプラスになる部分

ビジネス設計に寄り添う／踏み込む重要性を改めて学べる、という点は確実に言えます。書籍にもありましたが、「在庫の引き当てより、計算式の解釈／実行やメモリ上のキャッシュ管理アルゴリズムのほうが興味深く感じられる」ものです。放っておくとどうしても実装テクニックよりのところに関心が向きがちなので、定期的にデトックスするためにも本書の存在は有益です。

データモデル（帳簿設計）はアプリケーションの領域でしょうか？という問いも考えられますがどうでしょうか？ アーキテクチャはビジネスの射影でもあるよねという立場からすると、アーキテクト的なポジションの人も要件インプットとして知っておく必要があると私は思います。

例えば、マイクロサービスをどのようなサービスカットで作成するかといった設計は、DDDでいう「境界づけられたコンテキスト」で考えてみることも多いと思いますが、その単位がどのような「帳簿」「残（※詳細は書籍に！）」があるかという観点で、整理できると有益な場面も多そうだと感じました。

ユーザーとエンジニア双方にとって健全なアーキテクチャ設計

「可変性」という話がいくつか出てきます。例えば、先ほどの受注における出荷指図のロジックで、業務要件がフワフワしているとします。嫌ですね。早く決めたい／決めて欲しい。本書ではこうしたビジネスロジックが、ユーザーにとって1番の関心事がなんだ、と表現しています。開発者的には困ったな～、要件を決めてよ～って話ですが、ユーザーからすると、ここを柔軟に対応できることが、企業競争力や業務効率に直結するのでこだわりたいポイントです。これは「モノ」を動かす以上、人、お金が動くので当然です。

また、要件が変化しやすいポイントは、業務ユーザーとエンジニアの間で緊張が生じやすい。例えば挙動を変更するとエンジニアに依頼するので上下関係が生まれやすい。一方で一旦開発に入れば、リードタイムなどはエンジニアの手に委ねられ信頼するしか無いといったくだりがあります。確かに経験上、これはヘルシーな状況でないです。プロダクトオーナーと開発チームの信頼関係を構築するテクニックは数多ありますが、そもそもそれらが必要となる状況を減らせたら？

その対策の例として、「テーブル駆動方式」といった形式で柔軟性をもたせたり、DSLでユーザーが拡張可能にする話があります。興味深いですね。DSLあたりはアーキテクトレベルの人も関心が強いのではないでしょうか？ DSLは適度な制約が無いとシャドーITのごとく統制が取れなくなりますし、とはいえルールが強すぎても使い勝手が悪くなり使用されないと本末転倒です。

ローコードツールなども、ユーザーが自由に操れる「可変性」という領域に組み込まれるとより、よりユーザビリティが高められそうだなと私は感じます。いい感じに制約を付けられてかつ、組み込み型のローコードぽいツールを使ってみたい。

章ごとの雑感

いくつか特徴的だと思った章をピックアップして、面白いと感じたポイントを記載します。

1章 基幹システムとデータモデリング:

• 「データモデリングとは、帳簿をデザインすること」
  • 単なる事実の記録でもなく、帳票やテーブル定義でもなく、帳簿とは何か？が分かると、これをユーザーと対話してモデリングしないとならないことがよく分かります
• 帳簿設計≒データモデリングだとすると、システム開発プロジェクトでは基本設計フェーズより前に行う必要があると思います。おそらく要件定義。業務一覧／業務フローを定義しつつデータモデルを精緻化していくと想定

4章 活動のシステム（SoA）残概念に基づく業務・帳簿の分割:

• 「残」という概念に基づく、業務整理はかなり興味深いです！
  • 「残」を通して、ビジネスが駆動し、責任分担を明らかにするということ、納得感があります
• マスタ（リソース）について、データモデリングとの位置付けについて説明があります
  • 個人的には、「業務領域別チーム」とは別に結成された「マスタ管理チーム」についての話があり、興味深い見解だと思いました

5章 経営管理のシステム（SoM）:

• 経営管理領域でデータ管理粒度は「小は大を兼ねない」、という話は納得感が凄かったです
  • 分からなければとりあえず細かい粒度で持っておこう、と個人的にはなりがちですが、そうすると使えないシステムになりかねないということが分かり、真正面から考えていかないとならないと思いました

9章 マスターの共有─ エンティティとロール方式

• 「支払システム」と「人事システム」の2つがあり、支払いシステムの都合で「振込先口座」を複数にしたいという要望が、人事システムが持つ「従業員マスタ」に追加する是非について話があります
  • 数少ない「あるよなー」と思った章です。マスタデータ管理はこのDX／生成AI時代にも重要度が増していて、どうすればよいか悩みが深いです。書籍上はわかりやすい解こそないものの、示唆に富むアドバイスが書かれています

12章 偶有的複雑性に対処する──論理削除，テーブル分割，時系列データほか:

• 珍しくテクニカルな設計論チックなことを説明する章です
  • 本書では本質的に難しい点と、偶有的複雑性の点は分離しようという点で説明しており、新しい観点を得られると思います

もっと沢山、気になるポイントがあるのですが、「なるほど～」「たしかにな～」という感想を超える付加価値コメントができずで省略しています。このほかにも著者の豊富な経験と深い思考によって生み出された、示唆に富む内容がたくさんありました！

さいごに

「あ～、こういうパターンあるよね！」といった共感＋紹介／解説する書籍では全く無いなと思います（共感した内容もありますが）。杉本さんの思想（SoA、SoMの区別など）などもあり、あるべき姿が前提として説明されているため、どちらかといえば薫陶をもらえる系のヘビーな本だと思います。この記事を書くために3回読み返しました。

その分、濃密で示唆に富んでおり、この先、業務で「モデリング」する際には大きな助けになるなと感じます。人によって響いたポイントは異なると思います。みなさんの書評もお待ちしています！

物流サービス事業部の小林です。ドイツのシュツットガルトで3月に開催された国際物流展示会「LogiMAT2024」を視察しました！

3回のシリーズで現地での模様と注目のソリューションについてレポートします。

今回はその2回目となります。（1回目はこちら）

2回目のレポート

2回目は、LogiMAT2024 Best Product（最優秀賞）のソフトウェア部門を受賞したソリューションを紹介します。

ソフトウェアのフロアはSAP社のおひざ元ドイツということもあるかもしれませんが、SAP SE社（以降SAP）のロゴが至る所で見られ、SAPの欧州マーケットにおける影響力の強さを改めて再認識しました。

注目のソリューション

それでは、LogiMAT2024のBest Product（最優秀賞）の中から、注目のソリューションを解説します！

REPLY社のLEApedia^TM

LEApedia^{TMとは生成AIをベースとした倉庫管理システム支援ソリューションです。}

REPLY社はイタリアに本社を置く、グローバルIT企業で、AI、クラウド、ゲーミング、官公庁対応、IoT、量子コンピューティング等を幅広く手掛けています。

当社と同様に物流特化型のIT企業ではなく、様々な業種/業態においてテクノロジーをベースとしたコンサルティングとSIを実施しています。彼らにとって、ロジスティクスは注力領域の1つであり、サプライチェーン全体のデジタライゼーション、フリートマネジメント、ダークストアの開発等のソリューション提供を実施しています。REPLY社の倉庫管理システムはガートナー社のMagic Quadrantにもポイントされていることから、物流システムにおける評価が高いことも伺えます。

今回受賞したLEApedia^{TMというソリューションは、業務の効率性と信頼性を高める強力なマルチエージェント AI エンジンを統合することで、倉庫管理システム（WMS）やその他のサプライチェーンツールとの対話方法に革命をもたらします。}

具体的に言うと、事務職員とWMSが双方向にコミュニケーションすることによって、倉庫作業のプロセス、物流の専門用語、業務システムの操作方法等についての情報が速やかに得られます。

その結果、重要なことにより多くの時間を費やすことができ、ビジネスを前進させることが可能となります。

Q.過去3日間の収益の上位3か国はどこですか?

A.過去3日間の収益上位3か国は、イタリアが収益1,879万ユーロ、スペインが収益375万ユ
ーロ、フランスが収益165万ユーロです。

物流に生成AIを用いることは、まだまだ先のことだと思っておりましたが、今回の視察で物流における生成AIの利活用について様々なアイデアが湧きました！

現在、フューチャーのAIスペシャリストと物流×生成AIについての取組みを始めていますので、9月の国際総合物流展ではその取り組みを少しお見せできるのではと、楽しみにしています。

その他のソフトウェアソリューション

その他、ソフトウェアに関しての注目のソリューションとして、MODEX（北米最大の物流展）でBest IT InnovationAwardを取ったConfigura社もLogiMATで展示されていました。

こちらは物流のDigital twin実現に向けて大きな可能性を持ったソリューションとなります。

Configura社のソリューションについては、当社のDigital twinへの考え方も含め今後のブログでポストさせて頂きます。

さいごに

LogiMAT2024～その2～をレポートしました。

展示場があまりに広く、1日目ですでに足が棒になってしまう状況…。

私たちは、初日と2日目に来場しましたが、初日は人も少なく色々とインタビューできましたが、2日目は人も多く顧客では無い私たちは中々、声を掛けづらい状況でした。

もし、来年行かれる方がいましたら、会場が広いので3日間の来場をお勧めします。

また、2日目の午後に入るとシャンパンが出ていたり、ビールを配ったりと、リラックスタイムになる傾向があるので、ブース担当者と会話したい場合は、午前中の早い時間がお勧めです。

それでは、～その3～もお楽しみに！

物流サービス事業部の引網康暁です。ドイツのシュツットガルトで3月に開催された国際物流展示会「LogiMAT2024」を視察しました！ 3回のシリーズで現地での模様と注目のソリューションについてレポートします。

LogiMAT2024とは

LogiMAT2024は、ヨーロッパを代表する物流ロボット・マテハン機器の国際展示会です。

物流自動化のグローバルな流れを受けて、従来からの物流機器に加えて、最新のテクノロジーやAI関連の展示も活発になっています。日本では、フューチャーアーキテクトも出展している国際物流総合展が有名ですが、その約2倍の広大な展示面積に1600を超える多くの出展がありました。さながら、物流ロボットやマテハン機器のお祭りといった感じです。

▲Logimat DAILYという公式メディアから取材を受け、小林さんのインタビューが記事（5ページ目！）にも取り上げられました！

全体感として、物流業界が直面しているリアルな課題解決に向き合っている展示が多かった印象です。

前週にアメリカ・アトランタで開催された国際物流展示会「MODEX2024」では、未来志向のヒューマノイド型物流ロボットが展示されていたようですが、LogiMAT2024では自動フォークリフトや自動ハンドフォークリフトなど、業界の人手不足に対応した、より地に足の着いたソリューションを多く見かけました。

それから、中国の物流ロボット企業のブースは人だかりとなっており、物流自動化マーケットでの中国企業の隆盛をあらためて強く感じました。また、中国企業と欧米企業が資本提携を含むアライアンスを形成している事例もあり、物流ロボットのフルラインアップ戦略が加速していることも実感しました。

注目のソリューション

それでは、LogiMAT2024のBest Product（最優秀賞）の中から、注目のソリューションを解説します！

Brightpick社のAutopicker

Brightpick社は3Dビジョンをルーツとした物流ロボットを開発している企業です。同社が開発したAutopickerは、ACR(Autonomous Case-handling Robot : 自律走行ケースハンドリングロボット)とアーム型ロボットが一体となった、まさにハイブリッド型物流ロボットです。

ロボットの右側は商品を格納するコンテナをピックアップします。ピックアップしたコンテナに格納されている商品を3Dビジョンで画像認識し、アーム型ロボットがその商品をロボットの左側に置かれたコンテナへ移動します。フロアーを自由に移動しながら、一連のピッキング作業を滞りなく進めることができるため、効率的なピッキングと高いスループットが期待できます。画像認識できる商品のSKU(Stock keeping Unit)を増やすことが課題のようです。

LogiMAT2024の他の展示を見ましても、物流ロボットの特化した機能同士が融合することで、汎化した機能がより高まっていくトレンドを確認できました。例えば、Quicktron社のQuickBinも、保管棚への入出庫を担う「親機」と、フロアー上の搬送を担う「子機」がハイブリッドに融合したシステムと言えます。

さいごに

今回のブログではLogiMAT2024～その1～をレポートしました。

前職でドイツ駐在員をしていた経験がありますので、第二の故郷への久しぶりの帰郷でした。ヨーロッパでは、さまざまな国籍や民族の方が、国境や言語の壁を越えて働いています。そのため、業務標準化・規格化・効率化が、日本以上に当たり前になっています。物流自動化の展示を通じて、その一端を今回のLogiMAT2024でも再確認できました。

フューチャーアーキテクト物流サービス事業部では、おかげさまで物流自動化のコンサルティングのご相談をいただく機会も増えていますので、物流テクノロジーのリサーチ機能にますます磨きをかけていきます！

5月29日（水）に、LogiMAT2024の視察レポートウェビナーを開催しました！ このブログではお伝えきれなかったコンテンツも発信し、物流DXについて熱く語りました。

https://www.future.co.jp/futureinsightseminar/20240529/

～その2～に続きます！

私は2017年フューチャーに新卒入社し、これまでメディア業・アパレル業・防災事業にわたりパートナー企業様の事業効率化・拡大に携わってきましたが、昨年より総合エネルギー業の企業様とご一緒させていただいております。2022年度は、フューチャーの従業員代表も努めさせていただきました（従業員代表活動記事はこちら）

そんな私が、2023年1月にLPガス小売業では必須と言える国家資格「高圧ガス第二種販売主任者」に合格したので、なぜITコンサルタントである私が本資格取得に挑戦したのか、資格取得に向けどのように勉強したのかご紹介します。

第二種販売主任者免状取得に向けて、挑戦しようとしている方の参考になると嬉しいです。

参考までに：

高圧ガス販売主任者免状には、「第一種」と本記事で紹介する「第二種」があります。第二種は、LPガスの販売に係る保安の実務を含む統括的な業務を行う方に必要な免状です。一方で、第一種はLPガス以外の高圧ガス（詳細は一般則第七十二条参照）を対象としています。ガスの種類の違いなので、一種・二種に上下関係などはありません。

「高圧ガス第二種販売主任者」受験の動機

第二種販売主任者受験の動機は、パートナー企業様の現場や実務をより詳しく知りたいと考えたからです。
当然、経営とITをデザインするフューチャーですから、パートナー企業様の実務に詳しいですが”まだ足りない!!!”と感じたからです（笑）

私は昨年より、総合エネルギー事業を営むパートナー企業様と共に、LPガス託送の配送最適化に挑戦しています。
その中で、実際にLPガスの充填基地に訪れ、ボンベを担がせていただいたり、配送員の方々と会話させていただいたりと現場に触れる機会をいただきました。

しかし配送最適化に向けた議論をパートナーと重ねる中で、自身の配送現場の理解不足をしばしば痛感していました。

そんな最中、現場担当者様と会話させていただいた折、「IT知っている人はすごいと思う。私も自身の業務を動かしているシステムがどうやって作られているのか、理解を深めようとITパスポート挑戦してみたが本当に難しいと実感した」とおっしゃられていました。

私が現場の知識を求める一方で、配送現場の方もこちら（IT）の理解を深めたいと必死なことを改めて認識し、この方と同じレベルで託送について語りたい！ と思いました。LPガス現場の方々と同じ視点で語るためには、何が必要か、どんな手段があるかと調べた時に見つけたのが国家資格「高圧ガス第二種販売主任者」でした。

本資格合格後に得られる「第二種販売主任者免状」は、パートナー企業様社員や、LPガス小売業社員であれば皆保有している資格です。私は「高圧ガス第二種販売主任者」資格取得に挑戦することで、より深い知見を習得し、またパートナー様と同じ目線で会話したい思い受験しました。

第二種販売主任者免状を得ると、LPガスの販売事業所の統括的な業務主任者に選任されることができます。

業務主任者に選任されるためには、免状を取得していることの他に高圧ガスの販売に関する実務経験を６ヶ月必要としますが、条件を満たすことでLPガス販売事業では欠かせない人材となることができます。

LPガスの販売事業所において、LPガスの販売に係る保安の実務を含む統括的な業務を行う方に必要な資格で、工業用のLPガスの販売主任者（高圧ガス保安法）として、また、一般家庭等で生活の用に供するLPガスを販売するLPガス販売所の業務主任者又は業務主任者の代理者（液化石油ガス法）として選任されることができ、LPガスの販売に関する保安に携わることができます。

引用元：高圧ガス保安協会＞国家資格の概要及び職務範囲

実施した勉強方法

私が実施した勉強方法は以下です。

• 高圧ガス保安法の熟読（E-GOVというサイトから）
• 液化石油ガス法関係法令の熟読（E-GOVというサイトから）
• 講習テキストの熟読
• 過去問５年分の実施

高圧ガス販売主任者第二種試験は、法令・保安管理がありそれぞれ60点以上で合格となります。

法令試験問題では、高圧ガス保安法・液化石油ガス法関係法令があり、法の目的や対象範囲、法の各項目に対する問題です。

保安管理技術試験問題では、LPガス販売に係る保安技術に対する問題です。

例えば法令では、以下の記述が正しいかどうかの判断。

高圧ガス保安法は、高圧ガスによる災害を防止して公共の安全を確保する目的のため、高圧ガスの製造、貯蔵、販売、移動及び移動を規制することのみを定めている。

例えば保安管理技術では、以下の記述が正しいかどうかの判断。

マイコンメータSは、遮断弁の復帰操作を行った後、マイコンメータより下流のガス漏れをチェックし、ガス漏れを検知した場合に再遮断する機能を有している。

のような出題形式です。具体的には各問に対し、記述が（イ）（ロ）（ハ）（ニ）と用意され、どの記述が正しいのか組み合わせを選択する（例：イ、ハ）形です。

試験の難易度は、私の所感では一夜漬けや１週間程度の学習では到底合格できないと感じるレベル感でした。
私の場合は、パートナー企業の方から誰でも合格するレベルの問題と伺っていたため、学習に入ったのが試験から２ヶ月ほど前からでしたが、かなり苦労しました。おそらく実際にLPガス小売業の現場で働かれている方からすると、現場での知見の量が膨大なため、ある程度簡単に感じるのかもしれません。

まだ実務経験が十分でない方や、未経験である方は十分な学習期間と覚悟が必要です。

本受験は年に一度（１１月）のみ実施のため、不合格の場合はまた１年後までお預けです。どうしても合格の確率をあげたい！ という方は、事前の講習・試験を受けておくことをおすすめします。講習の受講とその後の試験に合格された方は、第二種試験の際に保安管理技術試験が免除されます。

令和４年の第二種販売試験の合格率は54.6％だったのですが、通常（法令・保安管理）受験の合格率は 37.0% 、保安管理技術免除の方々の合格率は90.0％と、合格率が大きく違います。

たびたび、高圧ガス第二種販売主任者試験の合格率は60％前後と記述されているメディアを見かけますが、講習参加による免除科目を有している方も入れた全受験者の合格率です。

全科目受験された方の合格率は37.0％であることは、資格勉強へ臨む前に認識しておいた方が良いと思います。

数値引用：高圧ガス保安協会＞国家試験の合格率の公表（令和４年度の合格率）

また既に高圧ガスに関する他資格を有する方など、他の免除項目もあるため興味のある方は「試験科目一部免除制度」を参考にしてみてください。

受験振り返りと実務への活用

私は試験勉強としては約２ヶ月、免除科目なしで挑んだ受験でしたが、正直なところ受験終わりの時点では、合否に自信はありませんでした。

稀に、ひたすら過去問を解けば合格できる！ のような情報を見ますが、今年の試験でも例年出題されていなかった類の問題がありました。過去問を暗記しているだけでは合格できません。実務として普段から高圧ガス周辺に携わっている人でなければ、ある程度の覚悟を持って勉強の臨んだ方が良いと思います。

理想としては、

• 法令（高圧ガス保安法・液化石油ガス法関係法令）全ての理解と暗記。
• 講習テキストの内容を全て理解と暗記。

ただし試験合格を最低限の目的とするならば、

• Step1：法令・講習テキストを流し読み（かなり難しいのでこの時点で全て理解しきらずで大丈夫です）
• Step2：過去問実施
• Step3：過去問回答とその周辺理解のために、再度法令と講習テキストを熟読。
  Step2~3の繰り返しが効果的と思いました。

または実際に、LPガス容器やメーターを見に現地に訪れ、具体的なイメージを持つと良いかもしれません。

引用：実は災害に強いLPガス | 愛知県LPガス協会

都市部の場合は都市ガスが普及しているため、LPガス容器を見かけることも少ないかもしれません。地方に出かけた際や、都市部でもラーメン屋や中華屋にもあります。ただし、当然不用意に敷地内へ入ったり、近づいたりしていいものではないため、遠くから眺める程度でお願いします。

合格後の現在、試験内容を全て理解しているかというと、正直今でもなお法令や講習テキストを日々開いています。実業務で普段から高圧ガス周辺に携わっている人と、試験取得に向けた勉強をした私とでは今もなお理解の深さには大きな差があるのは事実です。

しかし資格挑戦前と今では、マイコンメータを見かけた際に何号のメータか、マイコンメータSかEかなど目に付く機会が増えました。

またパートナー企業様と日々会話する中で、何か問題が突き当たった時に「法令の◯◯に触れなかったか、条件があった覚えがある」のように、その勘所は身についたかと思います。パートナー企業様からも「法令にある。久保さん見ておいてよ！」のように、第二種販売主任者免状を取得している信頼から、期待の声も生まれます。

資格挑戦のきっかけとなった現場担当者様にお伝えしたところ、「次は、液化石油ガス設備士に挑戦と、一緒にLPガス配送回ろう！」とお喜びいただきました。

IT業界では、担当のシステムについて仕様に詳しくなることは当然ありますが、そのシステムのインプットである現場がどう動いているのか、どんなルールがあるのか、どんな人がどのような手順で働いているのか。現場を抑えた上で、システム仕様を語ることの重要性を改めて感じる機会となりました。

高圧ガスという危険物を扱うからこそ、試験のための勉強で終わらせず、現場の方と同じ目線・知識であるべきを語り、理想の追及に向けて活用と理解を深めていきたいです。

EX（Energy Transformation）ユニット設立

エネルギーは国家、経済、産業の礎です。

しかし昨今、地政学的リスク顕在化によるエネルギー価格の高騰や、安全保障政策の変化、あるいは気候変動など現在進行形で産業構造・経済・社会に大きなパラダイムシフトが起きています。

フューチャーに2022年11月に発足したEX（Energy Transformation）ユニットに私は所属しています。EXユニットでは最近様々な企業様からお声をいただいております。エネルギーは、その種類から、サプライチェーンの大きさまでとても幅広いテーマで、求められる知見や経験も膨大です。

EX（Energy Transformation）ユニット
弊社のTIG（Technology Innovation Group）ではユニット制があり、その中でEXUは、世界の経済活動や安全保障戦略の礎となるエネルギー業界の在り方を、我々そしてクライアントやパートナーと共にテクノロジーを軸に根幹から変革していく組織です。

そんなエネルギー業界が今、急激に変わりつつあります。

期待をお寄せいただいた企業様に、スピーディかつ大きな価値を提供できるよう、私たちITコンサルタントは深い知見と幅広い技術スキルが必要となります。

技術に強いITコンサルタント集団のイメージが強いフューチャーですが、私はエネルギー業界の現場から経営、トレンドまで抑えたITコンサルタントを目指しています。

今後も現場と同じ目線で問題提起し、経営陣とあるべきを追求し、またエネルギー業界のトレンドにアンテナを貼って未来価値を創造していきます。
p.s.
最近はエネルギー×メタバースに興味を持ち、日々情報収集しています。リアルなメタバース空間を実現しようとしている EVERDOME（エバードーム）プロジェクトは、メタバース空間でのエネルギー活用で何かできないかと期待しています。

金融サービス事業部の山口です。

この記事は「業界ドメインに詳しくなろう」シリーズ連載の「銀行業務」超入門編です。
銀行業界を目指す学生さん、銀行業界にアサインされた若手SIer、他業種で活躍するITコンサルの方向けになります。

インフラエンジニアから銀行系ITコンサルにキャリアチェンジした私が、その道20年のキャリアを誇る安本大先輩の力を借りて、銀行業務について記載していきます。

ITコンサルが教える銀行業務シリーズ　銀行業務とは

銀行業務をお話する前に、なぜ「銀行」と呼ばれるようになったのはご存知でしょうか。

明治の世が始まって間もなく、「Bank」という英単語を日本語に何と訳すかという話の中で、「お金（金銀）を取り扱う」と中国語で「店」を意味する「行」を組み合わせて、「金行」・「銀行」という案が出て、語呂の良さから「銀行」に決まったと言われています。

２０２１年の大河ドラマ「晴天を衝け」の中では、日本初の銀行の頭取に就任した渋沢栄一が「銀行」🏦と名付けたというお話になっていましたし、実際にそんな一説があるという記事も見かけますが実際のところはどうなのでしょうね。
ともあれ銀行という単語は作られてからまだ１５０年くらいの比較的浅い単語のようです😄

本題の銀行業務にお話を移しましょう。

銀行における伝統的な業務は「預金」「融資」「為替」となります。(昨今の銀行は業務範囲を拡大してきてます。)

銀行の利益構造

銀行は、預金者からお金を預り、そのお金を必要とする企業・個人へ貸し出しています。

言わばお金という商材を預金によって仕入れ、またお金を必要としている人に貸出という形で販売するビジネスモデルです。

顧客の日々のお金のやり取り（決済や振込など）を円滑・確実に行い日常的な経済活動を支えており、社会的インフラを担う公共性の高い業種です。とはいえ、銀行は株式会社であり民間企業であり、しっかり利益を出す必要があります。

銀行はどうやって収益を得ているかというと、預金者から集めたお金を、融資という形で企業や個人に貸し付けを行い、この融資によって発生した利子で利益を得る構造となっています。

預金業務

バブル崩壊後においては超低金利時代とも言われており、銀行が融資することによって稼げる利子は大きく圧迫を受けており、銀行の収益モデルについては非常に厳しい状況となっています。

金融緩和政策によって世の中にお金が余っている状況が長く続いており、お金を預けたい（運用したい）人（＝供給）と、お金を必要としている人（＝需要）のバランスが供給過多の状況となっており、金利が低く維持された状態になっております。こうしたことが、私達一般市民にも少なからず影響が出てきています。

例えば、銀行口座を開設すると当たり前のように通帳をもらい、キャッシュカードをもらいます。通帳が全て印字し終わるとこれもまた当たり前のように次の通帳が発行され、その通帳発行に際してお金を請求されることはありませんでした。ところが、銀行の収益構造が非常に厳しくなってきたことや、スマートフォンなどのデジタル機器の普及も相まって有料化の動きが始まっています。三菱UFJ銀行においては、2022年4月以降紙としての通帳を発行する都度数百円の費用がかかるようになりました。

こうした動きは着実に広がってきています。各銀行が○○銀行アプリといったものを提供しそちらへ移行を促すCMなどを出しているのは上記のような背景があるといえます。

一方で、上述した三菱UFJ銀行において、デジタル機器を扱うのが苦手あるいはまだ与えられていないという未成年や高齢者については無償とするなど、完全有償化に向けては過渡期を経ながらということになっていきそうです。
なお、普通預金の平均金利は0.001％（日本銀行 時系列統計データ 検索サイトより）となっており、預金者の皆さんに還元される金利も同様にごく僅かなものとなってしまっているのもこうした収益構造の問題から発生してしまっています。

融資業務

融資に関しても同様です。例えば住宅ローンで、一部のネット銀行でしか金利1％を割るようなローンはなかったのに、今や全国の地方銀行で団信・三大疾病特約までついて金利1％を割るような商品が当たり前のように出てきています。銀行は以前にも増して非常に薄い利ざやで確実に稼ぐことが求められているのです。

それなのに、貸し付けたにもかかわらず、企業が倒産するなどして貸したお金が返済されないケースが発生してしまうのです。1000万円を年利5％で10先に貸すと、銀行にはざっくり1年間で500万円の収益が生まれるわけですが、10先のうち1先でも貸し倒れが発生してしまえば銀行の損失はあっという間に－500万円となってしまいます。薄い利ざやで確実に稼がなければならないのに、こんなことが起こっては銀行にとって泣きっ面に蜂🐝状態です❗

このため、銀行が融資する際には、融資先の業績や信用・将来性をしっかり審査した上で融資する必要性があります。ローン審査などで断られてしまい、お金を借りたいのに貸してくれない！ なんて感じたことがある方もいらっしゃるかもしれませんが、銀行としても生き残りをかけて必死な状況なんですよね。

為替業務

為替については、おそらく皆さんも一度は使ったことがあるサービスで、会社間あるいは個人間での資金移動であったり、光熱費などの各種費用の引き落としなどを行っています。お金のやり取りについては、日本国内に限らず、円・ドルなどの通貨が異なる銀行間での入出金についても銀行では対応しています。

今でこそ銀行の窓口へ行かずとも、バンキングアプリやすぐ近くにあるコンビニATMなどを利用することで当たり前のように預金サービスや為替サービスを受けていると思います。融資の申込みもバンキングアプリから直接申し込みができるようなサービスも増えてきましたね。

従来の銀行口座を介した資金移動は手数料の高さから敬遠され、個人間の少額送金は各決済アプリによる送金サービスに代替され始めているのが現状です。皆さんも飲み会の割り勘をするのに決済アプリの送金サービスを使うことが増えていませんか？ とは言え、給与振込等のしっかりとした信頼性を求められるものはまだまだ、銀行が活用されてますね。

まとめ

銀行という言葉の歴史は浅いですが、我々には深い存在であるということがお判りいただけたでしょうか。

日本や地域の経済を循環させるような血液のような役割を担っているのが銀行です。銀行はお金という企業・個人にとって非常に重要なものを取り扱う社会的責任の大きさもあって、株式会社として一般に定められている会社法・労働基準法等の法規制はもちろん、銀行法といった形で多くの規制を課されている業種です。

また、長引く低金利環境下における利ざやの縮小、様々なプレイヤーーが決済領域に参加する事での資金移動手段の変化、決済手数料の減少と、現在の銀行を取り巻く環境は大きな転換点を迎えている事も業界の概要・トレンドをつかむ上で重要なポイントだと思います。

今後は以下も予定してます。

• ITコンサルが教える銀行業務シリーズ　半沢直樹でも有名な営業活動
• ITコンサルが教える銀行業務シリーズ　融資の要！ 融資審査（1）　何を気にする？ 銀行員　～法人融資編～
• ITコンサルが教える銀行業務シリーズ　融資の要！ 融資審査（2）　何を気にする？ 銀行員　～個人融資(ローン)編～
• ITコンサルが教える銀行業務シリーズ　融資の要！ 融資審査（3）　何を気にする？ 銀行員　～担保や保証編～
• ITコンサルが教える銀行業務シリーズ　貸したら終わりではない　定期的にチェック自己査定
• ITコンサルが教える銀行業務シリーズ　変化と不変　変わりゆく銀行文化と変わらない銀行文化

HealthCare Innovation Group(HIG)所属の山本です。
2021年10月に新卒入社し、初のブログ投稿となります。

この記事は「秋のブログ週間」の7記事目です。
読書の秋ということで、ヘルスケアという部署に縁がある本を読んでみようと思いました。

読んでみたのはこちら、「AIファースト・ヘルスケア」です。

書籍の概要

書籍のタイトルを一見すると、画像認識や強化学習などなど昨今次々に新しい技術が開発され続けている機械学習を医療現場に活用した事例紹介や技術的課題が書いてあるのかと当初は思いました。

ですが、本書では「AIは機械学習以上のものである」ということを大きなコンセプトとしており、

機械学習に関する技術的な詳細を扱う内容ではなく、医療現場の課題を考慮し、実際に医療の現場の中心に幅広くAIを導入するための方法について議論するといった内容になってます。

本書が機械学習に焦点を当てるのではなく、あくまでAIとして扱っている思想については以下の引用で納得できる部分があります。

AIが機械学習と同じものだと見なしてしまうと、インテリジェントシステムを構築するために使用するソフトウェア郡のうち、機械学習出ない部分を無視したり否定してしまうことになります。さらに悪いことに、AIに何ができるかという私達の想像や知識は、機械学習によって実装可能な機能だけに限定されてしまいます。

章立てとしては以下のようになっており、興味がある章からでも比較的読みやすい構成になっています。

1章　AIの神話と現実
    1.1　AIの起源と定義
    1.2　AIヘルスケアの神話
    1.3　AIの神話
    1.4　AIテクノロジーの神話
    1.5　AIファーストなヘルスケア

2章　人間中心のAI（Human-Centered AI）
    2.1　“人間中心のAI”に向けて
    2.2　AIと人間の交叉
    2.3　人間の倫理とAI
    2.4　まとめ

3章　モニタリング＋AI＝個別化医療への処方箋（Rx）
    3.1　個人の健康に対する処方箋（Rx）
    3.2　AIを用いた継続的なモニタリング
    3.3　IoTとAIの医療への応用
    3.4　まとめ

4章　デジタルトランスフォーメーション（DX）とAI
    4.1　ヘルスケアDX
    4.2　デジタル・ヘルスケア
    4.3　予防と慢性疾患の管理
    4.4　AIと遠隔医療
    4.5　AIと服薬管理
    4.6　管理事務をデジタル化・AI化する
    4.7　まとめ

5章　不都合な事実
    5.1　医療の無駄
    5.2　管理費用
    5.3　医療従事者の時間
    5.4　まとめ

6章　AIを使った医療アプリケーションの登場
    6.1　人々の健康改善
    6.2　テクノロジーを医療現場で機能させる
    6.3　新時代のアプリケーションやサービスの到来
    6.4　まとめ

7章　医療機関のための大規模AI
    7.1　大規模AIの実現
    7.2　医療の変革
    7.3　見えないエンジン：医療プラットフォーム
    7.4　まとめ

書籍の感想

「AIファースト・ヘルスケア」とは？

この書籍の3章以降では、AIを医療現場に現状活用できること、今後の課題について医師や患者、企業を始めとした様々な視点から議論しています。

• IoTデバイスを用いた血圧モニタリング、管理
• 処方薬のボトルキャップにセンサーをつけることでの服薬・治療管理
• 医師の業務効率化、治療補助
• 保険適応や診療報酬請求の自動化

実際に挙げられている例のいくつかは研究レベルでの実施、あるいは一部限定された現場での適応は事例としてあるものです。

ですが、これらのAIが世界中の医療現場全体へ適応されているか？ という疑問については2022年時点では残念ながらNoと言わざるを得ないと思います。

以下書籍の引用ですが、実際にあらゆる面へのAIの適応性を考え、医療を再構築するという点において、「AIファースト・ヘルスケア」の視点は取り入れていく必要があると感じます。

AIファースト・ヘルスケアは、AIファースト企業と同義ではありません。AIファーストは技術的な声明ではありません。ヘルスケア分野の既存の企業がテクノロジー企業と競合することでもありません。AIをあらゆる面に適応することでペイシェント・ジャーニー、患者の体験、患者の治療に違いがでるかどうかを考えることです。あるいは、ICU(集中治療室)や家庭、その他のさまざまな場所の環境やインテリジェント・オブジェクトにAIを導入することで、医療を再構築することができます。

「個別化医療」について

書籍では主に3章で触れられていますが、”個別化医療”といったトピックはAIを医療に適応する上で今後大きなトピックになるのではないかと考えているため興味深かったです。

書評から外れていくためあまり深くは触れませんが、日本でも近年、「医師主体の医療」から「患者主体の医療」へと移り変わるような流れがあります。

例としては、「インフォームドコンセント」といった医師から患者が病気と治療について説明を受け同意した上で治療することであったり、「セカンドオピニオン」といった現在の主治医ではない他の医師から治療法の意見を聞くといったことなどですね。

この時代の1歩先としては、「患者に個別化された医療」が実現される可能性も十分考えられます。

そのような時代では本書で触れられているように、AIの適応が大きなインパクトを発揮するのではないでしょうか。

まとめ

“医療にAIを導入する入門書”という観点で記載されている本書ですが、1章、2章ではAI・機械学習とはそもそもなんなのか？ といった導入から始まり、各章のトピックでは様々な視点から”AI”をどのように医療現場に導入できるのかといったことが書かれており、興味深いです。

実際に医療現場やそのシステムに携わる方は自分が思うところがあるトピックを読んでも面白いとおもいますし、医療システムに関して初めて触れる方も最初から読めばわかりやすい構成となっています。

“AI×医療”というトピックが気になる方にはオススメしたい書籍です。

はじめに

こんにちは！ 2021年入社、TIGメディアユニット所属の菅野です。

本記事は、「業界ドメインに詳しくなろう」シリーズ連載の「メディア業界へのチャレンジ」第9回目です。
前回のフューチャーのメディア業界への取組み編では、新聞社の具体的な編集業務とフューチャーが開発したコンテンツ管理システムGlyphFeedsについてご紹介しました。

今回は少し視点を変えて、新聞業界のビジネスモデルの現状と課題、課題打破に向けた新しいビジネスモデルへの挑戦についてご紹介したいと思います。

新聞社はどのように収益を得ている？

皆さんは新聞社がどのように収入を得ているかご存知でしょうか？

ご存知の方も多くいらっしゃると思いますが、新聞社は新聞そのものの「販売収入」と、新聞紙面に掲載される広告の掲載料金による「広告収入」の2本柱によって収入を得るビジネスモデルとなっています。その他にも、雑誌や書籍の出版、イベント開催、不動産経営によって収入を得ている新聞社も存在します。

最近流行りの「サブスクリプションモデル」を他業界に先駆けて取り入れた新聞業界は、このビジネスモデルで数十年間安定的な収入を得てきました。
…しかし今、新聞社に危機が訪れています。

新聞社に迫る危機

新聞社の総売上高の推移を見てみましょう。新聞社の収入の2本柱である販売収入、広告収入が徐々に減少しており、特に広告収入に関しては2020年度には2004年度の約3分の1まで低迷していることがわかります。なぜ、年々収入が減少しているのでしょうか？

※引用：「日本新聞協会」¹

新聞社の2大収入柱が崩れかけている原因は皆さん想像されている通り、インターネットの発達です。Yahoo! ニュースやGoogleニュースなどのニュースサイト、NewsPicksやグノシーなどのキュレーションサイトの台頭によりメディアの情報量が爆発的に増え、簡単に早く欲しいコンテンツを得る事ができるようになっただけでなく、YouTubeやTwitterといったSNSの普及により誰もがコンテンツメーカーとなれる時代へと変化しました。

こうしたインターネットの発達によるメディアの変化により、新聞購読者の減少や高齢化、新聞広告からWeb広告へのシフトチェンジといった事象が起こり、新聞社の2大収入柱が崩れかけてしまっていると推測できます。²

それでは、この危機を乗り越えるためにはどうすれば良いのでしょうか？

【補足1】 新たなメディアが台頭しても、『新聞』にしかない使命があります。新聞の使命に関しては「メディア業界へのチャレンジ」第1回目、新聞業界（メディア業界）基礎編にて詳しく語っているので是非ご一読ください！

今こそビジネスモデル転換のとき！

メディアの変化に伴い、新聞の購読者離れや新聞広告の低迷をもたらしたことに対し、今日多くの新聞社は生き残りを賭けてデジタル化対応を進めています。

しかしながら「電子的に提供される情報＝タダ」という意識が深く根付いており、新聞各社がデジタルサービス（電子版新聞）を開始しても有料会員が伸び悩んでしまい収益化になかなか繋がっていないのが現状です。

各社が新たなビジネスモデル転換に苦しんでいる中、強みである充実したコンテンツや膨大なデータを軸に新たなビジネス領域を開拓する動きが出てきています。

今回はFutureとも関わりがある、「日刊工業新聞社」と「日本経済新聞社」について触れていきます。

日刊工業新聞社の取り組み：コンテンツECサイト

日刊工業新聞社は2022年2月14日に「TREK！」という名前で、記事・写真・動画等のコンテンツ販売サービスを開始しました。商品の検索から決済、著作権利用の手続きまで、すべてオンライン上で完結できるのが特徴で、新聞業界において先駆けたサービスとなっています。

各新聞社が現在とっている、記事や画像といったコンテンツを新聞紙面や電子版に向けて出版・配信するというビジネスモデルでは収益が頭打ちであり、また新聞や電子版に掲載されないコンテンツはお蔵入りになってしまうという課題が有ります。しかし日刊工業新聞社は「TREK！」によって、１つ１つを価値ある商品として販売し新たな収益を生み出すという画期的な事業を展開しています。

【補足2】 「メディア業界へのチャレンジ」第2回目、新聞業界（メディア業界）Futureの取り組みにも記載されていますが、TREK！ にはFutreが関わっています。

興味がある方は第2回の記事をご一読ください！

引用：TREK！³

日本経済新聞社の取り組み：データ活用

次に、日本経済新聞社の取り組みについて紹介します。日本経済新聞社は、読者が求めている時間帯に重要なニュースや解説を紙面に先駆けて電子版で配信するデジタルファーストを軸として持っている新聞会社です。デジタルファーストを達成するために、電子版購読者の行動をリアルタイムで分析し、コンテンツを強化し、デジタルサービスを新規開発しました。そして、日本経済新聞社は、データ分析システムを内製開発し電子版新聞への記事コンテンツのアクセス数など様々な顧客データを集め可視化する仕組みを整えました。

また、社内にモニターを設置して常にコンテンツへのアクセス状況を把握できるようにし、社内の誰もがデータ活用できる環境になるよう工夫しています。データの可視化によって早朝に多くのコンテンツが読まれていることがわかり、読者のビジネス活動時間に合わせて新聞紙面に先駆けて重要なニュースや解説を電子版で配信する「デジタルファースト」へのビジネスモデルへのシフトチェンジができました。

※引用：「NIKKEI2021」⁴

また、電子版購読者のアクセスデータを活用したコンテンツ強化やデジタルサービス開発の充実により、紙の新聞ではアプローチできなかった女性や20代の若者といった読者層が電子版有料会員として増加しており、日経新聞社の電子版有料会員数は2021年から2022年の1年間で約3万7千人増加³し収益化に成功しています。

さいごに

新聞社のビジネスモデルの現状とこれからについてご紹介してきましたが、いかがだったでしょうか。新たなビジネスに挑戦し続けている新聞社を今回は2社のみ紹介しましたが、他にも多くの新聞社が危機的状況から脱却するために日々奮闘しています！

次回はさらに未来の新聞社のビジネスモデルについてご紹介できればと思います。
10年後20年後、新聞社がどう進化するか…？ お楽しみに！

アイキャッチ画像は Photo by Matthew Guay on Unsplash です。

はじめに

このブログは、Google社によるパートナー企業向けのアプリケーション モダナイゼーションに関するテクニカルブログ投稿の集中キャンペーン兼大人の夏休みの宿題の成果になります。

Google社から、初夏某所、下記のようなお題でテックブログを書いてみませんか？ というお誘いが来ました。

サーバーレス製品を活用し、下記のテーマから選択いただいた社会課題を解決するためのアプリケーションアーキテクチャを投稿してください。

●対象テーマ: サーバーレス技術を活用した社会課題の解決策
○空き家問題
○買い物難民問題
○東京一極集中
○フードロス問題

そこでFutureの村田、鈴木、原木の有志三人で定期的に検討会を開き、「買い物難民問題」を解決するためにどのようなサービス、アーキテクチャが好ましいか検討しました。

お題「買い物難民問題」とそのモチベーション

私たちのチームでは「買い物難民問題」を選択しました。理由としては、私が今住んでいる関東郊外のとある地域には周囲五キロにスーパーがないという、まさに「買い物難民」当事者だったこと、だからこそ、生協やネットスーパーのようなサービスが今どきあるから既に「問題」じゃないのでは？ といった疑問に答えられると思ったからです。

「買い物難民問題」という言葉を聞いたことがないという人は少ないと思います。しかし、この問題について調べる前の私たちがそうであったように、単純に「買い物」ができるようになれば解決する話ではないことを知る人はそう多くないのではないでしょうか。

「買い物難民問題」に関して、当事者からヒアリングを行った経済産業委員会調査室の笹井かおり氏による『「買い物難民」問題 ～その現状と解決に向けた取組～』を読むと、単純に解決できない難しさの一端が見えてきます。

本資料では、関東近辺の高度経済成長期時代に山間部に造成されたニュータウン住民を取り上げています。

• 高齢者数が全体の1/4を占める
• 過去に地域内にあったスーパーが不採算のまま撤退
• 70代の住人は家族のために細い未舗装路を自転車で20~30分かけてスーパーで移動している
• 元々山を切り開いたところなので道路環境が悪い(Google Mapsで見る限り、坂も多そう)
• 現役時代には、都心に通勤し、早朝に家を出て深夜に帰宅する生活を送っていたという高齢者が多い。 したがって、住民は地域との接点が薄く、住民同士の横の付き合いも希薄なため、住民の連携が不足している。
• 今後、高齢の夫婦だけの世帯 や一人暮らしの住民が更に増加することが想定されるため、団地の外まで買い物に行けなくなる人が増加するおそれがある
  ※ブログ著者強調

こうしてみると、買い物難民は買いたいものが買えればOKでは決してありません。当時の時代背景ではあまり重視されてこなかった、地域コミュニティといったコミュニケーションの乏しさから来る「関係性の希薄さ」が「買い物難民であること」と表裏一体で問題であることが見えてくるのではないでしょうか。また、それが社会問題として全体化しているとはいえ、地域性の強い問題であり、人によって感度の違いはあると思います。

これらを踏まえた上で、私たちのチームでは全員にとって買い物難民問題を捉えやすくするために、地域の格差を取り払い(かつ将来現実化するかもしれない！？)世界を想定して、「買い物を通じて人との繋がりを生み出す」ための仕組みを考えてみました。

舞台設定

これから話す世界では、現実にはない、どこか少し不思議な世界です。そこでは自動運転が発達しており、キャンピングカーのような移動躯体に乗って生活することが当たり前の世界です。「お隣さん」という概念がもはや古くなって久しく、一か所に集まらないことが普通になった世界で、顔を突き合わせたコミュニケーションは過去のものになっていました。

しかし、こちらの世界で「昭和レトロ」が流行っているように、あちらの世界でも昔のものが形を変えて何度もリバイバルすることはよくあります。最近耳にしたのが、昔ながらのコミュニケーション方法、つまり知らない人と直接会って会話を交わすことが一部で圧倒的な人気を得ているという情報でした…

サービス概要

私たちのチームでは、「買い物」x「人との繋がり」x「(あちらの世界の)レトロ」という軸で、買い物をきっかけに人との繋がりを生み出す新しいサービスを提案します。

主なシステム要件

• 各ユーザーは手元のアプリから「欲しいもの」「受け取りたいエリア」「受け取りたい時間帯」「一緒に受け取りたい他のユーザーの属性情報」を登録できる
• アプリは複数のユーザー「受け取りたいエリア」をベースに、配達先を設定する
• 自動宅配車が欲しい物を指定の時間・場所へ届け、各ユーザーはそこにて交流の機会を得る
• 各ユーザーに別途入力されたプロフィール情報を元に、交流のテーマを設定する
  ※たとえば自家製パンの製造を趣味にしている人で集まることで食材などをある程度共通化する
• 一定人数が揃わないと空けることができないコンポーネントなどを設けることで「まとめ買い」による販売を促進する

システム全体の概要図

ポイント1: 位置情報のリアルタイム更新

本サービスでは物理的に直接会えることが重要なので、地理情報を予め分割した状態で永続層に持たせることで、「ユーザーの現在の場所」「商品受け取り場所(合流地点)」を更新、索引できるようにする必要があります。

位置情報の検索処理を検討する上で、課題の1つがどのように位置情報をデータベースに格納すれば効率的か？ ということです。”移動躯体”がラピュタのように空を飛んでいるのではなく、地上を走行することを考えた場合、地上データは密にデータを管理する必要がありますが、海上や湖上という場所はそんなに必要ないかもしれません。

こちらの世界で、マッチングサービスとして稼働しているTinderでは、Googleが提供しているジオメトリライブラリであるS2 Geometry Libraryを活用することでジオシャーディング(地理情報のインデックス化)し、Elasticsearch クラスターに入れているようです。そのロジック自体非常に興味深い内容ではあるのですが、本ブログでは割愛させていただきます。なにかしらの方法でジオシャーディングを行ったデータをデータベースに格納し、ビジネスサービス用アプリケーションと繋がっているとします。

ここでは、「ユーザ（ここでは移動躯体）」の位置情報は定期的にクラウドと同期され、Google Cloud上にデジタルツイン(現実世界の情報がクラウド上に再現されること)が構築される状態を実現します。定期的な位置情報の更新に合わせ、各ユーザの所属するジオシャードは常に更新される仕組みを考えました。

デジタルツインを実現するためには、定期的な位置情報更新が必要ですが、それを裏で支えるために、パフォーマンスはなくてはならないポイントです。位置情報は利用者に合わせて同期的に送られるため、ビジネスのスケールに応じて多くのトラフィックを処理しなくてはいけないかもしれません。そのためにキューイングをクライアントとデータベースの間に噛ませることで、混雑を緩和させます。

こちらの世界で身近なところでいえば、タクシー用のシステムは上記要件と近しいと思われます。たとえば、タクシーアプリ『Go』を開発しているチームではアーキテクチャを公開しており、中でも位置情報を捌く「動態収集・配信システム」は興味深い実装をしています。メインシステムはGoogle Cloud上で動かしていますが、ManagedServiceであるGoogle Cloud Pub/Subを使わずに、Pub/SubをGKE上のアプリケーション、キュー情報をMemorystore for Redisで管理するようにしています。おそらく、Pub/Subにおいてデータ加工等の業務要件があり、採用できなかったのだと思われます。現在でしたらCloud Pub/Subとネイティブ結合されたDataflowを用いるなど別の選択肢がありえたかもしれません。

以上を踏まえて、本サービスでは位置情報の更新処理にあたり、Cloud Pub/SubサービスとElastic Cloud(ElasticSearchのManagedService、 非GoogleCloud)を採用させていただきました。

ポイント2: マッチングサービス

今回のシステムの要は、「買い物」を契機としたマッチングサービスです。上記で検討した位置情報検索サービスを元に付近のユーザーを探し、一緒に買い物をする場所を提供します。

単に近い場所にいるユーザーであればいいというわけではありません。マッチングするための要素として最も重要視しているのが、「買い物」対象について同じ指向を持つユーザー同士を引き合わすための仕組みです。※あえて嗜好ではなく指向と書いています。

異なる食文化が摩擦を生み出す経験は、私もかつて卵焼きに砂糖を入れたことで、すれ違いという苦い思いをしたのでよくわかるのですが、それゆえにすり合わせは重要です。「買い物」を契機としてユーザー同士がつながりをもってもらうために、買い物対象はある程度傾向が同じであることが望ましいです。ビジネスサイドから見ても、多くの重複があることで食材の品種をある程度絞れるので、効率的な調達や配送ができることからメリットは大きいでしょう。

それでは、マッチングサービスの実装はどうなるのでしょうか？ Googleのテックブログでは、今回によく似た事例として「Vertex AI を利用して強化学習レコメンデーション アプリケーションをビルドする」として強化学習を行うための仕組みが紹介されています。この仕組みでは、ユーザーが試行を重ねることで精度を上げられるため、聞き放題のような試行回数を気軽に重ねられるシステムでは非常に有効ですが、本サービスでは残念ながらそのままブログの内容を流用できません。しかし、本質的なところは同じです。ユーザーの指向を特徴量として抽出したりベクトル化した上で、似たユーザーを引き合わすことが目標になります。

プラットフォーム上ではどんなレコメンデーションアルゴリズムを動かせば良いでしょうか。今回のブログでは、その詳細まで踏み込みませんが、参考文献をいくつか取り上げます。

たとえば、Alibabaクラウドのテックブログ「Basic Concepts and Architecture of a Recommender System」ではマルチチャンネルマッチング(複数のレコメンデーションアルゴリズムを元に三者協議する仕組み)とランキング(マッチングの条件にあてはまるものを優先度に応じて並び替えること)がEコマースにおいて重要だと伸べています。

今大きな隆盛を見せているディープラーニングも候補に入るでしょう。ZOZOさんのテックブログではディープラーニングを活用したレコメンデーション用アルゴリズムをいくつか紹介していますが、こちらも参考になりそうです。

マッチングの中には禁忌の組み合わせが考えられます。マッチングサービスにおいて論争になりそうな組み合わせ(先ほどの卵焼きにおける塩/砂糖問題)はルールベースで記載しておいて、ファインチューニングで定期的にモデルから取り除く努力が必要そうです。

上記を踏まえて、本サービスでは下記のような処理を検討しました。

1. 注文を受注する「注文サービス」から、ユーザーの購買履歴やサービスの閲覧ログなどを「パーソナルデータ」として保存します
2. パーソナルデータから、ユーザーを特定する機微情報などを取り除いた「レコメンド向け購買データ」をBigQueryに保存します
   a. このデータはマッチングサービス以外にも、購買予測や調達システムなどでも使用します
3. 「レコメンド向け購買データ」をVertex AIの機械学習処理にかけて、どういった購買履歴を持つユーザー同士なら親和性が高くなりそうか、推論エンジンを作成します
4. 注文後、マッチングを待つ「マッチングウェイティングサービス」から、下記条件で絞り込みを行い、マッチングを成立させます
   a. 「ジオシャード」から取得した位置情報
   b. 推論エンジンによるユーザー親和性判定

その他のポイント

本ブログでは書ききれなかった、アプリケーションアーキテクチャの考察ポイントであった議論をこちらで供養します。

• 「グループマッチング」と「受取地点・時間確定」の順番

今回のサービスは、「グループマッチング」した後で、「受取地点・時間確定」を決めていましたが、その逆もありえたかと思います。単純に落ち合う場所を最初に確保するだけではなく、街コンのようにテーマを決めた上で参加するような形式も今後このサービスが発展した上でありえるかもしれないと議論になりました。

最終的に「この世界では皆が自由なんだ。場所に縛られたくない」という、異世界転生者の一言で「グループマッチング」→「受取地点・時間確定」の順番になりました。

• 自動運転車の走行を支えるためのシステム。あるいは自動運転を裏で支える機械学習プラットフォームのデザイン

機械学習のモデル構築は重要な作業ですが、そもそもそのためのトレーニング環境をいかに自動化するかというのも大きなポイントです。たとえば、「自律走行車のための継続的インテグレーションと継続的デリバリーを Google Cloud で構築する」を見ると、現実かゲームか？ と見間違うような仮想環境、そして道路上で起こりうるイベントを人手を介さずに自動で構築し、自律走行のためにトレーニング環境として活用しているかわかります。E2Eテストの延長線上に広がっている世界に戦慄しました。

• 「支払い」を支えるためのシステムデザイン

PSP(決済代行業者、クレジットカード会社とユーザーの間に入って決済処理を代わりに行ってくれる企業)を用いて決済した場合、ユーザーが買い物をした後決済が完了するまでには一定の待ち時間が発生します。それをどういったロジックで吸収するのか、アーキテクチャ図を元に議論しました。

• 地図における最適な経路を決めるナビゲーションシステムのデザイン
• 買い物対象を、JITで調達するためのサプライチェーンマネジメントシステムのデザイン
• 無人配送車から商品を安全に受け取るための本人確認/認証に関するシステムデザイン

今回は議論できませんでしたが、興味深いテーマです。

さいごに

以上、「買い物を通じて人と人を繋ぐ」サービスとそのアプリケーションアーキテクチャの紹介でした。

今回の取り組みで最初に論点になったのが、こちらの世界で既にある既存サービスとの競合をいかに避けるかという点でした。最終的に異世界転生でいいんじゃないか？ という発想で解決しましたが、その結果、自由にシステムデザインを行うことができて良かったのではないかと思います。

最後に、こちらの世界で行われている取り組み、事業を紹介します。

「買い物難民問題」でよく問題が表面化するのが、「採算が取れずに近所のスーパーが撤退してしまった」ことです。その隙間を埋める1つに、一事業所のカバー領域が広く、人口密度が低い田舎であっても採算を確保できるネットスーパーがあります。しかし、すべての人の助けになるかといえば難しく、一部のデジタル化から取り残された高齢者、地方密着型スーパーのような新たな追加投資が難しい事業者の淘汰という新たな問題が生じました。

そこで最近名前を聞くようになったのが、「とくし丸」です。「移動スーパー「とくし丸」はなぜ“独走”しているのか　1000台突破の舞台裏」にあるように、地方のスーパーと協業したフランチャイズモデルを確立することで、採算性という大きなネックを解決しつつ、ネットスーパーではフォローできなかった人たちへの支えとなりました。

もちろん、官公庁でも「買い物難民問題」を座して解決を待っているわけではありません。農林水産省では「食料品アクセス（買い物弱者・買い物難民等）問題ポータルサイト」を立ち上げて、解決に向けた施策を実施、事業を支援しています。地域に応じた各地での買い物支援の取組では、様々な事例が紹介されており、今回のサービスでも、ビジネスの種として参考にさせていただきました。

中でも印象深かったのが兵庫県神河町・寺前楽座 「 まちの灯り 」 の事例です。地区唯一のスーパーが運営難により閉店後、地元企業や住民出資により運営会社「株式会社 寺前村振興公社」を自ら設立し、再建されたスーパーになります。

消えたまちの灯りを取り戻すべく屋号は「まちの灯り」に決定。また寺前11集落全世帯から1万円を支援金として募り、地区住民自ら意識を持ってスーパーの経営、運営にあたるべく代表を一人、監査役として同公社に配置されたそう。
引用元: https://iimono.town/topic/life/18862/

さらには前のスーパーが閉店したときに勤めていた店長・従業員全員を新しい店舗でも再雇用したとのことで、地域でスーパーを守っていくという強い意志が感じられる取り組みでした。

再建後、四年経ちましたが、Googleの口コミでも、小さめなスーパーだが地域に密着した良いスーパーだと評判は良いようです。そこ目当てで旅行するには敷居が少々高そうですが、最寄りの寺前駅から播但線で更に北上すれば、天空の城で有名な竹田城跡があります。寄り道にはちょうどいいのではないでしょうか。

参考

• Basic Concepts and Architecture of a Recommender System
  • https://www.alibabacloud.com/blog/basic-concepts-and-architecture-of-a-recommender-system_596642
• ディープラーニングを活用したレコメンドエンジン改善への取り組み
  • https://techblog.zozo.com/entry/deep-learning-recommendation-improvement
• Vertex AI を利用して強化学習レコメンデーション アプリケーションをビルドする
  • https://cloud.google.com/blog/ja/topics/developers-practitioners/build-reinforcement-learning-recommendation-application-using-vertex-ai
• Geosharded Recommendations Part 1: Sharding Approach
  • https://medium.com/tinder/geosharded-recommendations-part-1-sharding-approach-d5d54e0ec77a
• 技術書典頒布のタクシーアプリ『GO』アーキテクチャ図録を一挙解説
  • https://lab.mo-t.com/blog/mot-online-techtalk-7

はじめに

こんにちは！ 2021年入社、TIGメディアユニット所属の武田です。

本記事は「業界ドメインに詳しくなろう」シリーズ連載の「メディア業界へのチャレンジ」第8回目です。前回の新聞業界（メディア業界）基礎編では、新聞業界（メディア業界）の変遷や新聞社の使命についてご紹介しました。
今回はさらに新聞業界に深入りし、新聞社の具体的な編集業務やフューチャーの新聞業界への取組みについてご紹介します。

新聞社の編集業務　～新聞ができるまで～

まずはじめに、一般的な新聞製作の流れについてご説明します。
新聞社ごとに作業順序や部署の呼び方、業務の割り振りは異なる部分もありますが、基本的にどの新聞社も以下のような工程で紙面を制作しています。

1. 取材

まずは記者による取材です。政治、経済、文化、スポーツ、事件など世の中の様々な出来事を取材します。

記者が日常的に行なっている取材の形は、大きく分けて「会見取材」と「懇談取材」の2種類があります。「会見取材」は、報道陣の要請に応じて、あるいは自発的に、当事者が行なう説明の場であり、録音やカメラ撮影が許されます。記者の出席は基本的に自由で、質疑応答もあります。
もう一方の「懇談取材」は、正式な手続きや形式を踏まない取材を指します。録音や撮影がNGということも多く、メモさえも許されない場合があります。¹

その他にも「発生もの」と呼ばれる取材もあります。

例えば、事件や事故の当事者や家族、関係者への取材などがそれにあたります。事件や事故の関係者に、喜んで話してくれる人はいないのが当たり前で、取材先で断られたり、冷たく追い帰されたり、非難されたりすることもしばしば起こります。もちろん、いきなり訪ねる失礼は承知の上で記者も取材をしています。

記者は、関係者の辛さや痛みを察しながらも、その出来事の事実や核心を広く世の中に伝えることで、事件や事故の原因や経緯が明らかになり、それが取材に協力してくれた人々への恩返しになると信じて取材活動を続けています。そんな一生懸命な記者の真意や熱意、誠意が伝わって、徐々に心を開き、取材に協力してくれる人もいます。

2. 記事出稿

記者は取材してきた内容をもとに原稿を作成し、デスクに送ります（送稿・入稿）

デスクは、記者が書いた原稿をチェックしてアレンジしたり、削ったり、加筆したり、書き換えさせたりして、最適な形で記事を紙面に載せるための責任者です。取材の指揮をとるのもデスクの仕事で、誰にどこに取材に向かってもらうかを指示したり、記者が取材した内容に対して「もっとこういう話も聞いてきいてくれ」「こういう写真を追加で撮ってきてほしい」とアドバイスをします。

ちなみに、どこの新聞社でも取材記者としての経験を積んだ後に「デスク」という役職を任されることが多いようです。²

デスクが念入りにチェックをした後は校閲に送ります（出稿）

※自社で作成する記事以外にも、共同通信社や時事通信社などの外部通信社からの入稿もあります。

3. 校閲

情報の正確さを身上とする新聞記事に「間違い」はあってはならぬものです。そこで重要になってくるのが、記事の校閲です。

校閲部門は、各部からあがってくる全ての記事を読み、誤字脱字をチェックし、事実確認します。事実確認では、記事と一緒に送られてくる照合資料やインターネットなどを駆使して、触れられている情報は正しいか、固有名詞や日付に誤りはないかなど、調べられるものは全て調べます。校閲と聞くと「誤字・脱字を直す仕事」と思われがちですが、実はこの「事実確認」の部分に時間をかけています。

単純な文字の誤りだけでなくコンテンツの内容にまで踏み込み、徹底した事実確認のもと、著者ですら気づかないような間違い、表現上の矛盾点などを発見し修正しています。³

新聞という商品の品質管理を担うのが校閲部門というわけです。⁴

4. 編集デスク会議

編集デスク会議では、各部のデスクが集まり、「この記事は重要だから大きく掲載する」「この記事は一面トップに」「この記事は小さく」などと、掲載する記事や、その扱い方を決めます。

面白い原稿があれば、取材記者に依頼して、足りない要素を加えて原稿を膨らませてもらうことや、反対に原稿を短く削ったりすることもあります。⁵

5. 紙面レイアウト

掲載する記事が決まったら紙面のレイアウト作業（割り付けとも呼ばれる）をしていきます。新聞社によって、整理部の記者が行ったり、面担（経済面、社会面などの面ごとの割り付け担当者）と呼ばれる役職が存在したりします。

どの記事を一番強調するか、記事の価値を評価し見出しや本文を削りながら、位置やサイズを調整していきます。「見出し」は記事にとってとても重要です。おそらくほとんどの方は、見出しを読んで興味を持ったらその記事を読み始めるのではないでしょうか。文字の種類やデザイン、大きさ、文字数などでニュースの価値の大小を知らせるとともに、記事の内容が一目でわかるような見出しを付けます。

10人いれば、10通りの紙面ができるといわれているほど、レイアウトには個性がにじみ出ます。新聞社の特徴を出しつつ、そこに自分の個性を活かしていくために、日々、試行錯誤しています。⁶

6. 印刷

紙面が完成したら工場にデータを送って印刷していきます。工場にデータが送られると、刷版という印刷の原版が作られます。
印刷には輪転機と呼ばれる高さ10メートルにも及ぶ巨大な機械を使います。新聞の印刷に使われるのは巨大なロールになった巻き取り紙と呼ばれるもので、１本の巻き取り紙をのばすと、約16キロメートルにもなります。輪転機は、印刷はもちろん、裁断、ページ折りまでを自動で行ないます。１秒で25部から50部もの新聞を超高速で刷り上げて新聞の形にしていきます。⁷
輪転機は、かつて必ず新聞社内に置かれていましたが、通信システムの発達に伴い、外部に印刷機能を移している新聞社も出てきました。
大手新聞各社は印刷工場を別会社化し、その専門性を高めながら、連携する他紙の印刷を行なったり、新聞以外の印刷も受注したりといった専業会社として、独自に発展している例も増えています。

こうして新聞の出来上がりです！

フューチャーの新聞業界への取組み

ここからはフューチャーの新聞業界への取組みについて紹介していきます。

昨今のソーシャルメディアの普及に伴う新聞発行部数の減少を鑑みて、新聞社は新聞販売を主軸とした従来のビジネスモデルから、デジタルビジネスへのシフトが急務とされています。そこで大事になるのが、紙やデジタルといった媒体別の対策ではなく読者にとって読みやすいコンテンツをタイムリーに届けることに主眼を置いた「コンテンツファースト」の実現です。そのためには、紙の締切時刻や紙面割の管理を超えた新たな発想への転換が必須でした。それを支えるためのコンテンツ管理システムが「GlyphFeeds」です。

「コンテンツファースト」を支えるGlyphFeeds

GlyphFeedsは、フューチャーが開発したメディア業界向けのコンテンツマネジメントシステムを中核に持つクラウドサービスです。
全てのコンテンツを集約して管理するデータベースを搭載しており、記者が取材して書く記事やカメラマンが撮影した写真などを一括管理できます。

また、編集業務ワークフローを搭載していて、原稿の作成から編集まで、多様な編集業務をGlyphFeedsの画面1つで行えます。記者・デスク・校閲・整理・デジタル担当者などの全アクターによる統合編集が可能な上、PCやタブレットなどの端末と通信環境さえあれば、どこからでも行えます。従来は、媒体毎に「個別編集」を行っており、修正反映が大変でしたが、「統合編集」では、同一素材を派生させて利用しており、一括で修正反映が可能です。
コンテンツを適切なタイミングで新聞紙面やデジタルサイト・ニュースアプリ等に届けることで、コンテンツの価値を最大化できます。

GlyphFeedsは新聞社に不可欠な「可用性」にも強みを持ちます。クラウド基盤を利用し世界レベルでの冗長構成をとっているため、仮に日本で大きな災害が起きたときでも取材・報道活動を継続できます。どんな災害時でもニュースを届けなくてはならない使命を持つ新聞社にとって、非常に大きな意味を持ちます。

コンテンツの価値を再定義する

また、GlyphFeedsには一般公開用のコンテンツ活用APIも搭載しており、既存媒体向けの掲載編集に加えて、コンテンツを活用した新規サービス創出にも寄与します。
日刊工業新聞社プロジェクトでは、コンテンツを活用した新規サービスとして、1つ1つの記事や画像を商品として売り出すECサイトを構築しました。これにより、紙面などに掲載されなかったコンテンツにも価値を見出すことができるようになりました。

まだまだGlyphFeedsの魅力は伝えきれませんが、過去にもGlyphFeedsについて紹介された記事がございますので、ぜひこちらも御覧ください。

私たちで未来を創造する

2022年から始まった読売新聞社プロジェクトでは、単なるGlyphFeeds導入だけではなく、新たな業務領域にも踏み込み、新聞社各社が利用できる業界標準のプラットフォーム構築に取り組んでいます。

マルチベンダーで複雑化したシステムの集約による維持管理コストの低減や、業務フローの効率化で取材記者や編集記者の作業負担を軽減する働き方改革など、新聞業界全体の課題解決を目指します。

さらに、今後はGX（グリーントランスフォーメーション）も視野に入れ、環境へのアプローチも積極的に行っていきます。

今後のGlyphFeedsの成長にぜひご期待ください！

さいごに

新聞社の編集業務、そしてフューチャーの新聞業界への取り組みについて紹介してきましたが、いかがだったでしょうか。
少しでも新聞業界、GlyphFeedsに興味を持っていただけたら幸いです！

次回からは2回に渡り、新聞社のビジネスモデルの現状とこれからについて紹介する予定です。
新聞社の未来はどうなっていくのか・・・新聞業界のDXに携わるフューチャーの視点で新聞社の未来について考察していきます。

お楽しみに！

アイキャッチ画像は AbsolutVision on Unsplash を利用させていただきました。