デザイン思考の共感とブランディングにおける共感

デザイン思考の最初のステップは、共感から始まる。
デザイン思考に限らず、共感を得る、というフレーズはブランディングの文脈でもよく聞くキーワードである。
二つの共感の差と関係について、考察。

考察

  • デザイン思考における共感は、ユーザーの感情や行動を知ることであり、必ずしも、感情的な共感を意味するわけではない。
  • ユーザーが何に好意を持っているのか、プロダクトを選択するまでにどのようなストーリーを経るのかを知ることが共感で、製作者がユーザーに共感するという意味である。
  • 一方、ブランディングにおいては、ユーザーがブランドに共感を持ってもらえるような、企業としての取り組みのことを指す。
  • 製作者は、ブランドをどう見てほしいか、を定義したうえで、ユーザーにそのイメージを喚起してもらえるように、体験を改善していく取り組みを行う。
  • ブランディングはユーザーが企業に共感する、という意味である。
  • 言葉の意味や経緯は若干異なるかもしれないが、ユーザーが共感してくれるストーリーを知る(デザイン思考)ことは、ブランディングにおいても、ユーザーがイメージを喚起してくれるストーリーを作るうえで、大事なことであると思われる。
  • ブランディングを得ることは、リピーターの獲得や価格プレミアムの効果などの効果が期待できる。なぜ、デザイン思考なのか、なぜ、共感なのか、と問われた時の一つのヒントになるのではないか。

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

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

概要

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

共感

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

問題定義

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

創造

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

プロトタイプ

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

テスト

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

読書記録:不思議の国のアリス

概要

タイトル:不思議の国のアリス
作者:ルイス・キャロル

言わずと知れた、児童文学の名作。子供のころにももちろん読んだことはある。
本屋でふと目に付いたので、大人になった今読むとどう感じるか、と思い手に取ってみる。

感想

世界中で読まれている名作だが、改めて読んでみると、なぜ、世界中で読まれるほどの魅力があったのだろうか?と思わされた。
話の筋はほとんどないようなものだし、文体の面白さも原文で読むならともかく、翻訳された文章では、どうしても違和感の残る文章で、言葉の面白さにも触れやすいとは言えない。
作品の外の話では、作者のスキャンダラスな人生が死後、話題になったことや、ディズニーの影響などが大きいと思うが、作品の中に絞って考えてみる。

個人的に感じた本作の魅力は、作品の空白の大きさではないか。
この作品において、登場人物たちの心情はほとんど描かれることがなく、セリフや起こる出来事も前後の流れが唐突で、理由を理解できる出来事がない。
何をしているのかよく分からない、しかし、登場するキャラクターの見た目もセリフもインパクトがある。
子供心に、また大人であっても、このキャラクターは何を考えているのか?どうして、そんなことをするのか?とまさに読んでいる読者が不思議の連続を体験する。

強引と言ってもいい疑問の喚起は、これを読んだ創作者にとって、多くのインスピレーションを得られる機会になる。
そして、創作者の中に取り込まれたインスピレーションは、時にはパロディー、モチーフとなって、創造者の作る新しい創作物に取り込まれていったのではないか。
実際に、この作品は多くの創作物でパロディー、モチーフとして扱われている。
そうやって描かれていくことで、人から人へ、創作物から別の創作物へと形を変えて、多くの創作の源泉になったことが、世界中で愛される理由の一つだろうか。

その始まりは、作者が知人の少女に語り聞かせた物語であったという。幼い少女がなぜ、どうして、と何回も尋ねてくる中、ルイス・キャロルは物語を創っていったのではないかと想像できる。
そして、娘に与えたインスピレーションは、多くの子供と大人にとっても多大なインスピレーションを与えられ、また、自分にとってもなぜ?と無邪気に考えられる魅力の詰まった物語だったと思える。

リーン、アジャイル、デザイン思考の違い

よく開発現場で聞くリーン、アジャイル、デザイン思考の違いについて、自分なりに整理した。

リーンについて

成り立ち

もともとはトヨタの効率的な生産方法について、マサチューセッツ工科大学で研究された手法を「リーン開発方式」などと呼んでいた。
そこから派生して生まれたのが、「リーン・スタートアップ」。
「リーン」というと、最近は「リーン・スタートアップ」のことを指すことが(おそらく)多い。

特徴

簡単に言うと、製品を世の中に出す時、必要最低限の機能を持った、ミニマムな製品として、世の中に出し、ユーザーの声を聞きながら改良しておこう、というもの。
仮説検証を行っていく中で、時には、戦略を転換(ピボット)してでも、ビジョンを達成するための製品を出していく、ということをしたりする。

「リーン・スタートアップ」と名前がつくとおり、新製品を世の中に出す時の目的の達成のさせ方に対する手法を整理したもの。

アジャイルについて

成り立ち

2001年に宣言された「アジャイルソフトウェア開発手法宣言」が元になっていると言われている。(言葉としては。概念はそれ以前から、存在していた。)
ソフトウェアの開発のコンセプトについて提唱されたもので、手法そのものとは違うらしい。(手法は、「スクラム」など)

特徴

計画をきっちりと立てて、計画通りに進めていくウォーターフォール型とは対照的に、週単位などで、設計~リリースまでのサイクルを回していき、環境の要件を取り入れながら、開発を進めていく。
変化に対しては強いが、最終的に作られるものが、ずれていってしまう可能性もある。

デザイン思考について

成り立ち

他2件とは、毛色が違うが、その名前の通り、優秀なデザイナーがクライアントの要望に応えるためのデザインのフローを体系化したもの。
デザイナーが出発点にはあるが、通常の課題解決を行うフローにも適応できるために世の中に広まっていった。

特徴

上記の通り、ユーザーの課題解決を行いたいとき、ユーザーが何を求めているか、どういうものが提供されるとうれしいか、ということを徹底的に詰めていく。
フローの最初に「共感」というフェーズがあることが特徴で、ユーザーインタビューなどを通して、ユーザーがなぜ、ある製品を使うのか、どういう感情の動きがあるのか、といったストーリーを作成し、自分のプロダクトに落とし込んでいく。

読書記録:外資系コンサルの知的生産術

kindle unlimitedで読了。

タイトル:外資系コンサルの知的生産術 プロだけが知る99の心得
著者:山口 周

サマリ

論理思考やフレームワークを学んでも、仕事がうまくいかないのはなぜ?劇的に成果が上がる、本当に使える「知的生産の技術」=「行動の技術」。

Amazonの「内容」より抜粋

知的生産を行うものが意識するべきことは何か?について、著者の考えを99の項目に分けて、解説している。
上記にもある通り、フレームワークのような一般的な話ではなく、著者独自の見解や手法が多数含まれているのが、他のビジネス本とは異なる。

感想

こういったマインドセットに使えそうな本は時々読むようにしている。
本の内容を実践してみる、というよりも、自分の行動や考えを振り返るきっかけに出来ると思っている。
この本は、先述の通り、一般論としてのフレームワークや行動論ではなく、著者独自の心得が論理的に分かりやすく書かれているため、成否とは別に考え方の参考になった。
知的生産のプロセスやインプットに対する意識など、自分が常日頃、意識するべき項目の再確認をすることができたと思う。

海外ニュース:次世代に流行するAIは何か?

The Next Generation Of Artificial Intelligenceの要約。

次世代に流行するAIは何か?

記事によると以下の3点が注目らしい。

教師なし学習

現在も機械学習の1手法として、使われている学習手法。
データに対して、正解ラベルを付与する必要がある教師あり学習に比べて、正解ラベルが不要であるため、学習コストが少ない。
その分、現状、教師あり学習の方が主流であり、教師なし学習が適応できる範囲はそう多くない。

しかし、ラベルを付与する工数は思っている以上に多大であるため、教師なし学習によって、適応できる範囲が増えれば、それはブレイクスルーになるだろう、とのこと。
「その他全てのものからすべてを予測する」と言われているらしい。

連合学習

初耳だった。googleが2017年に提唱した概念とのこと。

文脈としては、大量に集まるデータのプライバシー保護の観点から考案された概念らしい。
AIを学習させるには、大量のデータが必要であるが、個人情報保護などの観点から、重要な情報にいつでも自由にアクセス出来るとは限らない。
そこで、集権的にデータの集まる一つのサーバー上で学習を行うのではなく、ユーザーが持つ端末(googleなので、この場合Androidを想定されているのだろうと思う)の中で、小さな学習を行い、夜間などに集約して大きなモデルとして再学習、再配布を行う、というもの。

この場合、個人情報を送信する必要はなく、端末との送受信はモデルのみになるため、プライバシー保護にもなるだろう、というもの。

Transformers

自然言語処理に関わっている人は、全員が知っているであろう、近年の自然言語処理のブレイクスルーとなった技術。
Attention機構という文章のどこに注目するべきか、というアルゴリズムをベースとすることで、計算の並列処理が可能になった。
それまでのRNNに比べ、計算効率がはるかに向上したため、自然言語処理では、それまでに使用できていた以上に巨大なデータセットで学習させたAIモデル(GPT-3やBERTなど)が登場してきている。

テストコードを書く理由の考察

テストコードをなぜ、書く必要があるのか、について考察。
深く考えずに、工数削減と思っていたが、それ以外のメリットの方が重要なのではないか。

そもそも、なぜテストコードは工数削減になると思ったのか?

テストは工数がかかるものである。
小さなサービスのうちはよいが、ある程度、機能が増えてくると、その一つ一つを手動で確認するのは、困難になる。そのため、テストコードを書いておけば、繰り返し実施するテストについては、毎回、手を動かす必要はなく、その点においては、確かに工数削減になっていると思う。

しかし、webの記事を読んでいても、テストコードを工数削減の文脈で語られていることは少ないと感じる。
なぜなら、テストコードは一度書けば終わり、というものではなく、プログラムの変化に伴い、運用していかなければならないものであり、その分の工数は増えてしまうという側面がある。
テストコードを工数削減のために書く、という考えは、浅すぎるように思える。

なぜ、テストコードを書いたほうがいいのか?

テストコードは運用をしていくものであり、開発工数は増加する。
テストの手作業分の工数を差し引いて、総合的な工数が削減される、という理屈は、感覚的にも信じられない。
では、なぜ、テストコードを書くべきか?を考えたときに思いあたるのは以下の通り。

  • 再現性を持たせることで、必要な機能の動作を網羅的に担保することができる。
  • 開発者の意図を残せる。
  • ソースコードという組織としてのナレッジが溜まる。

特に後者二つについては、なかなか、効果を可視化はしにくいものの、思っている以上に効果のあるものではないかと思える。
0からサービスのプログラムを書く、という経験は珍しいのではないかと思われるが、誰かの書いたソースコードを引き継いで、開発を行うとき、機能のどのような動きが肝であるのか、を残すことはとても重要なことである。
どういう経緯で作られ、仕様・要件はこうで、というドキュメントは残されているだろうが、そういったドキュメントを更新し続けることは、現実的には難しいと思われる。
テストコードが特別、他のドキュメントよりも更新しやすいとは思わないが、開発者自身が行うタスク(テスト)とセットになっていることから、自分事になりやすいという側面はあるのではないか。

開発者目線では、ソースコードを読むことで理解できることは、大きなメリットがある。
テストコードを工数削減という目線で考えるよりも、組織的ナレッジを長期に渡って残すため、という目線で考えるほうが、正しいのではないかと思う。

TensorFlow Extendedのチュートリアルを動かしてみた所感

CI/CDとMLOpsにおけるCTの概念でCTのことを書いたが、肌感覚をつかめていなかった。
ので、目に付いたところから、TensorFlow Extendedのチュートリアル(リンク先:Colabで実行)を試してみた。
他ライブラリやプラットフォームとの比較はできないが、パイプラインについて思ったことなど。

所感

  • 結果の可視化は実際に目にしてみると、便利そうだなと感じた。
  • メタデータなどもどういう情報を格納しているのか、目にしてみると、機械学習の検証管理に使えそうだという感覚もあった。
  • コードは比較的簡単に見える。(細かくは読み込んでいないが)
  • 複数人で機械学習の検証を繰り返すようなプロジェクトの管理としてはよさそうなのかなと感じた。
  • 運用中のバッチ処理の自動化、可視化にも便利そうに感じた。
  • エラーや検証の理解は、可視化によって短縮できるように感じた。

チュートリアルなので、理解は浅いと思うが、今後の選択肢として、覚えておきたい。

CI/CDとMLOpsにおけるCTの概念

継続的インテグレーションの最初の一歩のために調べたこと、考えたことの情報からアップデート。
MLOpsの概念では、CI/CDの他に、CTの概念もあるらしい。

MLOpsとは?

CI/CDなどを含む、運用のしやすさを含めて開発を考える、というDevOpsに対して、MLOpsはMachine Learningのライフサイクルを円滑に進めるための概念。

機械学習にはデータを集める、加工する、アーキテクチャを作る、学習する、予測する、といった工程があり、煩雑になってしまう管理を考える必要がある。

CTとは?

Continuous Trainingの略で、継続的トレーニングのこと。
機械学習のモデル学習を継続的に改善していく運用を考える概念。

パイプライン化について

機械学習のプロセスをパイプライン化してくれるライブラリは色々ある。
少し見た限りでも、metaflow、airflow、Kerdo、luigi、など。
Tensorflow Extendedのようなプラットフォームも。

いまいち、パイプラインの利点がよく分かっていない。
処理を直列に並べることと、プログラムで順番に処理していくことと、読みやすさ以外に、何か違うのか?
メタデータによるバージョン管理だったり、可視化することで、どこの処理がどう終わったのか見やすい、といったところが利点、であるようには見える。
この辺りは、機械学習の運用をもう少し経験すると、肌感覚が分かるのかもしれない。

読書記録:技術とは何だろうか(マルティン・ハイデガー)

本情報

タイトル:技術とは何だろうか 三つの講演
著者:マルティン・ハイデガー
ハイデガーの三つの講演記録を翻訳されたもの。
過去にも翻訳はされているようだが、これは2019年の図書。

テーマ

そのタイトル通り、技術とは何か、という問いに対して、瓶の役割や建てること、住むこととは何か、という例示を元にハイデガーの哲学が述べられている。

感想

時々、近年の技術の進化に対して、疑問を抱くことがある。
この技術の進化は、だれが幸せになるものだろうか?
AIの台頭が様々な業種に革新をもたらす、と声高に叫ばれている一方で、技術の進歩に追いつけない人々は、仕事がなくなる、新しい知識を常に学び続けるように、と急き立てられている印象がある。
また、医療の進歩など、それによって救われる人がいるだろうと思う一方で、世の中が便利になっていくことで、一定の時間でこなす仕事量の水準が上がり、結果として、個人で見たときに幸せになっているのだろうか、と思うこともある。

本書の内容はかなり難しく、一読しただけでは、理解しきれたとは思わない。
ただ、上記の疑問に対しては、本書にある「総駆り立て体制」という言葉がしっくり来た。
現代の技術は、資源を徴用し、取り立てて、ある形として表象される、という行為が連鎖的に駆り立てられているという。
それも、人が物を支配しているのではなく、人も駆り立てられる側として、連鎖の中に組み込まれているから、「総駆り立て体制」と命名されているらしい。
ここは、自分が共感できる論であったと思う。

最後の提言は、なかなか、理解できたと思えないが、ヘルダーリンの「だが、危機のあるところ、救いとなるものもまた育つ」という言葉が引用されており、技術の進歩という人類に対する脅威が含まれる中にも、(ヘルダーリンの言葉が正しいと仮定すれば、)救いが育っているはずだ、という論が語られていた。