優れたアイデアやデザインがあっても、それだけではソフトウェアプロジェクトを成功させることはできません。プロジェクトを円滑に進めるためには、ステークホルダーの理解と支持を得て、チームが協力できる環境を作ることが重要です。本書では、そのために不可欠で効果的なコミュニケーションの方法を解説します。具体的な例やパターンを通じて、適切にメッセージを伝えるためのドキュメントや図の作成方法を紹介します。 まず、ソフトウェアアーキテクチャの視覚表現を活用し、受け手にわかりやすくメッセージを伝える方法を解説します。次に、書面・口頭・非言語コミュニケーションの技法を用いて、相手に意図が正しく伝わるように工夫する方法を紹介します。また、ナレッジマネジメントを強化し、チームや組織の集合的な知識を最適化することで、生産性と革新性を向上させる手法についても解説します。さらに、アーキテクチャに関する重要な意思決定を的確
「エンジニアの管理職」の時代 かつては「課長/部長/リーダー」とだけ呼ばれていた。 「とりあえずマネージャやってね」の時代 マネジメント職になりたがらない技術者たち。 技術の現場から離れるとおいて行かれるのではないかという恐怖。 役割定義があいまい。各社で異なる状況。 ポータブルスキルが身につかないのではないかという懸念。 エンジニアリングマネージャーの登場 2018年頃から「エンジニアリングマネージャー（EM）」という肩書きが普及 人材育成・技術戦略・プロジェクト管理・プロダクト連携の専門職 ジョブディスクリプションや求められる知識・スキルも次第に明確に。 エンジニア"リング"マネージャ エンジニアのマネージャ EMコミュニティの活性化 2018年頃より活発化 EM Meetup（毎回多くのEMが参加） EM.FM（累計再生数10万回超） Engineering Manager Adve
2025/02/27 https://distributed-agile-team.connpass.com/event/342568/ 分散アジャイルチームについて考える会 にて発表した資料です！
はじめに こんにちは。プラットフォームエンジニアリング部門の池田（@progrhyme）です。 この記事では、モノタロウのテック系の部門で筆者が取り組んできた「ドキュメンテーションプロジェクト」について、下の目次の流れに沿って紹介していきます。 【目次】 はじめに 「ドキュメンテーションプロジェクト」とは プロジェクト発足の背景 ねらい（まとめ） 何をやったか ドキュメンテーションの促進 Confluence → Googleドキュメントへの移行 その結果どうだったか 上手く行ったこと 上手く行かなかったこと まとめ 「ドキュメンテーションプロジェクト」とは 初めに、プロジェクトの概要について簡単に説明します。 このプロジェクトのミッション（＝目標）は主に以下の2つです。 ドキュメンテーションを通してプロジェクト内外のコミュニケーションを効率化し、業務プロセスの効率を上げる 社内のドキュメ
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
こんにちは。ソフトウェアエンジニアの椎葉（@bufferings）です。最近実施したオリジナルのふりかえりがよかったので紹介します。 いつもはエンジニアリングマネージャの小田中さん（@dora_e_m）が、そのときのチームの状況に合わせたふりかえりの手法を用意してくれていて、毎週違うふりかえりをみんなで楽しんでいるのですが、今回は小田中さんが不在だったので私がファシリテーションをしてみることにしました。 どんなふりかえりをしようかなと ふりかえりカタログ を眺めていたところ Six Thinking Hats が目に止まり「これをアレンジして『帽子の交換』をすると、今のチームにちょうどいいかもしれないな」と感じて、今回のふりかえり手法を思いつきました。 カケハシはリモートファーストの会社で、私の所属するチームもフルリモートで開発に取り組んでいます。そのため、今回のふりかえりもオンラインホワ
ドワンゴ教育事業 バックエンドエンジニアのtakuminishです。 現在、私は教材入稿ツールの開発チームに所属しています。 教材入稿ツールは昨年の2023年06月に社内向けに正式リリースされた比較的新しいツールであり、リリース当初はリリースノートに関する運用について検討が進んでいませんでした。 リリースノートは開発メンバーが手動で作成しており、内容も前回リリース後にマージされたPRタイトルとリンクを箇条書きで記載しているだけの簡素なものでした。 また、PRタイトルのフォーマットも存在しなかったため、英語で記載されたタイトルと日本語で記載されたタイトルが混在している、ユーザ影響度がタイトルからわからないといった問題もありました。 そこで、教材入稿ツール開発チームではリリースノートの運用として、Conventional Commitsを導入するとともに、conventional-change
対話を変えれば組織文化も変わる―。組織内の対話を変えることで、アジャイルな組織文化を築くための実践的な方法を解説します。 オープンな自己表現と相手への理解を促進する「対話診断」を使い、信頼と心理的安全性を築きながら共通の目標に向かって進むための会話の進め方を紹介します。5つの対話ステップ（信頼の構築、心理的安全性の確立、目的の共有、コミットメントの構築、説明責任の遂行）を実例とともに解説し、日々のコミュニケーションを通じて組織内のエネルギーを高めて革新を促す方法を提案します。 迅速な意思決定と主体性を育むアジャイルな組織文化への変革を目指すリーダーやチームメンバー必携の一冊です。 推薦の言葉 はじめに 第I部 1章 ソフトウェア工場からの脱却 1.1 ソフトウェア工場での労働 1.2 アジャイル：人間駆動の開発 1.3 リーンソフトウェア：チームを強化する 1.4 DevOps：運用担当も
リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする
RSGT 2024 Day 2 スポンサーセッション
こんにちは。データ・AI戦略部 SREチームの小野です。普段は部内のシステムに対し、SRE推進活動を行っています。直近では、データエンジニアと協力してデータ基盤周りの改善に取り組んでいます。 <SREの主な仕事> IaC化(Terraform/Terraform Cloud Business)の導入・推進 SLI/SLOの導入・推進 ポストモーテムの導入・推進 アプリケーションデプロイ基盤の導入・推進 ツールやAPIの設計・開発 インフラ設計・開発・運用 トイル削除・システムの自動化 データ基盤改善 一般的なSREエンジニアは、インフラ関連の業務が中心になると思います。しかし、データ・AI戦略部のSREチームは、開発を含めた幅広い仕事をします。やりたいことがあり、手をあげればそれを後押ししてくれる雰囲気の職場です。 今回は、SREエンジニアである私が、組織改善プロジェクトを立ち上げた話をお
ストックマークの社内研修の公開版※資料です。 （※実際に研修で利用したものとは異なります）
これはなに？ こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提 〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています（ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください）。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷を食べる」「南極に送り込む」
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
こんにちは、CTOの山岡（@hiro_y）です。ここ数年「心理的安全性」という言葉を目にすることが増えました。Web上の記事でも、書店に並ぶ書籍でも。 自分も何度か「心理的安全性」って大事だよね〜と話した記憶があるのですが、実際のところ「心理的安全性」とは何でしょう。大切なのは誰もが同意するでしょうが、皆が思い描く「心理的安全性」が達成された状態は少しずつ違っていたりしないでしょうか。 ちなみに似たような感じで扱われる言葉に「コミュニケーション」があると思っていて、大切なことは否定できないけど具体的に何を指しているかは人それぞれ、という…。最近はなるべく「コミュニケーション」という言葉を使わないようにしてみています。 さて、話を戻します。「心理的安全性」とはそもそも何なのでしょうか。自分なりに考えた結果としては、「状態を指す言葉ではあるけれど直接は作れないもの」です。どのような状態かという
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く