エンジニアリングマネージャーお悩み相談室
エンジニアリングマネージャーお悩み相談室という本を読んだ。
自分の中での学びとなった部分と感想を書く。
当書は5つのパートに分かれている。 マネジメントについてや、ピープルマネジメント、EMとしての成長という抽象度の高い問題についてといったテーマ。
一つ一つざっくりとではあるがまとめてみようと思う。
エンジニアリングマネジメントって難しい
目標
目標はチームのガードレールのような役割を持つ。 これまでどういったフローで開発や進め方をしてきたかを可視化することで、どのような問題が遷移してきたかを指標とすることができる。 その上で、可視化したものから仮説をもとに改善を試みる。
仮説には、Four Keysを用いることもある。 PRなども一つの指標になる。 ここで重要なのは、可視化した部分だけが指標となるものではないということ。 つまり、人とのコミュニケーションの中でその人がどのように感じているか、それがどのように仕事に影響しているのかから仮説を立てる必要がある。
[--- 所感 ---]
これは非常に重要なことだと思う。 数字からしか見えてこないものだけを指標にしてしまいがちだが、人との対話の中で何が起こっているのかの想像力を鍛える部分も重要に感じている。
例えば、五人チームでPRのマージ数が100件/月だったとして、半年後に同じ100件/月だったら何も変わっていないかというとそんな事はない。 五人のチームの中でもPRの数が著しく下がってる人がいるかもしれない。その理由が難しいタスクだったからという理由であれば、それをその人はどのように捉えているかにも着目したい。 難しいタスクを抱える精神的負担の度合いによってはデンジャーゾーンに入ってしまう可能性があるので注意が必要。（ちなみに自分はデンジャーゾーンの経験多数あり）
[---]
OODA
O: Observe
チームやメンバーの観察を行い記録していく。記録することで、今後の計測の分析として役に立たせる
O: Orient
観測のデータを分析して、うまく行ってる部分、ボトルネックの部分を掘り下げる。 次のアクションに繋げるための布石。
D: Decide
次のアクションを具体化し、優先順位をつける。 全てをやるのではなく、必要なものを見極めて行うことで得られるメリットと、逆に生じるデメリットを比べる必要がある。
A: Act
実際にアクションに移す。 そしてまた、その結果を観測の対象とする。 どこまでやって、どこでやめるかを決めておくと続けるかどうかの判断がつきやすい。 また、アクションの工程で問題が生じれば再度観察・状況判断へと戻すことも可能。
1on1の予定
自分がEMだとして、1on1の予定を入れる事に遠慮されてしまう立場を考える。 1on1の予定を入れることで自分の生産性を高められるのであれば、EMの立場からすれば入れて欲しいと思う。 そのために、EMとして慣れない業務の中だとしても、無理のない余白を空けておくことが重要。
メンバーの特性を見える化する
メンバーの特性や、個性を自分の見える範囲で書き出してみる。 誰かに見せるわけではなく、自分のために書く。 そうすることで、チームの中で強みを発揮できるような正確に由来するチームへの良い影響を強みとしてあげていくことができる。
逆に、弱みを強くしようとしないことも重要。 そうすると強みも弱まってしまう可能性があるので、弱みを仕組みでカバーできるようになることが重要。 弱みについては、ゼロにするための施策より、どこまでなら許容範囲として扱えるかという考え持つことが大事。
目標
期待という名の道標を示す。 半年後にどうなっているかという像を伝えること。 その中に、その人のwillがあるのであれば盛り込む。 しかし、willがない人に対しては
- キーワードリストから重要に感じる単語を選び、エピソードを振り返るようなことをする
- ムービング・モチベーターズ・ゲームやWevoxバリューズ・カードを活用し、価値観を可視化する
大事なのは、目標が決まらないから行動できないという袋小路に入らないこと。
最初の1歩目
そして、最初の一歩目を具体的な行動としてアクションを作ること。 技術スタックの刷新や、コードの品質向上などの大きな目標は大きく、すぐに着手できるものではないので、細かく小さくすることで着手しやすくし、来週までにできることといった粒度まで落とすことが大事。
提案の却下
提案を却下する際も、メンバーの意見を尊重するという意味でも、もしかしたら良い案があるという点でも、今ある障壁を伝えた上でどう解決するかを一緒に考えるということをしてみると、お互いに解決への考えを巡らした上で採用されるか、却下されるかになるため、ただ却下されるより納得感を持つことができる。
仕事は頼むものではなく、役割分担する
チームを前進させるために必要なタスクを、全員で手分けして進めるもの。 誰が何を得意とするのかを可視化した上で、それぞれが何をしていきたいかなどを加味して決めることでチームでの進め方をスムーズにすることができる。
[---所感---]
個人的にはかなりしっくり来る言葉だった。 基本的にチームで働く以上はチームの中での役割分担というのが大事になって来ると思うので、その中で誰が最適か、挑戦したい人はいるか、バックアップできる体制はできてるか、できてないなら認識をどこまで合わせて進めるべきか。などを検討した上で、どのようにプロジェクトに向き合うかを決めて行った方が良いだろう。
自分の中での考えが言語化されていて、スムーズに読み進めることができた。
[---]
古い機能の改修作業は新しいスキルなどを得にくいなどと捉えられる傾向があるが、その周辺の知識があればこその感想であり、メンバーの姿勢や工夫によって変わって来る。 目の前の仕事に追われるだけでなく、メンバーより長い軸で物事を捉え、今後の方針を練ることも大切な仕事になる。
メンバーにポジティブに仕事に打ち込んでもらうには、難しい理由や、なぜやるのか、タスクの意味、それによって得られる効果をまとめて伝えることも大事。
チームの向きを揃えるって難しい
どうやるかはメンバーの腕の見せ所
シャドーイングでサポート
任せた仕事に対して、自分だったらどう進めるかをある程度先回りして考えておき、相手が困ったときに具体的なアドバイスをすぐに提供できるようにしておく、というもの。 この時、メンバーが少し道を外したと感じても、すぐに軌道修正に介入しないこと。
相互ワークショップ
相互に理解するためのワークショップを実施する。 それは、自分の開示になる。いきなり開示としてもうまくできない人も多いので、ワークショップという形で行う。 そこでは、以下のようなことを話す。
- 得意な仕事、苦手な仕事
- 仕事の振られ方の好み
- 仕事のスタンス、大事にしている価値観
- ぶっちゃけ話(一緒に仕事をする上で、みんなに知っておいてもらいたいこと)
環境の変化による方向性
いくつかに分解してみる。
「既存のプロダクトをベースに、新しいセグメントへの売り方を模索する」 「全く異なるプロダクトのプロトタイプをいくつか 作って既存顧客の反応を見るつもりなのか」 「 それらは、どの段階で何を持って成功。もしくは失敗とみなすのか」
などのように策定し、暫定のゴールと、それを満たすための基準を可能な限り具体的に把握するようにする。 この指標自体も正解かは分からないが、自分たちはどんな役割を果たし、何を最優先に取り組むべきかが見えて来るはず。
他部署との連携も重要
新しいセグメントの開拓などを考える時、様々な部署、チームとの連携し、自分なりの仮説を持って、他の人がどんな視点で事業やプロダクトを見ているのか、すでに持っている仮説やアイデアは何かを尋ねていくことが大事。
他部署の知見を得る
プロダクト開発における進捗や成果を共有する会を開いたり、自分たちが他職種の勉強会に参加してみたりと、お互いが何を考え、何をしているのかを気軽に知る機会を作ってみる。 スプリントレビューを利用しても良い。
また、他部署のマネージャーと1on1をするのも良い。考えていること、悩んでいることの共有によって解決の糸口の示唆を得られるかもしれない。
スプリントの結果をこまめに可視化する
このスプリントで検証した仮説は何だったか 実装した機能や実験的要素は、どの程度まで動いたか スプリント中のやりとりで生じた新しい課題は何か チームやユーザーにとって有益だった点と、そうだなかった点はなにか
[---所感---]
これは、以前の職場ではあまりできていなかったなと反省している。 そもそも、仮説を立てるというところまでうまくいけてなかった気がする。 もしかしたらPdMとかは立てていたのかもしれないが、それを可視化として反省に活かすという点でいうとあまりできていなかったように思う。
自分がEMとなったら、そういった視点を持ち、仮説に対する可視化の方法も考えていかねばと思う。
[---]
また、失敗した場合でも、「 失敗したことや人を責めるのではなく、次のサイクルでどこを変えれば状況が改善するかを冷静に分析し、チームに事件として共有すること」を行うことが大事。
経営方針との認識合わせ
経営陣が、なぜこの判断をしたのか、その背景に何があるのかを尋ねてみる。 目標数値やKPIがあれば確認し、未確定な部分については仮説として扱う。 そうすることで、チームで掲げたユーザー中心の方針がほんの短い期間だけ後回しになるのか、それともどちらも捨てずに済む方法があるかなど、経営方針とチーム目標がどこで交差するのかが見えて来る。
また、経営陣からのオーダーをただの圧力と捉えたくなる気持ちをこらえて、今何が起きているのかを自分の言葉で説明できるまで情報を撮りにいくところから始めるのも良い。 具体的には、公開されてる議事録や資料を改めて読み直したり、冗長との対話や経営陣とのミーティングに同席してみたりして、「どうしてこの優先度が急に上がったのか」、「経営としてはどの段階で何を成功の指標とみなしているのか」などを尋ねてみるのが良い。 そこの知識をそのまま伝えるのではなく、自分の言葉で噛み砕いて伝えることをする。
[---所感---]
これは、自分もメンバーとしてすごく疑問に思う部分はあった。
なんでそれをするのか。なんでその編成に変えるのか。
何も説明のないまま進められることが多かった。 その時のモチベーションはやっぱり低く、チームとしてもやりたいことは多かった（リファクタリングとか）。 でも、それをやるという決定まで持っていく話ができなかったのと、できたとしてもその説得のための準備や言葉を考えることの労力に対して得られる確保された時間というののコスパが良くなかったりと、あまりモチベーションを維持して続けることができないことの一つであった。 そんな時、EMがいたらまた別の見方や結果になっていたのかなと思うと、やはりEMの存在は大きいと思う。
[---]
続行・撤退のラインを細かく引く
どこまで開発すれば、どのくらいの何の成果が見込めるかを大まかに合意しておく。
「1週間でプロトタイプを作り、見込み顧客の10社へデモを行う。その際に3社以上のポジティブな反応、かつ具体的に協業開始可能時期についての質問が得られたら…」のような具体的な数字を入れることで、どこで撤退し、どうすれば次の開発に進めるかの線引きの判断を容易にすることができる。
エンジニアリングの観点でいうと、「体験面、連携面の双方で、検証の材料となる最小限のプロトタイプを探るスキル」が求められる。 プロトタイプのコードとは全く別で作ることも考えられるし、一部必要な部分だけ既存アプリケーションに組み込むなども考えられる。
馴れ合いチームではなくお互いに期待されるチーム
仲良しのチームで、成果が出せていないチームは、雰囲気はいいが結果が出ないので、組織の中ではあまり良い目を向けられない。 しかし、成果は出していく必要がある。
これは何も雰囲気を壊して成果を求めろという訳ではなく、考え方を「求め合うチーム」へと移行させていく必要がある。 つまり、チームの中でも何が期待されていて、他の人には何を期待しているのかというのをお互いに持つ。 そうすることで、皆がオーナーシップを持つようになり、自立したチームへとなる。
背伸びを楽しむ
目標は高くするほど苦しい局面が訪れる。 それによりコンディションに影響が出ると、助けたくなるものだが、そこをメンバーの様子を観察して、どの程度までの負荷なら耐えられるかを把握することが必要になる。 しかし、それが常態化しないようにして期限を切り、目の前の仕事に集中できるような環境を整えることが大事。
以下のことを注意して行うと良い。 - リソースの空き具合や個々のスキルの棚卸しをし、今のチームならどこまで行けそうかを予測する - 自分も含めて、チームが「これなら少し大変だけど面白そう」と思えるラインを設定する - 成果に繋がりそうな要素にリソースを大きく取れるようにし、そうでない作業は可能な限り省略化する
ピープルマネジメントって難しい
共感することは同調することとは違う。 相手を肯定することだけでは同調となり、賛成しているふりをして寄り添おうとするようなもの。 逆に同調をすることで、不満を言っているメンバーと不満の先が別のメンバーなどの場合、対立構造を助長させかねない。
共感は、感情の一致のみだけではなく、その心情や経験を理解しようとするプロセスそのもののことを言う。 共感は分かち合うこと。 分かち合いとは相手が今どんな状態なのか、どんな状態になりたいかを頭と心でイメージし、それを共有すること。
事実と感情を切り分ける。 なぜその感情を抱くに至ったのか想像しながら質問する。
あるメンバーのリソースが足りなくて辛いといった相談をされた時に、それを自分基準と切り離して考えることが大事。 掘り下げるために、「直近でどんな場面で辛く感じたか」のように聞いてみるのが良い。 こうしてやりとりを通じて本人も自分が抱えている感情を改めて整理できたり、何に由来するものなのかを精緻に知ることができたりする。
こうしてメンバーの思考や気持ちを整理しようとしていると、うまく言葉にしてもらえないや、何が本当に問題なのかが見えてこないと言うタイミングが出てくる。 そこでよく使われる方法がカウンセリングで用いられるミラーリングやバックトラッキングと言うテクニック。 これは相手の発言に対して、自分がどう受け止めたのかをそのままあるいは少し言い換えながら、投げ返すことで、相手が抱いている思いをよりクリアに引き出す方法。
ミラーリングとは、相手のジェスチャーや表情真似し、親近感を与える心理効果のこと。 バックトラッキングは積極的傾聴の技法。 相手の発言内容をそのまま繰り返し予約しながら会話の流れを整える。
忘れてはいけないのは、 みんなが 納得するただ1つの答えを存在しないと言う事。 それぞれの辞書に対して、それぞれが持つ感想や考えと言うのは別々になる。 チームの目標においても、その通りで背伸びして頑張りたい人や余裕を持ってコツコツ仕上げたい人とでは基準値が異なる。 しかし、実際のところ、大半の子決定は、2択のうち、どちらかをいつでも明確に選択可能なわけではない。 スピードを優先するか、品質を守るかリスクを取るかなどなど。 そのためにも達成したい目標があって、メンバーそれぞれに思いも優先順位もある。それらを踏まえて結論を出すには、あなた自身があるいはチームでどこをゆずれないポイントと定義するのかが不可欠になる。 どんな優先順位なら、自分とチームにとってベストに近い判断になるかを決める軸。
最終的に、例えば満点の答えが出せなくとも、今のチームにはこれが最善と言う着地点を相手と合意できるかどうかと言うところを作るのがマネージャーであるあなたが目指すラインになる。
[---所感---]
これは、自分自身にも思い当たる節があり、 ある人と話すときに、その人が自分の言ったことをミラーリングしている部分が多くあることがあった。 確かに共感という意味では近いのだが、あまりにも繰り返しすぎると、ただのオウム返しになり 逆に話しづらくなると言う経験もある。
ある程度ミラーリングしても良いかもしれないが、あまりやりすぎると、何も考えずにオウム返しをしてるだけのように感じるので、 最低限自分の考えを少しでも取り入れたり、ただのお返しにならないようにすることを意識したい。
[---]
推論のはしご
ある事実を目にした時、 人が無意識に要素を取捨選択し、自分なりの解釈や仮説を積み上げることで、結論に至る過程をはしごに例えて示したモデル。 相手の話を聞き、その裏にある相手の感情をうまく理解できない場合に同情するのではなく、その人が今どんな立場でどんな気持ちや前提を持っているのかを想像しようとする姿勢を持つこと。 不満の裏にある感情をどう解釈したのかに結びつけて考える工程。 実際に起きたことの中で、事実から行動に移るときの過程の心理状況、つまり頭の中で起きたことを可視化することで、行動への道筋を立てることができる。
ネガティブなフィードバック
ネガティブなフィードバックを返す際の方法として、 ここでも推論のはしごを使うと良い。 例えば、「先日のチームミーティングの〇〇さんの提案をあなたはどう捉えているのか教えて欲しい」 のように聞くことで否定から入るような 配り方ではなく、しっかりと聞く姿勢を伝えることができる。
そうすることで、 相手の視点を聞く → 自分の受け止め方を伝える → 一緒に改善策を考えると言う流れを意識できる。
[---所感---]
ネガティブなフィードバックの言い方はかなり難しいと自分でも思っていて、 その例を出してくれるのはすごくありがたい。 これが1つの例でしかないが、今後そういったことに気をつけて言い方を考えていったり、繰り返すことでより自然にその表現で話すことができるようになるだろうと考えている。 普段から、この表現方法を気をつけるよう意識していきたい。
[---]
メンバーの希望とズレたアサインメントをする
このような状況下では、 希望を叶えられないことを相手に説得することを納得してもらうことをゴールにしないと言うことが大事になる。 直近は希望通りのセメントが来えないと言う事実はそのままにして、その結論に至るまでの過程、あるいはその先の数字をどのように一緒に考えるかがポイントになる。 とくべき課題を間違えないためにも初めにやるべき事はこれは何を満たすためのリクエストなのかリクエストが叶えられたとして、メンバーはどんな状態になりたいと考えているのかを一緒に考えていくこと が大事になる。
やることは、以下の3つに焦点を当てる。 1. 伝えてくれたことへの感謝と今の状況の事実を共有する 2. メンバーの思考を掘り下げる 3. 時間軸とゴールイメージをすり合わせる 4. 未来に向けた行動が、今の朝にはどう変えるかを考える
翻訳
リードエンジニアの人が難易度の高いタスクを半年かけて行った。評価に対してうまく上司に伝えることができずに、評価が1段階下げられたと言う状況に対してどのように対処すればよかったかといったことに対する問題の解決。 経営層が必ずしもエンジニアリングに詳しいわけではないので、そこに対して1から学んでもらうと言う事は現実的ではない。共通の価値観、すなわちビジネスの文脈に変換する必要がある。 生徒に評価されない理由は、主に3つある。 まず技術的な専門用語や概念を翻訳するスキルが不足している。 そして、ビジネス価値への接続が明確でないこと。 最後に、それら2つを裏付ける定量的なデータの不足。 これらの技術言語からビジネス言語へと変換する 習慣をつけ、数値化できる指標を探していくことから始めてみる。
より細かい評価の基準を作るには、メンバーの動きがメモに残すことが大事になる。 ある瞬間の点ではなく、日々の積み重ねで生まれる線で捉えるものと考えてみる。 忙しい業務の中ではなかなか難しいが、できるだけ継続することを意識する。 その中には、ポジティブ・ネガティブ・気になる点の3種類に分けて整理すると良い。 こういったものを取っておくと、次の1on1やちょっとした雑談 の時に本人に直接あの時の状況についてもうちょっと教えてもらえませんかなどと尋ねることができる。
そうは言ってもすべての活躍を把握することは容易ではない。そこで大切になるのがメンバー自身にも成果を記録してもらう仕組みを作ること。 月に1度などの頻度でメンバー自身に工夫したことを達成したこと、逆に思ったよりうまくいかなかったことなどをまとめてもらう機会を作る。
この習慣を根付かせるコツは、フォーマットをシンプルに保つこと、あらかじめ項目と入力例を提示しておく。
言語化の衰え
普段のコミュニケーションの中で周りのことを分かった気になりがちである。 しかし、以下のような質問にすぐに答えられるかと言われると難しいことに気づく。
- 現在の仕事に満足していますか？ その理由は？
- 現在の仕事をよりよくするために、自分やチームに必要なインプットやアクションはなんですか？
- あたなのプロダクトを利用する人はどのような人で、どの点に特に魅力を感じていますか？
こういった話をする時、見聞きした内容を答えるのは容易ではあるが、ここで自分の言葉を利用することが大事。 そうしないと、次第に自分の心の動きにも鈍感になってしまう。
その結果、以下のようなことになりうる。
- 気づいたら会社の状況が変わっていた
- 気づいたら今の仕事を楽しめなくなっていた
- どうしてこうなったんだろう…転職しよう
内省を行う機会を持つことが重要になる（それが顕著なのが特に転職活動の時などである） その時に自分の言葉で直すことで思い出すのでも良いが、どうせなら転職をする前に気づけるようになっておくと良い。
事業目線を持つって難しい
組織・事業領域
組織・事業のことまで視野を広げるには 以下のようなことを考えると良い。
- ユーザーに好評だった新機能は、ユーザーにどのような価値が届き、会社は対価として何を得たのか
- 今ある機能は運用面や機能面で今後どのようなリスクを抱えるか
- テクノロジーのトレンドから、プロダクトに今組み込んでおくべき機能
- 早めに検証しておくべき技術領域は存在するか
これらを自分一人ではなく、PdMなどと協力して情報を集めていくことが重要になる。
[---所感---]
これまでチームという領域までしか目を向けられていなかったので、いざ組織や事業領域まで目を向けろと言われた時に 何を指標に考えればいいか分からなかったので非常に参考になった。
しかし、考えれば考えるほど徐々にPdM寄りになっていくのを感じる。 本質的にはEMもPdMも近い存在となったり、兼業することにもなるのかもしれない。
それこそEMはコードベースでの理解や促進を図ることができるので1年、2年後くらいまでを想定して進めることはできるかもしれないが PdMはさらに5年、6年後を想像してロードマップを引いたりするかもしれない。
そういった長期目線でのスパンの違いがEMとPdMの違いなのかもしれないなと思った。
[---]
プロダクトのフェーズ
例えば、10年後の目標として経営陣からプロダクト数を10個に増やしたいなどの要望があった時 10年後にチームとしてどうなっていなきゃいけないかなどを考える必要がある。
売上は？ チームの数は？ メンバーの数は？ それらを計画に埋め込んでいき考える必要がある。 その時、それらのプロダクトの立ち位置などを上長や経営陣に確認しておくと良さそう。
例えば、プロダクト10個のうち、市場に出して3つまで絞り込んだ上でプロダクトの運用を考えるようにしていきたいという温度感であれば それに合った技術選定、アーキテクチャ、チーム数など、採用にかける考えも変わってくる。
プロダクトへの方向性と考えに合わせてチームを考えていかなければならない。
[---所感---]
これはあまり考えられてなかったことなので参考になった。
プロジェクトのあり方などの認識を理解する必要があるなと思った。 10プロダクトと言われたら、10プロダクト全てを運用にのせるという前提で考えてしまうので、その認識のズレはそれぞれのチームに対する期待値のズレにも影響するなと感じた。
例えば「今だけこのプロダクトも運用しながら、新規プロダクトの開発もやってもらいたい」などとチームへの期待値を調整することで、 チームへの負荷やモチベーションを保ちながらプロダクトを増やしていくという考えも出てくるし、納得もしてもらいやすくなるかもしれない。
[---]
EMのキャリアって難しい
EMになることによって技術力の低下を心配する人は多い。 しかし、一定の時間をかけて、キャッチアップすれば再び前線でパフォーマンスを出せると言う気持ちがあるのであれば、一旦はEMとしての知識や経験を優先すると言うことを心がけた方が良い。
逆に、これまでの経験を生かし、メンバーからの不安や意見を取り入れると言うことにたけているマネージャーとして活かすことができる。 そこで、半年を目安に キャッチアップできるようにある程度触れておくが、それ以外はマネジメントの海に取り込むと言うことに割り切ることが重要。
タイミングとしては、一度何かの分野でしっかりとプレイングをやりきったタイミングで移行するというのが良い。 そうすることで、戻る選択肢も残せる。
[---所感---]
自分もEMはテックリードの次、のようなイメージを持っている。 それは別に自分が そうあるべきと思っているわけではなく、周りもそのように考えていることも影響で、自分の考えに影響が及んでいる といった経緯である。
しかし、キャリアの最初からマネージャーと言う立ち位置で行う人もいるわけだ。 そういった人たちもそうだし、これからEMになると言う人も、自分の技術力に対して心配を持ちながらやっていくことになるかもしれない。 それは逆に言うと、技術を優先するものではないと言うものである。 もちろん技術はあれば良いのだが、結局その背景や経験をもとに新しい領域へと踏み進めるものなので、技術に固執してしまうと逆に良くない。 テックリードは逆にテクニカルなことについて優先順位が高い。そのため、技術に対する固執は大きいものではあるが、それが必須条件なのかと言うことについては、今も疑問が残る。
もちろん、テックリードを経験した方が経験豊富と言う意味では、生かせる 知識は豊富かもしれないが、それによって自分がやりたいEM層と言うものに少しでも早く触れていくことを先延ばしにする理由になって良いものなのかは難しい。
[---]
まとめ
僕自身はまだEMではなく、悩むというところまで行ってないのだが、事前に悩むだろうと思われることを知っておくことは無駄ではないと思う。
EMになるかならないかは定かではないが、こういった知識や考えないといけないことを知っておくだけでもこれからの仕事のやり方は変わってくると思うので 自分の「今」を変えるためにも、EMではなくとも、EMを目指していなくとも、読んだ方が良い一冊だと思えた。
EM関係の本は何冊か読んで、知識が浅いところであったり、不安に感じるだろうというところをポイント押さえて言及されていたのは非常に参考になったので、また1ヶ月後くらいに読み返しておきたいと思う。
Amazon Web Services 基礎からのネットワーク & サーバー構築
概要
Amazon.co.jp: Amazon Web Services基礎からのネットワーク＆サーバー構築改訂４版 : 大澤 文孝, 玉川 憲, 片山 暁雄, 今井 雄太: 本
普段Google Cloudを使っていますが、AWSも使っていきたいと思っていました。 そんなところに、友人から勧められた当書を手にすることにしました。 そもそもCloudでも各サービスとかは使っていたりするけど、一貫して環境を作るってことをやったことないなとなり、自分の中でモヤモヤしていた部分がありました。
当書はハンズオン形式で読み進めることができる本になっているので、実際にAWSに環境を構築しながらNotionにメモを取りながら作成していきました。
CHAPTER 1: システム構築をインフラから始めるには
インフラ構築の基礎となるクラウドアーキテクチャについて学びました。 特にAWSを使用したインフラ構築では、VPC（Virtual Private Cloud）を基盤として、パブリックサブネットとプライベートサブネットを適切に配置し、セキュアな環境を構築することの重要性を理解しました。 インフラ構築では、ネットワーク設計から始まり、サーバー構築、セキュリティ設定と段階的に進めていく必要があります。 この章では、後続の実践的な作業の前提となる基礎知識と全体像を把握することができます。
CHAPTER 2: ネットワークを構築する
AWSのVPCを使用してネットワークを構築する実践を行いました。 具体的には、VPCのCIDRブロック（10.0.0.0/16）を設定し、その中にパブリックサブネット（10.0.1.0/24）とプライベートサブネット（10.0.2.0/24）を作成しました。 また、インターネットゲートウェイを作成してVPCにアタッチし、ルートテーブルでの関連付けも行いました。これによって、インターネット通信が可能になります。 この過程で、AZの選択や可用性の考慮など、実践的なネットワーク設計の基礎を学ぶことができます。
CHAPTER 3: サーバーを構築する
EC2インスタンスを使用したサーバー構築の実践を行いました。 キーペアの作成、ネットワーク設定、セキュリティグループの設定など、基本的なサーバーセットアップの手順を学びました。 特に、SSHでの接続確認やElastic IPの割り当てなど、実運用で必要となる基本的な設定作業を体験しました。 これにより、クラウド環境でのサーバー管理の基礎を理解することができます。
CHAPTER 4: WebサーバーソフトをインストールするWeb
サーバーの基本となるApacheのインストールと設定を行いました。 サーバーへのソフトウェアインストール、基本的な設定変更、起動確認などの作業を通じて、Webサーバーの構築手順を学びました。 また、セキュリティグループでポート80を開放し、外部からのHTTPアクセスを可能にする設定も行いました。 これにより、実践的なWebサーバー構築の基礎を理解することができます。
CHAPTER 5: HTTPの動きを確認する
telnetを使用してHTTP通信の仕組みを実践的に学習しました。 実際にtelnetでポート80に接続し、HTTPリクエストを送信することで、Webサーバーとクライアント間の通信の仕組みを理解しました。 特に、リクエストヘッダーの構造や、空行の重要性など、HTTPプロトコルの基本的な動作について深く理解することができます。
CHAPTER 6: プライベートサブネットを構築する
セキュアな環境を実現するためのプライベートサブネットの構築を行いました。 プライベートサブネットを区切る方法や、プライベートサブネットの存在理由などを学ぶことができます。 プライベートサブネットは外部と直接通信できないため、パブリックサブネットに配置したWebサーバーを踏み台として、プライベートサブネット内のサーバーにアクセスする方法を学びました。 また、セキュリティグループでのICMP設定など、プライベートネットワークでの通信制御についても理解を深めることができます。
CHAPTER 7: NATを構築する
プライベートサブネット内のサーバーがインターネットにアクセスするためのNAT（Network Address Translation）の構築を行いました。 NATゲートウェイの作成、EIPの割り当て、ルートテーブルの設定など、実践的なNAT環境の構築手順を学びました。 これにより、セキュアなネットワーク環境でのインターネットアクセスの実現方法を理解することができます。
CHAPTER 8: DBを用いたブログシステムの構築
プライベートサブネットにMariaDBをインストールし、WordPressと連携させたブログシステムの構築を行いました。 CHAPTER6で作ったwebサーバを踏み台にすることで、webサーバを経由しプライベートサブネット内のインスタンスにアクセスし、NATを通してDBをインストールをするという流れを学びます。 その他、データベースの初期設定、ユーザー権限の設定、WordPressのインストールと設定など、実践的なシステム構築の手順を学びました。 また、WebサーバーとDBサーバー間の連携設定についても理解を深めることができます。
CHAPTER 9: TCP/IPによる通信の仕組みを理解する
ここでは、ネットワークの基礎となるTCP/IPプロトコルについて学習しました。 直接的にAWSに関係している訳ではないですが、一般的なネットワークに関する知識を学習します。 私はTCP/IPという本を読んだことがあったので、既知の情報であったりもしましたが、内容は非常に参考になり、もう一度おさらいとしても読むのはオススメできます。 パケットに付与されるヘッダーや、ルーターからDNSサーバへの通信を学習したり、SYNやACKなどの概念などを学ぶことができます。
まとめ
自分自身、アプリケーションエンジニアということもあり、構築されたAWSのサービスをいくつか触ったり、既存の設定をいじったりはしていたものの、サービスの公開といった構築まではしたことがありませんでした。新規の機能やサービスといっても、Google Cloudが多かったですし、そもそもサーバレスな環境が多かったのでここまでサービスを繋ぎ合わせなくても良しなにやってくれる部分も多かったのです。 そのため、この本を通して一通りの流れなどを知る良いキッカケになったと思います。
サーバーレスの普及や、コンテナ技術の一般化によってEC2を使って構築というのは最近は減ってきているかもしれません。 それでも、やはりそういう機会はどこかである可能性があるということ、そうでなくてもエンジニアの教養として学んでおくということは損ではないと思っています。
今度は、ここで構築したサーバやネットワークをTerraformやAnsible、Chefを使って構築するということをやるのもIaCを学ぶキッカケにもなると思いますし CDKを使うことにも繋げることできると思います。 それらのツールはこの本で学んだことが前提知識としてあるものとして使われるので、この本で学ぶことで次に手を伸ばすということにもしやすいのではないでしょうか。
松岡まどか、起業します AIスタートアップ戦記
以下の本を読みました。
東京都知事選から知った安野さんの作品ということと、タイトルも自分に刺さるような内容だと思い、結構軽い気持ちで読み始めました。
結論から言うと、思っていた5倍くらい熱い作品でした。
最初は正直なところ、あまり期待はしてなかった部分もありました。
よくある起業小説の出来レースの内容に、知識のひけらかしを小説にしただけなんじゃないの？とか。
しかし読んでいくと、小説としてどんどん惹き込まれる要素が後半にいくにつれて高騰していきました。
もちろん、ある程度フィクションということで、運が良すぎるという面もありましたが、
それ以上に同時進行で発生する障害や、一つ一つにかかる解決までのスピード感は読み手を飽きさせない作りとなっていて
4割くらいまで空き時間にちょこちょこ読んでいたのですが、5割くらいを読んだあたりから一気に最後まで読み進めてしまいました。
話の展開の仕方が、アメリカのドラマ・ブレイキングバッドを重ねてしまうような印象を受けました。
ブライキングバッドでは、主人公が麻薬を売ってお金を作るという主旨の話なのだが、
巻き込まれる問題（金額）がどんどん大きくなり、次々起こる問題に次は何か次は何かというワクワク感とそれを乗り越えるにはどうするのか
というのが非常にうまく作られており、見るのがやめられないという状況に陥ってしまう現象があるのですが
本書も同じような構成のように感じました。
それこそ、ストーリーは一年という期間で、金額も本全体を通して変わらないですが、最後には次に進むストーリーが想像できワクワクする流れでした。
環境の変化であったり、成長のスピード感というのはさすがスタートアップといった感じで、自分も今スタートアップで働いていたりするので、
経営者の気持ちや考えというのが主人公を通して筆者が取り組んできたことも見え隠れした部分もあり没入感がありました。
あまり書くとネタバレになってしまうので控えめになりますが、久々に小説を読んで面白いと思えたということだけ書いておこうと思います。
続編が来たら是非読みたいなと思いました。
解像度を上げる
概要
解像度を上げるという本を読みました。
非常に参考になることが多く、実践向けの本だと感じました。
解像度を上げるために必要な知識の列挙
それに対する行動の仕方というのを細かく書いてくださり
今後、行動に迷いが出た時の一つの指標とできるように感じました。
解像度の高い人がもつ4つの視点
- 深さ
- 広さ
- 構造化
- 時間
深さ
原因や要因、方法を細かく具体的に掘り下げること
課題を考える時も何が根本的な問題であるかが分からない。
つまり、見えているものの奥にある原因や可能性を深く掘り下げて把握すること
広さ
考慮する原因や要因、アプローチの多様性を確保すること
広く原因を把握し、異なるアプローチや視点を幅広く検討することで、もともと考えていたのとは別のところにある原因や可能性に気づくことができる。
構造化
深さや広さの視点で見えてきた要素を、意味のある形で分け、要素感の関係性やそれぞれの相対的な重要性を把握すること
新規事業の先行事例を集めるときも、成功事例や失敗事例を多く深く知っていたとしても意味がなく、共通する部分はどこで、違いは何なのか、どういった関係性にあり、その中でも最も重要なのはどれで、それはなぜなのかを理解する必要がある。
時間
経時変化や因果関係、物事のプロセスや流れを捉えること
市場は、時間との戦いでもある。
一時では物事の深さや広さ、構造をうまく把握できていても、時間によって動く的の行き先を適切に予測できていなければ、目標が動いてしまって「分析の時点では正しかったのに、行動をし始めたときにはすでに間違っていた」ということもありえる。
基本的に深さが足りないことが多い
ある一定まで深さを深めていこうとすると、構造を分析する必要が出てくる。
広さを持っている場合でも、どの部分を深めていくかの判断をする時は、構造や時間の分析が必要となる。
しかし、情報を綺麗にまとめているだけでは一定以上の深さや広さにたどり着けない。
そういうアンバランスの中でよくあるのが深さが足りないパターン。
起業家の中でよくあるのが
- 海外のスタートアップの表面的なマネはできている
- ビジネスモデル自体はありえる
しかし、目の前の顧客の課題の深掘りができていない。
例えば、教育の現場で何が起こっているか、アプリ改善のために企業が実際やったことはなど。
こう言った情報はインターネットではなかなか手に入らず、希少性が高いものになっている。
何をすれば良いか迷ったら、まずは「深さ」から取り組む。
自分の分析
まずは分からないことを明確にする
解像度が低いものに対しては、疑問が湧かなかったり、質問ができない状態になる。
逆に突き詰めた物事であれば、自分が分からないことやまだ知らない領域が明確で説明することができる。
解像度を高めるというのは自分が分からないことを明確にし、分からないことを言語化できることである。
構造のチェック
解像度が低い時は、「ユニークな洞察」ができていなかったりする。
例えば、重要なところを明確かつ簡潔に話すことができなかったり、人に話してみて「それってどういう意味？」という反応が返ってくる時など。
そういう時は、事例の羅列しかできていないので、「So What?」の質問を受けることになる。
そのため、自分の今の事象について構造を高める必要がある。
広さのチェック
構造化はできているが、ユニークさが足りない場合がある。
その時は広さが足りていない。
幅広い選択肢、をきちんと知っているかどうかが広さになる。
複雑な物事の関係性を多層的、多視点的に説明することができる。
競合製品との詳細かつ多面的な比較が言えるかどうかは一つの基準になる。
解像度が低いと、評価軸が少なかったり、デザインの良さといった抽象的な評価軸でしか比較できない。
そういった時は「競合に対して全性能で勝っている」や「競合よりも良い品質で、安く提供できる」などの言葉で表現される。
全性能で優っているというのは、そうそう無く、何かを見落としているはず。
競合がいないというのも、本当にいないのであれば市場としての価値がない可能性もあるので、やはり広さが足りていないということになる。
深さチェック
一般的な状況で説明することも可能ではある。
例えば、「新規開拓をした状況で、売上に課題を持つ飲食店向けの製品」など。
しかし、これはあまりにも一般的すぎて意味がない。
顧客対象が曖昧というのは、よくビジネスのアイディアで見られる。
具体的な人の話を1時間以上話せるようになったら、深さの視点での解像度は十分に高い。
逆に、多くの事例に当てはまるような話しかしてないと、解像度が低い症状になる。
七段階以上、課題に対して一般的な課題が当てはまるかをチェックしてみる。
「飲食店の売り上げが上がらない」→「顧客単価が上がらない」 → 「ドリンクが想定以上に売れていない」 → 「3杯目以降のドリンクが注文されていない」 → 「…」 といったように掘り下げる。
課題に対して、逆の発想の解決策しか提案できていないケースも解像度が低い。
例えば、「既存のアプリが使いずらい」 → 「使いやすいアプリを作る」 など。
時間チェック
最初の一歩として何から始めれば良いのか分からない時は、そもそも目的やビジョンの解像度が十分に高くない場合が多い。
環境の変化についての時間的な身通りがあるかどうかもチェックするべき項目。
ツリーを作り見える化
これまでの項目を踏まえ、ツリーを作成することで自分の課題に対するより解像度が高まる。
ツリーの深さが7段階上にいけば十分と言える。
「他にも複数の原因の候補があったけれど、その中でも徳にこれが大事で、それをさらに深掘りすると、これこれの複数の原因があり…」と複数の選択肢を検討した上で、需要な一つの原因に絞って解決策を考えることができる。
解像度チェック
以下の項目に当てはまるか
- 重要なところを、明確かつ簡潔に話せる（構造）
- 自身を持って言い切ることができる（構造）
- ユニークな洞察がある。（構造、広さ）
- 多層的、多視点的に説明ができる。（広さ）
- 競合製品との詳細な比較が言える。もしくは、代替品が何で、顧客は代替品のどの点に不満を抱いているのかを明確に言える。（広さ）
- 各要素が、具体的である（特に「顧客」）。（深さ）
- 短期的な目標は何で、長期的な目標としてどこまで辿り着きたいのか、そしてそこに至るまでの道筋や目標数値を明確に言える。（時間）
以下に当てはまると、解像度を上げる余地あり
- それってどういう意味？ 説得力がないと言われる（構造）
- 「で、なんなの？」「それって何の価値があるの？」と言われる。（構造、広さ）
- ふわっとしていて、多くの事例に当てはまるようなよく聞く話である。（広さ）
- 安易な解決策を提案している。（深さ）
- 最初の一歩として何から始めれば良いのかが分からない。（時間）
行動・粘り強さ・型が大事
行動
行動を起こすことが大事。
理論だけでは、賄えないものを行動することで、よりその工程に対し理解を進めることができる。
ただし、行動の方向性というのは定めないと行動の意味を持たない。
MVP という考え方は、まず行動から始まる。
ある程度の指針が整ったら、その指針が正しいかの検証を行うには行動を行う必要がある。
しかし、いろんな考えや検証項目を同時に検証しようとして行動するのは間違っている。
行動を起こして、そこで得た情報をもとにまた思考し、すぐまだ行動する、というサイクルを行うことが重要になってくる。
粘り強さ
アイディアがものになるほど解像度を高めるには時間がかかる。
早い人でも、1000時間程かける必要がある。
これは、1日8時間を20営業日と考えると半年。
副業で1日2時間ほどしかとれないのであれば、一年以上かかることになる。
その間に、方向転換することもあれば、挫折してしまう人もいる。
型
効率的な行動にするには、型を学ぶのが良い。
型を身につけ、実感できるようになるには数ヶ月の時間を要することが普通にある。
一度失敗したことで、型の重要性に気づくチームもある。
まずは、型を心から信じて最初の半年だけでも愚直に実践し続けることが重要。
何の解像度を上げるべきか
価値
付加価値や、仕事でバリューを出すなどの文脈で出る言葉になる。
課題があり、それに対する解決策があり、両者がうまく重なり合うことで課題解決がなされて、価値が生み出される。
この課題と解決策がうまく合致している状態のことを、「プロブレム・ソリューション・フィット」と呼んでいる。
課題と解決策がずれている部分は、需給のアンバランスであり、「歪み」と呼ぶことがある。
顧客はそこにフラストレーションを感じているので、それを解決することが、新たなビジネス機会となる。
そして、課題と解決策の解像度を上げなければ、ビジネスの価値を生み出すことができない。
良い課題
課題とは、顧客や市場の持つ問題。
良い課題を選べるかどうかで生み出される価値がほぼ決まる。
解決策が課題を完璧以上に解決していたとしても、課題の大きさ以上の価値は生まれない。
つまり、解決策が課題に対して、オーバースペックであっても、そのオーバーの部分にお金を追加で払ってくれる人はいない。
マネージャーになるほど、つまり裁量のある仕事を任されたりするほど、自分が「課題の質を高める」仕事なのか、「解決策の質を高める」仕事なのかをどういうバランスで行うべきなのかを常に考える必要がある。
良い課題の３条件
- 大きな課題である
- 合理的なコストで、現在解決しうる課題である。
- 実績をつくれる小さな課題に分けられる
大きな課題である
課題が小さいと、解決しても課題の大きさ以上の価値にはならない。
100点の課題ではなく、1億点満点、1兆点満点の課題に対して、0.01%でも解決する方が価値がある。
スタートアップなどは、今はまだ小さいが、今後課題が大きくなるものに取り組むのが良い。
これを課題の強度と呼ぶ。
また、その課題の頻度も影響がある。
つまり、その課題がどのくらい頻繁に起こるか。
回数が多いほど、その問題を解決した時の大きさは大きくなる。
課題の強度と、頻度を掛け合わせたものを課題の大きさと捉える。
課題の解決
昔からある現代の課題はほとんどが解決されている。
しかし、時代によって強度と頻度が増した課題も存在する。
それを見つけていくのが重要。（例えば、SNSの画像の加工課題など）
まずは小さな課題を
大きな課題にいきなり取り組むのは、コストが非常に高い。
小さい課題を解決する中で、大きな課題が見えてくることもあるため、まずは小さなものから取り組むのがいい。
ただ、一部の顧客が強い痛みを感じている課題や、緊急性を感じている課題を選ぶようにする。
そういった強度の高い課題は、大きな課題につながりやすいため。
症状と病因
市場の課題と顧客の課題の混同により、市場の課題では症状としての課題についても、顧客の課題の病因と考えることで、課題の深さが十分かどうかが見えてくる。
深さのレベル
7~10くらいの深掘りができていないと、重要な洞察を得られない。
普通の人は2~3くらいの深掘りしかせず、すぐに解決に目を向けてしまう。
課題が決まらなかったりすると、曖昧さに耐えられず、解決策に飛びついてしまうためだ。
その深掘りのための、9つの方法があるので、紹介されている。
内化と外化を繰り返すことで深めていく
内化は読む、聞くなどを通して情報を得る。
外化は書く、話す、発表するなどを通して情報を出す。
インプット・アウトプットとの違いは、情報の血肉化と加工して生み出されるというニュアンスを含んでいる点。
ここでいう、深めるというのは物事を詳しく知るなどの内化をイメージされがちだが、話したり、発表することで表現するプロセスも大事になってくる。
仕入れたものを思考し、きちんと行動することが大事。
そして、実際行うことで、見えてくるものも変わってくるのである。
言語化して深掘る
まずは書くことで頭がはっきりして集中でき、理解していないことも明確になる。
しかし、より詳細に課題を検討するときには、文章として長文で書く方がよく、箇条書きにしてしまうと論理の飛躍や矛盾に気づきにくくなってしまうので注意が必要。
スライドも同様に文章も簡素になり、箇条書きと用いてしまいがちなので使わないこと。
話してみる
自分が考える課題について話してみる。
言い淀む部分があるなら解像度は高くない。
人にプレゼンするつもりでスライドを作るのでも良い。
もし解像度が低ければ、論理のミスや、スライド間のつながりの悪さや抜け漏れが出てくる。
インタビュー
半構造化インタビューを行う。つまり、洞察を引き出すためのインタビュー。
普段の雑談では流れを大事にすることがあるが、インタビューでは時に元のトピックに戻り、深く質問して情報を獲得する必要がある。
方法としては以下のような流れ。
基本的に同じ質問を行う。
そうすることで、結果の比較がしやすい。
興味深い回答があれば、その場の判断で深掘りもできる。
欲しいものではなく、理想を聞くことも重要。
専門家のインタビューでは事実ではなく、意見を聞くことが多くなる。
しかし、そういう専門家は、業界全体のことは詳しいが、現場のことを知っているわけではないこともある。なので、現場の課題を持つ人にも話を聞くようにする。
そして、メモをとるときは、要点だけではなく、一言一句を書き留めるつもりで行う。
えーっとなどの相槌もメモすることで、その場の雰囲気や相手がどこで思考したのかを残すことができる。
50人にインタビューをしてようやく入り口なのである。
それくらい行って、初めて端緒が見つかるという印象。
繋がり
インタビュー相手がいないことであれば、自分が不得意な領域に手を出そうとしている可能性がある。
興味関心があれば、自分からそういったコミュニティなどに参加しているはずなのである。
アンケート
アンケートで顧客への理解が深まることはほとんどない。
対面のインタビューにより複雑な情報を得ることができる上に、機敏な反応を見ることができ、そうした反応こそがヒントになる。
アンケートのやり方
見ると、観察は別物。
- 構造化
- 半構造化
- 非構造化
の分類で観察することが重要である。
構造化
あらかじめ項目を決めたワークシートに観察内容をまとめていくやり方
半構造化
ある程度観察する項目を決めておき、現場では柔軟に対応するやり方
非構造化
観察項目をまったく持たずに行って現地で観察をするやり方
why so?を繰り返す
顧客にwhy so?という質問を繰り返すことで、いずれ顧客自身では答えられなくなってくることがあり。
他の人がたどり着けてないwhy so?も答えが得られたら、それはあなただけの洞察になる。
why so?は自問自答しているだけでは、行き詰まってしまう。
深掘りが甘い段階では止まってしまいがちになる。
そのため、誰かに壁打ち相手になってもらうことがよい。
そして、why not so?という質問も有効である。
「なぜこの課題はこれまで解決されていなかったのか？」というのを問うなどをしてもいいだろう。
why so?で気を付けるべきところ
- 十分に具体化してからwhy so?を問い始めること 顧客は何かを習慣化したいができない という抽象度が高いと、「やる気がでない」などの一般的な答えしか出てこない。 具体化し、「都会で働く社会人3年目の顧客は運動を習慣化したいけれどできていないのはなぜか」といった具体な質問にすると、「時間が不足しているから」「早朝や深夜に行けるジムが少ないから」などの具体的な答えが出てきやすくなる
- why so?はストレスフルで、回答へ至るまでに時間がかかる可能性がある 2回目、3回目くらいまでであればすぐに答えにたどり着くが、4回目とかになってくると根本的な原因になってくるため、見えてくるまでに時間がかかることがある。 そういったこともあり、why so?を繰り返し自問自答するには覚悟が必要となる。
- 原因を人に帰属させすぎないこと 何かのミスをその人のせいにするのではなく、仕組みやシステムに対して目を向けて改善すべき視点を変えるなどを行う。 寝不足などの多忙な状況ではなく、普通の人でもミスはする可能性はある。そうした時に、ミスが発生しても良いようにする仕組みやシステム作りにも目を向けるのが良いだろう。
- 業界・会社・個人などの問題のレイヤーの抽象度を上げ下げしながら深掘りする必要があるということ 業界全体でFAXが使われていない理由は、個人にの問題ではないので、問題の真因を見誤りがちになる。 場合によって、抽象度の異なるレイヤーがそれぞれ相互に作用して課題を生み出していることもある。 業界の課題 > 会社の課題 > 個人の課題 となる。
- why so?という問いを誰かへの攻撃のために使わないこと なぜ？という問いかけは、問い詰めるときにも使われる言葉である。 また、答えたとしても納得できないというような相手をやりこめるためだけの質問である時もある。 そのため、攻撃や論破のためではなく、自分自身で深めていくときや、解像度の低い人に対して思考を誘発するために使うことに注意する。
習慣的に言語化する
書く、喋るの発展型としての3つのコツ。
- メモをする 断片的なものでいいので、メモを書くということを習慣化する。 星新一ですら、記憶を頼るということはせず、メモを取ることで断片的な記憶の繋ぎ合わせから革新的なアイディアに繋げるということをしている。
- 対話する 誰かに話すということだけでも、強制的に言語化が促され、さらに質問によって深さが足りないところを自覚できる。 壁打ちということを繰り返すことで、自分の思ってもみないところからの意見をもらうことができる。 しかし、壁打ちは誰でも良いと言うわけではなく、壁役がトピックについて同程度知っていることが重要になる。 そうしないと、教える-学ぶという構造になってしまい、思ったように進まなくなってしまう。
- 教える 今考えてることについて、よく知らない人に教えるつもりで話してみる。 自分が教えるという立場になる以上、深くを理解しなければならないため、より多くの情報にアンテナを立てることになる。 輪読などで、自分の発表の番が回ってきた時などは、深く理解して発表に備える過程で、これまで以上に学びがあったという経験と同じである。
数字だけにとらわれない
数字だけに捉われると、その背後や周りにある景色が見えなくなりがち。
定量的な数字の未来予想は過去の傾向の延長でしかなく、特異的な機会やリスクを見逃してしまう可能性が高い。
新たな発見という意味では脆弱である。
前提を疑うための問いのパターンを持つ
- そもそもを疑う 既成の前提を疑い、ゼロから考えることで新たな洞察を得る。 ゼロベース思考とも呼ばれる。 「そもそも何のためにあるのか？」「そもそも必要なのか？」「そもそもどうやって作れば良いのか？」
- 10* の問い 今の10分の1の価格で作る方法はないか？などの1桁違う改善策を考えることは、課題への視点を無理やり変える効果もある。
- リフレーミング 物事を異なるフレームで見てみること うまく述べられた問題は、半分解決されているようなものだという言葉がある。 今向き合ってる問題が別のフレームに沿って述べられないかを考えることでより良い課題に近づけることもある。 例えば、自動車製造販売会社として何をするべきか？ではなく、移動をより良くする会社として何をするべきか？とリフレーミングする。
視座を変える
広さの視点で解像度を上げる。
視座とは、物事を見る場所。
視野とは、見えている範囲。
組織規模で言えば、一つ上の規模を想定して立場を変えて考えてみたりする。
顧客の課題だけではなく、その先にある業界や社会の課題を見据えて考えてみるなど。
二段階上の人の視座から見ることはおすすめ。
視座を高くすることで、観察対象としているシステムの境界を広げてみることとも言える。
別々のレンズを持つ
世の中にある物事を捉える時に、様々なレンズを持つことで物事を捉える時の視点が複数持つことができる。
例えば、コストに注目するレンズもあれば、儲けの機会に着目するレンズなど。
優れた起業家はこのようなレンズを激しく入れ替えしている。
マクロの市場の視座とミクロの課題の視座、ユーザーと競合の視座、未来と現在の視座、ビジネスと物理と社会のレンズなど、視座を切り替えながら、自分の仮説を検証し、もし正しくなさそうであれば別の仮説を作り上げていく。
体験してみることの重要性
例えば、現場まで足を運び視察に来ているのに、体験するということをせずに、文字通り視察だけする人がいる。
百聞は一見にしかずで、1回体験をすることで得られることは見聞きするだけに比べて段違いなのに、非常にもったいない。
深さは一気に広がるが、広さは時間がかかるので、少しずつ体験したり人と話したりをして広げていく必要がある。
選択肢を捨てる
選択肢を狭めるということは難しい。
やらないことを決めるという選択が難しくなる。
そのため、選択肢を選ぶ手段を確立していく必要がある。
すでに既知の選択肢から入る
この選択肢だったらもっと深掘りできそうだとか、この選択肢だったら過去に試したことがある、などを指標にすでにある知識を使って深めることができる場所にあたりを付けていく。
構造化する
分ける
現象をうまく要素分解し、それぞれの要素を個別に認識することが重要。
そのための方法は以下。
切り口を工夫する。
ツリー構造で整理する。
一つの要素を複数の下部要素へと分けて、樹形図にように伸ばしていくこと。
切り口から考えることで、分けたあとの深めることへのしやすさや、比較しやすさに繋げることができる。
例えば、電気利用料を見てみると、「何に」使われているのかというところを切り口にすると、「冷暖房」「輸送」などになる。
それが「どこで」の切り口に変わると、「オフィス街」や「住宅街」といったものが出てくる。
切り口の順番も重要。
何に使われてるかを切り口に、どこで使われているかを見ていくと、「冷暖房がどこで使われているか」をみることができる。
どこで使われているかを切り口を先にすると、「電気は、住宅街では給湯に最も使われており、オフィス街では冷暖房に最も使われている」
MECE
ミーシーと呼ぶ。
Mutually Exclusive Collectively Exhaustiveの略。
漏れなく、ダブりなくと訳される。
切り分け方が下手だと、漏れやダブりがあることを表現している。
しかし、人間の感情を完璧に分けることは不可能なので、分解することが難しいこともある。
他の戦略論
3C(Cosutomer, Competitor, Company)や、マーケティングの4P(Product, Place, Price, Promotion)、事業環境分析のPEST(Politics, Economy, Society, Technology)などのフレームワークがある。
しかし、これらのフレームワークも当てはめようとしすぎて、重要な点を見逃していたり、解像度が上がってないのに安心してしまう危険性も孕んでいる。
最低限のレベルまでの切り口を提供するものであり、新たな洞察を得るための道具としては使えない場合も多いことを理解しておく。
比べる
分けた要素を比べるというフェーズに移行する。
本来の分析は、「分けた上で比較し、そこから意味を見出す」こと。
課題を分けていった先の一番右側のどれを選び、深掘りしていくかは比べることで見えてくる。
比べることを繰り返すうちに、見た目だけで美味しいりんごとそうでないりんごの見分けができるようになるようになる。もしかしたら病気のりんごも見分けがつくようになるかもしれない。
そのために、比べる前に「比較可能にする」という準備が必要となる。
比較可能にする
物事は、抽象度を合わせることで比較可能になる。
ビジネスモデルと呼ばれる。ビジネスの特定の部分を抽象化し、お金の流れやステークホルダーの関係性のみに注目し、そのビジネスの構造を把握したものがビジネスモデルになる。
ビジネスモデルをさらに抽象化して、ビジネスモデルの共通点をくくって、カテゴリーを作ることもある。
抽象度
逆に抽象度が低いというのは、具体度や具体性が高いということ。
抽象度レベルが異なるもの同士の比較はできない。
そのため、まずは抽象度レベルが同じものかどうかを考える。
使い勝手の良さには、ボタンの位置や大きさ、色など具体的なものが含まれてくるが、ある機能の追加などは機能レベルの抽象度なので、どちらが優先すべきかという比べることができない。
大きさ
どの市場が大きいかをみることは、参入する市場を決める時の大きな判断軸の一つになる。
顧客がいる場合でも顧客セグメントを複数に分け、どのセグメントが大きいかを見る。
基本的に利益率の高いものから着手するのが定石で、100億売り上げを1%上げて10億の上がりを出すのと、10億の売り上げから10%上げて1億の上がりを出すのとでは、前者の方の改善が優先される。
コストを減らすさいにも、大きいものから手をつけていく。
絶対量としての大きさだけではなく、成長率などの比率の大きさを比べる。
重み
全体への影響度のことを指す。
売り上げを、顧客単価 * 顧客数 * 購買頻度という切り口で分け、さらに顧客数を新規顧客数と既存顧客数という切り口で分けたとき、売り上げを伸ばすにはどの数値を伸ばすべきか？
「結果の80%は、20%の原因から生み出されている」という有名な80対20の法則がある。
取り組む価値のある重要な課題はたいてい10あるうちの2、3割程度。
この2,3割の課題を解決すると、連鎖的に他の課題も解決されるという考え方がある。
視覚化
比べるものが多くなるほど、情報量が多くなり比較が難しくなるため、視覚化が重要になる。
棒グラフや、円グラフ、帯グラフ、ヒストグラムを使って、どのシチュエーションで、どういったことが求められるかを可視化した上で、必要な機能などを見定めていく必要がある。
関係付ける
切り口で分けたものを比べるのと同時に大事なものとして、関連付けがある。
切り分けたものを共通のもので関係付けることで、比べやすくなり、新たな構造を再構成することができる。
グループ化する
共通項という関連性を見出してまとめること。
さくらんぼとりんごは美味しい → 赤い食べ物は美味しい などのようにグルーピングすることができる。
ここからも、新しい共通項がみえてくることもある。
並べる
同じ項目を並べることで、注目すべきものが見えてくることで、評価軸ができてくる。
時間軸で並べることも、構造の把握に役に立つ。
物事がどういうプロセスやステップで進んでいくかを、時間順に並べるともできる。
繋がり
人の繋がりを見ることも大事。
因果関係を捉えて、何々をすると何々になるという法則を見つけ出す。
サプライチェーンの繋がりを可視化することが大事。
また、共起ということも重要。
サラダとドレッシングの相性は良いなど、共通点はないが相性の良さによる繋がりのことを指す。
システムを把握する
互いにつながり合って、相互作用する要素の集合体をシステムと呼ぶ。
複数の要素の関係性を面で理解するとも言える。
システムの中にある要素の相互作用を理解していないと、場当たり的な解決策になってしまうだけでなく、悪い結果になることもある。
事例として、コミュニケーションの促進には物理的な壁を取り除くという策があったが、実際には人前で話すことへの抵抗であったり、騒がしくなることへの対策としてヘッドホンをつける人が多く、逆にコミュニケーションが減るといったことがある。
物事の変化は気づきにくい。
バスタブへの水を貯めることも、じっと見ていなければ溜まっているのか把握することはできないし、穴が空いていれば、本来最初にやらなければいけない「穴を閉じる」という行動も水を貯めながらだと気づきにくい。システムの関係性を把握していないとこういったことに気づきにくく、解決すべき問題が見えにくい状態が生まれてしまう。
システムの理解は、複雑で認知負荷が高い。そのため、単純化しようとする傾向が人間にはある。
しかし、安易に単純化するのは良くないこともある。例えば、陰謀論などがある。
システムへの介入
システムには、好循環と悪循環が起こる。
電話などは、利用者が増えるほど効果のあるようなビジネスになる。
インターネットの普及によって、このようなビジネスが増えてきている。
悪循環は、景気に左右されるという傾向がある。
購買力がなくなり、さらに買わなくなり、さらに景気が悪くなると言ったような感じ。
課題の構造をシステムの相互作用と理解することで、システムのどの要素に介入するべきかが分かるようになる。
新しい製品が既存のシステムの中にどのようにうまく溶け込めるようになるのか、どこから入り込めばいいのかを考えることが重要。
関係性の視覚化
関係性を図などにして視覚化することは重要になる。
よくドラマなどで、壁にかけられた関係性に線を引くようなもののイメージ。
ステークホルダーマップや、顧客が商品やサービスとの関わりの中で辿る一連のプロセスを描いたカスタマージャーニーマップなどがある。
アナロジー
既知の物事(ベース)から未知の新たな物事(ターゲット)に対して、構造や関係性を写像して推論する。
既存のベースの構造と、未知のターゲットの構造の類似性や違いの中に未発見の要素があるのであれば、類似したビジネスと比較することで新たな課題の構造に気づけるようになるかもしれない。
ただし、ベースの構造の理解が甘ければ、類似性や違いを見つけられません。
省く
これまでの、分ける、比べる、関係付けるのすべての項目の中で行うべきことだが、共通して意識的に行うべきことでもある。
分ける際には、その他という分類を作り「分ける」ことで省くことができる。
比べる際には、「数にする」などの抽象化することは、特定の特徴以外を省くこと。
関係付ける際には、グループ化すれば必ず何かがグループ外のものとして省かれるということ。
目的の一部を省くことで、抽象度をあえて高くし粗くすることで比較や計算が行いやすくなるなどのメリットもある。
バリューチェーン
抽象的なプロセスとして、しばしば使われる方法。
企業が価値を生む活動の連なりをプロセスとして可視化したもの。
バリューチェーンは、業界全体の価値生成のプロセスを可視化したもの。
飲食店が、農作業界からの直送で野菜を仕入れているとしたら、それは流通までバリューチェーンを伸ばしていると言える。
日々の業務にも大小様々なプロセスがある。
経費生産、勤怠管理全体など。
これらのステップを明らかにすることで改善が可能になる。
ユーザーがどこに摩擦を感じているのかを把握し、どこが課題なのかといったヒントも得られる。
流れを見る
ボトルネックを見つけるというのが重要な工程になってくる。
ボトルネックを見つけて、そこを最大限になるように活用し、ボトルネック以外をボトルネックに従わせ、強化していく。
というのを繰り返す。
ボトルネックの考え方は物の流れだけではなく、人の流れや仕事の流れ、情報の流れにも応用可能。
課題の解像度を上げるとは、その課題の研究者やマニアになるということ。
業界の顧客のことならなんでも知ってるという自信を持った状態になること。
解決策の解像度を上げる
良い解決策の3条件
良い課題の条件に合わせて、良い解決策の条件も3つあげられる。
- 課題を十分に解決できる
- 合理的なコストで、現実実現しうる解決策である
- 他の解決策に比べて優れている
課題を十分に解決できる
課題を解決できない解決策は、解決策とは言えない。
十分に解決ができれば良いということがポイント。
深さの視点で解決策の解像度を上げる
プレスリリース
Amazonなどは、アイデアを洗練させる時に発表時のプレスリリースを書くそう。
そういった、言語化ができるかどうかが重要になる。
プレスリリースのような、詳細さと論理が求められる文章形式のものがオススメ。
逆にスライドのようにシンプルに伝えるようなものになってしまうと、解決策の解像度という点では不向きである。
当たり前すぎる解決策しか載せられてない場合は、十分な深さではない可能性が高い。
逆に、その解決策ならではの、固有の強みを書けるようにする。
行動可能な単位までHowを問う
課題では、5回のwhy?を問うことを意識する。
解決法では、how?を問うことを意識する。
手で考える
自分の手で動かして、すでにあるものを分析することで
製作者の意図や設計、考えを自分の中で咀嚼することで解決策の解像度は高まる。
動画編集にしても、今世には動画編集ができる若者が多いが、それは作った動画を披露する機会が多くなっていることも起因している。
そうした、世に出ているものをただ傍受するだけではなく、自分でも手を動かしながら思考を巡らせる必要がある。
体で考える
ある解決策が思いついたら、その製品があるかのようなロールプレイをしてみる。
競合製品を使い倒すなどをすることも、体で考えることである。
プロモーションビデオを撮ることも解像度を高める助けになるし、作られたビデオは今後の販促ツールとしても活用できる。
広さの視点で解決策の解像度を上げる
使える道具を増やす
一つの道具に頼りすぎて、何でもそれで解決しようとすることはよくない。
複数の道具を知ることで、解決策の思いつきなども変わってくる。
サーベイや、コミュニティは有効。
最先端の技術についてのサーベイがあると良い。
そして、実際に自分で試してみることで、全部を知ることはできずとも、広がりを見せることはできる。
外部資源を獲得する前提で広げる
今自分にないからといって諦めたり、解決策から外してしまうことはよくない。
外部から調達することで達成可能できるのであれば、資金調達であったりスキルがある人の支援を受けることもできる。
探索に資源を割り当てる
人は、解決策を「深める」ことに資源を投下しやすい。結果が見えやすいからだ。
このトラップに陥らないように2割程度の時間やお金を広げるために探索を行うこと。
そのために、20％ルールを取り入れたり、違う領域の専門性を高めるサイドプロジェクトをやってみても良い。
解決する範囲を決める
あえて特定の責務を負わないように設計すること、つまり解決する範囲をきちんと決めること。
一つの解決策で全てを解決しようとすると、そのシステムは複雑の一途を辿る。
そのため、分割した上で、どこを解決するかを明確にする。
やらないと決めたところには、必ず弱さが生まれる。資源配分をあえて減らしたりするとリスクが生まれるといった感じだ。
今回のシステムでは、ここが強いが、ここには弱さがあり、意図的に目を瞑っていると言えるようにならなければ、良いシステムとはいえない。
新しい組み合わせを生み出す
多くのパターンを知ることは、解決策を作るのに重要になる。
しかし、パターンで解決できない課題には、創造的な思考が必要になる。
創造的な思考を持つには、二つのシステムを組み合わせることで、新しいアイディアやシステムに繋がるが、それらを行うには二つの条件がある。
- 課題と解決策をたくさん知っておくこと
- 新しい関係性を作り上げること
1については、既存のパターンを知ることで、新しいものへの応用という意味
2については、発想法を活用すること
発想法とは、SCAMPERT法などを用いて、アイディアを強制的に広げる。
その他にも、マンダラートや9つの窓といった穴を埋めていくようなツールもある。
しかし、これらも課題を意識しながら要素を組み合わせていく必要がある。
課題を解決しないアイディアは意味がない。
ただし、新しすぎるアイディアはなかなか受け入れられずらい。
社会に受け入れられる新しい組み合わせを生み出す上で、新規制と慣れているものの間にあるスイートスポットを見つけることが重要。
足すことより引くことの方が大事
多くの人が捨てる選択肢を取らなかったという統計がある。
コストの高い手段が足す方法であれば、コストが高くても人々はそれを選ぶ。
しかし、一番大事なのは引くことで、ゼロトゥワンではなく、ワントゥゼロの考えなのだ。
制約をつける
システムは、制約を意識しながら築く必要がある。
予算などが分かりやすい。
予算内での実現可能な解決策を作る必要がある。
美しさを担保するデザインのガイドラインや、メンテナンス性を保ための開発のガイドラインなども制約にあたる。
そうして、自ら制約を定めることで、捨てることを可能にし、ソフトウェアという物理的な制約がないために足し算が行われてしまう仕組みによる複雑化を避けることができる。
ストーリーで顧客を裏切る
ストーリーを伝えることは一番イメージしやすく、人に理解を促し、感情を掻き立てやすい。
しかし、ストーリーのわかりにくさによって注意を引くことができないこともある。
王道なパターンでは、顧客の注意を引くことはできない。
そこで、王道ではないパターンで、ある種顧客の期待を裏切ることで、注目をしてもらうことを目的とする。
そのためには、まず王道を知っておく必要がある。
裏切るといっても、当たり前の市場データを見せるということをやめて、現状認識を共有しつつ、意外で重要な課題やデータを見せることを意味する。
雑な構造から描き始める
最初から完成系を見据えて作ることは不可能。
そこで、作っていく中でより良い構造が見えてくるということもあります。
しかし、そこで注意点として、最初の草案はできるだけ雑に作ること。
後で消さざるを得ないレベルのものでないと、このまま残してもいいかという気持ちで捨てることができないものができてしまいます。
これはソフトウェアにも当てはまる。
時間の視点で解決策の解像度を上げる
何かを解決する時、全てが一気に解決することも、全ての課題に手をつけられるほど資源が豊富なこともほとんどない。
多くの場合、課題を一つ一つ順々に解決していく。ステップがあるのだ。
そのため、最終的な目標の計画自体には完成系が見えたものではないため意味はないが、計画を立てるということには役にたつ。
しかし、計画の立て方は1ステップ1ステップに十分な説得力を持たせる必要がある。
どのように展開していくのかを考えるのが重要。
なぜこの順番で解決することが有効なのか、その理由を十分に言えなければ解像度は高いとは言えない。
岩を割る際も、小さな楔をいくつも打つことで大きな岩を割ることができる。
市場も同じで、既存の気[ぃようが独占する大きな市場でも楔を打ち込んでいくことで、市場の構造が変わり大きく成長できる。
そのため、大きな課題の一部でありながらも、重要で解決可能な課題を選び、どのような方向から楔を打ち込むとドミノ倒し的に解決の連鎖が起こるのかのストーリーをきちんと言えるかをチェックしていく。
そのため、最短ルートを決めて、そこへの逆算で道筋を挙げて言語化することが重要。
これは、先のプレスリリースを書いてみてからやるべきことを考えるといった手法でも通じる考え方。
タイミング
なぜ今なのかというタイミングも重要になる。
2年前でも、2年後でもなく、なぜ今なのかを問う。
長期の視点で時間を味方にする
難しい課題を1年でなんとかしたいのか、10年かけても良いのかによって、取れる解決策は大きく異なる。
長期の視点により、短期の予測に左右されないことが強みとなる。
もう1点、アジャイルに対応できるようにしておくことも重要。
実験して検証していく
ここまで、解像度の上げてきた課題や解決策はあくまで仮説でしかない。
どれだけ深く、広く、構造化されて、時間について考慮したとしても仮説である以上は間違ってる可能性もある。
大事なのは、行動することに対する抵抗感の少なさや過度とさえ言える積極性がある。
とりあえず、コンテストやプログラムに応募してみるというのは一つの例。
応募することで、フィードバックが返ってくるし、新しい選択肢が見えてくることもある。
解像度を高めたあと
MVPを作り、スケールしないことをする
人は作り込みすぎてしまう傾向があるので、まだ雑だと思う段階のもので出すことがオススメ。
そうすることで、自分の考えが正しい方向性を向いているかどうかを早い段階で分かる。
身銭を切ってもらい検証する
相手がお金を払ってくれるかどうかである程度検証できる。
「その製品が欲しい」と熱烈に口頭で伝えられても、身銭を切っていなければ信用できない。
単なるお世辞であるケースが多い。
「上司に相談」などの返事があった場合、その上司を連れてきてほしいと言った時にも、本気かどうかは判断できる。
機能はまだできていないが、できたら買ってくれるという覚書にサインを求めて、その場でできるかどうかで本気かどうかというのは判断することができる。
大事なことは、最初の仮説が間違っていたとしても、粘り強く続けて、改善し続けていくこと。
行動することで機会を生む
自分が行動することで、それを周囲が認知し、対応が変わったりなどの変化が起こることがある。
そういった自分の行動が基になり、次の行動へと切り開いていくこともありうる。
将来世代の視座に立って、あるべき姿を考える
未来に生きる誰かの視座に立ってみること。
今の自分の視座から未来を想像すると、今までの延長線上の未来や、ニュースなどで言われているような一般的な未来しか想像できない傾向にある。
そういったことを、フューチャーデザインと言われている。
アマゾンでは、重要なミーティングでは、一つ空席を用意していたそう。
それは、ステークホルダーである顧客がいるものとして話すことで、顧客の存在を意識することができるからである。
まとめ
当書は、最初から最後まで、「行動が大事」ということを伝えています。
当然そこには、苦労や努力の嵐であり、ほとんどの期間がそれに悩まされることになるとも言われています。
しかし、その先に開かれる未来や解像度というのは、瞬間的にパッと開かれるものではなく、そういった努力の積み重ねによって徐々に開花していくものとも言っています。
そのためには、思考を続け、常に解像度を高めるという行動を起こす必要があり、そのためのアイディアのまとめ方、考え方などを当書を参考に部分的にでも実践していければと思います。
ハウツーとしての本でも、考え方の本としても非常に良い内容で、また時間を開けて改めて、ハウツーの部分だけでも読みたいと思いました。
「技術書」の読書術 達人が教える選び方
概要
こちらの本を読みました。
本を読むということに対してのアプローチの紹介や、メモの取り方、本の選び方など、読書に対してのhow toが書かれてします。
デジタルからアナログ、物理本の扱い方、メモの取り方、メモを取る場所、図書館の利用など、多種多様な読み方が紹介されていて、読書への愛を感じることができました。
全部の方法をやることは難しいですが、僕も本を読むのは好きなので部分部分で参考にしながら、日々の読書習慣を充実させていこうと思ってます。
本の構成
1章: 本の選び方について
どんな本を選ぶべきか、その本の対象に当てはまるか、新刊の情報の収集方法など。 本に対するアンテナを高めることを目的とした内容。
2章: 読み方
本をどういう順番で読むか、何回読むか、1回目と2回目と3回目の読み方の意識。 読む上でどういったサービスを使うべきかといった内容。
3章: 情報発信について
本を読むことはインプットだが、それをアウトプットに変えていくことの重要性や、アウトプットにすることで得られる価値についての内容。 どういったアウトプットがあるか、アウトプットする上での心構えなどの内容が書かれています。
読書術
本の選別
図書館で借りて来る際に、全体を見渡して本を選んでくるという方法の紹介がありました。 興味のある分野や、読もうと思ってる分野の棚に行き、目を瞑って本を選ぶなどを行うようなものでした。 このやり方は自分的には衝撃でした。
そして、大事なこととして自分のレベルに合った本を読むという点。 これは当然と言えば当然なのですが、自分のレベルで読めるレベルの本なのかによって、モチベーションも読むスピードも変わります。 レベルを見極めるには、目次を見て中身のイメージができるかどうかでその本のレベルが合ってるか確認します。 優しすぎるからといって、読まなくて良い訳ではなく、たとえば新卒の子などに説明する時に役に立つ知識になるかもしれません。
読み方
一冊の本を3回読むことを目安にするように設定していますが、読み方は人それぞれという感じになります。 1回目はざっくりと読んでメモだけしておいて、2回目以降に理解を深めるなどをして読むスタイルもあれば、 1回目から精読して、2回目以降は軽く目を通してメモと照らし合わせて理解していくといったスタイルも推奨されています。
また、技術書などの手を動かさないといけないものについては、できるだけ手を動かして 動かなかった時のバグ解消をすることでスキルの向上も図れます。
同じ系統の本を同時読み
新しいものを学ぶ時、同じ系統の本を3冊くらい並列で読むことが重要になります。 ある本で理解できなかった説明を、他の本を読むことで理解できたりすることもあり、相乗効果により学ぶことができます。
サンクコストを考える
人はせっかく読み始めた本は、買ってしまった手前読まないとという意識があり、自分に合わない本だとしても読もうとしてしまいます。 しかし、今自分のレベルに合ってない本を無理に読んでも理解できずに無駄に時間がかかってしまうこともあるので、その場合は理解は置いておいてすぐに読み終えるようにするか、いっそ今は読まないといったような判断をすることも有効です。
メモ
メモに使えるアプリなどの紹介もあります。 読みながらメモを取るのは非常に有効で、物理本であれば付箋を貼ってそこに書いていくといった方法があります。
またマーカーを引いていくことの重要ということもあります。 これは賛否両論あるかと思います。本を綺麗に保ちたいとか、売る時のことを考えるとマーカーとかは引きたくないという人もいるかもしれません。
本の分解
物理本の場合、旅行とかに持っていくには重くなってしまう可能性がある。 そういう場合に、本を章ごとに物理的に切って、持ち運びやすくして、読んだらその場で捨てて来るといった方法もあります。 そうすると荷物も減るし、読む量も無駄なく持ち運べるので効率的です。 しかし、物理的に切ったり捨てたりするので、当然ですが中古とかで分解用に売られてる本をメルカリなどで買うという手段を取らざるおえないです。
媒体
本といっても物理本だけではないです。 ここでは、電子書籍や、オーディオブックなども紹介されています。 電子辞書では、場所を選ばずに持ち運びが便利であったり、メモが取りやすかったり検索のしやすさなどに利点があります。 オーディオブックは、耳だけを使うことで目を休めることもできれば、移動中とかでも読むことができます。 そういった手段を、本によって棲み分けることで効率的に本を読んで行くことができます。
複数の手段によって本を読むことで、圧倒的なインプットを超多読することの重要になります。 そのインプットによって、アウトプットに繋げることができます。 これは超多読を繰り返した末に到達する領域なので、続けていくことで見えて来るものがあるようです。
超多読によって得られる効果としては以下の5つがあります。
- 読書スピードが向上する。
- 速読スキルが向上する。
- 時間に敏感になる。
- 視野が広がる。
- アウトプットに独自性が出る。
アウトプット
アウトプットにもいくつか種類があります。 ブログにまとめたり、LTなどで登壇するなどをして、インプットをアウトプットに変えていく必要があります。 それによって、自分の成長に繋げることができます。 5分とかにまとめるスキルであったり、文章力や構成力がなければアウトプットできないので、読む度にアウトプットに繋げていくことで自分のスキルを高めていくことができます。
ここで重要なのは、自分の考えを含めたアウトプットにしなくてはいけないということです。 そこで、自分はまだまだだとか、この知識でアウトプットするのはどうかなど考えて行わないのが一番良くないです。 今の自分の知識で書くことで、同じレベルの人の助けになるかもしれないです。
心構え
コードでもそうですが、3日前の自分は他人と思うようなことがあり、自分がコードも3日後には忘れてしまう事も多いです。 それと同じで、アウトプットも将来の自分のために書くといったことを心構えとして持っておくといいでしょう。 他人に紹介する時も、そのアウトプットを使うことで有効に活用してもらうこともできます。
まとめ
読書力の向上は一朝一夕で向上する訳ではないため、何年もかけて少しずつ速さややり方を洗練させることを目標にやる必要があります。 しかし、一度身につけたらコスパの良いスキルになるので、本を読む力というのを身につけることは人生において重要なスキルになると思って日々読書していこうと思います。
僕も去年から本を意識的に読み始めていて、まだまだ読むスピードとかは遅いですが、この本の方法をいくつか参考にして多読をやっていこうと思います。
つくって、壊して、直して学ぶ Kubernetes 入門
概要
こちらの本を読みました。
経緯としては、Kubernetes をほとんど触った事がなかったので、触ってみたいというのがキッカケです。
仕事で使う可能性がありそうなのと、DevOps 領域に興味があり、深く関わっていそうだったのでこちらの本が出版されると聞いて即買いしました。
本の構成
当書は、ハンズオン形式で行う本になっており、頭から順番にやるだけでも、Kubernetes を触った気にさせてくれます。
実際、全てのことをこの本1冊で網羅するのは不可能ではあるのですが、入門とあるように最初の1歩としてはかなり分かりやすく、ハンズオンを通してコマンドにも慣れることができます。
ボリュームもめちゃくちゃ多いというわけではなく、程々の量なのでハンズオンを全部やらずに少し齧った部分は飛ばすなどをすれば、2、3日くらいで終わるのではないでしょうか。
僕は、全くの kubernetes 未経験だったので、GWを使って5日程使ってやりました。
感想
Part1
Docker の使い方から、Kubernetes の概要、説明がメインでした。
GitHub も公開されているため、無駄に Dockerfile やマニフェストの写経をする必要がなく、コマンドや内容に集中できました。
Kind と呼ばれる、マルチ Node クラスターが構築が可能なツールを使って行うことになるため、Kind の説明や使い方についてもここで解説されております。
Dockerfile の作成などは別途勉強するのが前提とはなりますが、当書の目的は 「Kubernetes に慣れること」なので、マニフェストを書くところはある程度にして その後に続く知識を身につけていきました。
Part2
ここから実際に、Node や Pod を壊して直していく工程に入ります。
一番長いパートなので、少し気合を入れて取り組みました。
ここでは主に、最初に構築した Cluster 上に何度か Development を適用し、 通信がうまく行えないような状況を直していくという感じになります。
ここでも基本的に写経は程々にし、どこでエラーが出るのか、どこでエラーを見るのか、その直し方の考えはどうするか に集中しました。
Pod の Status を見る事、Pod のログを見ること、設定されているマニフェストの diff の確認や、ポートの確認、実際にコンテナ内でのログ出力や疎通確認など
様々な角度から Kubernetes に対して操作を行なっていきます。
port-forward を行い、外部からコンテナへのアクセスをする方法などは実践でも使えそうだなと思いましたが、 実践でどこまで利用されているのかは、読み終わった後の今でもまだ分かりません。
ただ、そういった手段はあるということを知るだけでも、機能の理解の助けになるのではないかと思います。
affintiy などの概念は正直、読み終わっただけでは完全に理解したとは言い切れません。 何をどうしたら良いのかというのは、より詳しく解説されてる本を読むのがいいかもしれないです。
しかし、この本で概要を掴むことで、いきなり詳しい本に行くよりはかなりハードルが下がったと思うので 読んで非常に良かったと思える部分でした。
Part3
ここからは、主に Kubernetes 周りのエコシステムについての説明が多いです。 主に監視や、運用方法、今後の学習の進め方についての話が多いです。
Part3自体は、割と薄めなので、ツールや学習方法の紹介する程度となってます。 各項目については、それぞれに特化した本などで学習するのが良いかと思います。
まとめ
Kubernetes は僕自身、すごい怖いもののイメージでした。 所属する会社でもよく使われるのを見てはいますが、自分が触った事がなかったので非常に難しいものと決めつけていました。 しかし、今回何度もコマンドを叩き、実際動かないことを経験しながら、自分でいろいろ見ていくうちに少しずつその恐怖心が薄れ 最後の方は、本を読まずとも、「あぁ、次はこのコマンドで確認すればいいんだな」と表示するものが分かっていたので非常に進めやすくなりました。
今回は入門編ということで、概要だけ掴めたらいいという気持ちで買ったので、その目的は達成できて非常に満足のある本でした。 次は、もう少し詳しく書かれている本に立ち向かってみようという準備運動ができたと思います。
Lean UX
Lean UXとは
「リーン、スタートアップ」以外にも「デザイン思考」と「アジャイル開発」の概念を基盤としている。
かつては、物理的なものを作るため、細部のデザインを決め切ってからでないと、瑕疵があった場合の損失が莫大になってしまっていた。
しかし、昨今ソフトウェアに、継続的デリバリーという概念が導入され、製造上の制約を受けなくなってきた。
例えば、Amazonの運営するEコマースサイトでは、毎秒何らかのコードが追加されデプロイされているという。
マーケットからのフィードバックを得て、学習したことに基づき、イテレーションを繰り返す。ユーザーとの継続的な対話となる。
これにより、ユーザーのニーズを満たしているか、期待値を上げていけてるかという結果を生み出していくことをLean UXで行う。
しかし、デザイナーがアクセシビリティから、ページロードの時間、美しいインターフェース、ワークフローを作って渡していくのでは、コミュニケーションのコストが増えてしまい、より目を向けなくてはならないようなプロダクトの戦略的決定に影響を与える情報収集に時間が割けなくなる。そこで、チームメイト同士の共通理解が重要になる。
Lean UXを取り入れることで得られる3つの効果
- UXデザインのプロセスから無駄を取り除くのに役に立つ
- デザイン、開発、プロダクト/サービス間の対話を進めるために必要な作業(デザイン、リサーチ、ライティング)のみを行う
- 対話を最小限にすることで、長時間の交渉から解放される
- それらのための、チームの学習を促進する
- 部門横断のコラボレーションを促す
- プロダクトマネージャー、QAエンジニア、マーケティング担当者などを部門横断で透明性のあるコラボレーションを促す
- デザイナー以外の人も、デザインプロセスに関与する。
- デザイナーが何をすべきかを明確にして、チーム全員の参加を促す透明性の高いプロセス。
- 実験と検証に基づく学習をすることでマインドセットを変える
- 特定の人物に頼って1つの視点から最適なソリューションを導き出そうとするのではない。
- 迅速な実験と測定によって、自分たちの作る体験に客観的な視点でとらえられるようになること。
- そんとあめ、デザイナーの役割は、単に中間生成物を作るだけではなく、デザインのファシリテーターへと進化し、他のメンバーも新たな責任を担うことになる。
受け入れるのが難しいもの
「未完成」や「醜い」状態の中間生成物を人に見せなければならないこと。
最初の設計に時間や労力を多く費やすほど、その後の柔軟な修正は難しくなる。
大切なのは、コードのデプロイではなく、顧客に与えるポジティブなインパクトである。
そのためには、学習とイテレーションの継続が大事になる。
Lean UXの基盤
元々
- インタラクションデザイン
- 情報アーキテクチャ
- グラフィックデザイン
などの多くのデザインを包含している。
しかし、その中心には、人間のニーズがあり、人間のニーズを特定するところから始まる。
人間を直接的に観察することを原動力とするイノベーション手法であり、人々が生活の中で何を必要として、特定のプロダクトやパッケージ、サポートなどの方法を好んでいるのかを観察すること。
その考え方には、ビジネスのあらゆる側面は、デザイン手法でアプローチできるというデザイン思考により、明確な立場をとっている。
そして、アジャイル開発のコアバリューと以下の面で完全に調和している。
- プロセスやツールよりも個人との対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも、変化への対応を
Lean UXの原則
自身とチームを正しい方向に導くための原則
- チームビルディング
- チームや組織文化の指針
- プロセスの指針
チームビルディング
- 部門横断的
- 小規模、専念、同一環境で作業する
- 10人以下のチーム
- チームは一つのプロジェクトに専念し、同じ場所で作業をする
- リモートワークだと何かを逃してしまうという考えによる
- 自己充足的で、権限を持つ
- チームが外部依存なしでプロジェクトを進められるようにする
- チームに対して以下のような権限を与える
- 直面する問題の解決方法を決定する
- ユーザーや顧客と直接関われる
- これによりチームが直接、マーケットから学ぶことができる
- 課題焦点型
- 機能の実装ではなく、ユーザー課題の解決を目標にする
- 共通理解
- チームが一緒に働きながら時間をかけて築いていく集団的な知識
プロセスの指針
- これまでと同じことを速くやるのではなく、仕事の進め方を見直す
- プロダクト開発のフェーズに注意する
- 調査フェーズ、デザインフェーズ、開発フェーズ、テストフェーズなど
- そのような「フェーズ」と名がつくときは、何かが間違っているという警告サイン
- アジャイルの中で、これらのフェーズをすべて断続的に行うべきなため
- フェーズでは、プロセスステップが完了するだけで、生成物を完成させるには、フェーズで区切るのではなく、断続的に仕事を進める方法に移行する必要がある。
- 外に出る
- かなり早い段階で見込みユーザーからのフィードバックをもらう
- ユーザーの行動と要望、その理由を理解する
- プロダクトの成否を最終的に決めるのは、チームではない。
- あなたがデザインした「購入」ボタンをクリックするのはユーザー
過去と現在のプロダクト開発フローの違い
昨今では、完成品が見えた上でプロダクトを作ることはない。
つまり、何を構築しなけっればならないかが正確に分かっていることが前提となる開発はほとんどありえない。
マーケットの変化に対する機敏な対応が求められるためだ。
しかし、現在でも要件を固めた厳密さというのは、「以前はうまくいったから」という根拠のない自信によって横行されてしまい、
要件の完全性に疑問を持つ個人やチームはトラブルメーカーとみなされてしまい、プログジェクトの納期が遅れたりスコープを超える作業が発生した時の責任が押し付けられてしまう。
ユーザーは裏切る
現在、我々は
- 一貫性
- 予測可能性
- 安定性
- 確実性
が低い現実にいる。
そのため、消費者行動の変化に対応した新たなメンタルモデルを構築していく必要がある。
例えば、Amazonでは、毎秒1回リリースが行われるというようなユーザー体験をより良いものにする機会を得ている。
その中でも消費者は、自分たちが直感的で使いやすいと思って作ったUXの期待した行動とは異なる行動で我々を裏切ってくる。
そういった結果が出た時こそ、自分たちの要件が間違っていたと証明するものになる。
どうすれば良いか？
まず我々は、要件を「権威をもって表現された単なる思い込み」であると認識すべき。
そのため、「人間の行動は予測できるものではない、そのため我々が取り組んでいるものは高リスクなことである」ということを理解する必要が出てくる。
そこで、これまではLean UX キャンバス といったものを取り入れることで、自分たちのアイディアを「検証可能な思い込み」として新たな方法で表現していた。
キャンバスの使い方
どんな時に使う？
キックオフミーティングに最適な枠組みを提供してくれる。
キャンバスには以下のメリットがある。
- 一連のストーリーを推進するようにデザインされた連続的なプロセスに統合
- 複雑な要素を一つの視覚的モデルにできる
- ファシリテーションツールとして簡単に利用できる
- ブレーンストーミングではアイディアを出すことに躊躇しがちなメンバーに、意見を提出しやすい公平な場を提供する
- 共通言語の構築
- チームの仕事の枠組み
- チームの枠を超えて広く伝えられる
これらは、それなりの大規模なプロジェクトの計画を立てる際に、使用することでプロジェクトの大きさへの感覚が研ぎ澄まされていく。
主に次のようなものに直面している時に効果を発揮する。
- 未知のもの
- 不確実なもの
- 複雑なもの
流れ
- 基本的にキャンバスの作成には、2日間や1週間かかることもある
- 参加者はチーム全員
- 全員の参加を促すための仕組み
- まず、参加者が一人、短めの時間(5分程度)を決めて直感的に浮かんだアイディアを記載したり図式化する
- 一人での作業が終わったら、テーブルや小グループでアイディアを共有
- アフィニティマッピング(9章に出る)をしても良い
- 2人1組とかになり、アイディアを練る
- ペアワークは時間がかかるので1人の時より少し時間を多めに取る
- その後、発表をしてもらい、その時にディスカッションをしても良い
- 次に、各テーブルや、サブグループのアイディアを1つのプレゼンテーションにまとめる
- 最後に、最終的にアイディアを1つにするなら、グループ全体でアイディアを絞り、練り上げる
ボックス1: ビジネスプロブレム
ビジネスの抱える問題は何か？
ソリューションではなく、課題を認識した上で表現することが大事になる。
それがビジネスプロブレム・ステートメントになる。
具体的には以下の条件が満たされるべき
- 機能ではなく、解決すべき具体的な課題の提示
- 顧客中心の視点で、顧客のシエ高が最終目標となる
- スコープの対象となるもの、対象外のものを明確にするガイドラインと制約の明記
- KPI、ターゲットオーディエンスに求める具体的な成果として表現される明確な成功の基準の明記
- ソリューションを定義しない
そして、ステートメントは以下の3つの内容により構成される
- プロダクトの現在の目標
- なぜこのプロダクトが作られたのか
- どんな課題を解決することが目的だったのか
- どんな価値提供が意図されていたのか
- プロダクトによって何が変化したか？
- 達成された目標と、未達の目標
- プロダクトの改善要求
- 改善を成果として定量化するもの
エクササイズのプロセス
プロダクトマネージャーによる、チームにコンテキストや背景情報の提供がある。
具体的には以下のようなことの質問に答える。
- 問題があると至った観察・測定結果は？
- 誰をターゲットにした機能か？
- この機能の前者的な事業の中での位置付けは？
- この問題の解決で、全社の経営にどのような影響があるか？
これらに基づいて、ペアやトリオに分かれてステートメントのドラフトを作成する。
気を付けるべきこと
ソリューションを含めないこと
「〜を解決するためのモバイルアプリはどのように実装すれば良いだろうか？」
といったソリューションにしてはいけない
具体的であるべき
例えば、以下のような文が含まれているステートメントがあった
「ショッピング体験の向上を目指し、平均注文額を上げるために直感的なUIを実装した」
しかし、これでは何が実装されたのか漠然としているので、チームはUIのどの部分を改善対象にすればいいか分からなかった。
そもそも、直感的なUIは、あえて言うものでもなく、誰もが目指すものであるので、記述に対する意味はない。
ボックス2 ビジネスの成果
ユーザーの行動に焦点を充てる。
カスタマージャーニー
チームが注目すべき、価値ある顧客行動を見つけることが目的である。
現在の顧客がどういった行動をしているかを見るところから始める。
「海賊指標(AARRR)」「メトリクスマウンテン」のようなテンプレートも使える。
ボックス3: ユーザー
デザインにおけるペルソナは重要。
しかし、かけた労力に伴い、絶対的なものとして捉えてしまう傾向がある。
また、外部のリサーチチームやベンダーがペルソナを作成することがあるが、利用側と知識のギャップが生じやすい。
開発チームのジレンマ
開発者は、ユーザーと定義されたペルソナのことを、自分達と同じ人間と思いがちになる。
そのため、自分たち好みに作ってしまうという傾向がある。
エクササイズ
ペルソナの制定のための話し合いが必要となることもある。
以下のような流れで行う。
- どんな人がターゲットになるのか、プロダクトの利用によってどう影響するのかの意見を述べるところから始まる。
- ペルソナタイプのリストを作成する
- 「大学生」「ストリーミング好き」「医療従事者」などのターゲットセグメントを決める
- 最もターゲットになりそうなペルソナを3〜4人に絞り込む
- ペルソナのテンプレートを、ニーズや役割によって区別するように作成する
- 小グループに分かれて、テンプレートに沿って各グループで1つ作成してもらう
- 結果を全体で持ち帰って検討する
ペルソナは一度決めて終わりではない
基本的にペルソナは一度定めたら終わりではない。
エクササイズを行って制定されたペルソナが正しいかどうかを確かめるフェーズが必要になる。
例えば、ペルソナとして想定した人を見つけられない場合、潜在ユーザーはいないということになる。
同じように、ペインを解決しようとしても、潜在ユーザーを集めて話を聞いてみると、課題となっていない場合もある。そうなると存在しない課題を解決しようとしていることになってしまう。
- 例
ある投資家達の、プレゼン資料やタームシートや、資本政策などをまとめるためのアプリを考えていたが、実際に話してみると年に１、２度しか投資を行わなかった。
それくらいであれば、メールやExcelで十分管理できてしまうということになり、無駄に労力をかけることを避けることができた。
ボックス4: ユーザーの成果とメリット
ユーザーの成果は役割によって異なる。
「ビジネスの成果」「顧客の成果」「ユーザーの成果」の違いについて考えてみる。
たとえば、ある会計ソフトを取り上げてみる。
顧客: 経理部門の効率を上げて、建て替えできない費用への支払いを減らし、全体的な運用コストを下げること
ユーザー: 早く経費を精算し、短時間で正しく経理データを入力すること
どちらも、行動ベースの成果だが、視点が異なる。
異なるグループの人が、異なる目標を指している。
購入者: 経理部の効率化の実現によって、上司に評価されたいという目標ができ、それを達成できるソフトを探す。
ユーザー: 面倒な手続きなしに精算できるようになることを望んでいる。
感情的な目標を達成できたかどうかになる。
しかし、感情的な目標を定量的に計ることは難しいが、かなり重要。
難しいからといって、注目しなくてもいいわけではない。
もし、適切に定量化ができれば、その定量的な測定基準において良い成果をあげることにつながるため。
エクササイズ
そのため、Lean UXキャンバスの、このセクションでは感情面に注目した議論を行う。
ペルソナが何を求め、プロダクトを探し、見つけた時に何をするのかを理解することを議論の目標にする。
注意すべきこと
機能に意識が向きすぎてしまうことがある。
それが顧客のモチベーションになると思い込んでいるから。
Apple は、競合他社が「12メガピクセルのカメラ」と機能をアピールする一方で、「外国にいる祖母に、赤ちゃんの姿を見せよう」と宣伝する。
ボックス4: ユーザーの成果とメリット
ユーザーの成果は役割によって異なる。
「ビジネスの成果」「顧客の成果」「ユーザーの成果」の違いについて考えてみる。
たとえば、ある会計ソフトを取り上げてみる。
顧客: 経理部門の効率を上げて、建て替えできない費用への支払いを減らし、全体的な運用コストを下げること
ユーザー: 早く経費を精算し、短時間で正しく経理データを入力すること
どちらも、行動ベースの成果だが、視点が異なる。
異なるグループの人が、異なる目標を指している。
購入者: 経理部の効率化の実現によって、上司に評価されたいという目標ができ、それを達成できるソフトを探す。
ユーザー: 面倒な手続きなしに精算できるようになることを望んでいる。
感情的な目標を達成できたかどうかになる。
しかし、感情的な目標を定量的に計ることは難しいが、かなり重要。
難しいからといって、注目しなくてもいいわけではない。
もし、適切に定量化ができれば、その定量的な測定基準において良い成果をあげることにつながるため。
エクササイズ
そのため、Lean UXキャンバスの、このセクションでは感情面に注目した議論を行う。
ペルソナが何を求め、プロダクトを探し、見つけた時に何をするのかを理解することを議論の目標にする。
注意すべきこと
機能に意識が向きすぎてしまうことがある。
それが顧客のモチベーションになると思い込んでいるから。
Apple は、競合他社が「12メガピクセルのカメラ」と機能をアピールする一方で、「外国にいる祖母に、赤ちゃんの姿を見せよう」と宣伝する。
ボックス5: ソリューション
ソフトウェア開発では、全てを俯瞰し、いくつかの制約を設けておく方が良い結果が得られる。
ここまで、ビジネスプロブレム・ステートメント、ビジネスの成果、ペルソナ、ユーザーの成果やメリットについて議論してきたので、制約を設けてきた。
これらの制約は、ソリューションを作り出すための空間をつくるものになる。
この段階では細かなデザイン作業は、まだ行わない。キャンバスが完成してからになる。
様々なブレーンストーミング
アフィニティマッピング
最もシンプルかつ、チームを協力させることができる方法。
一つの質問をチームにし、5分かけて各自が書き出したアイディアにつちえ議論をし、最適なのを導き出す。
質問: ペルソナが望む成果を実現するために、どのようなソリューションをデザイン・構築すれば良いか？
デザインスタジオ
5~8人のチーム
オンラインの場合、Miroなどのボードツールを使用
手順
- 課題の定義と制約やリスクの明確化
- 各メンバーによるアイディエーション(多様性)
- プレゼンテーションとフィードバック
- 2人人組でのイテレーションとアップデート(形成)
- チーム全体でのアイディエーション(集約)
課題の定義と制約条件
チーム全員で、解決しようとしているビジネスプロブレム、取り組みの成功を定義する成果、ペルソナ、ユーザーの達成しようとしているメリットを共有する。
これまでやってきているので、全員が認識を持っている状態であるが、一緒に作業していなかった人がいる場合は、説明し質疑応答をする。
各メンバーによるアイディエーション
5分ほどで行う。
6分割に罫線が引かれたテンプレートを利用する。
それぞれのボックスに、ペルソナとペインを上部に書き、それぞれの解決策のラフなスケッチを書いていく。
様々な図形などを使って表現しても良い。
プレゼンテーションとフィードバック
1人3分でプレゼンテーションをチーム全体に対して行う。
良いフィードバックには、自分の意見を述べるより、相手に質問をする方が効果的である。
質問をする方が、チームが議論しようとしていることについて議論がしやすくなる。
逆に質問ではなく、意見を述べると、議論が活性化せず、コラボレーションも起こりにくくなる。
その結果、メンバーは自己弁護的になる。
2人1組でのイテレーションとアップデート
10分ほどで行う。
ここで、できれば同じアイディアを持つメンバーを2人1組にする。
書くペアで、それぞれデザイン案の改良に取り組む。
目標は、各ペアが最もメリットのあるアイディアを選び、それを進化させ、統合することである。
何を残し、何を変え、何を捨てるかの決断は難しい。
そのため、一般的、抽象的なアイディアにしがちになるが、そうならないように注意する必要がある。
チーム全体でのアイディエーション
45分ほどで行う。
チーム全体で、有望なアイディアを絞り込む。
ここで選択されたアイディアは、次のプロセスである仮説の構築と、その後のデザインと実験の基礎になる。
選択されなかったアイディアも、一時的にためておくためのバックログを作るようにしておくと先に進みやすくなる。
注意すべきこと
参加者が平等に参加できるようにすること。
ただし、リモートセッションでは、難しいツールではなく付箋を使えば楽なところが、とても難しくなる。
チームが下流で行う機能やデザインの選択に対して、抵抗を示す可能性が出てきてしまう。
このような時、チームのデザイナーにとってデザインファシリテーションが極めて重要なスキルになる。
ボックス6: 仮説
ここでは、ペルソナであるユーザーがプロダクトを使うことでどのような利益を得られるのかということを宣言する。
ビジネスの成果を達成するのに、ユーザーの成果を達成する必要があり、どんな機能がそれを可能にする ということを信じるフェーズになる。
この場合、複数のペルソナや機能を対象にしていることに気づくことも多々ある。
そうした時、複数の機能を同時に行うのは難しいので、一つの機能のみを目指すということを目指していくようにする必要がある。
ボックス7: 最初に学習すべき最重要事項は何か？
仮説の中で、どれを最初にテストすべきかを決める必要がある。
人々はソリューションを必要としているのか？
彼らはそれを探すだろうか？
試してみるだろうか？
使うだろうか？
価値を見出すだろうか？
などに考えていく必要がある。
初期段階において、とても重要になる。
これらの質問が全て、いいえと答えられるのであれば
どのようにデザインするか、構築するかについて考える必要はなくなる。
そのため、最初に学習すべき最重要事項は何か？にフォーカスを当てる必要がある。
そこで、チームの合意が必要となるが、合意に達しないのであれば、さらなる情報が必要となる。
そのためには、どれを対象にするかについてひとまずの決定を下し、実験を行う。
この決定は、プロダクトマネージャーが下すことになるが、選ばなかった仮説や前提、リスクを完全に捨てるわけではないということに注意。
とりあえず、特定の仮説を対象にして進めるだけで、誤りと証明されれば、仮説のバックログに戻り、このプロセスを行なっていく。
ボックス8: MVPと実験
最後のステップである、ボックス8 では実験に焦点を当てる。
Lean UXキャンバスの2つの重要な質問の一つは、「次の最重要事項を学ぶために必要な最小限の作業は何か？」に対する、仮説検証のための実験である。
つまり、MVPの作成になる。
優れたMVPは、価値と学習の両方を創造する。
しかし、Lean UXではMVPは学ぶことに重点を置く。
MVPを構築するには
まず最初に必ず、「次に学ぶ必要がある、もっとも重要なことは何か？」を考える。
核心を突く
ナビゲーション、ログイン、パスワード取得フローなどは、アイディアそのものがターゲットオーディエンスにとって無価値である場合、考えても意味がないので後回しにする。
明確なCTA(コール・トゥー・アクション)を使う
サービスの選択やサインアップの機会を提供することで、ユーザーの興味の度合いや、実際に金を払ってくれるかどうかを判断しやすくなる。
行動を測定する
実際の行動を測定できるMVPを構築する。
人々の言葉で説明する自らの意図に惑わされずに、実際の行動に焦点を当てることができる。
ユーザーと話す
MVPを通して、何をしたかは分かったが、「なぜ」の部分が分からないと意味がない。
そのため、意図通りに使った人と、そうでなかった人の両方から話を聞く。
優先順位付けを重視する
優先順位が大事なので、有効であることが検証されていないアイディアを気に入ってるからという理由で固執しないように注意。
しかし、デザイナーは楽観的に物事を考える傾向があり、考案するのに5分のものも5ヶ月のものも、自分たちのソリューションはよく寝られたものだと思いがち。
実験の結果が期待に反したものであれば、その期待は間違いということを忘れないこと。
アジリティを維持する
アップデートが容易な方法やツールを用いて実験やプロジェクトを進める。
0から作ろうとしない
アイディアをテストするためのツールやシステム、仕組みはすでに多く存在している。
既存のツールを使って学習をする方法を検討する。
電子メール、携帯メール、チャットアプリ、Facebookグループ、Shopifyストアフロント、ノーコードなど
プロトタイプの種類
- ペーパープロトタイプ
- 低忠実度のオンスクリーンモックアップ
- 中〜高忠実度のオンスクリーンプロトタイプ
- ノーコードMVP
- コーデッドプロトタイプ、ライブデータ・プロトタイプ
コラボレーティブデザイン
コラボレーティブデザインを主導するのは、従来と同じく、デザイナーになる。
コラボレーティブデザインのためのミーティングを主足し、メンバー間のコミュニケーションを促す。
カジュアルな形式の会話や、
スケッチのセッション、
ホワイトボードの前でのエンジニアとの本格的な1on1のセッション
など
一般的な流れ
- チーム全体でスケッチをする
- デザインのアイディアについて議論し、チーム全体で意見をまとめる
- 成功の見込みが高いと思われるソリューションを1つに絞り込む
デザイナーは従来通りデザインを行いながら、チーム活動のファシリテーターを行う。
Lean UXとデザインスプリント
デザインスプリントとは
- チームを集め
- 質問を定義
- アイディアを出す
- 試作品を作る
- テストする
というのを5日間で行う。
ただ、デザインスプリントでは仮説やMVPといったLean UXで登場する言葉は出てこない。
そのかわり、スプリントの最終日にプロトタイピングとテストを行う。
この点は、対立しているように感じられることがある。
ジェイク・ナップのインタビュー
Lean UXは、プロダクトサイクル全体、組織全体で使える料理本のようなもの。
対して、デザインスプリントは、チームの特定のメンバーが特定の瞬間に特定のものを作るための、1つのレシピ。
実験の中の実験という形で、デザインスプリントの中でオリジナルを試しながらチームを観察し、少しずつアレンジしていく必要があると言う。
ただ、プロダクトの細部を決めるものではないので、全体の開発スケジュールを計画したりするためのものではない。
MVPの代わりにもならなければ、ゼロから立ち上げまでの道筋を提供するものにもならない。
特定の期間に最大限の効果を発揮する。
Lean UXのプロセスでのデザインスプリントの使用
Lean UXでは、作業を「構築すべきもの」ではなく、解決すべき課題として再構成することが奨励される。
Lean UXでは、課題、オーディエンス、潜在的ソリューション、成功について前提を明確にすることを推奨する。これにより、良い仮説が立てられ、デザインスプリントの構成にも役立つ。
仮説が、デザインスプリントの開始地点となる。
スプリントで行った作業を使用して、これらの前提を細かく検証し、仮説を洗練させて次のステップを明確にする。
デザインシステム
デザインシステムを利用することで、画面構造、プロセスフロー、情報設計などの決定（ホワイトボードで作成できるもの）を適切なチームメイトが担当し、色、フォントタイプ、スペーシングなどを別のチームメイトが担当することができる。
これにより以下の2点が促進される。
- デザインの高速化
- プロトタイプの高速化
組織に対しても大きな利点がある。
- 一貫性の向上
- 品質の向上
- コストの削減
リモートのコラボレーション
分散型のチームとのコラボレーション
コラボレーションを容易にできる、重要なポイントが2つある。
- 全員が同じ条件で参加できるようにすること
- 自由なコミュニケーションを促す仕組みをつくること
全員が同じ条件で参加できるようにすること
自分以外が会議室にいて、自分だけ電話でミーティングという状況とかが分かりやすい。
ホワイトボードに付箋を貼ったりとかになると、電話で参加している人は難しくなる。
そのために、使うツールを適切に選ぶこと。
例えば、MuralやMiro、共有ドキュメントなど、オンラインホワイトボードを使用するなど。
自由なコミュニケーションを促す仕組みをつくること
オンラインミーティングでは、唐突に始まり、唐突に終わる。
それもメンバーを集め、アジェンダを細かく定め、時間通りに終了するという杓子定規な方法で行われるが、実際のオフラインでは会議の前に廊下で軽く雑談をしたり、ミーティングが始まるまでの間、あれこれと話をする。
ミーティングが終わったあとも、一緒に会議室を出て、コーヒーを飲みながら感想を述べあったりする。
こういったコミュニケーションが仕事の本質とは無関係ではなく、重要な意味を持つ。
こうしたコミュニケーションを通して絆が生まれ、一緒に仕事ができている。
ワーキングアグリーメント
各スプリント後に行われるレトロスペクティブをサポートするドキュメント。
コラボレーションを進めていく上でのどんな合意がチームにあったかを記録する。
合意した内容に従って作業が進められているかどうか、新たな合意内容を追加するために更新すべきかどうか、不要な古い合意を削除するかどうかを確認する。
以下のようなことを書く。
プロセスの概要
定期的なコミュニケーション
どんなコミュニケーションスタイルか？デイリーはいつするのか？企画会議やでもを開催するのはいつか？
コミュニケーション/ツール
ドキュメント化するためにどのようなシステムを使うか？
プロジェクト管理ツールは？アセットはどこに保管しているか？
チーム文化/安全性/対立関係の解決
どのようなチーム文化が望ましいか？
安心してチームメイトと働くために、個人として何が必要か？
対立が起こったらどうするか？
意見の相違の解決方法は？
労働環境と時間
誰がどこで働く？
メンバーがオフィスにいる時間は？時差は？
要件とデザイン
要件定義、ユーザーストーリーの作成、優先順位付けをどう扱うか？
ユーザーストーリーを作成するのはいつか？
開発方法
どのようなプラクティスを採用するか？
ペアプロするか？テスティングのスタイルは？
ソース管理方法は？
開発中の制限や制約
バックログとアイスボックスのサイズは？
プロセスの各段階にどのようなWIP制限が存在するか？
デプロイ
リリースの流れは？どのようにユーザーストーリーを受け入れるするか？
その他いろいろ…。
心理的安全性
A Culture of Safety(著者アラ・ウェインバーグ) 引用
「チーム内に、ミスを認める、質問をする、新しいアイディアを提案する、などの行為が恥ずかしいことと見なされず、抜歯もしないという共通の信念があること」と定義。
フィードバックとユーザーリサーチ
Lean UX におけるユーザーリサーチは断続的である。
進行中の採掘にフィットする一口サイズのユーザーリサーチを行う。
ユーザーリサーチは、専門のリサーチャーに外注せず、チーム全体で行い、責任を分担する。
これにより、詳細な文書がなくても、意思疎通を図ることができ、学習の質も高まる。
重要なのは、チーム全体で共通理解を深めること。
ユーザーリサーチ
ユーザーリサーチによって得られた未加工のデータから、意味のある情報を取り出すのは、時間のかかるフラストレーションのたまりやすい作業。
そのため、リサーチ結果を外部に委託してしまうことがあるが、これはできれば避けるべきこと。
ユーザーリサーチが終わったら、できれば同日、少なくとも翌日に、チーム全体でレビューを行う。
ユーサーリサーチの結果
結果をまとめようとすると、データが矛盾を示すケースが出てくる。
このような時の対処法は以下。
- パターンを見つける パターンとは、特定の要素に対してユーザーの意図が繰り返し向けられていることを意味する。パターンに当てはまらない場合は、異常値であるとみなす。
- 異常値は、駐車場に置く（いったん脇に置く） 異常値を見つけた時は、無視する（またはソリューションで対処する）。 しかし、暫定的なものとしてバックログに記録しておく。 継続していくにつれ、他の異常値が見つかることで、パターンが示される場合がある。
- 他のソースを使って検証する あるチャネルから得られたフィードバックの妥当性に確信が持てない時は、他のチャネルを使ってそれを確認する。 カスタマーサポートのE mailを対象にしたユーザーリサーチの結果は、ユーザビリティのリサーチ結果と同じ懸念を示しているか？ オフィス内外のユーザーは、プロトタイプの価値について同じ意見を持っているか？ そうでなかったら、サンプルに偏りがあったと考えられる
カスタマーサービス
カスタマーサポートに連絡し、取り組んでいるプロダクトやサービスの部分について、ユーザーからどのような話を聞いているかを尋ねる。
今月、ユーザーが好んだものは何か、好まなかったものは何かを議題にする。
月末にカスタマーサービスとコミュニケーションをすることで、チームは自らの取り組みが成果を上げているかどうかを知るための明快な指標を得ることができる。
課題が上位10件のランキングにとどまっていれば、ソリューションが効果をあげていないと判断される。
オンサイトでのフィードバック
以下オプションで、フィードバックの仕組みを設ける。
- シンプルなEメールフォーム
- カスタマーサポートフォーラム
- サードパーティのコミュニティサイト
これにより以下のような目的のリサーチで使える。
- サイトの特定セクションから受信したEメールの数をカウントする。
- オンラインディスカッションに参加して仮説をテストする。
- 被験者が見つけにくい場合には、コミュニティサイトを活用して募集する。
検索ログや、サイト利用状況の分析、ABテストによって、機能の使われ方や使いやすさを調査する。
サイト利用状況には、KissmetricsやMixPanelといったサードパーティのメトリクスプロダクトを用いることができる。
ABテストには、Optimizelyなどのサードパーティツールを使うことができる。
アジャイル
Lean UX をアジャイルの仕組みにどう適合させるかについて。
アジャイルの仕組みの重要なポイント
- 短いサイクルで作業を進める。
- 各サイクルの終わりに価値を提供する。
- 毎日、簡易的なプランニングミーティング（デイリースクラム）を開く。
- 各サイクルの後にレトロスペクティブ（振り返り）を行う。
重要なことはレトロスペクティブ
スクラムをやるとした場合、最初にやらないといけないことは、最初１、2回のスプリントの後にレトロスペクティブを取り入れること。
そこでは、チームの課題について気軽に本音で議論できるレトロスペクティブにしなくてはならない。
「何がうまくいっているのか？」「何がうまくいってないのか？」「今後、何を変えて行きば良いのか？」などを検討する。
スタッガードスプリント
デザイン工程をスプリントを一つズラして行うこと。
しかし、これは小さいウォーターフォールを行っているようなもので、ウォーターフォールからアジャイルに移行する時には有効だが、最終的な目標ではない。
なぜなら、同じことに対してチーム全体で取り組んでいる訳ではないから。
部門横断的なコラボレーションのメリットが得られない。
マルチスプリントテーマ
プロダクトゴールは、一連のスプリントをつなぐために用いるマルチスプリントテーマとみなせる。
それぞれのスプリントのテーマに対して、デザインスプリントを用いる。
つまり、仮説、検証、改善を顧客の価値基準で試していく。
デザインの細部について話すわけではなく、あくまで顧客が使うか、それによって得られるメリットを念頭に置いて、スプリントを繋ぎ合わせていく。
エクスペリメントストーリー
デザインスプリントなどでカバーしきれなかったディスカバリ作業を、そのイテレーションで追加的に実施する必要がある。
それにより以下の利点がある。
- ディスカバリ作業を可視化する
- デリバリー作業への優先順位付けが必須になる
- ユーザーストーリにーに対しての優先順位を、いつするか、どれを作業しないについて議論する
プランニングには全員が参加する
全ての活動（スタンドアップミーティング、レトロスペクティブ、プランニングミーティング、ブレーンストーミング）にチーム全体が参加すべき。
それにより、共通理解が学習され、たとえ9割が自分に関係のないことだとしても、関わる1割の情報によってその後の作業の何時間かを節約できるケースがある。
ステークホルダーとリスクダッシュボード
プロダクトオーナーやステークホルダー、CEO、クライアントは状況を詳しく知りたがる。
プロジェクト計画を自らの判断で承認したがるから。
しかし、成果重視型のチームにとって、プロジェクト計画は学習した内容に応じて変化していくもの。
そのため、1回の計画で予定する作業量は多くない。せいぜい1つまたは2つ先の凍レーションを計画している程度。
しかし、マネジメントはこのような計画を「近視眼的な」ものと捉え不満を抱きがち。
そう言う中で、マネジメントに上の介入をされないようにするための方法。
事前対応的なコミュニケーション
追加した機能をリリースすることを事前に告知しておくというもの。
そのために、強力なツールとしてリスクダッシュボードを作成しておく。
これによって、ステークホルダーに次のような情報を提供できる。
- 作業の進行状況
- 次に注力すべきリスク
- 機能セットではなく、成果（目標に向かってどのように前進しているか）を重視していること
- 依存関係のある部門（カスタマーサービス、マーケティング、オペレーションなど）と、これらの部門が、今後自らに影響を及ぼし得る変化を認識しておくことの必要性
ロードマップ
これまでは、ロードマップがソフトウェア業界では使われていたが、デジタルプロダクトの開発は、直線的ではなく、イテレーション的なものなので、顧客行動を見て、どう影響を与えるかを観察し、再びイテレーションを回す。
そのため、出発点と明確かつ機能固有の終点（つまり締切）がある従来の直線的なロードマップモデルは、結果重視のデジタルビジネスの手法を反映するものであり時代遅れである。
プロダクト主導型では、成果主義を取り入れる。
そこで、成果ベースのロードマップを採用する。
エージェンシーにおけるLean UX
ここでいうエージェンシーとは、クライアントにサービスを提供する組織全般を指す。
エージェンシーにとって、クライアントとの業務では、クライアントの意向によるので、期待されることもあれば、やり方を拒絶されることもある。
そう言った場合でもLean UXは活用される重要なポイントが5つある。
どのような方式のビジネスか？
エージェンシーは、成果物ベースのビジネスをやることが多い。
これはLean UXとは合判するもの。
そのため、成果物を作るために稼働率を上げることを目的にしがちになってしまう。
そうすると、部門横断型のコラボレーションもできなくなってくる。
これらの解決しなければならない2つの課題に対するアプローチ。
従来型の成果物ビジネスから脱却すべき
タイムアンドマテリアル（工数単価）色のモデルに変えること アプリやデザインを売るのではなく、クライアントが抱える問題のソリューションを見つけるためにクライアントと共同作業をすることの対価として、報酬を得る形。 ソリューションは、プロジェクト開始段階では分からないが、それを一緒にクライアントと探す。
稼働率を高く維持するためには、少人数のチームを明確な更新基準の契約に基づき、期限付きで売り込むこと。
通常3ヶ月更新の契約で仕事をする。
そのため、短期間サイクルでの仕事の進め方を行いやすくなる。
これにより、仕事の進め方が合わないクライアントのために延々と働き続けなければならないというリスクも減らすことができる。
実験に誰もお金を払わない
クライアントは実験が嫌いで、実験にお金は絶対出したくないという考えが多い。
10万ドルの予算のうち、1万ドルを実験費として残りの9万ドルの最適な使い方を探る費用にしようと提案すると渋るだろう。
しかし、実験とはLean UXの一部ではありますが、単なる戦術である。
学習、適切な意思決定、ポジティブな成果を生み出すプロセスの一部である。
