HsbtDiary

■ デザインの伝え方を読んだ

書籍「デザインの伝え方」を読んで - snoozer05's blog を読んで、この本は良さそうと感じたのでシュッと読んだ。

この本は「デザイン」の伝え方とタイトルについているものの、内容は自分のアイデアや設計(デザイン)のようなアウトプットをどのようにしてコンテキストが異なる人たちに伝えて、組織において実行に移させるか、というコミュニケーションの手段について、意思決定が行われるステークホルダーの会議(書籍ではS会議と名付けている)でどう振る舞えば良いかということを紹介している。

特にS会議とその参加者について

• 理解する
• 傾聴する
• 応対する
• フォローアップする

という4つに分類して、それぞれのフェーズに置いて、デザイナ(アウトプットを正しく伝えたい人)が何をすればいいか、どのような言葉を使えばいいかというレベルで添削のように解説している。

よく、「優れたコードを書いて技術力を示すのがエンジニアであって政治は興味ない」という声が大きい人の言うことを真に受けて、同じように振舞っていたら誰にも見向きにされず「この優れた技術を理解できない経営陣や偉い人がダメなんだ」と腐るのを見かけることがある。本書はそのような人に本当にオススメしたい。

一部の優れたエンジニアはコードで世の中を動かして、会社の方向性をも決定するのは事実なのだけど、おおよそのソフトウェア開発は、人と人とがそれぞれが出来る限りのことを協力して、大きな成功を成し遂げることがほとんどだと思う。だからこそ、ソフトウェアを作る時に協業する人の考え方や背景を事前によく知った上で、設計の議論をする時に言葉を選んで発言し、何かしらの意思決定のあとにも賛成や反対した人と対話してフォローアップをする、と言うことが重要なのだと思う。

なぜ自分のビジネスアイデアが採用されないのか、OSS なら GitHub で pull request がマージされないのか/送ったパッチを受け取ってもらえないのか、デザインのモックアップが決定されずに時間ばかり過ぎていくのか、と言うようなことを経験したことがある人は本書を読んだ上で「コミュニケーション」の技術を向上させると良いと思います。

デザインの伝え方
Tom Greever
オライリージャパン
￥3,080

■ Asakusa.rb 第 423 回

久しぶりに神田の永和で開催だった。

https://asakusarb.esa.io/posts/846

前半はイギリスから輸入したという謎紅茶をみんなで眺めながらひたすら rdoc の pull request をレビューしては変更の開設をしてもらったりしつつ、後半は最近 rubygems/bundler チームからあった相談を紹介してみんなであーでもない、こーでもない、いやいやそこで Module の unload ですよ、というような話をしていた。