エンジニアのためのデザイン思考入門 を読んだ

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

会社の行き帰りにちまちま読んでいて、またまただいぶ時間がかかった。

デザイン思考ってなんぞやというところから、適当に買ってみたのだが結構面白い話が読めてよかった。東工大でのデザイン思考を実地で学ぶための授業、東工大生のみならず別大学の学生や企業もごちゃ混ぜのワークショップ。そこでの環境づくりや運営方法、ワークショップを進めていくための方法、実際に授業を受けた人のコラムなど、WhyからHow to、感想まで書かれてる。

ユーザーインタビューを通じて共感し、ユーザー自身が気がついてないニーズを見つけていく。繰り返しのプロトタイプ作りでフィードバックをもらい、煮詰めていくというところは割とソフトウェア開発でも聞く話であるので、そうよねとすんなり納得できた。環境づくりにしても、すぐに試せるような場所にしたり雑談できたりと大事にされていることである。

何より多様性やデザイン思考が根底となる文化が大事、共通言語を持つこと、チームメンバーへの信頼感があるようにしていかなければならない点などは、アジャイルやDevOpsなどでも共通する話であるなと思いながら読んでいた。*1実際に文中にアジャイルやソフトウェア開発でのプロセスに言及されているので、そういったものも参照されてるのだろう。

raydive.hatenablog.jp

raydive.hatenablog.jp

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DDDなんかでもユビキタス言語をドメインエキスパートとの共通言語としたり、Event Stormingで多数の視点からイベント・コマンドを洗い出すなどの話もあったりする。

raydive.hatenablog.jp

raydive.hatenablog.jp

こういうのはやはり問題解決のためになにをすべきかを考えていくと、自然と似通っていくのかな。

閑話休題

一方でデザイン思考のみだと、気づいてないニーズとはいえ、根っこの部分は他者に依存しているので全く新しい発想にまでたどり着くのが難しいのかなと感じた。*2コラムにてデザイン思考と合わせてクリティカルデザインという思考についても触れられており、新しい発想に繋がるように思える。

まあそんな感じで、話題の共通点を色々見つけることができて面白かったです。

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

*1:Effective Devopsまだ全部読みきれてない

*2:誰も思いつかない発想を自分が発想するという前提自体が間違ってるのかもしれないが