「プロダクトリサーチルールズ」バイアスをなくしユーザーを知る
アドカレ9日目。
プロダクトを考えているとき、いかに自分たちがバイアスに塗れていて本当のユーザー像を見れていないかを感じることのできる一冊。特に、輪読会のようにして実際のプロダクトについても話しながら読むと「それバイアスですよね」という言葉が飛び交うとても面白い場になります。
その辺の話はこちらにもちらっと書いてあるので是非 zenn.dev
いかにして、バイアスを取り払うかからインタビューの質問の仕方・分析方法まで丸っと書かれた一冊。
お気に入り箇所
目的とするのは、ユーザーから学ぶことだけです。ユーザーの良い体験と悪い体験、~中略~ 立ち止まって話を聞き、ユーザーに自分の言葉で語ってもらいます。
目的をユーザーから学ぶに限定しているのがとても良い。ユーザーに話を聞くことで、新しい知見を得られることは先日の「正しいものを正しくつくる」でもありましたが、対話をするときに目的を「学ぶ」に限定するのはとても良いことだと思っています。
そうでないと、ユーザーからいい声を聞こう・改善点を教わろうとバイアスや誘導がでてしまいユーザーの自然な声を聞けず正しく学ぶことができなくなるからですね。
2章は全体的に面白く、様々なバイアスの起こす悪影響といかにしてバイアスを自覚するかが書かれています。
参加者が散走してくれたのは、あなたを喜ばせるためではありませんか？参加者の反応や行動が本物である証拠はありますか？参加者の行動に影響を与えるものはありませんか？
バイアスとは私たちインタビューする側が持つものだけではありません。インタビューを受ける人も持ちます。そのため、インタビューする人が「最近リリースされた〇〇を使っていますが、使い心地はいかがですか？」と聞くと善良なユーザーは「とても使いやすいです」とあなたを喜ばせるために温かい言葉を投げかけてくれるでしょう。
そのために、インタビューを受ける側のバイアスも配慮してどのような問いをデザインするかが重要なポイントにもなってきます。
ユーザーがいる場所に行く
プロダクトが実際に使われている様子が見られるだけでなく、ユーザーがどのような環境でプロダクトが使われているのかがわかるようになる。
例えば、プロダクトを使っており場所が電波が悪いところかもしれない・充電がし辛いところかもしれない。オフィスで働く人々とは根本的に違うところで働いている人がとにかく多い。そのような根本的なバイアスを排除し、その世界の中ではどんな価値が重要視されるかという問いを考えるかはとても重要になる。
思考の描画
家事の分担や組織図などから意思決定に至るまでなんでも絵にしてもらうというインタビュー手法。
絵に描くことでどこから描き始めたかという形で、思考の順番もわかるというのは斬新。UXを設計するときに、ユーザーの思考の順番通りに操作できることはとても重要になってくる。他にも、想像していない繋がりが描かれたりと様々な発見ができる。
絵が下手でも正確でなくてもいいと示す必要はあるので、あえて下手な絵を描いてアイスブレイクをしてから始めるのとセットで使うといい。
離れたところで作られたインサイトや推奨事項の背景を理解することは不可能です。
リサーチを外部に委託したり、完全に別のチームに切り分けることのデメリット。分析は行われているが、現場は理解できず、結局最も重要なユーザーの経験・ニーズ・行動の理解が現場に反映されなくなる。
象牙の塔の分析とも呼ばれるが、これは結構多い印象がある。なぜその分析をしたのか・分析の方法などは即座に共有して行われるべきだ。モチベーションもそうだが、顧客のことを理解しないまま開発が行われる恐ろしさをもっと知った方がいい。
かといって、どうやって協力して分析をするかについては「みんなでアジャイル」の組織重量の第2原則を用いてチームのの中に分析者も入れ込んでしまうのが最適だろう。
これはインタビューの結果などをタグで分類することについての注意点である。そもそもタグの分類方法には、自由にタグを作るもの・事前にタグを作るものの2種類がある。自由にタグを作るのは想像の通りタグが増えまくり分析が困難になる。一方で、今回のように事前にタグをつけると、その事前のタグがバイアスとなりインサイトの発見を阻害する要因となる。
こうなってくると、そもそもタグづけは必要なのか？という気がする。個人的にはタグはあってもいいもの分析の中心にあるべきではないと思っている。「ユーザーの層によって、どのようなタグが集まるか」というようなユーザー中心でありつつタグを利用する形の方が、意外なインサイトが得られるだろう。
ペルソナはプロダクトチームが共感できるように、一人のユーザーを一般化したものではありません。ターゲットユーザー全体を表現するために作られた架空のキャラクターでもありません。ペルソナは、本章で説明するすべての手法と同様に、リサーチデータに基づく必要があります。
ペルソナは、本章で説明するすべての手法と同様に、リサーチデータに基づく必要があります。というのはかなり厳しく「こういう趣味だろう」というふうに「だろう」という憶測で属性を追加することさえ、禁止している。
私はその道のプロではないが、ペルソナというと「こういう人に使ってほしいよね」や「こういう人も作っておこう」と憶測と想像で作られていることが多いようなイメージがある。それに対して真っ向から否定しているのはとても面白い。
ペルソナとは、リサーチやインタビューを通して非常に理解した個人なのだ。
「みんなでアジャイル」組織全体で顧客に向き合う
アドカレ8日目。日程がずれている気がするけど気のせいです。
エンジニアが中心で行われがちなアジャイルを、以下にビジネスサイドなども巻き込んで行うかが書かれている本。全人類読んでほしい。
お気に入り箇所
アジャイルを言い換える
昨日の書籍でもあったが、アジャイルはエンジニアが推進することも多いうえアジャイル自体に専門用語が多い。それらの「わからないもの」が組み合わさることへの拒否反応というのは計り知れない。そういった言葉を、わかりやすい言葉にすることで拒否反応を減らすこともできる。
なにより、アジャイルプラクティスを単純に適用するのではなく自分達の組織に反映させるにはという視点を持ち、十分に咀嚼して反映することができる。
顧客中心主義を実現することで ~中略~ プロダクトエンジニアチームを超えてアジャイルを拡張できる共通言語を作り出す。
顧客の使う言葉を共通言語にするのはドメイン駆動などでも出てくることなので、共通言語を作り出すのは一石二鳥。また、「顧客との対話が最も学習効率が高い」という本書でのプラクティスを実践しやすくもなる一石三鳥の手法。
ただ、業界によってはユーザーによって使う言葉が違ったりするのでそういった言葉の違いが何で生じているのかを考えることでユーザーの層を考えることにもつながっていくので「言葉」と意識するのはとても大切になってくる。
自分のチームやサイロの中で心地よい、一番簡単な仕事を優先する
これは組織論の話。組織重力の第二原則とも言われている。本書では、この法則を応用し、横断的チームを作ることで、分野が違ってもコミュニケーションを増やすという手法を提案している。
チームかしていなくても話しやすい飲み会マンにチャットが集中するという悲しいことがあったりする。そういう意味でも明確に「チーム」というものを作ってあげるのがいいのだろう。
事件の起こる部屋
事件の起こる部屋の要件がこちら
- 人数は10人以下にする
- 何を決めるか決める
- タイムボックスを意識する
- 参加者への期待を明確にする
- 会議と呼ばない
- 同じ場所にいることと同期して行ないことを区別する
本書では事件の起こる部屋と書いているが、「何かが決まる部屋」という方があっているのでは？という気がする。そう、何か意思決定をする時のMTGの条件がこれです。
個人的に好きなところが「会議と呼ばない」こと、単純に「会議」という言葉が便利すぎて議論をする場も意思決定をする場も全て「会議」とまとめられてしまう。
困ったことに、議論をする場と意思決定をする場ではMTGに向けての準備や覚悟が変わってくる。急に「意思決定します」と言われても「いや、下調べ十分じゃないけど...」となる人が出てくるのは目に見えている。
MTGを設定するときは「〇〇を決める」みたいなわかりやすい名前でMTGを入れよう。
あと、改めて見たけど人数は10人というのはちょっと多いんじゃないかという気がする。この本の発刊が2018年とオフラインでの仕事が中心だったというのはあるのかもしれないが、今は5,6人くらいがちょうどいい気がしている。
デイリースタンドアップの使い方
なんのためにデイリースタンドアップをやるのかの目的意識の共有。振り返りやアップデートの時間。特にデイリースタンドアップ自体をアップデートしていく。
アジャイル自体が経験知と改善の繰り返しなので、デイリースタンドアップはその練習をする場というイメージを受けた。改善するというのは意外と難しく、慣れが必要な所がある。そういう意味でも、毎日行いかつ短時間で失敗しても影響の少ないデイリースタンドアップで改善慣れをしていくのはとても合理的。
常に仮説を立てる
仮説を立てるとは考えようという話だけではなく、結果を比較し自分の中のバイアスに気づくための方法。バイアスに気づくのは本当に難しいので、様々な方法でバイアスに気づくきっかけを準備する必要がある。
また、仮説では「定量的・簡単なもの」より「ビジネスと顧客に最も必要な質問を始めよう」とされている。定量的や簡単なものだと目先の数字などで本質を見逃すためだと思われるので、この辺りはチームの強さ次第で切り替えていいと思う
継続的にプロダクトやチームを改善していくには、継続的に「自分の問題を告白し、対応する必要がある」
この辺の感情労働のコストを減らすためにも、心理的安全性が重要になってくる。組織重力の第二原則をうまく使うこともありだろうなー
ベロシティで重要なのは市場でのベロシティ
アウトプットよりもアウトカムという言説に近い気がする。消化したストーリーポイントとカウントされがちだが、それだけだとエンジニアの中で終わってしまう。みんなでアジャイルをするためには、実際に顧客に価値を提供しFBを得て改善するという動きを早くする必要がある。
そのために、会社内のベロシティではなく、市場に対して顧客に対してのベロシティが重要になってくるという話なんだろうな。
ただ、これを行うためにはストーリーバックログや優先順位もアウトカムベースで考える必要があるなどエンジニアも顧客中心主義を持つ必要がかなりある。
「正しいものを正しく作る」不確実性に向き合うとはわからないを増やすこと
アドカレ7日目〜
現在のプロジェクトが複雑化している世界で、分かるものを正しく作り・わからないを健康的に増やしていく方法を以て不確実性に対応する方法論やアジャイルの必要性が問われている本。
お気に入り箇所
今私たちが作ろうとしているプロダクトとは、「どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく」 ~中略~ 何となく以前作ったプロダクトにイメージが似ているから同じような機能をリストしておこう、インターフェースも他のよく似たアプリから拝借してこよう。
「仕立てていく」という言葉遣いがとてもしっくりくる。
「目的に合った状態に作り上げる」と「そうでないものを、それらしく作り上げる。」の両方の意味が混在しているのが面白いところだと思う。 「仕立てる」の意味や使い方 わかりやすく解説 Weblio辞書
特に、後者については引用の後者とも紐づくところがある。かくいう私もやってしまうことがある。ユーザーの利用環境が違うのに、過去の似たような機能のインターフェースを使うなどだ。そういう状態は、本来使われるべきでないインターフェースを、機能を作るという目的のためにそれらしく使っているに過ぎなかったのだと痛感させられる。
本当にユーザーが望むものは何かを考えて、1機能ずつ十分に考えて仕立て上げることが必要なんだなと感じる。
特に本書でも取り上げられているが「どうあるべきか本当のところは誰にもわからない」が故に、どのような機能があり・どのようなインターフェースをイメージしているかは各々で異なってくる。そこで、細かな違いや認識のずれをいかに速くキャッチする開発フローを組めるかも現在の開発には必要だと最近はヒシヒシと思っている。
アジャイル開発とは、ユーザーにプロダクトを「価値があるものなのか」「必要な機能は何なのか」「どういう形であれば使えるのか」試してもらいながら開発を進められる、というものだ。
この書籍でのアジャイルについての説明。印象としてはデザイン思考に通ずるところもありつつ、開発だけでなく様々なメンバーを巻き込む必要性が記載されているのが好きポイント。
プロダクトバックログが途絶えている、死んでいるということは、プロダクトについての思索、施策、試作が止まっているということだ。
「しさく」の3連コンボ好き。ではなく、プロダクトバックログが積まれていない時に何がボトルネックになっているのかを考える必要はありそう。 FBが適切に得られていない・FBの期間が短い・FBを得られるだけのリリースができていない・そもそもプロダクトオーナーが何らかの理由で機能していないなど様々な要因が考えられる。
エンジニアからアプローチするならば開発生産性をいかに上げるかというところに落ち着きそうだが、FBをどのように吸収するかも監視ツールなどを用いることで異なる知見を提供することができる気がするので面白い情報(特定の時期や時間による機能のスパイクなど)を探す余裕は持っていきたい。
「このチームはやれる」という期待が必要だ。その期待は、小さくともチームの上げた最初の成果にもとづく。小さな結果から関係の質を上げ始めるのだ。
アジャイルを実行する方法などが書かれている章に登場する一文。成功循環モデルをより回すための方法とされている。
成功循環モデルというものをここで初めて知った。振り返ってみると、とても実感する。同じメンバーで１､2年開発すると当然ながら「関係の質」が向上してくる。そうなると「思考」を話しやすくなり、改善の「行動」につながりやすくなる。もちろん「行動」をすれば「結果」が伴う。それらがとても速く回っている経験をしたことがある。とても良い体験だった。
ただ、どこから始めるかというのがとても難しいと感じていた。関係から作り始めると、その関係を崩すまいと行動を制限する節が出てくる。それを考えると「結果」を求めることを重視するこの方法はとても良いものだと感じる。
結果を意識し、結果を楽しむ関係を作るためにプロジェクトを始める時に、小さいタスクから始め成功を盛大に祝うというのは面白いし、ファシリテーションするときに使っていきたい。
エンジニアとプロダクトオーナーの2つの境界
「作る」と「作らない」の境界
アウトプットとアウトカムの境界
この辺はあるあるだと思う。お互いがいかに歩み寄るかが重要になってくる。ドメイン駆動などは、この境界の特にアウトプットとアウトカムを意識する時には重要になってきたりする。
一方で、作ると作らないの境界は非常に難しく、エンジニアがわかりやすく説明する力をつけるか・POがエンジニアについて理解や信頼を持つことの重要性が大切になる。言葉が通じなくとも「この人たちは全力でやっている」という信頼を勝ち取ることが重要になってきそう。
わからないものを増やすためには、自分の理解しているところから外へ出なければならない
よくコンフォートゾーンという言葉があるが、プロダクトにもそれに近しいものが存在している気がする。プロダクトは常に意外な使い道をする人がいる。そういうエッジケースだからこそ得られる知見は存在する。
また、この書籍では「わかったものを正しく作る」「わからないものをわかるようにする」というサイクルを重要視している。後者がかなり曲者で、わからないものを見つけるのは悪魔の証明に等しい。その方法として、自分の理解の外である特殊なユーザーや普段とは異なる層のユーザーを見ることで得られるものはプロダクトリサーチルールズ(多分来週くらいに紹介する本)にも記載されている。
「ドメイン駆動設計入門」を読んだ
アドカレ6日目〜
この2日設計の本を書いたので、DDDの本を書いていきます。
この本は入門書ということもあり、昨日の良いコード/悪いコードから学ぶ設計入門と被る点もありますが、DDDの要素と実際のコードを繋ぎ込むのにこの2冊はとてもいい本でした。
お気に入り箇所
ドメインモデルとして挙げられていなかった概念を値オブジェクトにすべきかどうかの判断基準として、筆者は「そこにルールが存在しているか」という点と「それ単体で取り扱いたいか」という点を重要視しています。
値オブジェクトについて、何を値オブジェクトにするかの一節です。
プリミティブ型で実装をしないためにも、値オブジェクトやエンティティとして扱うのがいいよねと個人的には思っています。で「そこにルールが存在しているか」については、ドキュメントとして残す価値があるか・コードを説明する時にコード以外にドキュメントや口伝での継承が必要になるかを基準にして考えるといいと思います。
実際本書でも後述でコードのドキュメント性について値オブジェクトの大切さが明言されていますしね。
値オブジェクトを定義するとそういったルールは値オブジェクトに記述され、コードがドキュメントとして機能し始めます。
続いて3章からエンティティについて
エンティティの性質は次のとおりです。・可変である・同じ属性であっても区別される・同一性により区別される
エンティティと値オブジェクトの違いは、可変/普遍・同一性か/等価性かになります。ということで、エンティティは後からデータの加工ができるものになります。
そのため、扱いは慎重にする必要がありライフサイクルが存在しない限り、できるだけ値オブジェクトにする方が安全だと私は考えています。
ドメイン駆動設計で取りざたされるサービスは大きく分けて 2つです。ひとつがドメインのためのサービスで、もうひとつがアプリケーションのためのサービスです。この 2つを混同することは混乱のもとです。その区分けをしっかりとするために前者をドメインサービスと呼び、後者をアプリケーションサービスと呼びます。
昨日の本でも、ドメインと技術は分けて考えた方がいいと記載されています。それを固有名詞で解説してくれています。
アプリケーションサービスは、アプリケーションを動作させるためのロジックでディスパッチャやDB周りのコネクション周りなどを指しています。
ドメインモデル貧血症という言葉いいですね。症例としては、値やエンティティオブジェクトに正しくドメイン知識が反映されずドキュメントとしての実装が行われていない状態のことを指します。
例えばこの連日の本で言われているgetterを使っており、ロジックが外部に漏れるや、ドメインオブジェクトには何でもロジックが書けてしまうためドメインオブジェクトが不要なコードでファットになることが挙げられます。
テストを行うための手間が積み重なると開発者は次第にテストに対して誠実でなくなっていきます。
リポジトリ層についての利点です。リポジトリ層は技術基盤を呼び出す層です。ドメイン→リポジトリ→技術基盤という依存関係にすることで技術基盤を変えた余波をドメインにまで及ばないようできます。
こうすることで、リポジトリをモックにすることでテストコードを簡単に実装できるようになります。また、テストコードではDBではなくメモリを使うことで、DBへのアクセスを減らしテストコードを速くすることもできて幸せになります。
依存関係はオブジェクトを利用するだけで発生するのです。重要なことは依存を避けることではなく、コントロールすることです。
「利用するだけで発生する」の怖いですね。ドメインオブジェクトを返すと、受け取った側は「ドメインオブジェクトが出来ることを出来てしまう」これは記述箇所を増やし、利用箇所を増やすことにつながるのでドメインオブジェクトの利用をいかに減らすかということが重要になってきます。
複雑な道具はその生成過程も複雑です。ともすれば生成過程がある種の知識となります。
ファクトリーパターンについての記述で、「生成を責務としたオブジェクトを作ろう」という話。ドメインが複雑であるならば、実装も複雑にならざるを得ないので責務を分けて個々の複雑性を分解していくのが重要ですね。
もっとも重要なことはドメインの本質に向き合うことです。技術的なパターンは絶対的な答えとして君臨するものではなく、ドメインの本質に向き合い、それをうまくコードで表現するためのサポート役として機能します。
時折批判はされている軽量DDDはパターンのみを反映させたものなので、ドメインという本質に向き合う必要があるので批判されているような感じですね。
ドメインの本質を見ることで何が変化しやすいか、何をオブジェクトにすべきかといった話ができるようになります。
「良いコード/悪いコードから学ぶ設計入門」悪いコードが生まれる原因を考える本
アドカレ5日目〜
昨日に引き続き設計本。今年のITエンジニア本大賞でも大賞になっていたので読んだ人も多い気がします。通称ミノ駆動本と呼ばれているのをみて笑いました。
内容としては、先日の現場で役立つシステム設計の原則より一歩、クラス設計の方向に近づいている書籍になります。また、実際に悪魔のコードが掲載されているため失敗をより肌で感じながら読めるのものこの本のいいところです。
お気に入り箇所
良いクラスの構成要素
データクラスの欠点の1つとして、設計に興味のない人がデータクラスの中からドメインを流出させ、同じ処理が複数で書かれることがあります。これは先日の本でも「getterで処理を書き出したら気をつけろ」と言われていましたね。
この本では、もう少し踏み込んでクラスの自己防衛責務や防御的プログラミングと呼ばれるような以下のことについて話しています。
- 「一度データクラスを作ったら値を変えられないようにする」すなわちsetterをなくす
- 間違いない値のみしか登録できず、値を書き換えられないようにすべき
この辺りの話は、texta.fmでt-wadaさんも語っているので興味のある人は是非聞いてみてください。
凝集度を高める
「クラス内における、データとロジックの関係性の強さを表す指標」を凝集度として話を進めます
本書ではクラスについて扱うため、粒度を「クラス」にすることで凝集度を上記のようにわかりやすく説明してくれています。
データオブジェクトにロジックを記載する。などは凝集度を高める手法の1つと言えます。
初期化ロジックがあちこちに分散して低凝集になってしまう場合があります。
これはインタンスを生成する時にconstructで値を挿入する際の値が異なる場合、ドメインが流出してしまうことを言っています。
例えば以下の場合です。
- 一般ユーザーは100ポイント付与する new UserPoint(100)
- プレミアユーザーは500ポイントを付与する new UserPoint(500)
これらの100や500は本来UserPoint内で決めてもいいものにも関わらず、インスタンス生成のロジックに流出しています。
そのため、UserPointのコンストラクタをプライベートにし、値の生成でのみ使えるstaticメソッドを使うことでロジックの流出を防ぐことができます。
このようにすると、「継承を使ってポイントをオーバーライドすればいいのでは？」と考えるでしょう。僕も考えました。
継承に絡む密結合
継承については非常に議論のあるところですね。実際Go言語など、継承の概念がない言語も存在します。ミノ駆動さんも、本書では継承は推奨しないというスタンスをとっています。
負わすべき責任を負わせず何でもやってあげてしまっている、過保護な毒親です。過保護な毒親のように責任を多重に負うクラスをつくると、ほかのクラスは未熟になります。
これは単一責任の原則を無視している親クラスへの言及です。こういった当時は意図していなくとも、「この方が楽だから」と毒親になってしまっているクラスを見たことありますよね？
これを避けるために、コンポジション構造にし依存性注入でインターフェースに依存する形にすることが良いと記されています。
名前重要
名前の重要性は前回の書籍でも語られていました。この本でも語られており、さまざまな臭いの見つけ方が示されています。
会話に登場する重要な概念が、ソースコード上で名前も付けられず、雑多なロジックの中に埋没していることが本当に頻繁に見受けられます。
これは雰囲気で実装が進むとよく起きるイメージがあります。しっかり会話をしていく中で、名前が見つかることも多いですし、ドメインに詳しいメンバーやユーザー(または普段ユーザーと話しているCSメンバー)と話すことでしっくりくる名前が見つかります。
「現場で役立つシステム設計の原則」リーダブルコードからDDDにつながる一冊
アドカレ4日目！3日坊主は避けた。えらい！
2,3年前に読んだ本ですが、設計やDDDのことを学んでいく上でとても良い本だったので紹介です。
内容としては、リーダブルコードとDDDを繋ぐような内容になっており、私もDDD本を読んで「抽象的な話が多くてわかんね」となっていたところから「これってDDD本で書いてたあれじゃん」という感じで読むことができました。
お気に入り箇所
設計の善し悪しは、ソフトウェアを変更する時にはっきりします。
「ただ設計をして、実装をして終わり！」ではなく、自分で設計したコードを継続的に変更してこそ、自分が良い設計をしていたかを気づけるという言葉として受け取りました。
今は、依存関係を小さくする・コードの分散を防ぐは当然として、変更を予測して実装をすることが設計の勘所だなーと感じています。
判断や処理のロジックをメソッドに独立させる
メソッドに独立させることで特定の式に名前をつけることができるようになって、名前重要がより捗らせることができます。
また、インターフェースの定義も行いやすくなり依存性注入もしやすくなります。この辺を「依存性逆転の原則」という言葉を使わずにうまく実装で表現しているのもこの本の好きなところです。
データを持つクラスからデータをgetして、そのデータを使って判断/加工/計算するロジックを書き始めたら、何か変だと考えましょう
データオブジェクトから値を取得することについての言及です。最初はgetして加工でもいいが、今後のそれらの処理をデータオブジェクトに移するなど設計改善をしていくかが、ソフトウェアの変更容易性を大きく左右するとも言われています。
最初のお気に入り箇所でも書きましたが、設計の善し悪しは変更する時にわかるもので、そのための違和感やコードの臭さを感じる1つの要素として実装・変更時には意識してみています。
業務知識を広げるほど、クラス名やメソッド名が業務を表現する用語集として育っていく
ドメインオブジェクトの導入における課題として、命名がとてもあると思っています。マニュアルの読み込みはもちろん、セールスやCSメンバーが製品や使い方の説明で使っている言葉を聞くと「その言葉使うんだ」という驚きがあったりします。
その時に、言葉同士の関係性を意識していくと「言葉は違うけれど同じものだった」ということや逆に「同じ単語だが違う意味を持っていた」と業務ロジックに一歩踏み込み先を見据えた実装がしやすくなります。
逆に、これらの言葉の差を吸収していないと話していた要件が微妙にアンジャッシュしていたということもあるので早いうちから認識を揃えて、部署を超えて同じ言葉を使えるとやりやすいですね。
画面に引きずられた設計はソフトウェアの変更を大変にする
画面ごとに実装をするのではなく共通のドメインは統一して呼び出すというのはよくある話ですが、画面が先に作られることで処理が画面に引きずられるというのもよくあります。
デザイナーがいない現場、デザイナーがいる現場の両方を体験したので改めてデザイナーの偉大さとデザインの持つ強さを感じているところではあります。
デザイナーがいない場合、オブジェクト指向UIなどを学習すると画面の方から改善していけるのでおすすめです。また、本書にも書かれていますが、「そもそも画面とドメインオブジェクトの関係がおかしい」という場合は、設計改善チャンス💡なのでガンガン違和感にアンテナをはりましょう。
1年の振り返りをしてきた with 小田原コーチングビレッジ
一人アドベントカレンダー3日目です
本日は本ではなく、12月2日にあった小田原コーチングビレッジさん主催の1年振り返りワークショップに参加してきたので感想や気づきを書いていきます。
小田原で2023年の振り返り会を行います！
— 小田原コーチングビレッジ (@odawara_coach) 2023年11月20日
📅日付:2023年12月2日(土)13時-17時
🏯場所:小田原
💰料金:1,000円(会場費、材料費含む)
1人での振り返り時間と、対話やワーク時間両方設けています☺️
ご都合合う方はぜひお越しください✨#小田原#小田原コーチングビレッジhttps://t.co/CYILIq6xx8
ワークショップの内容
個人ワークと対話を繰り返す形で行われました。
- 1年の天気予報の作成
- 対話
- この1年で「手放したもの」「投資したもの」「感謝したいもの」を考える
- 対話
- 1年のチャートの作成
- 対話
最終的にできたチャートがこんな感じ。
天気予報
2023年の各月を天気で表現する形で進んでいきました。
話した相手から「仕事の話が多いですね〜」と言われ「あれ、そういえば仕事以外何してたっけ。何で仕事のことしか書いてないんだろう」と自分が普段使っているバイアスを認識することができました。
この気づきが最初のワークであったおかげで、後半のワークで「仕事以外の自分」を考えながら進めることができたのは細かく対話が挟まれている良さだなーと感じました
この1年で「手放したもの」「投資したもの」「感謝したいもの」
この問いがとても秀逸で普段なら「得たもの」を考えがちですが、「手放したもの」とすることで私は自分がどれだけコンフォートゾーンから脱していたかという得たものとは異なる成長感や、なにを天秤にかけて・なにを優先したかという自分の中の価値観に気づくことができました。
終わってからの食事でも話題になっていましたが「手放したもの」という問いが、普段見ない側面から自信を振り返ることができる本当に面白い問いでした。
チャートの作成
ここまでのワークの総決算でがっつり時間が取られたところです。
チャートの作り方も自由だったので、意図的にGood、Badの2段構成の図で感情の変化全体を感じるようにし、仕事での出来事や私生活での出来事を分類していきました。
感想
全体を通して「対話」から得られる気づきが非常に多かったです。
1年の振り返りはやっていましたが、個人で行うことが多く人に話すなんてことはまったくやっていませんでした。ただ、人に話していると「こんなこともやってたな」と話している中で気づきが得られることも多かったです。何より、話した相手の質問から自分のバイアスを認識できたのも非常に良い体験でした。
開催とお声かけいただいた小田原コーチングビレッジの皆さんはもちろん、対話しやすい雰囲気を醸していた参加者のみなさん。ありがとうございました！
ちなみに会場も、窓から海も見える程オープンないいところでした。
