1.0UX TIMEShttps://uxdaystokyo.com/articles大本 あかねhttps://uxdaystokyo.com/articles/author/akaneohmoto/rich600338<blockquote class="wp-embedded-content" data-secret="DEbaRQEITr"><a href="https://uxdaystokyo.com/articles/installation-lean-ux/">ソフトウェア開発には「LEAN UX」の導入が必須だ</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://uxdaystokyo.com/articles/installation-lean-ux/embed/#?secret=DEbaRQEITr" width="600" height="338" title="“ソフトウェア開発には「LEAN UX」の導入が必須だ” — UX TIMES" data-secret="DEbaRQEITr" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://uxdaystokyo.com/articles/wp-includes/js/wp-embed.min.js </script> https://uxdaystokyo.com/articles/wp-content/uploads/2023/06/leanuxcanvas.png19441320LEAN UX 第3版のCanvasで作業工程の確認が可能に！ 2023年5月のUX読書会は、LEAN UXを取り上げました。その前回、2019年12月には第2版をテーマにした読書会を開催しており、今回が2回目の開催となりました。 #image_title この本は広範な内容をカバーしています。そこで、第3版では LEAN UX Canvas（キャンバス）の導入によって実践的なフローがより明確になり作業工程の確認が可能になりました。 ただ、この本を読んだだけでUX設計が完全にできるわけではなく、むしろUXの拡大を促すためのLEANの考え方を学ぶことができるでしょう。つまり、ペルソナやストーリーボードなどの基本的な知識がある前提として扱われています。 著者：ゴーセルフ氏（引用：Amazon） 著者のゴーセルフ氏は「Lean UXはマインドセットである」と述べている通り、この書籍にはマインドについて記載されています。私自身も実際にプロジェクトに関わる度にマインドの切り替えが必要だと感じることがよくあり、実践経験も深まって再度読むことで、より深く理解が深まりました。 ちなみに、ゴーセルフ氏には UX LONDON でお会いしました。とっても優しそうな方でした。ちょうど出版されたばかりの「Sense and Respond  」の書籍をプレゼントしていただきました。（嬉）今では、日本語でも「センス＆レスポンド」が出ているので読書会の題材にしたいです。 Lean UXの理解を深める LEAN UXの原則 １）「チームビルディング」に関する原則 ２）「チームや組織文化の指針」となる原則 ３）「プロセスの指針」となる原則 LEAN UXの原則には、上記の「チームビルディング、組織文化の指針、およびプロセスの指針」3つがあります。また、それぞれに重要なポイント（原則）が存在します。 1)「チームビルディング」に関するポイント（原則）部門横断的なチーム小規模で同一の場所にいるチーム自己充足的で、権限を持つチーム課題焦点型のチーム2)「チームや組織文化の指針」となるポイント（原則疑問から確信へ結果(アウトプット)ではなく、成果(アウトカム)を重視無駄を取り除く共通理解を生み出すユニコーン、エバンジェリストやヒーローは不要失敗を許容する3)「プロセスの指針」となるポイント（原則）バッチサイズを小さくしてリスクを減らす継続的に発見するGOOB 新たなユーザー中心思考を用いる仕事を外面化する分析よりも形にする中間生成物中心の仕事の進め方から脱却する 例えば、チームビルディングの原則では、課題焦点型チームのマインドセットを持つことが重要です。なぜなら、改善の意識を持たない組織では何も進展しない可能性があるからです。 また、組織文化の指針では、ヒーローは必要ないとされています。一部のスーパースターに任せることで問題が解決すると考えるマインドセットは、LEAN UXの理念には合いません。 さらに、プロセスの指針では、GOOB（Getting Out Of The Building）新たなユーザー中心思考を用いるという原則があります。これは、ユーザーの声を早い段階で聞き、アイディアの有効性を判断する重要性を示しています。ユーザーを無視したままテストを行っても意味がありません。常にユーザー視点に立ち返ることが重要です。 LEAN UXは、無駄なく開発するためのテストマインドセット LEAN UXの基盤・UX・アジャイル開発・リーンスタートアップ LEANは、その名前通り、無駄を削減する思考方法です。そして、UXを組み込むためには、3つの「UX」「アジャイル開発」「リーンスタートアップ」の手法を用いることが重要とされています。これらがLEAN UXの基盤となります。 では、無駄とは具体的に何を指すのでしょうか？ 現場では問題を提起し、解決策を考え、提供するはずですが、どの部分が無駄になってしまっているのでしょうか？具体的に考えてみましょう。 よくあることとして、問題の本質を見極められず、間違った解決策を作ってしまうことが挙げられます。この点で、ユーザーリサーチは非常に重要な要素となります。また、リサーチ結果をどのように分析し、問題として捉えるかも重要です。もしも問題提起が間違っている場合、作り上げたものが全くの無駄になってしまいます。 さらに、よくあることとして、ソリューション志向で考えてしまったり、リサーチや分析を省略して直ちにソリューションを考えてしまったりすることがあります。初めてのアイデアが必ずしも悪いわけではありませんが、即座に思いつくアイデアは既に市場に存在していることが多く、注意が必要です。 また、開発現場によってはウォーターフォール型のプランニングと実行スタイルが残っています。ウォーターフォール型では、プランを立てることでゴールが設定されますが、そのゴールがなぜその時期に設定されるのか、その根拠がしばしば不明瞭です。願望に基づいてゴールを仮設定しているケースが多いです。 もちろん、ゴール設定は重要ですが、自身の開発能力を考慮し、マーケット（ユーザー）に合ったプロダクトかどうかをテストし、アジャイル開発によるソフトウェア開発が重要です。ゴール設定は必要ですが、柔軟に変更可能なゴールを定め、市場のフィードバックに基づいて進化させていくことが大切です。 よくある問題問題提起がきちんとできていない→　違うものができてしまいます。（結果無駄）ソリューションから物事を考えてしまう→　違うものができてしまいます。（結果無駄）仮想のゴールを設定→　予測ができずバグやエラーがあると後手にまわってしまう。 これらの問題を最小限に小さくする方法が、LEANです。ですので、私は、”LEAN UXは、無駄なく開発するためのテストマインドセット”であると考えています。 マイナンバーカード問題はLEANができていない組織問題である 引用：【解説】「マイナンバーカード」トラブル続出　“人為的ミス”や“システムに問題”…　個人での対策も 最近、マイナンバーカードに関連する問題がニュースで取り上げられています。例えば、同姓同名の別人のデータが混ざっていたり、自分のマイナンバーカードの顔写真が別の人のものになっていたり、赤ちゃんのカードの登録情報が親のものになっていて、助成金などが名義不一致で受け取れないという問題があります。 河野太郎デジタル大臣はテレビ番組「モーニングショー」に出演し、「人の手を介しているためミスが生じる（人的ミスの多少は仕方がない）」と話されていました。私も同感です。ただ、私が問題と感じるのは、テストが欠如しているということです。 全国規模で一斉に導入したため、エラーの数が当然増えてしまいました。なぜ、地域を限定するなどのソフトローンチを行わなかったのでしょうか。それは、アジャイルなマインドが欠けていたからと言えます。 その証拠に、大臣は番組で「2024年秋に健康保険証との1本化」をゴールに掲げていると述べています。しかし、来年秋までの期限の根拠は番組上では明確にされておらず、全国一斉に導入している行動からもアジャイルなマインドが欠如していると考えられます。 他の報道では、「急ぎすぎているのでは？」という声もあります。もしテストをしっかりと行い、慎重に進めていれば、このような批判も少なくなったでしょう。 実際に、書籍でも、「計画に従うことよりも変化に対応すること」が重要であると述べられています。 デジタル庁の発足から、新しいことに積極的に取り組んでいる姿勢は素晴らしく応援したいと思っていますが、LEAN・スクラム（アジャイル）などの海外からの本当の学びを正しく得られていないのではないか？と疑ってしまいます。 まずは、自分たちがアジャイル開発の組織にマインドシフトする必要があるのだと考えています。それが、日本で流行っているDXに繋がるのです。 小さいこと（書籍の例）から実施しよう 書籍では、小さいことをテストする方法としていくつか紹介しています。 例えば、ランディングページやクラウドファンディングでもユーザーの反応を見ることができたり、実際に開発する前にその機能を紹介し、クリック数が多ければ、実際に開発に取り掛かるなど、すぐにできるテストを仕込むことができます。 組織内では、すぐに完璧マインドやできないことを探すマインドの方もいると思いますが、冒頭でも説明したように、課題に焦点を置いて解決マインドにシフトしなければなりません。 LPでユーザーの動きをテストする開発前に機能の必要性をテストする 読書会に参加された方の中には、「社内でLEAN UXの輪読会で知識を得ていたけれど、大きな組織で、なかなか実現まで落とし込むことができなかった。」とおっしゃられていました。 しかし、読書会に参加することで、「実際にやってみようと思いました。」と、マインドチェンジした言葉をいただいたので、一人で読んで得た以上のものを得られたのだと感じています。（事実、6月の読書会にもお申し込みいただいています。）ぜひ、マインドシフトするためにも読書会に参加して気づきを得ていただければうれしいです。