「コンテキストをすくい上げて育てる」のが良い会話だとわかってきた

前提

自分はビジネスサイド（マーケティング部）に所属し2025年を過ごしている。そのため、他チーム・他職種の人と会話する機会が増えた。

話し方・進め方を見つめ直す必要があった

エンジニアチーム→ビジネスサイドで何が変わったか

今まではエンジニアチーム内で、ある程度お互いの性格や価値観が分かってる上で会話することが多かった。しかし最近は、あまり関係性の深くない人と会話することの方が多くなった。

難易度の上がった会議とコミュニケーション

さらに重要な会議も増えてきた。会話時間も限られている中で、意思決定したり、決定したことを実行に移すコントロールなど難易度が上がってきた。

例えばマーケティング施策に他チームに協力してもらうなど。また、細かな担当の変更、体制などヒトの変更みたいなところも色々発生している。

それぞれ容易くはないし、正直、苦心することが多い。

そういう事情もあり、話し方や進め方を考えることが多くなった。

対処としてやっていること

そのため、自分としてやったことは

• 本を複数冊読むこと
• 本で得た知識をもとに実際の会話やミーティングで実践すること

これの繰り返し。複数の本を読み実践する中で、共通項も見えてきた。なので、単純な読書録というより、自分なりに整理したこと、考察したことを書いてみようと思う。

長いので、気になるとこを拾い読みしてもらえればと思います。

想定読者

• エンジニア〜な人々
• いろんなチームと会話やミーティングする人

読んだ本

読んだ本を列挙すると以下。大きく3つに分けられそう（読みかけのものもある）

1. 話し方

• 最強のエンジニアになるための話し方の教科書
• Think Fast, Talk Smart
• 1分で話せ

2. 相互理解や認知について

• 他者と働く
• 何回説明しても伝わらない。はなぜ起こるのか
• ファスト & スロー
• 予想通りに不合理

3. 会議の進め方

• 結果を出す組織はどんな会議をしているのか

色々な本を読んでるが、それだけ試行錯誤を繰り返しているというところでもある。このあたり出来てる人は読まないで済む部分も多そう。

1. 話し方の本の要約と考察

聞き手が一番重要という逆説

話し方について共通して言えるのは「話すことより相手が聞く姿勢になってるかが重要」ということ。話し方の本なのに、逆説的に聞き手が一番重要だと書いている。

自分視点から相手視点への転換

僕のような話の下手な人はどうしても「上手く話そう」とする。抑揚だったり話す順番だったり。

でも、それでは自分にしか意識が向いていない。どれだけうまく話しても、相手が聞く姿勢でなかったり、聞く気持ちにならなかったり。

結局は聞き手が重要という至極当たり前のことが書いてある。言われてみればそう。

それが根底にあり、その上に話し方の上手さがある。

コンテキストに乗ってコンテキストを広げていくイメージ

聞き手の状態を見るということは、相手の状況を把握するのを繰り返す作業。これはエンジニアに馴染みの深い表現で言うなら、コンテキストを深くしていくイメージかなと思う。聞き手のコンテキストを掴み、自分の主張を盛り付けていく感じ。

多分AIと普段会話してる皆さんならわかるでしょう。でもAIと違うのは、会話を始める前から複数のコンテキストが点在していること。

自分の内なる声も聞く

「Think Fast, Talk Smart」には「聞き手の状況を見ると同時に自分自身の内なる声にも意識を向けろ」と書いてある。この本で特徴的なのはこの部分かなと思った。話し手と聞き手のそれぞれの状態を把握してその状況やニーズにあった会話ができる。

とっさの会話であろうとスピーチであろうと、結局は準備が大事。ある程度フレームワーク的に心得ていれば、どのタイミングでも話すことができると書いてある。

具体的に意識するようになったこと

• アイスブレイクを30秒入れる。同意や感謝の言葉から入る
• 質問をする、話を他の人に振る。相手の表情や反応を見る
• 全てを話そうとしない
• 話の構成をパターン化する。三段論法など

2. 相互理解や認知の本の要約と考察

視点の違いとバイアスの理解

他チームに納得してもらうこと、相手が働きやすくなるよう考えること、コンフリクトを生まないことなど考えると相互理解や認知が大事だと感じた。

さらに前述の、聞き手のコンテキストに乗る会話のためにも、相互理解や認知がなおさら重要なポイントだと考えた。

上記の部分があり、それを補助する系の本を読んでいた。

立場の違いと視点の違い

相互理解という意味だと、働く実務や役割によって視点が全く異なるということ。これが大前提かなと思う。そしてそれぞれが視点が違う中でもバイアスがある。このあたりは「他者と働く」や「何回説明しても伝わらない。はなぜ起こるのか」などに書いてある

人間の認知の曖昧さ

「ファスト・アンド・スロー」や「予想通りに不合理」は、いかに人間の認識が曖昧で、誤解を招きやすいかがわかりやすく書いてある。人間の脳の思考の癖、印象の受け方が書いてある。

このあたりを読んで、

• それぞれの違いがどこから生まれるか
• 難しさはどこから生まれるか
• どういった認識や印象づけになるか

を理解した。ポジションの違いから認識の違いが発生しうることを念頭に置いた会話ができるようになったかもしれない。

具体的に意識するようになったこと

• 相手の目標や進め方、課題、大事にしてることを知るための会話をする。時には相手の作業に入り込む
• 相手の背景にあるストーリーを知るための会話をする。時には相手の作業に入り込む
• 相手のコンテキストや用語、言い回しを知るための会話をする。時には相手の作業に入り込む
• 言葉の通り伝わることはほとんどないと心得、相手にどう伝わっているかを都度確認する
• どういう言い方でどう人間が認知してしまうか知り、意識して話す

3. 会議にまつわる本の要約と考察

相手に寄り添うだけで上手くいくわけない

聞き手のことを思って相手の立場を理解すると会議は上手くいく…わけではない！

上手く話すだけで会議が進むわけない

聞き手と自分を意識して上手く話していれば会議は上手くいく…わけではない！

準備の重要性

それだけでは足りない…！と、会議の進め方に関して、本を読んだ。会議の本以外にも、話し方の本にもプレゼンやミーティングでの話の進め方が含まれている。

それらに共通して言えるのは、「準備をする重要性」。会議のアジェンダやどういう話をするか、時間をどう区切るか？そういう根本的なことを案外みんな大事にしない。とっさの会話でも、ミーティングの予想しない議論でも準備やシミュレーションできた量が成功を左右する。

具体的に意識するようになったこと

• ゴールを明確にすること。それを会議で合意すること
• 目的を明確にするため話の流れを一通り手短になぞることも大事。会議で認識を揃える
• 画面共有など視覚的に表すこと。また議事録はその場でリアルタイムに取ること
• 後からメモ取ってテキスト共有しても誰も見ない。その場で飛び交う言葉をテキストに落とし込み、同じ画面を見ることに意味がある

まとめ

話し方や会議の進め方についての本を読みつつビジネスサイドで色々な人と会話を実践してきたところを整理した。

まとめると

• とにかく準備が大事。準備できてないとうまくできない
• 聞き手の視点に沿った話をすることが重要
• 聞き手がちゃんと認知できるような情報を提供すること。画面共有やテキスト化をその場で出す
• そういった聞き手の状況、心理を理解するために認知の理解や相互理解が前提となる

やはり当たり前を地道にしっかりやるのが重要ということ。どうしても話し方や進め方をうまくやろうとすると、自分視点になって相手を忘れがち。

どこまで行っても他者がいることで複数のチームで働くことは成り立っている。そのことに改めてハッとさせられたし、忘れてはならないなーとなった。

※便宜上「ビジネスサイド」という言葉を使いましたがあまり好きではありません ※ 自分はまだまだ全然出来てないので自戒や整理として書いてる部分が大きいです ※スキルアップとして読まなくても、どの本も読み物として面白いところが色々あったりなかったりします ※ 色々読んだけどエンジニアへのおすすめは「最強のエンジニアになるための話し方の教科書」。ベタにして、ベストかもしれない

なぜノーコードツールは売れるのか？

はじめに

ノーコードツールが出回っていますが、ソフトウェアエンジニアにとってはあまり馴染みがないものです。何故売れてるんだろう？と不思議に思いませんか。

だからこそ、ノーコードツールの価値、使いどころをソフトウェアエンジニアが分かっておいた方が良いのかもしれない。

ということで今回は、エンジニア視点とビジネスサイド両面から見たノーコードツールの価値と役割について掘り下げて考えてみます。

エンジニアの自分）ノーコードの存在意義が分からない。メンドイ

私自身、エンジニアとして日々コードを書いてきました。正直なところ、ノーコードやローコードツールでできることは大抵自分で実装できてしまう。

「GUIでチマチマやるより、コード書いた方が早い」と思ってしまう。

エディタでもない、ターミナルでもない、わざわざブラウザ上でポチポチやることに、なぜ時間をかけるのか。バッチ処理やワークフロー作成とかだってコード組んだり、CLIで実行できるほうが明確だしUIに振り回されることもなくラク。

マーケターの自分）他の人が面倒見れないツールを作ってしまう

しかし、現在、僕が身をおいているのはマーケチーム。ビジネスサイド。

エンジニア時のノリでツール用にコードを書いていて、ふと気づく。
僕がツールを作っても、同じチームのメンバーはコードメンテが出来ない。シェルスクリプトとか渡しても果たして動かしてくれるか…。

作るものに縛りがあるなぁ。他の人に使ってもらうにはUI必須だ。GASでつくれば他の人も使えそうだけど、バグった時のメンテは全部自分だよなぁ…など。

チームメンバーへの甘えに気づく

ビジネスサイドのメンバーはまずgit pullとかしたこともないし、シェルスクリプトも実行できないし、SQLも書けないし、デバックも出来ないし、コードベースのconfigファイルもイジれないし、ハードコーディングの一部分を書き直すことも出来ない。

これまでサクッと作ってたツールは、使い手を選ぶものだった。

よく考えたら今まで僕は「チームメンバーがソフトウェアエンジニアであることに甘えていた」んだな、と。

"スキマの改善"を救うのがノーコードツール

そうすると、ソフトウェアエンジニアが改善して、コードメンテすれば、チームとして取り組めて良いよな。
ということで、業務改善としてエンジニアに依頼しよう！
しかし、開発チームにも開発の優先度がある。つまり優先順位が低くてなかなか改善が進まない業務プロセスが無数に出てくるわけです。

これは前回のブログでも書いた内容です。 リンク：誰のための自動化？

雑ベン図2）水色の部分とか自動化されないがち

このベン図の中の「スキマの業務」を埋めるのが、ノーコードツールです。

ノンプログラマーにとっての「実行環境」

改めて、手札が変わって気付かされたこと。
ビジネスサイドの人々は、根本的に「実行環境」がない。GitHubやCI/CDなどの環境もない。クラウド・インフラ環境へのアクセス権もなければ、そもそもインフラが無い。ソフトウェアエンジニア恵まれてたなぁ。

そんな中で、自分たちの手で業務効率化や自動化を実現できる唯一の「実行環境・選択肢」が、ノーコードツールなのかもしれません。

エンジニアにとっての「手離れの良さ」

もう一つ、大きな価値は、エンジニアの手離れの良さです。

社内向けのツールやちょっとした業務支援システムをエンジニアが作ってしまうと、その後のメンテナンス責任も伴います。機能追加・不具合対応・環境構築……すべて自分に返ってくる。

しかし、ノーコードツールを活用すれば、運用や保守はベンダー側に任せることができ、エンジニアは本当に重要な開発業務に集中できる。

CMSやSaaSと同じ発想：抽象レイヤーを上げる意味

ここまでを整理すると、ノーコードツールの価値は

• プログラムを抽象化し隠蔽すること
• ノンプログラマーであるビジネスサイドに「実行環境」を与えること

インフラを抽象化したIaaSやPaaSと同じように、「プログラミング」という行為を抽象化して、より多くの人が扱えるようにしたのがこれらのツールと言えそう。
昨今のCMSやSaaSもこの役割と言える。

つまり、「レイヤーを上げることで、扱える人口を増やす」ということ。

これはDockerとかもそう。プログラミング言語も機械語を抽象化してますね。その結果プログラマ人口を増やしていると言えそう。

適材適所としてのノーコード・ローコード

もちろん、業務に強く依存した独自仕様のものはエンジニアが設計・開発・運用するべき。しかし、ある程度の汎用性があって、自動化でカバーできる業務なら、ノーコード・ローコードで十分。

特に、初期構築だけエンジニアが関わり、その後はビジネスサイドに引き継いで運用を任せる形は、理想的な分担かもしれませんね。

ツール爆発、Config地獄、マニュアル地獄

ここまで、ノーコードツールはビジネスサイドの味方ではあるということを書いてきました。
でも正直、良いことばかりでもないです。

ツールが多様化・複雑化したときに起こることは何か？ツール爆発です。ツール多すぎ問題。

複数のツールをまたがるコンテキストスイッチ、入力内容の転記。コピペ。そこにまつわる人為的ミス。爆発したツール同士を結ぶのは人です。ツール間のインテグレーションはだいたい後回しになったり、プラグインがなかったりします。

また、秘伝のタレ的な設定値もツールの数だけ必要です。マニュアルも必要。ああだからGUI嫌なんだよ（）

ツールも経年劣化するし、お金がかかるし、サイロ化する

実行環境を得たとしても、ツールの品質やユーザビリティの影響をモロに受けてしまいます。導入すればいいってものでもない。ツール自体のバージョンアップや運用管理者なども必要ですよね。

もちろんお金もツールの数だけかかったりします。

また、部署ごとに「うちではこのツール使ってるから！」という局所最適を生み出しかねない。

銀の弾丸欲しいよ〜

今、考えるべきこと

ビジネスサイドをよく見ると、現場をワークさせているのはSaaS、CMS、SFA、CRM、MAなどたくさんのいわばノーコードツールです。そしてなぜノーコードツールのニーズがあるか？もう分かったと思います。そして「そこにある問題」「何故それが起こるべくして起こるのか」も。

エンジニアがそれらを理解し、適切に業務システムと使い分けることができれば、組織全体の開発力と生産性に良い影響を与えそうです。

ツールを使うべきか

「自分で作るべきか、それとも任せるべきか」その判断こそ、今エンジニアに求められているスキルかもしれません。
また、ビジネスサイドのメンバーも「ノーコードツールを選定すべきか、エンジニアに依頼すべきか」特性や領域を理解した棲み分けが重要になりそうです。

いつ捨てるべきか、標準化すべきか

あとは「捨てるべきツールは何か」を見極めるのも大事そうです。業務丸ごと要らないじゃないか？Fit to Standardなど考えることも大事ですね。ありがちな話ですが。

まとめ

ということで本当にとりとめもなく書きましたが、まとめます。

• ノーコードツールはビジネスサイドのための抽象化
• ノーコードツールが使われるのは、実行環境が無いから
• 便利だからといって導入しまくると、ツール爆発は起こり得る。銀の弾丸はない
• ツールにするか業務システムに落とし込むか。エンジニアとビジネスサイドが相互の視点で考えるべし
• ツールも業務システムも経年劣化する。捨て時、改善のタイミングが大事
• 「業務そのものが本当に必要か」まで考えれるとより本質的

ということで、ソフトウェアエンジニア、SRE，情シスエンジニア、ビジネスサイド、リーダー、経営陣とかみんなで考えていこうね！

誰のための自動化？

はじめに

ぼくは現在、ビジネス側のチームに所属しています。ソフトウェアエンジニアとしての活動は虚無って感じです。

そして、実際にビジネス側のチームに所属することで「視点」とかも変わってきた部分があるし、そのあたり、今だからこその思考なんだろうなぁとも思う。

なので、ちょっとそういったところ踏まえなんか書いてみようと思います。

リモート前提のまま変わらない組織

サマリ

• コロナ禍、フルリモートへ
• フルリモートでなんとかなった
• オフライン回帰。しかし雇用や制度設計はリモート前提のまま
• フルリモートで出来るようになったこと・出来なくなったことを正しく評価することは難しい
• たとえば、アジャイルの「全員同席」
• 機能的な出来ることと、偶発性で出来ること
• オフライン前提からハイブリッド前提へのシフト。失われた概念

【どれ使えば良い？】たくさんの生成AIに囲まれたおれたちは

自分の整理メモです。

簡単にまとめ

• 雑にコード出してほしいならChatGPT
• しっかりめに壁打ちしたいならClaude
• 雑にリサーチしたいならGemini
• しっかりめにリサーチしたいならパープレキシティ

まえおき

AIのトレンドも、「使う」から「任せる」に変わってきている。
またAIそれぞれも専門家、高度化、多様化している。
専ら、最近の話題はAIエージェントなのかなと思ってる。各AIでエージェントモードとか始まり、それがエンジニアの関心になってそう。