エンジニアが「ザ・モデル」を読んでみて
目次
動機
プロダクト開発で開発メンバーをしているアラサーエンジニアです。
弊社の開発チームは6,7名でSaaS製品を開発しています。
その中で、マーケティング兼営業を担当している方に「僕エンジニアですけど、マーケティングも少しかじっておいた方がいいかなっていう殺伐としたイメージを持ってて、なんかいい本ないですかね」という話しから教えてもらいました。
この本はSaaS製品の営業活動をどのような体制で管理していくのが良いか。ということが書かれています。
なぜエンジニアの私がマーケティングを知りたかったのかというと、日々の会話でよく聞いていた「インサイドセールス」とか「カスタマーサクセス」とかいうワードがなんじゃらほい状態だったことと、
プロダクト開発の相手は基本的には目に見えない（見えにくい）ユーザです。
そのユーザに対してマーケティング分野の視点も持てると、微力ながらユーザを意識した開発の一助にななるのでは？という思いから、思考の幅を広げる意味で読みたいなと思ったからです。
この本では以下の4つのフェーズを「レベニューモデル」と呼んでおり、どのように管理・実行していくかについて書かれています。
これらは顧客の購入意欲ごとに区切られており、それぞれの視点で顧客へアプローチ行います。 （厳密には、カスタマーサクセスは購入後のアフターフォローといったイメージですが）
弊社ではこれら４つを一人の担当者で回していますが、本来これらは意味的な縦割りによる分業を行いながらユーザへアプローチを行います。
（ここでの意味的なというのは完全な縦割りではなく、各フェーズでSFAやCRMでの密な連携が行われている）
マーケティング
製品提供会社とユーザのファーストコンタクト。
ファーストコンタクトと言っても、現代は自社Webサイトに製品情報がほとんど記載されています。
ユーザはWebサイトに記載されていることを見て、この製品でやりたいことを実現できるかのジャッジを行うフェーズです。
このフェーズでは「認知拡大」と「リードの獲得」に焦点を当てます。
プロダクトサイドで言うところのドキュメントやデモ動画、展示会、メディア露出などにあたります。
ユーザが自社の製品ページでどこの画面に遷移しているのか、どのようなアクションを行ったのか、セミナーに申請があったのか、さらに参加したのかを管理します。
これは後続のインサイドセールスで活用するための証跡となります。
現在でいうとZendeskなどの製品を利用することで、製品ページのどこを見たのか、どれくらい滞在したのかを確認することができます。すごい便利。
インサイドセールス
ユーザが「やりたいことを実現できるかも？」というフェーズです。
このフェーズでは、ユーザの属性情報がフォーム入力されて送信された、または展示会での名刺交換などがあたります。
これらは「リードの獲得」としてインサイドセールスに渡されます。
インサイドセールスでは「契約の見込みがありそうなユーザかどうか」を振るいにかけます。
振るいというのは、実際にどのような悩みを持っていて、それが自社の製品で解決可能かどうかのジャッジを行います。
よくあるプロジェクト開発でいうところの「私たちはこういう悩みを持っていて、こういうことが出来ないかな？」という要求定義のようなフェーズですね。
このフェーズで脈あり！と印が押されたユーザは後続のフェーズへいきます。
営業
提案～クロージングフェーズです。
弊社入社当初、営業というと「マーケティング～カスタマーサクセス」まで一通りのことを意味していると誤解していました。恥ずかしい。
この分野については読み飛ばしました。
（エンジニアだから・・・という怠k）
必要になったら勉強します！
カスタマーサクセス
製品購入後のアフターフォローのフェーズです。
SaaS製品の多くは買い切りというよりは、サブスクリプションや従量課金を主にしているかと思います。
つまり契約とは別に、継続的に更新してくれるまたはアップグレードをしてくれることも重要になってきます。
ここではユーザのコミュニティの重要性についても記されており、いわゆる口コミで広まるのが一番だよね。という記載があります。
最近よくテレビCMで見るkintoneも、製品を中心としたコミュニティの活動にとても力を入れているなと、実際にコミュニティを見て思います。
最後に
本書ではマネジメントについても記載されています。
社員のモチベーションという命題について「ビジョン・ミッション・バリュー」を明確にすることが大切と著者個人の思いが2Pくらいで記載されている箇所があります。
このページが面白いなと思ったので少し紹介。
- ビジョン → 私たちはどうなりたいのか
- ミッション → なぜ私たちはそれをやるのか
- バリュー → なぜその道を選ぶのか（選択の指標）
この３点、どこかで見覚えあるなと思ったのですが「チームジャーニー」というアジャイル開発チームの成長を促すための本でした。
ビジョン・ミッションをチームの中で共有し情報の透明化を行い、実際にチーム開発でどのようなタスクを行うのか（バリュー）をチームが自立的に行えるようになると、チームは最大の力を発揮することができる。というものです。
こういった共通的なものは、エンジニアや営業に関わらず、感情を持つ人間すべてに言えることなんだと思います。
経営層、営業、エンジニアが共通のビジョンを持つことって、あまり上手く言葉にできませんが、理論値以上に価値があるんだなと色んな本を読んで感じます。
一番伝わる説明の順番 を読みました。
プロダクト開発チームで開発をしているアラサーエンジニアです。
弊社は人が少ないこともあり、基本設計・詳細開発・リリースまで担当させてもらっています。
その中で「今回の課題を解決するために、このような機能が必要になります」という基本設計フェーズでの打ち合わせを数回行うのですが、「うまく説明できてないなぁ。」「そもそも自分の思考をコントロールできてないな」という思いがずっとあり、その時手に取ったのがこの本でした。
どんな本か
だれかに何かについての説明をするとき、相手から「何を言いたいの？」や「結局何をすればいいの？」というはてなマークが返ってきたことがある人もいるかと思います。
では分かりやすい説明とはなんなのか？どのような順序で、どのような構成で説明すれば相手にすんなり理解してもらえるのかについて書かれています。
今回はこの本の解釈を、私なりの目線も含めて書いていきます。
なぜ説明が下手なのか
「下手」と言うと少しグサっとくるかもしれませんので、「苦手」というオブラートで包んでおきます。
説明が苦手な人は以下３点の過ちを犯しています。
- 話そうとする事柄を時系列でそのまま話してしまう
- 相手に合わせた説明ができていない
- そもそも自分の中で整理ができていない
頭の中で考えたことをそのまま説明するのではなく、一旦「整理」するフェーズが必要になります。
時系列をそのまま話すとは、思い付きで話すと同義であり不要な情報が多く含まれがちです。
また、自分の頭の中で整理できていないのであれば、そもそも説明しようがありません。
「整理する」とは、具体的にどのように実行すべきかについてもこの本に書かれています。
それが書き出すということです。
書き出す行為は自分の頭の中にある情報。つまりは主観を客観することができるのです。
- 今回説明することについて、聞き手に必要な事前情報はあるか
- 重複した情報がないか
- まとめられる情報はないか
- どのような順序で説明する必要があるか
- 不足した情報はないか（これについては事前に知識を集めるフェーズが必要になるかもしれません）
これらの結びつきをノートで紐づけしながら、説明順序を構成する必要があります。
「説明する」という行為の究極的な目的は「相手に何かをしてもらうこと」です。
例えばそれが、許可をもらいたいのか、意見が欲しいのか、どうすれば解決できるかの助言をもらいたいのか、はたまた単純に情報の共有なのか。
最終的に相手にどのようなアクションを取ってもらいたいのか。という大前提をブレずに持つことが分かりやすい説明の入り口なんだと思います。
分かりやすい説明とは
では、分かりやすい説明とはどのような説明なのかについてです。
本書では以下の5つの順に説明することが分かりやすい説明であると述べられています。
- 前提を揃える
- 結論・主張・本質を述べる
- 根拠・理由・事実を述べる
- 補足情報があれば付け加える
- 結論を述べる
前提とは、今説明する事柄の範囲（スコープ）について共有します。
これは他の書籍でも良くあるメンタルモデルを共有するということです。
最近読んだ「世界一流エンジニアの思考法」の本でも「一流エンジニアは複雑な事象理解するためにメンタルモデルを持っている」という言葉があります。
メンタルモデルは、話す事柄についての地図のような働きをします。
このメンタルモデルが話し手と聞き手で合致したイメージを持つことが「前提を揃える」ことなんだと思います。
そして「結論・主張・本質」を述べた後、それについての「根拠・理由・事実」を述べます。 補足情報があれば補足し、最後に再度結論を述べます。 1～4までの説明で時間が経過していることもあり、聞き手が「あれ、最終的に何をすればいいんだっけ」となりかけた時に、再度道しるべを示すような締めくくりをします。
最後に
この本や、途中紹介した「世界一流エンジニアの思考法」、そのほかの本にも同じく書かれていることに、 「しっかり物事を理解することが大切」という言葉が何度も現れてきます。
自分自身で理解できないものは説明しようがありません。
理解する。ということはそれ相応の時間が必要になりますが、理解せず付け焼刃の知識だけをやりくりし「あれって何なんだっけ」ということがあれば都度都度検索して、その時だけ分かった。という状態は、中長期的に見て生産性が低いです。
しっかりと理解し次のステップに進む。その時に時間はかかりますが、それは確実な一歩なんだと思います。
「チーズはどこへ消えた？」を読みました。
どんな本？
「変化」に対してどう立ち向かうかを、ストーリ仕立てでサクサクと読み進められる本。
内容は、２匹のネズミと２人と小人が、日々迷路の中に存在しているチーズ（価値のあるもの）を求めて冒険する物語になっており、ある日突然ずっとそこにあると思っていた大きなチーズが消えたことから、単純な脳を持つ２匹のネズミと、感情や複雑な推理をしてしまう２人の小人がどのように感じ（ネズミに思いはないですが）、どのような行動をして、どのような結果になったのかが書かれた本です。
変化すること
この本の中の登場人物である2人の小人、ホーとヘムのホーは、「変化することの恐怖」に対する偏見を捨て、行動してみると案外面白いんだなということに気が付き、どんどん変化を受け入れ前進します。
一方ヘムは「ずっとここに居たんだから、もうここから動きたくはない」と変化することを拒絶する場面があります。
変化を受け入れたホーはどんどん新しい経験、景色を見て、新しい味のチーズを発見します。
私がこの本を読んで感じたことと吸収したいなと思ったことは「変化することの恐怖」に対する偏見を捨てる。ということです。
ヘムのようにコンフォートゾーンにずっと居るのは居心地が良いです。今思うと私自身もコンフォートゾーンに2,3年居たよなぁと思いながら読んでいました。
その時は新しいプロジェクトに移りたいという意向だけは伝えていたこともあり、現在は新しいプロジェクトで様々な経験を積ませてもらっています。
ですが今でも大きく変化することへ恐怖は感じてしまい、脳が一瞬尻込みをしてしまうことがあるので、まだ「変化を楽しむ」という境地まではいけていないのだと思います。
例えば、ランチに行く時はいつも行きつけの店ではなく、少し変わった店に入ってみるだったり、小さな変化を楽しむ習慣を付けた方がいいのかなとも思ったりしています。
「スタンフォードの自分を変える教室 」を読みました。
どんな本？
人間の「意志力」、「自己コントロール力」とはを、科学的に証明された事実を基に解説された本です。 心理学や経済学、スポーツ科学、学生への試験的な実験など、様々な分野の研究結果から「意志力」、「自己コントロール力」がどのような仕組みになっているかについて記載された本です。
「つい仕事を先延ばしにしまう」や「ダイエットや禁煙にチャンレンジしたけど途中で挫折してしまう」という悪しき行動を取ろうとしたとき、その時人間はどのように感じて、どのような決断を下してしまうのか。 そしてその悪しき行動を取らないようにするには、どういう思考や訓練があるのかについて学べました。
「意志力」とは
「意志力」
本書で書かれている「意志力」とは以下の３つのことを言っています。
- やる力
- やらない力
- 望む力
1.やる力
自分のやるべきことをやる力、やりとげる力。
イエスというときにイエス！と言う。
脳科学的には左脳が引き受けている。
2. やらない力
悪しき行動、習慣をやらないようにする力。
ノーというときにノー！と言う。
脳科学的には右脳が引き受けている。
3. 望む力
自分が最終的にどのような結果を期待しているか、どのようになりたいかの軸となる目標。
本書では「肝心なときに自分にとって大事なモチベーションを思い出す」力と定義されています。
例えば「つい仕事を先延ばしにしまう」に対する望む力としては、「昇進して責任のある仕事をまかせてもらいたい」というものです。
脳科学的には前頭前皮質が引き受けている。（以下、wikipedia引用）
前頭前皮質による機能を表す最も典型的な用語として、実行機能 (executive function) がある。実行機能は対立する考えを区別する能力の他、現在の行動によってどのような未来の結果が生じるかを決定する能力、確定したゴールへの行動、成果の予測、行動に基づく期待、社会的な"コントロール" (もし行ってしまったら、社会的に容認できないような結果を引き起こすような衝動を抑制する能力)に関係している。
望む力は前頭前皮質で管理されているので、悪しき行動を取ろうとしたとき、本来自分が望んでいる結果を思い出し、やる力とやらない力を行使することができるようになります。
脳は1つでも「自分」は2人いる
自分の中には「賢い自分」と「だらしない自分」の2人が共存しており、自分にとって悪しき行動を取ろうとするときに「だらしない自分」が顔を出してくる。
この「だらしない自分」に『なまけもの』等の名前を付けようと言っています。
名前をつけることで、そういう自分になりかけた時に「賢い自分」が気付き、思いとどまるキッケカになるという小技があるそうです。
「意志力」を鍛える
「意志力」は湯水のように無限に湧き出るものではなく、ある程度の限界があります。
その限界を引き上げる訓練として「スケジュールを立てて、立てたスケジュール通りの行動を繰り返す」ことで「意志力」が全般的に引き上げられると紹介されています。
他にも「利き手ではないほうの手を使って食事や歯磨き、ドアを開けたり」することで鍛えられるそうです。
どうにでもなれ効果に立ち向かう
掲げた目標を少し挫折した場合、どうにでもなれ効果が発生します。
（ダイエット中なのに高カロリーの物を食べたり、禁煙中なのに１本吸ってしまったり、仕事で叱られたとき）
どうにでもなれ効果が発生すると、さらに過食をするようになったり、１本吸ってしまったから残りの箱も全て吸ってしまおう。という行動によく出てしまいがちです。
これについての対策として紹介されているのが「なぐさめの言葉でどうにでもなれ効果が軽減される」です。
とある研究で、ダイエット中の２つのグループにドーナツをまるごと一つ食べさせた後、片方のグループにのみ「あまり自分に厳しくしないように、誰だってときには自分を甘やかすこともあるってことを、忘れないでくださいね。」と慰めの声掛けをし、そのあとにボウル入ったお菓子を自由に食べても良いという実験をしたそうです。
この研究の結果は、慰めの言葉をかけてもらったグループは、もう片方のグループよりボウルのお菓子が半分以上残っていたそうです。
慰めの言葉をかけてもらわなかったグループは、ダイエット中なのに・・・という罪悪感から「望む力」を正常に行使できなかったのだそうです。
現在私の会社に仕事が思うようにいかず、一つ資料の修正を行う度に上司から手直しを求められることを繰り返している社員の方がいます。 やる気がない部類の人ではなく、むしろ会社に貢献したいという気持ちが話の節々からも感じられる方なのですが、繰り返えされる手直し依頼の中でひどく「罪悪感」を感じてしまい、本来達成するべき目標（前頭前皮質にある最終的なゴール）をなかなか思い出せずに苦しんでいたんじゃないかなとこの本を読んでふと感じました。
「この1冊でよくわかるソフトウェアテストの教科書」を読みました
| 勝手に評価 | |
| ジャンル | テスト技法 |
| 概要 | 冒頭、要件定義～テストまでの流れについて記載されています。 冒頭以降は実際にテストを行う上での技法、ドキュメント、モニタリング、自動化について。 テストを体系的に学びたい方は読んでおいて損はないかと思います。 |
| レベル | 初級～中級 |
今まで私が行っていた明らかに間違っていた手法
現在担当しているプロジェクトでは、週2,3（小さめの機能追加）～2ヶ月に1回（大きめの機能）をリリースするアジャイル開発スタイルでフロントバック～単体テストを担当しています。
機能実装とテストコードを書く人が一緒になるので、テストを書く時は頭の中でパターンを思い描きながら記載していました。（自分の書いたコードはある程度頭に入ってるから大丈夫。と高を括っていました。）
脳内メモリ容量が多い人だとテストケースが漏れることなくテストを実装できる（最適なテストケースの定義を行うことができる）かと思いますが、
少し条件の複雑なコードのテストを書く際に、脳内メモリのオーバーフローが発生したり、単純に漏れていたりするケースがありました。
最悪な場合、テストケースの抜けに気が付かずユーザから不具合報告として挙がってきたりもありました…。
このように、少し頭を捻れば、または少し勉強すれば防げたであろうテストケースの書き方を本書籍では解説されています。
認識統一のためのドキュメント
まずはプロジェクト内でテストに向き合う際に用意しておいた方が良かったドキュメント2点
テストマップ
どの機能に、どのようにテストを行うべきであるかを定義するためのドキュメント。 プロジェクトメンバー内にテストに精通しているメンバーがいない場合、真っ先に作成した方が良いと思いました。 テスト実装前段階におけるメンバー間の認識統一に最適だと思います。
また、新規参画者のテストへの向き合い方も、このドキュメントで補えそうです。テスト観点一覧表
実装した機能をどのような観点からテストを行うべきかを定義するためのドキュメント。
このドキュメントでは、各プロジェクトが何に重きを置いているか（プロジェクトの個性）も交えながら、テストマップよりも一つ掘り下げた次元で、どのようなテスト・確認を行うべきかを記載します。
例えば、商品の在庫を管理する機能がシステムの根源としてあり、在庫商品に対するアクション（仕入、販売、確認）を行うようなシステムの場合、アクションを行った後に正しい在庫であることを確認する旨をテスト観点一覧表に盛り込んでおく。等でしょうか。
テスト工数と欠陥を見逃すリスクはトレードオフに関係にある
組み合わせテスト技法について、「オールペア法」と「直交表」が紹介されています。
9割以上の網羅率を達成できる手法だそうです。（2因子間の網羅率を数学的に組み合わせ）
大手、中堅規模のプロジェクトであれば上記2つの手法を駆使し、網羅率の高いテストケースを設計し、テストエンジニアがテストを実行（テストコードを記載する）のかもしれませんが、 数名で担当するプロジェクトではテストと工数のトレードオフ、を吟味し、限定的なテストケースを考える必要があると思います。
「良いコード/悪いコードで学ぶ設計入門」読みました。
| 勝手に評価 | |
| ジャンル | 設計、デザインパターン |
| 概要 | 一人でクラス設計、メソッド設計を行えるようになるためのテクニック。 著者はリファクタリングを得意とする方で、リファクタリングを多く経験するなかで得た良い設計、悪い設計の基準を分かりやすく解説しています。 |
| レベル | 初級 |
イメージの付きやすい例（RPGゲームや金額計算）を題材にサンプルコード（Javaで書かれています）が記載されていて読みやすかったです。
この書籍を読んでまず第一に感じたことは、オブジェクト指向を強く意識されている書籍だなと感じました。
そのため、オブジェクト指向を前提に開発しているプロジェクト、かつもっと良いクラス設計、メソッド設計（もっと良いコード）を書きたいと考えている方にベストフィットするかと思います。
この書籍の根本として、神クラスは悪であり、どうすれば神クラスを根絶することが出来るのか。に重きを置いて解説されています。 プロジェクトの規模によっては、神クラスがあった方が実装スピードが向上する場合もあるかと思うので、そこはトレードオフでしょうか。
また、コメントや命名（クラス名、メソッド名）について触れられている章がいくつかあり
- userInfo（ユーザ情報、info必要？）
- isMemberHpMoreThanZeroAndIsMemberCanActAndIsMemberMpMoreThanMagicCostMp （引用：メソッド名長すぎ問題）
といったよく陥る命名の悩みの解消法についても記載されています。
勉強になったこと
凝集度
凝集度は、モジュール内における、データとロジックの関係性の強さを表す指標です。
クラス内で保持している変数が、そのクラス内のメソッド内とどれほど強く結びついているか。この結び付きが強いほど凝集度が高いと言える。 クラス内の変数を他クラスと結びつくような実装は避けること。
結合度
結合度は、モジュール間の、依存の度合いを表す指標です。
クラス内で利用される他クラスの数のこと。多くなるほどそのクラスを修正する際の影響範囲が大きくなる。 基本的にはクラスは単一責任を持つこと。他のクラスの機能を多く使っている場合はクラス設計を疑ってみる。
フラグ引数は使わない
引数にbooleanやint等のフラグを受け付け、呼ばれたメソッド内でそれぞれのフラグに応じた条件分岐処理を記載しないこと。
見通しの良い見栄えにする
for内でifを利用する場合など、continueやbreakを併用し見通しをよくすること。
if条件に否定形は避ける
if (!isEnabled()) {} // ×
if (isDisabled()) {} // 〇
リファクタリングについて
今担当してるプロジェクトで、プッシュせずにローカルでリファクタリングをしてみる。 この方法が一番勉強になる気がする。
今後はデザインパターンの勉強もしよう。
「プリンシプル オブ プログラミング」を読んで
| 勝手に評価 | |
| ジャンル | プログラミング |
| 概要 | KISS, DRY, YAGNI等のプログラミングの設計ガイドラインや思想等、それらがなぜ必要なのかが書かれています。 |
| レベル | 初級 |
序章ではコーディングをする上で最低限注意すべきガイドラインが記載されています。
私が今のプロジェクトに参画する前までは、思い描いた通りに処理が実行されれば良い。という、KISS, DRYといったエンジニア共通のコーディングルールを無視したコーディングを繰り返していました。
今プロジェクト内でコーディングしており、KISS,DRY,YAGNIといった言葉を知らない人、またはレビューで色々指摘されて改善したいなと思っている方にまず初めに読んでほしい本です。
内容自体はテクニック等の記載はなく抽象的です。
なので現行でプロジェクトに参画している、または過去にプロジェクトに参画してコーディングをしていた方向けになります。
