本記事の概要 非エンジニアの私ですが、これまでエンジニアと働く上で、「コミニュケーションが難しい」「言っていることがさっぱりわからない」みたいなよくある悩みを感じたことがないのですが、なぜなのかが最近言語化できた気がするので記事にしてみました。 結論、エンジニアのやっていることが「なんとなくわかる」というのが大事なんじゃないか、という記事です。 ※本記事を読んでいただいたエンジニアの方、「いやいやこれくらい知っておいてくれ」「こんなレベルじゃ話にならない」等あればツッコミお待ちしております！ 前提 これまで一緒に働いたエンジニアがいい人たちすぎて「わかりやすいよう歩み寄ってくれている」みたいなありがたい環境ということは大前提 Qiita株式会社でマーケティングやセールスに従事する私自身のエンジニア経験はゼロ Progate、ドットインストール等でHTMLやCSSをかじったことがある程度 業

テキストメッセージを「デザイン」すると、読み手に寄り添うコミュニケーションができるかもしれない話 | Design Journal Vol.22 この記事のサマリーSlack等でテキストメッセージを送る前に、デザインのプロセスを用いることで、読み手に寄り添ったコミュニケーションができ、「伝わらない」ストレスが減り、お互いがハッピーになるかも、という話です。 背景社会人になり約4年半ほど経ちますが、まだまだ難しいなぁと日々感じていることが、「テキストコミュニケーション」です。 ここ2年ほどでリモートワークの割合も加速し、テキストコミュニケーションが中心になってきているチームも多いのではないでしょうか。 そんな中で、「この人のメッセージ、いつも内容がスッと入ってくるなあ」と思うことや、 逆に自分が送ったメッセージを読み返し、「何が言いたかったんだっけ…？」と反省することも多々ありました。 そし

幸せ視点の経営を学ぶ、革新的なオンラインスクール hintゼミの主催で行われた本イベント。新著『小さくはじめよう 自分らしい事業を手づくりできる「マイクロ起業」メソッド』を出版した、ビジネス・ブレークスルー大学経営学部教授の斉藤徹氏が登壇しました。本記事では、職場の人間関係を円滑にするために、コミュニケーションの技術以前に意識すべきことについてお伝えします。 本音と建前を一致させることが大切 斉藤徹氏（以下、斉藤）：機械とかコンピューターだったら、正しいコマンドを入力すれば、必ず正しい結果が返ってくるんだけど。でも人は心を持っているから、仮に「こうしてほしいんだよね」って正しいことを言ったとしても、自分で決めないと反発しちゃいますよね。特に言い方がすごく大切になります。 実は言い方は、言語情報だけじゃなくて、非言語な情報もとても大切です。表情、目の輝き、相槌とかね。今からそういったことを考

1on1ミーティングガイド (1on1ガイド)は未完成の部分も残したβ版として公開しており、今後コンテンツの追加やスタイルの修正などの変更が予定されています。 また追記やスタイルの修正だけでなく、現在記載されている内容が大きく見直される場合があります。

こんばんちは、スーパー太っちょWebディレクターです。 スーパーは太っちょにかかります。 先日、こんなことをX（Twitter）でつぶやきましてね。 社内外問わず、「あいつら（他部署やクライアント）は全然わかってない」はよく聞く話なのだけど。だが、そもそもちゃんと説明してないことも多々あるんですよね。そりゃ違う仕事してるんだから説明しないとわかるわけがないのに。 ちゃんと丁寧に説明すれば、理解してくれる人もたくさんいますよね。 — toksato（とくさと）｜むめいなうぇぶディレクター (@toksato) May 8, 2024 そして、その後日、こんな素晴らしいインタビュー記事を読みまして。 仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた | Agend(アジェンド) 僕もこれをリアルに社内でやってるなぁと思って。ま

私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。 初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。 数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落

リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする

参考 プリンシプル オブ プログラミング - 3年目までに身につけたい一生役立つ101の原理原則 発行: 2016/3/23 著者: 上田 勲 まえがき プログラマーの世界で語り継がれる原則や格言を知ることは、その共通の言語や道徳を理解する手助けとなります。 『プリンシプル オブ プログラミング』（以下、プリプロ）は、統一された語句と形式により、先人のプログラマーたちが重要視していた思考法やアプローチを、微妙な概念の違いに気を使うことなく理解できるよう構築されています。この記事では、この本を読む上で役立つ101の原則マップと原則から抽出した価値観をまとめます。プリプロを読む際のガイドになればと思います。 一方で、プリプロに収録されていないウィットに富んだ原則や格言も多く存在します。この記事では、主に私の現場で重要視しているプリプロの101の原則以外の原則・格言も追加で紹介します。 プログラ

「指示の出し方が悪い人」が、いる。 例えばこんな具合だ。 「安達さん、web制作会社からあがってきたページの確認をしておいて！」 そんな指示が上司から飛んだとする。 実際にそれを体験してみると、この指示が「良い指示」だと思うビジネスパーソンは、ほとんどいないだろう。 なぜならば、 １．「あがってきた」とは何か。メールで届いたものか。メッセンジャーで来たものか。他にもあるのか。何が全てか。 ２．「ページ」とは何か。webページのことか、または別の形式・フォーマットを指すのか。 ３．「確認」とは何か。何を基準とするのか。どうすれば作業終了となるのか。 など、作業を進めようとすればするほど、次々に疑問が湧くからだ。 酷いときには、よくわからない書類をぽんと渡されたり、謎のメールを転送されて 「これやっといて」 などという指示をする人もいる。 要するにこれらはすべて、「手抜き指示」だ。 こういう指

これはなに？ こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提　〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています（ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください）。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷を食べる」「南極に送り込む」

最近「心理的安全性」っていうことば、耳にしませんか?職場やビジネスで注目されているようだけど・・・分かるようで、分からない。そもそも何なのか、どうやったらつくることができるのか、「心理的安全性」の専門家に聞きました。 心理的安全性って何？

技術をわかりやすく伝えるためのテクニックとしての「テクニカルライティング」を学べます。Developers Summit 2023の登壇資料。開発者・エンジニアの方向け。 https://twitter.com/naoh_nak

仕事において、相手に情報を正しく伝えることは必須です。逆に、伝えたいことが正しく伝わらなければ、相手は誤った情報を元に業務を遂行することになります。結果、いくら質高く、効率よく仕事をしたところで、アウトプットは想定外のものとなり、全く役に立たない場合すらあります。 このように正しく伝えることはよりよい仕事をする上での大前提であり、非常に重要です。そして、正しく伝えることは才能ではなく習得可能な技術です。「正しく伝える技術入門」では、伝えたいことを意図通りに正しく伝えるために必要ことをまとめます。 # 更新情報 * 2022/11/16 - 公開

”ユーニス・パーチマンがカヴァデイル一家を殺したのは、読み書きができなかったためである” という一文から始まる「ロウフィールド館の惨劇」というミステリ小説がある。 「読み書きができない家政婦」がその劣等感をこじらせ、一家惨殺に及ぶまでを追いかける話で、映画化もされている。 3年ほど前に知人のすすめで読んだのだが、倒叙ものや、変わった話が好きな方は読んでみても良いと思う。 ＊ ただ、ストーリーの強烈さより私が覚えているのは、文盲までいかずとも「文章が正確に読めない人」は、今でもかなりいるな、と思ったことである。 例えば、リーダーが部下に、こんなメールを送ったとする。250文字だから、ツイート2つ分弱だ。 明日の朝10時までに、私をCCに入れて、Yさんにメールを送っておいてください。内容は次回の定例までの宿題事項と、現在までに積み残している課題の一覧の二つです。積み残しの課題については、期限を

この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。 こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。 みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？ 先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。 質問力を向上しよう！と至った背景 弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに

一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ

タイトルは、ポール・グレアム氏（Yコンビネーター）の「メイカー（作り手）のスケジュールとマネージャーのスケジュール」(Maker's Schedule, Manager's Schedule) からの引用です。 マネージャーは多くのミーティングをこなすなど、1時間単位でタスクにあたりますが、エンジニア（プログラマ）は最低でもまとまった半日単位の時間を作業に必要とする、と書かれています。 paulgraham.com 日本語訳 note.com エンジニア上がりのプロダクトマネージャーとして開発もプロダクトマネジメントも並行してこなしてきたのですが、意思決定のためのミーティングスケジュール、自身が開発を行うためのスケジュールをやりくりするバランスに腐心していました。 自身のタイムマネジメントで特に感じた点として、ミーティングとミーティングの間に1時間が3コマある時の開発生産性と、3時間まとま

「SESエンジニアが今を楽しみ、希望にみちた未来を実現できる。」そんな状態を目指してスタートした「SES Plus」のラジオ。今回のテーマは、「PM vs スペシャリスト」。日本企業において多くあるキャリアの分岐と、需要がなくならないキャリア形成に必要な要素について話しました。 今日のテーマは「PM vs スペシャリスト」 國司壮太郎氏（以下、國司）：みなさん、こんにちは。 久松剛氏（以下、久松）：こんにちは。 國司：10分で元気が出るエンジニアラジオ「エスプラジオ」。この番組は、エンジニアがSESで働くことの良さを再発見し、再創造して、明るく楽しく働ける未来を作りたい。そんな思いを掲げて運営している「SES Plus」の提供でお送りしています。 パーソナリティは、流しのエンジニアリングマネージャーこと久松剛さんと、現役SES人事である私、國司でお届けいたします。久松さん、よろしくお願いし

不確実性に立ち向かう各社のアジャイル開発のリアルについて話す「『不確実性』にどう立ち向かう？アジャイル開発現場のリアル【BASE・DMM】」。ここで合同会社DMM.comの梅林氏が登壇。ここからは、通信不確実性の対処法について話します。前回はこちらから。 対処法「できる限り議事録やメモを残す」 梅林良太氏（以下、梅林）：（スライドを示して）ではここから、それらがあることはわかったので、なんとか軽減、マシにするにはどうしたらいいのかのヒントを、少ないですがいくつか書かせていただきます。 先ほどの事例分析と1対1で対応するわけではないですが、これらをふだんやっておく、意識しておくことで、ある程度の広い範囲でカバーできるんじゃないかと私自身が考えていることです。 （スライドを示して）まず1点目が、できる限り議事録やメモを残す、です。言った／言わないが往々にして起こったり、何か書き残していないと、