デザイン思考における5つのステップ

少し古い資料だが、デザイン思考のステップについて、スタンフォード大学が整理した資料の翻訳を読んでみた。
ステップ自体は知っていたが、元の資料を読むのは初めて。
スタンフォード・デザイン・ガイド デザイン思考 5つのステップ

概要

元の資料を読むのが分かりやすいが、自分の中で流れを整理。
※資料の内容そのままではなく、自分の理解を含む。

共感

その名前の通り、ユーザーの感情に共感しよう、というもの。
共感が大事であることは、プロダクトを使うユーザーの目線になって考えることで、あるべきデザインが出来るから。
手法としては、観察、関わる、見て聞く、などユーザーと関りを持つことが大事。

問題定義

こちらも名前そのまま。
共感のステップで得られた洞察から、ユーザーの解決するべき問題を定義する。
解決するべき問題の領域を絞ることで、より良質な解決策を生み出す傾向にある。

創造

問題に対して解決策のアイデアを考え、整理していくステップ。
アイデアを絞る必要がはなく、この後のプロトタイプとテストによって、繰り返し試せる、アイデアを洗い出していく。

プロトタイプ

プロトタイプを創作する。
机上でいろいろ考えるよりも、実際に作って目で見たほうが圧倒的に情報が多い。
完璧なものを用意しなくても、早く作って失敗を繰り返すほうがよい。

テスト

ユーザーにプロトタイプを触ってもらい、フィードバックを受ける。
前述の通り、早く作って早く失敗したほうがよいので、創作⇒プロトタイプ⇒テストのステップを繰り返していくのがよい。

継続的インテグレーションの最初の一歩のために調べたこと、考えたこと

システムを作っていると、当然、バグが発生する。
これまで、プログラミング技術は重点的に勉強してきたが、実際のビジネスではプログラムをするだけではなく、バグをどの程度少なくするか、それをどのように運用するか、といった運用管理についても考えなくてはいけない。

継続的インテグレーションについて

CI/CDという言葉がある。
継続的インテグレーション、継続的デリバリーの略で、いかに効率的に運用管理を行うかといった手法や考え方のこと。
範囲は広範なため、詳細は書けないが、概念として、どういった範囲をカバーしているのか、を以下に記載する。

テスト自動化

そのまま、テストを自動化していくこと。
テストにもユニットテスト、インテグレーションテスト、UIテスト、など、細分化され、それぞれのテスト自動化の手法、ツールもいろいろある。
プログラムのバグの発見が目的。

インフラ構築

インフラの構築にもCI/CDの概念がある。
最近はIaC(Infrastructure as Code)というインフラの構築をコード化する概念が流行しているらしい。
インフラの構築は、手動で実施している部分が多くドキュメント管理が主流だったことから、職人技になりやすかったことから脱却を目指した。
コードで管理していくことで、ナレッジの蓄積にもなっていく。

自動デプロイ

テスト後、本番環境に向けて自動でビルドとデプロイをしてくれる仕組み。
あまり、それ以上のことは調べられていない。

自分ができることは?

CI/CDで調べてみると、たくさんの概念やツールが出てくる。
ツールは自動化を実行してくれるものであって、何を自動化するのか、については、事前に自分で検討する必要がある。
また、途中で仕様が変更になれば、自動化の内容にも見直しが必要になってくるので、自動化のツールや手法自体を運用管理していく必要がある。

自分が関わっているシステム制作については、そもそも、サービスがほとんど成熟していない、関係者も少人数、という立ち上げたばかりの状態なので、まだ、手動テストでも対応できる状態にある。
ツール導入やテストコードを書いていくのは工数の観点からすると、時期は今ではないと思う。
ただし、自動化=核となる機能で変更になりづらい、ということであると思うので、将来のために、どこが核になるのか?を、今のうちから明確化し、継続に困らない仕組みを想定し始めることは大事だと思った。