TAMALOG

プログラミングがあれば遠いところへ行けます。プログラムと人の共生を記録します。

2020/06/29 今日の学び

転職してから29日目。最初こそ苦労したが、いまは前職の延長のことをしている。やっていることはあまり変わらない。マンネリ化しないようにたくさん挑戦したい。

今日は、神田昌典マーケティングの本を少し読んだ。マーケティングの名著だというが本当か。タイトルに「90日で儲かる」などと入っており、少々不安。

エモーショナルマーケティングとは、あなたがお客を探す方法ではない。お客があなたを探す方法だ、と前に説明した。

納得。だが、いまどきそれが当たり前のような気がしている。

f:id:tamanobi:20200630092428j:plain

この図は、「お客は、最初からあなたにお金を払おうとは思っていない。適切な段階を用意し、最終的にお金を払ってもらうよう設計する」ことを示している。この設計が大事だと、本では主張している。

2020/06/28 今日の学び

今日はジブラルタ生命保険の契約をした。ドル建ての10年払い終身保険。死亡、高度障害、疾病。コロナの影響で保険利率が大幅に引き下げられるらしいため、滑り込みで契約。FPの仕事はお金絡みで楽しそうだ。

ほかには、マーケティングの本を読んだ。売るために宣伝をするのではなく、お客さんが買いたくなるように見せるという基本を学んだ。

コーチングの本を読んだ。あとでまとめる。

本当は来週に控えた勉強会の内容を詰めるはずだったそこまでいけなかった。

コーチングについて

スタート地点

コーチングは、相手の考えを引き出して行動へつなげることだとざっくり知っていた。 私の先入観では、「人に伝えるためにしゃべることで思考が整理され、自己解決する」ラバーダッキングと似たようなものだと思っていた。 その気になれば、ルールに従った機械的な応答を返すだけでもある程度目標が達成できるのではないか?と考えていた。 「来談者中心療法のセラピスト」のように振る舞えるELIZAのように。

現状の理解

コーチングはcoacheeの中の知識を引き出し、行動を促し問題解決するためのものである。知識を与えたり問題を見つけるものではない。目標がなければ向かない。 コーチングは定期的に行う。coacheeの目的が整理され、目標が決まり、定期的にどうなっているか話をする。

読んだ本

amzn.to

学び

f:id:tamanobi:20200627114139p:plain

コーチの投げかける質問にクライアントの視点が変わり、物事がはっきりし、発想が膨らみ、そして行動を起こす意欲が湧いてくる。そのようなプロセスを作り出すことがコーチに求められる支援のあり方と言えるでしょう。

コーチングは教わらない。問題を見つけない。問い、解決に導く。

> コーチングは「知識と行動の間に横たわる溝」に橋をかける試みと言えるでしょう

コーチングは行動を促し、目標達成に導く。coacheeに知識を与えることが主目的ではない。 コーチングが有効に働く例として、知識が増えスキルも上がり意欲が弱まっている人が挙げられていた。

「あなたの話を聞いていて、あなたは◯◯◯という期待や目的をもっているように感じる。そこを目指してみるのはどうか」と提案することも役立つでしょう。

コーチングは、目標がない場合に有効に働かない。やりたいことがないならコーチングは向かない。対話を通じてcoacheeが持っている目的を提案することで意義のある時間になる。

簡単にまとめると、コーチングを通じてcoacheeの目的は整理され、coarchee自身が目標を設置する。coacherは定期的に話をしてモニタリングする。

ここまでがコーチングにおけるセットアップ。コーチングはセットアップ、実践、振り返りという3つのフェーズに分かれている。

モニタリングするときの観点が三つある。

クライアントの状態を把握するためコーチは3つの視点をもっています。それは、

・ポゼッション、身につけるもの ・ビヘイビア、行動 ・プレゼンス、考え方、信念

という視点です。これを「PBPの視点」と呼びます。

ポゼッション、ビヘイビア、プレゼンスの三つ。

ポゼッションの視点からコーチのする質問として、以下のようなものがあります。

・理想の状態に近づくために自分に必要なものは何ですか? ・目標達成のためにはどんな分野の情報が必要ですか? ・自分がいまもっている知識やスキルで使えそうなものは何ですか?

ポゼッションは、スキルや技術、知識の視点。目的と目標を達成するために何が必要かcoacheeに気づいてもらう。いわば、努力の方向のキャリブレーション

コーチはクライアントがどんな行動をするか、どれくらい行動しているかなどのBehaviorに注目しコーチングを進め目標達成を支援します。たとえば、コーチのする質問として以下のようなものがあります。

・やろうと思っていて実行できないことは何ですか? ・目標を達成するために今日からできることは何ですか? ・次回のセッションまでにどんなことをやりますか?

ビヘイビアは、行動の視点。知識と行動のギャップをcoacheeに把握してもらう。目標達成に必要な取り組みの確認と同意。

Presenceについてコーチのする質問としては以下のようなものがあります。

・あなたが大事にしている価値観は何ですか? ・環境の変化に合わせて、自分が変化すべきことは何でしょうか? ・その目標を達成することは、あなたにとってどんな意味がありますか?

プレゼンスは、目標達成を邪魔する意識に気づかせること。「人の時間を無駄にしてはいけない」というプレゼンスのもとに「人に聞かずに一人でやる」という行動をしていたりする。目標達成はときにはマインドセットを変えないといけないことを表している。

今日はここまで。

2020/06/26 今日の学び

転職してから26日目。仕事が終わったあと、前職メンバーと飲み会をした。みんな元気そうでよかった。みんな仲良くしてくれてとてもいい。ずっとつながっていたい。

高校生の情報の教科書に、データサイエンスの内容が含まれている。僕はそこを押さえていないのでとても焦りを感じた。 www.mext.go.jp

2020/06/25 今日の学び

転職して25日目。

最近体力が落ちていて、残業ができないようになってしまった。大した作業をしていないのに、19:00過ぎるとがんばったなぁと一息ついてしまう。

ここ1-2年は「お金」に執着するようになり、副業や起業について調べている。この本は、Kindle Unlimited にあったため読んでみた。

www.amazon.co.jp

「さまざまな本を読んでその内容を私見と合わせて Kindle 出版としてアウトプットしてお金を稼ごう」という一文で要約できる。分量も短く、長めなブログ記事程度の本に仕上がっている。 「Kindle はページがめくられることで報酬が入ってくる」という点は、初めて知ったので時間の分の見返りはあった。 epubで出版できるらしいので、僕が書いたKubernetes本に表紙をつけて出版してみようかと思った。

お金が入ってくるなら、やってみてもいいかなと揺らいでいる。 そもそも僕はアウトプットが少なくなっており、深いインプットができていない自覚がある。

「売れる本を、誰かのためになる本を作る」というモチベーションであれば、より一層深い理解に取り組めるんじゃないかと思っている。

2020/06/24 今日の学び

転職して24日目。今日は、この本を読んだ。

www.amazon.co.jp

「あなたの人生を見返して強みを見つけ、週末を使って安全に起業しよう」という本。50代に向けて書かれていたが、テクニックで学びは多かった。自分の人生を年表として書いてみる試みは実際にやってみて気付きが多かった。昔はゲームプログラマになりたかったことを思い出した。

DDD実践の現場の増田さんの話をまとめてみた

BPStudy#141〜DDD(Domain Driven Design)実践の現場 (2019/05/29 19:30〜) を聴講したときに、増田さんの発表がとても勉強になったのでまとめてみます。

簡単なこの記事のまとめ

  • DDDは「ソフトウェアの変更を安全に楽にする」ことが目的。振り切っている
  • DDDは、反復プロセスであって設計して終わりではない
  • 勉強には、増田さんの本を読んだあとに、エヴァンス本がおすすめ。ほかには教材(GitHubのコード)などが用意してあり誰でも参照できる
  • エヴァンス本は読みづらいが、コツがわかれば読みやすい

増田さんの資料

ドメイン駆動設計の正しい歩き方

DDDの目的

  • 進化するソフトウェアを手に入れる
  • 現実世界の変更に追従するソフトウェア
  • 動くだけではないソフトウェア
  • ソフトウェアの変更を安全に楽にする

もちろん、進化する必要のないソフトウェアもある。そういうものには不向き

ドメイン駆動設計の考え方

ソフトウェアの複雑さはビジネス活動の複雑さに由来する。ビジネス活動ではなく、 ビジネスルールがソフトウェアを作るときに影響してくる。

  • ビジネスルールとは、ビジネスの活動を駆動し、制約する約束事のこと。ビジネスをうまく回する制約のことだったり、ビジネス上の約束事だったりする。
  • ドメインロジック: ビジネスルールをコードで表現したもの

ビジネスルールをよく理解してモデリングするためには、ビジネス活動を継続的に学ぶ必要がある。ただし、コアとなるビジネス活動を見つけ出し、集中すること。闇雲にやり続けてはいけない。

DDDを実践するための問い

以下の問いを、DDD導入時だけでなく 継続的に問い続けること が重要

  • コアドメインに集中しているか
  • ビジネスを深く洞察しているか
  • ドメイン層を独立させているか
  • モデルと実装を密に結合しているか
  • システム間の秩序の改善を続けているか

脱線しがちなパターン

ビジネス活動から目をそらす
テクニカルな問題に対してとかに発生しがち。
全体を均質にカバーしようとする
すべてを値オブジェクトにしたくなってきたりするが、すべてそうするのは悪手。あくまでも本質を見出しそこを徹底的に改善していく
ビジネスを表面的にとらえて理解した気になる
表面的に捉えてからが本番なので油断してはいけない
ドメイン層に入出力の関心事を持ち込む
画面やテーブル単位で考えてコードを書くのは間違い。それは本質的になっていない。画面やテーブルがなくてもドメインモデルは育てられるし、テストだってできる
モデルと実装を切り離す
「実装がきれいになるから」などの理由でモデルと実装を切り離してはいけない。ソフトウェア変更時に苦しむことになるし、きれいになった気になるだけ。
システム間を力づくで連携させる
「相手方のインターフェースに合わせればいいや」となりがち。ビジネスにおける本来の連携を考えつづけ、改善し続けられるか?相手のシステムならこういうドメインモデルにしたほうがいいんじゃないか?と試行錯誤すること。

事例研究: ホテルの予約アプリケーション

  • DDDハンズオンでよく使っている
  • ほかのドメインを無視して(コアドメインを見つける)、料金計算を独立させる。それだけでテストできるように作っていく
  • DDDは、現実のビジネスルールから、モデリング、実装まで段階を踏んで終わりではない。何度も繰り返して改善するもの
  • ずっと紙とにらめっこしてしまうのは間違っている。コードに起こしてみて妥当性を確認する。何を軸にするにするか決めきれなくても、候補をすべてのパターンをコードに起こす
  • 上手く回るとコミュニケーションロスも減る

ビジネスを深く洞察するための問い

  • 中核となる料金ルールはなぜそうなっているか
  • 周辺の料金ルールはどういう意味か
  • 周りのシステムにどういう情報を渡すか。仕入れの管理ツールとの連携はどうあるべきか?

現場に導入するポイント

  • 想定読者の要件をクリアする(要件クリアは結構シビアだが、クリアするためのおすすめ書籍がある)
  • 28ページの抜粋版を読む
  • エヴァンス本をちゃんと読む(即効薬ではないが、じわじわ効いてくる)
    • この本は読みづらい。 読み方にはコツがある

教材

増田さんの意見

エヴァンス本を読むコツ

  • 紙を読んだほうがいい。流れがつかみやすい
  • 検索したいときは電子版が役立つ
  • 増田さんは、電子版と紙両方、それぞれ邦訳と原著を持っている(計4冊)
  • 実践で役立つテクニックは3部、4部にある

エヴァンスの文章スタイルに慣れる

章、セクションに共通して以下の流れがある。 無視して良い箇所があるので、見極めて読むと非常に読みやすい

  • 体験談: わけのわからない話が始まる。あとで読んでやっと理解できるため、最初は無視して良い
  • 設計課題と考えの説明: ようやく設計の考え方の説明。ここをじっくり読む
  • 他の事項との関連性の説明: 話が発散しがちなので一旦無視してよい

質問への回答

ドメインエキスパートが説明が下手だった場合どうするか?

  • ドメインエキスパートが説明が下手だった場合、「間違った具体例」を持っていく。そうすると喋ってくれる
  • ビジネスルールについては、バックオフィスの方が一番詳しい場合がある。「期日を過ぎたらどうなるんですか?」などの境界値となるケースに答えられるのは経理だったりする
  • スタートアップなどでエキスパートがいない場合、みんなで考えるしかない