ふりかえりカンファレンス キーノートを聞きました

kumahiraさん「リフレクション」って何?

confengine.com

リフレクションと対話を日本の当たり前に!

ダイアログとリフレクションについての書籍を執筆されている方。

なぜリフレクションが大事だと言われるようになったのか?

リフレクション:事故を客観的かつ批判的に振り返る行為。思慮深さなどと訳されることもある。

リフレクションを適応することで、物事に対して、批判的なスタンスで、経験から学び、考え行動することが可能になる。 なるほど

正解がある時代では、正解に辿り着くために、PDCAを実行することが大切であった→前例を踏襲してもうまくいかない昨今ではAARが大切だと思われる

行動→リフレクション→見通し→

ここから、反省は意味がない。 反省ではなくリフレクション。

反省は、結果に対して責任追及する行為。ネガティブなイメージが伴う。

リフレクションは、経験に価値があるという前提のもとで振り返る行為。

もっと最近では、このAARモデルをより早く行動することが求められている。

キーワード 「ビジネスモデルキャンバス」「デザインスプリント」「スクラム」「デザイン思考」これはAARの各フェーズのためにあるもの

リフレクションに欠かせないメタ認知とは何か?

メタ認知とは、認知していることを認知すること・自分が考えていることを俯瞰することが重要

認知の4セット * 意見、経験、感情、価値観 意見の背景にはこのよつつがある。 結論としての意見に重きを置きがちだけれども、それぞれの項目について考えることが大切

誰でも無意識にこの4セットを用いて考えている。

犬を見たときに 犬が好き(意見) 昔から犬を飼っている(意見) 喜び・安心(感情) 犬は癒しの存在(価値観)

内発的動機を引き出すリフレクションについて

クリエイティブテンション

ありたい姿と現状とのギャップを埋めようとする強い内発的動機のこと。 これが高まると、人はより創造的になる。 なるほど。

クリエイティブテンションがあると人は楽しいと感じる。確かに

確かにビジョンが明確になっているとき、ポジティブな振り返りができているかもしれない

動機の源 やりがいを感じる理由であり、あなたを突き動かす、大切な価値観である。自立型人材は、自己の動機の源を知り、活かすことができる。

例:Googleの例 ラリーペイジ氏とサーゲイブリン氏 インターネットの検索エンジンは、広告と同じように高いお金を払った人が上の検索結果にあることにとても苛立ちを感じた。 検索結果は必要な人に必要な情報が手に入るようになるべき。 これが動機。ありたい姿。クリエイティブテンション。

自分のクリエイティブテンションをどのようにチームに伝搬させればいいのか

主体性の変化 昔は第三者の意見。求められていることに対して積極的なのが主体性 今では、自分の意思とありたい姿に向かっていくことが主体性になっている。

共感を得られるビジョンの語り方とは?

感情のメタ認知 ネガティブの感情のメタ認知が有効 幸せな時は考えるのが難しい。

ネガティブなものについては、ありたい姿を考えやすい。 裏返せば願いがあるから。

ネガティブな感情についてメタ認知をしてみて、ありたい姿を考える。

価値観が満たされている(経験)→ポジティブな経験 価値観が満たされていない(経験)→ネガティブな経験

感情は、どのような価値観や経験を持っているのかのリトマス試験紙になっている。なるほど 感情に向き合うと、なぜそのような意見を持っているのかがわかる。

ビジョンを語る。

方針を語る→何を実現したいですか、メンバーへの期待はなんですか? ビジョンを語る→何を実現したいですか、あなたにとってなぜそれが大切なのですか。それに関連する経験はなんですか?メンバーへの期待はなんですか?

ビジョンを表面する意図は共感してもらうこと。自分の大切にしていることなどを語ることが大切。感情を合わせることが大切。 ストーリーテリング

ビジョンを語ることを方針を語ることとしてやってしまうのは良くない。

ミッション・ビジョン・バリュー(MVV) MVVの共有→行動計画→学びのサイクル MVVをちゃんと共有しないと、行動計画にうまくつながらない。どうしてやってるんだっけってなる。

MVV:ビジョンを語り聞き合うことで自分ごと化の連鎖が生まれる

経験から学ぶリフレクションとは?

経験→経験の振り返り→法則の発見→行動計画

www.insource.co.jp

想定していた結果はなんですか?→実際の結果はなんですか? 計画:どのような行動計画を立てていたか。

今までなんとなく「お気持ち」とかを書いてたけど、このような意図があったんだな

実際に振り返ってみたい。

想定していた結果:自己紹介で好印象を持ってもらおう 実際の結果:準備していた自己紹介を出すことができたが、緊張してしまったため、自分を見せられなかったかもしれない

計画 * 行動計画:オンラインの自己紹介なので、パワポを用意する * 仮説:パワポをつあくと口頭だけでもたくさんの情報を伝えられる 経験 * 経験:練習の成果もあり、スムーズに話すことができたが、緊張してしまい、固くなってしまった * 感情:プレゼン中ドキドキ、終了後ほっとした。その後ちょっと残念 学び:これらの経験から仮説を見直す

過去の自分。こうすればうまくいく!このくらいで大丈夫!これが正しい道だ!

意見:練習することで、スムーズに話せる 経験:大学で研究発表を行った。ものすごく頑張って、徹夜で潤をして発表に臨んだ。ところが発表の練習をしていなかったので、発表の時間が足りなくなってしまい、準備した内容を全部伝え切ることができなかった。 感情:残念、悔しい 価値観:高品質の追求

ダブルループラーニング。アンラーニング

メンタルモデルとは。一人一人が持つ世の中の人や物事にあkんする前提のこと。 メンタルモデルは経験を通して形成される →結果を作るのはメンタルモデルだ!とも呼ばれる

認知の4点セットと同じ。

ダブルループラーニング

問題に対して、既存の目的や前提そのものを疑い、それらも含めて軌道修正を行うこと。 それがダブル。

物事がうまくいかない時に、自分の外に原因を探すのではなく、自分のメンタルモデルを振り返ることが大切。

アインシュタイン「問題を起こした時と同じ思考では、その問題を解決することはできない」→メンタルモデルの話

アンラーニングとは 学びほぐしのこと。過去の成功体験などに基づき形成されたものの見方。行動様式をアップデートしていくこと これは難しい。 なぜ?

何を手放すのかというのがはっきりしない。 過去の結果や成功体験は大切だとしながらも、過去の成功体験から得られた学びを手放して、行動を変えること。 過去の成果に対してメタ認知を行う

何をアンラーニングする必要があるのか。 意見:PDCAを徹底することで、成果を上げてきた。しかし最近苦労することがある。 経験:これまで計画を徹底することでうまくやってきた 感情:心地よい 価値観:計画を立ててやることは良いこと

これをアンラーンする。 計画の質よりも、まず試してみることが大切であるということ。

アンラーンが難しいのはおそれの感情がある。 どんな? 精密な計画を持たずに行動することで、良い成果を出すことができないのではないか?という恐れ。

アンラーンをする必要があることに気づいたのにアンラーンしないのが一番体に悪い

ビジョン形成 変化の激しい時代にも、これまで通り、成果を出す有能な人材であり続けるために、アンラーニングに挑戦しよう!

少しずつ試しながら、小さなステップでアンラーンしていく。

友達だったり、チームだったり、みんなでリフレクションする。

対話にリフレクションが欠かせない理由

対話:自己を内省し、評価判断を保留にして、他者に共感する聞き方と話し方。 評価判断を保留にして、多様な世界に共感することで、自分の枠の外に出ることが可能になる。

対話では、リフレクションを通して自己の内面をメタ認知し、評価判断を保留にして、他社の話を傾聴する。 内省と共感。共感は賛成ではない。

対話から共創へ

対話スキルを上げることで、共創にいくことができる

価値観レベルまで対話すること

  • アンラーンするきっかけを気づくことはどうやってできるだろう。ネガティブなことを感じたらアンラーン?

  • チームの主体性を出すためにはどうすればいいのだろう→リフレクションをする。みんなで価値観レベルまで対話する。

Learn: アンラーンやメタ認知の4セットについて初めて知ることができた。 Action: 今まで全く考えたことがなかったので、普段から意識して生きてみる!

ふりかえりカンファレンス 「保育とふりかえりをコネクト!保育の会議が「問題対私たち」に変化した事例を紹介します 」

 「保育とふりかえりをコネクト!保育の会議が「問題対私たち」に変化した事例を紹介します 」

振り返りカンファレンスで、「保育とふりかえりをコネクト!保育の会議が「問題対私たち」に変化した事例を紹介します 」を聞きました。それのメモと感じたこと。

confengine.com

ケース保育園でクラス替えのフリア帰りをしているけどうまくいかない

議論が空中戦になるし、一部のメンバーが話しているだけになってしまう、結論が結局でない。さらに時間がいつもよりも伸びてしまう。

広さも関係している

クラス替えは、部屋の広さにも関係している

なるほど。。。

保育の先生

全員同席の原則

全員同席をしないと、結果として時間がかかることが多い。

予定合わせられないことに合わせているといつまでも決まらなかったりする。

でも業界では全員同席のハードルが高いことはあるが、最小限の関係者全員

事業所にいる全員が集まる。

今回はクラス分けの議論の対象者だけ集まるだけでもやった方がいい。

ホワイトボード

議事録をとってくれている先生はいるけど、全員がすぐに確認することはできない。

議論の場所を見ながらできないので、やっぱり議論が空中戦になりがち。

しかし、打ち合わせに、ホワイトボードを持ってくるのが難しい。

解決策:模造紙

議論の状況を付箋紙に貼って書いていくことで空中戦を防げる

模造紙を用意することで、「人間」vs「人間」から「問題」vs「私たち」にすることができる。

模造紙を前にして、問題に立ち向かうことによって、人間から問題を切り離すことができる

壁もなければテーブルで!

人間vs人間→問題vs私たちの構図にすることで、効果的な議論にすることができる

アジャイルソフトウエア開発宣言でも、対話することの大切さが書かれている

ファシリが難しい

この話し合いをよくしたいと思っている人を探す。

付箋紙に議論を書く人と、司会で分けてみるなどもできる。

ペア司会

問題vs私たちを実現するためには、ホワイトボードが必要だけれども、可視化することが大切。一人で全部するのは難しい。なので協力してくれる人とペアで司会するのも良い。

レトロのファシリ、いないのが理想とされている。けどいきなりそれに持ってくのが難しい。

振り返り手法

KPTやYWTに無理やり合わせなくてもいい。

やり方は色々

大事なのはみんなで一度立ち止まること。これまでどうだったかを振り返り、これからどうするのかをみんなで話し合うこと。

合わせた手法を作る

教室ごとに、何人いるのかを可視化→問題を見失わないように

その問題について、いい点、問題点、今後の心配点について話し合う

実際にやってみて

いい感じにいった。

関係者全員を集めることができたし、みんな主体的に参加してくれた。

時間より早く終わった→問題を見失わないようにできたからかも

そして、月一で振り返りをすることになった。

振り返りを続けるコツ

  • 一回で終わらせない

  • 小さな振り返りを高頻度に

  • 身近なところから始める

感想

learn:

  • 議論に課題感があるチームが、振り返りをする上で大切なことを知った上で振り返りの場をデザインする。

  • そのことで、会議が改善するだけではなく、職場も改善したりなど、良い効果が得られた話が、自分の課題感とも重なった。

  • 自分も振り返りに課題感を感じているけれども、もう一度原則を考え直して振り返りを考えてみようと思った。

TDD+モブプログラミングでワイワイする会 その40 に参加しました(原点回帰!)

TDD+モブプログラミングでワイワイする会 その40に参加しました!

その記録を残そうと思います

会の流れ

  1. TDDとモブプロについて、また今回のモブプロで意識することについての説明
  2. チームに分かれてTDD + モブプロする(1問目)
  3. 中間振り返り+休憩
  4. チームに分かれてTDD + モブプロする(2問目)
  5. 最後の振り返り

チームに分かれてTDD + モブプロする(1問目)

チームは四人で、私たちのチームでは一問目としてFizzBuzzPythonで解くことにしました。 まずToDoリストを作成し、テストを書き、TDDの「Red、Green、Refactoring」のループを回します。

私たちのチームは、TDDについて経験をしていた方がほとんどだったので、サクサク進みました。

最後に、「値が出力される」をどのようにテストできるかと言う話になり、Pythonのpytestにあるcapfdなどの機能を用いることで、標準出力に出力された値をassertすることができるという知見を得ました。

参考: docs.pytest.org

チームに分かれてTDD + モブプロする(2問目)

FizzBuzzが終了し、二問目として「Roman Numerals」という課題を行いました。

Roman Numerals - Coding Dojo

簡単に課題についての説明をすると、アラビア数字を入力し、ローマ数字を出力するメソッドをTDDで作ると言うものです。

一つずつToDoリストに挙げたテストとそれを満たす実装を繰り返していきましたが、あっという間に時間になってしまい、1~10までの実装しか行うことができませんでした。

最後まで実装することはできなかったものの、やはりTDDの醍醐味である動作するコードを常にアップデートしていくという感覚はとても楽しかったです。

テスト駆動開発」の書籍の冒頭でもありました「『動作する綺麗なコード』がテスト駆動開発のゴールだ」という言葉のように、まさに単体テストを重ねながらコードを書いていくことで「動作しながら、綺麗なコードを作り続ける」ことができることを実感できました。

shop.ohmsha.co.jp

最後に

半年ほど前にこのTDD+モブプログラミングでワイワイする会に参加させていただき、TDDに初めて触れました。そこから自分でTDDで開発するようになったり、会社でTDDYY会をやってみたりなど、最近ではTDDを自然に行うことができる様になってきていました。

しかし、最近では最初にTDDYY会でTDDを行ったときよりも、ToDoリストをサボってしまったり、一足飛びで実装してしまったりなど、TDDの作法から逸脱したことをしてしまうこともしばしばありました。

実は今回の参加のもう一つの目的は、自分の中で緩くなってしまったTDDの作法を叩き直すと言うものもありました。今回、みなさんとTDD+モブプロを行うことによってその目的を達成することができました!

これからTDDで実装を行っていく際は、作法にしたがってしっかりとTDDをしていきます!

第5回「オブジェクト指向のこころ」読書会に参加しました(モンスターボールはカプセル化だね)第5, 6, 7章

第5回「オブジェクト指向のこころ」読書会に参加しました!

オブジェクト指向のこころを読む会 Vol.5

今日やったこと

先週アレグザンダーの建築クイズに時間を使ってしまい、応用問題について扱うことができなかったので、第5章の応用問題について皆で話すところから話し始め、その後第六章と七章の問題を皆で話しました

第五章

応用問題

「慣れすぎてしまうことで、明らかなものを見失ってしまうことがあります」パターンを使うことでなぜこの様なことが避けられるのでしょうか

話したこと * パターンを適応することに熱心になってしまうと、杓子定規にパターンを適用することに躍起になってしまい、ここでいう「慣れすぎてしまうことで、明らかなものを見失ってしまうこと」につながらないか? * 本当の意味での「パターンを使う」とは、そのパターンが生まれる理由となった問題やパターンを用いる目的を理解した上で使うことである。正しくパターンを用いることで慣れてしまい、明らかなものを見失うことを防ぐことができるのでは? * CSD(認定スクラムデベロッパー研修)でも、デザインパターンはパターンを覚えるよりも、そのパターンが解決したい課題に注目をせよという話があった。この問題に関係していそう。

出てきた話を受けて、デザインパターンを覚えていくにあたって、パターン自体だけでなく、そのパターンが解決したい課題について意識できる様になろうと思いました。

パターンにおける「因果関係」と「フォース」の関係とはどの様なものでしょうか

話したこと * フォースとは、問題を解決する際に与えられる無数の解決策の中から、結果として一つの解決策が取られた時に、解決策が一つに選ばれる際に働く力のことを指す。例えば東京から大阪に行くという問題を解決するために得られる解決策として新幹線が取られるが、その解決策が取られる過程で予算や時間などの拘束条件が存在する。この拘束条件がフォースとなる。 * フォースについて理解することはできたが、「因果関係」という言葉が我々が一般的に用いている因果関係とは異なるかもしれない * GoF本の中では、「因果関係」ではなく「結果」と訳されている。実際にconclutionという単語は結果の意味の方が強いかもしれない。 * 問題文を因果関係ではなく、「結果」と読み替えると理解しやすい。これは「結果」と解釈して問題はなさそう。それなら理解できる。

「流動的要素を見つけ出し、カプセル化する」とは、どういったことを指していると思いますか?

話したこと * 例えば、OSの違いによるpathの表記方法の違いを吸収するpython のpath objectが例として考えられる。これはpathの操作と言う流動的要素をカプセル化することによって問題を簡素化している例ではないか * ポケモンモンスターボールカプセル化することによってポケモンと言う流動的要素を隠蔽することができる。複雑な仕様が介在せず、投げるだけでポケモンを繰り出すことができるので、カプセル化だ!

第六章

今回は第六章ではfaçadeパターンの日常生活における例についてのみ話しました。

応用問題

実生活におけるfaçadeの例を一つ挙げてください

  • 何か複雑なものの管理などをお願いするのはほとんどfaçadeでは?
  • 会計士さん、積立NISA
  • 通信技術などの複雑な技術を隠蔽しているチェットツールなどもコミュニケーションにおけるfaçadeかも。
  • お母さんはfaçade?

第七章

今回は第七章で、Adapterパターンの日常生活における例についてのみ話ました

実生活におけるAdapterパターンの例を一つ挙げてください

  • HHKBや自作キーボードなどの自分の好きなキーボードは、既存のキーボードのインターフェースを守りながらも、各個人のタイピングしやすさに適合するためアダプターではないか
  • チャイルドシートは、個人の体格と既存の車のシートの形状を適合するためのアダプターではないか
  • Amazonの梱包は、どんな商品でも同じ箱に梱包されることにより、配送者に配送する商品の形状や積み方を意識させない様にするためのアダプターなのではないか

などの話がありました。

最後に

今回も話がかなり弾み、全ての問題について扱うことはできませんでした。しかし、自分だけで問題を解いている時には出てこなかった答えを他の参加者の方から聞くことができたりなど、ひとりでは辿り着けなかったところに進めている感覚がとても楽しいです!

次回は、次には進まず、今回扱えなかった6, 7章の問題や、本文についての疑問などについて話す会にしようという話になりました!

第4回「オブジェクト指向のこころ」読書会に参加しました

第4回「オブジェクト指向のこころ」読書会(2024/01/31)に参加しました!

オブジェクト指向のこころを読む会 Vol.4

今回は第五章を読み、主に「あなたの意見」についてはなしました

あなたの感想

「パターンの真の力とは、あなたの思考レベルを引き上げる能力です。」これが真実であると感じた経験はあるでしょうか?例を挙げてください。

出てきた話

  • 音楽をやっていた時に、コード進行などで議論をするというのは、詳細なコンテクストの前提の上に議論をできていることに相当するかもしれない
  • あまり、「思考レベルを引き上げられている」と認識できたと思うことはうまく出てこないが、共有しているコンテクストがずれていることによって、議論を前に進めにくい、思考レベルが上がらない、などと感じることはあるかもしれないです

「死んでいる」と感じる建物や構造を思い浮かべてください。それに存在しておらず、より「活き活きしている」と思える類似の構造に共通して存在しているものは何でしょうか

「死んでいる」と感じる建物という概念がうまく理解できなかったので、この書籍の中で登場しているAlexander氏の著作である「The Nature of Order」に登場する建物から、「死んでいる建物」「いきいきしている建物」の例を挙げていただいた。

例の中から感じ取ることができた「活き活きしている建物」にでてくる建物の共通点としては

  • 建造物に一目で目につく中心的な構造が含まれている
  • シンプルな形状の要素で構成されている
  • 適切な余白がある

などの話が出てきました。 これらの話は、解釈を広げると「良いソフトウエア」にも共通する部分があるのではないか?と参加者で意見を交換しました

最後に

本日は、「死んでいる建造物」と「活き活きしている建造物」の話が盛り上がり、応用問題について話すことができませんでした。次回は5章の応用問題から皆で話すみたいです!

第3回「オブジェクト指向のこころ」読書会に参加しました

第3回「オブジェクト指向のこころ」読書会(2024/01/31)に参加しました!

オブジェクト指向のこころを読む会 Vol.3

今回は第三章、第四章を読み、「応用問題」と「あなたの意見」について参加した方々と回答の共有と意見交換を行いました。

第三章

第三章では、題材としている問題領域についての説明が主に行われていました。

応用問題

Q.CAD/CAMの事例が抱える本質的な問題とはなんでしょうか

話の中で出てきた回答

  • CAD/CAMシステムの後方互換性のないバージョンアップが頻繁に発生し、変更に工数のかかるエキスパートシステムがそのCAD/CAMシステムに直接依存している状態が発生するのはよくないという問題

Q. ポリモーフィズムは、ジオメトリーの抽出レベルで必要となりますが、フィーチャーレベルでは必要となりません。その理由はなんでしょうか。

話の中で出てきた回答

  • 「ジオメトリ抽出を行う」というレベルでCAD/CAMシステムのバージョン変更によってエキスパートシステムの変更を余儀なくされるのは好ましくない。そのためポリモーフィズムをジオメトリ抽出レベルでは担保する必要がある。
  • しかし、フィーチャーレベルにおいては、各フィーチャーの特徴や持つべきメソッドが異なることは自明なため、各フィーチャーの実装クラスの使用方法は異なっても問題がない。(=各フィーチャークラスがポリモーフィズムを満たしている必要はない)
  • 逆に異なる特徴を持つ各フィーチャーを無理やり抽象化してしまう方が危険なのでは?

あなたの意見

Q. 私はCAD/CAMの問題における用語定義に時間と紙面を割きました。この作業についてはどう思いますか?

話の中で出てきた回答

  • ユビキタス言語の話だ!!
  • 今回のCAD/CAMシステムのような複雑な問題を理解するために用語について合意を取るのは理解を助けるために重要。実際に用語表に何度も戻りながら本を読み進めた。
  • でもちゃんとユビキタス言語を遵守して開発するのって難しいですよね。どうしても形骸化してしまうような経験がある。
  • 表で管理する以外のいい方法などはあるのでしょうか。

第四章

第四章では、第三章で説明されていた問題について、実際にオブジェクト指向で解決するという話でした。

応用問題

本章で解説したCAD/CAMの問題を解決するためのアプローチを解説してください。また、このアプローチは妥当なものですか?

話の中で出てきた回答

  • 今回は三章で挙げられていた「エキスパートシステムがCAD/CAMシステムを使用する際に、エキスパートシステムが複数バージョン存在するCAD/CAMシステムのバージョンの差異に影響を受けてしまう」という問題を解決するために、複数バージョンのCAD/CAMシステムを包括するような抽象クラスを作り、エキスパートシステムからバージョンの差異を意識しなくても良いようにしたというアプローチをとった。
  • 今回の解決策だと問題があることが本には書かれていたが、このアプローチ自体は正しいアプローチだと思う。私もこのようなことをすると思う。
  • これ以外にどのような方法があるのか?

あなたの意見

詳細に踏み込むことをできるだけ遅らせてください。あなたはこれに同意しますか?同意する、しないに関わらず、その理由はなんですか?

話の中で出てきた回答

  • 詳細について話し始めると戻るのも難しくなる。抽象的な部分である程度成熟させてから進んだ方が良かった経験が多い。
  • 基本的に未来の自分の方が優秀(ドメインについての理解が深まっている)なので、初めから詳細に詰めて戻れなくなるのはリスキーですよね
  • 「詳細に踏み込まない」というのが「概念レベルで詰めきらないと実装に移らない」という意味だとすると、ちょっと賛成できないかもしれない。実際に概念をモデリングする際にコーディングを行いながらトライアルアンドエラーをしてみると、紙の上では気づけなかったことに気づくことが多い。
  • コーディングしながら、実際にクラスを設計してみるというのはとてもわかる。ではコーディングの初期段階で「詳細に入りすぎてるな」と思うポイントはどこか?
    • 処理のアルゴリズムなどについて考え始めるのはかなり詳細かもしれない。実際に試行錯誤フェーズではメソッドのシグネチャと仮の戻り値とかだけ決めて設計している感じ
    • DBのテーブルの型とかについて話し始めるとちょっと詳細かもと思うかもしれない。
    • 確かに、「モデリング→ある程度モデルが固まる→どう保存するか考える」みたいな流れにできると理想かもしれないですね。

「優れた解決策であると直感的に感じられなかった」という理由で、ある解決策を破棄しました。アナリストやプログラマは直感に従うべきでしょうか。

話の中で出てきた回答

  • これは難しい問題ですよね。。。時間が無限にあるなら、「なんかしっくりこない」でひっくり返したいところっていっぱいあります。
  • チームで開発していて、「ちょっとしっくりきていない」という理由である程度できているモデルを最初から考え直すとかって踏み切れないですよね。
  • 逆の立場で考えると、「なんか違う」でモデリングしていたものがひっくり返されてしまうのは賛同できないかもしれないですね。でも「なんか違う」というのは大切なメッセージだと思うので、「なんか違う」を深堀して、違和感の原因を引き出そうと試みると思います。
  • ドメインに明るい人が「なんか違うかも」って言ってたら絶対聞いた方がいい気がしますね
  • 逆に、自分が「なんか違う」と思っている時に、チームに違和感があることを伝えることは大切かもしれないですね。もしかしたら他の人で違和感を感じている人もいるかもしれないですし、それがモデリングの重大な問題を孕んでるかもしれない。

感想

普段の業務の話と本の内容を絡めて皆さんとお話しできたのがとても楽しかったです!

変化しにくい(させたくない)ものと、変化してしまうもの。この両方を繋ぎ止めるために頭使ってモデルを考えているのがとても面白かった。次回以降、デザインパターンの話に入っていくのでとても楽しみです!

次回について

次回は5章について行うみたいです!

第一回「オブジェクト指向のこころ」読書会に参加しました

オブジェクト指向のこころを読む会に参加しました。

オブジェクト指向のこころを読む会 Vol.1

やったこと

20:00〜21:00 第一章のもくもく読書会

21:00〜21:35 第一章について、疑問に思う点などについて話し合う

21:35〜22:00 章末の応用問題についてそれぞれの考えについて発表し、話し合う

気になったこと

  • この本での「カプセル化」について、他の書籍での説明と異なるという話が出てきた。手元にある他の本のカプセル化の説明とどのように違うのかを見比べてみようと思った。
  • 1.3で「システムの要求は変わるものとして設計をする必要があるよね」という話の中で、「システムの要求が変わるというより、要求への理解が変わることが多いよね」という話が出て納得した。
  • discordの「なるほど」スタンプが欲しいので作ろうと思った。

次回の話

もう少し応用問題について話す時間を取りたいので、次回は応用問題について意見交換をすることから行い、共有が終わってから本文の気になったところについて話し合うというような流れがいいかも。という話になりました。

感想

個人的に、「手続き型プログラミングからオブジェクト指向プログラミングに移行すると、main関数の責務を分散できるよね」という説明が好きでした。続きも楽しみ。