いうものが紹介されていた。単行本(ソフトカバー)DDDとあまり関係ない話だったけど、便利そうな考え方なので紹介します。LCOMにとっての凝集度最高の状態とはすべてのインスタンス変数がすべてのメソッドから使われている状態。メソッドから使われてないインスタンス変数が多いとき、凝集度が低いとみなす。この考え方を聞いて最初戸惑ったけど、いくつかのケースをシミュレーションしてみたところ、なかなか有用な尺度な気がしてきた。Deleteの2メソッドを持っていて、Deleteがインスタンス変数userServiceを使ってないとき、LCOMとしては凝集度が低い状態と言える。凝集度の低いクラスこういうケースの改善手法はクラスを分割すること。凝集度の高いクラスこれで凝集度の高い2クラスに分割できた。機械的にLCOMを適用して高凝集度を目指すのはよくない気がする。なくクラスが複数の責務を背負ってそうなわだかまりを感じたとき、LCOMを利用してコードを改善するのが良さそう。LCOMを使えば個人の感覚に依存せずに定量的な指標として使えるので、複数人で開発しているときに、コード修正方針への抵抗感を減らせて良さそう。Evansのドメイン駆動設計に、ファクトリとリポジトリの責務の違いが書かれていた。ファクトリは新しくオブジェクトを作るのが責務で、リポジトリは古いオブジェクトを再構築するのが責務だ、とのこと。ファクトリとリポジトリの違いをはっきり意識してなかったので、へえー、となった。この二つの責務は明確に分けておくべきとのこと。ORMツールには二つの挙動がわからないように隠蔽してしまうものもあるが、それは思いもかけない状態になってしまう場合があるので良くないとも書かれていた。確かに、RailsのActiveRecordは、DBに保存されているオブジェクトなのか新規オブジェクトなのかで挙動が変わることがたまにあって、何度かハマったことがある。いう点が嫌だなーと思っていたので、エヴァンスのこの意見はそうかもしれないなと思う。ファクトリ/リポジトリの責務の区別を試してみてもいいかもしれない。いう便利な言葉を知ったので紹介する。Object)の特徴の一つだ。「概念的な統一体」と日本語訳されているが、この言葉は意味がわかりにくい。「概念のまとまり」とか「概念の単位」のほうが理解しやすいと思う。Wholeとは呼べない。Wholeは値オブジェクトを切り出す単位の基準として使える。ユビキタス言語にマッピングされた概念を過不足なく表現できる属性の集合が、値オブジェクトとして切り出す単位として適切だと言える。「部屋識別名」という値オブジェクトに切り出す。ON/OFF、IPアドレス、サブネットマスク、ルーターIPアドレスを、「IPアドレス設定」という値オブジェクトに切り出す。(値オブジェクトに限らず使えるテクニックだと思う。)IDDDには以下のように書かれている。各属性が重要なパーツとなり、それらが全体として、値について説明している。他と切り離して属性単体としてみると、意味のある内容がえられない。すべてが合わさって初めて、計測値や説明として意味をなすものとなる。これが、単にいくつかの属性をひとつにまとめただけのオブジェクトとは異なる点だ。まとめただけで、それ全体がモデル内の何かを的確に表しているのでなければ、まとめること自体にはあまり意味がない。DevOps読書会がやっと読了しました。見る本当に長かった...いつ読み始めたのか忘れるくらいに長かった。1年以上かけて1冊の本を読み切りました。これまでに読書会に参加していただいた皆様に感謝を申し上げます。僕にとっては学びの多い会を最後まで続けられたのは、参加していただいた皆様の協力のおかげです。本当にありがとうございました。今のタイミングで、この読書会の経緯とこの会から学んだものを、僕の視点から整理してみます。DevOps読みたいなーと個人的に考えてたと思います。あるんじゃないかと期待していました。長期的に見ていい方向に会社を持っていくときに役立つ知識を学びませんか。DevOpsを一緒に読んでいくことにした、んだったと思います。読書会が始まりました。初期はもの珍しさも手伝って、まあまあ参加者が集まりました。みたいな誘い方をして、事務や営業の人にも参加してもらいました。読書会を始めた頃に、興味を持ってもらおうと思ってまとめたDevOpsとは何かっていう箇条書き。これを書いた頃は、組織の文化って何?みたいな感じだった。DevOps読書会向けに、devopsとは何かを整理してみた。最初の方は結構飛ばしながら読んでいて、記録を見返すと1ヶ月くらいで半分くらい読んでた。大きな変換点だったと思います。言葉の意味や、書いてる内容がわからない点についての質問がいっぱい出てくるようになった。自分の経験や気付きなどが語られるようになった。これらの点は、僕にとってはすごく貴重なフィードバックだ、と感じました。向かっていくのですごく質の高い学習だと感じました。参加者に聞いてみても好感触だったので、以降はこのスローペースでずっと読み続けました。DevOpsっていう本が、こういう読み方に向いていたなーとも思います。みんなでワイワイと俺はこう思う、僕はこうだ、と情報を交換し合うことで理解が進む本だった、と感じています。DevOps読書会は、これまでやってきた社内勉強会の中で一番うまくやれてる。毎日開催してるのに楽というのがすごい。他の会社の人を読書会に誘うのはどうだろう、というアイデアが出てきました。読書会が実現することになりました。ヌーラボさん、本当にありがとうございました!新しく参加される人も増えるので、その時点でまた最初から読み直すことにしました。新しい感想が聞けるならいいんじゃないか、とということになりました。Drinkイベントhttps://t.co/VhKgZs4bpSプログラマやデザイナなどを対象に、技術やデザインについて語りつつ飲みつつ交流。2018年8月31日ヌーラボさんからも興味を持った方に参加いただけて、フィードバックの幅がぐっと広がりました。会社がちがうと抱えてる問題や文化も違って、自分たちの無意識の前提にも数多く気づくことができました。したペースで続けています。色々な概念を含んだ大きなムーブメントなのだという事が、少しづつ分かってきます。12:00から30分というルールにして運用していきました。2018年8月から年末くらいまでこのころから、読書会ができない日が多くなりました。初期はたまたま僕が時間が取れてる日が多かったのですが、このころ時間があまり取れないことが続いて、参加者もあまり集まらず、休会が多くなりました。2018年11月14日この時期は読書会の進め方について悩んでた時期で、僕が会に時間を割けないせいで、読書会というコミュニティのエネルギーが損なわれてるのではないか、と感じていました。がんばって時間を割くようにテコ入れしようかと思ったこともあったのですが、結局は「休みが多くても良い」というポリシーにすることに決めました。その理由は、この本で学習しているDevOpsというものが、ずっと続けられる文化を目指すものだというのが一つでした。継続可能な体勢を作るための学習が、誰かのがんばりに依存するようなものであってはうまくいかないはずです。あれば、目指すべきは無理をして短期間で終わらせることではなく、自分たちのペースでずっと学び続けることだ。休むことに罪悪感や引け目を感じることなく、堂々と「今日は参加できない」と言えるようにしようと思いました。緊急作業が入ったときにはこれを消費するのが良い、ということが書かれてました。問題ないよね、ということをメンバーで共有して、会の開催形式についても会自体で調節していきました。2019年以降あいかわらず休みは多かったですが、特にそれは問題ではないと考えて運用を続けました。他に参加者がいないときは一人で読み進めることも考えたこともありましたが、それは採用しませんでした。有益だと考えていたので、ゆっくりとみんなで学習することを楽しもう、と思って一人で先に読むことはがまんしました。あせらず、自分が楽しいと思える状況を維持することに気を付けて続けました。この活動は続けられる。自分に言い聞かせつづけました。そんな感じで読み進めてきた結果、ペースを保ったまま、なんとかこの分厚い本を読了することができました。学んだこといろいろと学んだことは多かったのですが、今思いつく範囲でこういうことを話したよなー、ということをせっかくなのでいくつか書いていきます。組織の文化とは何か組織の文化というのは、組織が内外について伝えたり、メンバーが実際に行動によって作られる価値観やみんなが信じること。文化について語られるのは組織の健全性について話すときで、メンバーが安全と感じているか、そうでないかというのが重要な観点になる。メンバーが安全と感じていれば、リスクを取って行動しようと考えるようになるし、安全でないと考えていれば、自分の身を守ろうと行動するようになる。リスクを取ることを組織が奨励しているか、それが口だけでなく実際の行動でもリスクを取ったことを責めないようになってるか、という点が心理的安全性に影響を与える。あとは何が重要かをはっきりさせていることも文化を作るのに重要。それがないと、みんななにが目標で仕事しているのかわからないまま仕事することになる。そんな状況はまずいだろ、と感じるかもしれないが、そういう組織は結構ある。固定思考は「人の能力は生まれつき決まったもので、行動によって変わらない」と信じること。成長思考は、人の能力は後天的に獲得できると考えること。能力の獲得だけじゃなくて、自分の無意識の前提に気づくことができれば、行動も変えられる、と考える。この本では固定思考は悪で、成長思考が良いという考え方を取っている。話している人は多いんだなーと今は感じている。失敗は悪、と考えてしまうのも固定思考で、成長するなら失敗するでしょ、と考えるのが成長思考。失敗はまずいこと、と考えてしまうのはどっちかというと自然な心の動きのような気もするので、人間はデフォルトで固定思考なのかもと思う。仕様を最初にバシッと決めたらあとはそれを実装さえすればいい製品ができる、という考え方も固定思考の結果だと思う。開発初期には自分たちは開発後期に比べて十分な知識がないはずなので、その時点の設計は間違っている可能性が高い、そう想定して開発することでリスクを減らせると考えるのが成長思考的だと思う。今まで失敗したことがない人のほうが固定思考になる傾向があるらしい。成長思考の考え方からすると、固定思考から成長思考に変わることも可能と考えるが、自分の中での気付きが得られないと、変われないので、なかなか難しいだろうなあとも思います。人を成長させるために必要なこと直接本に書いてあったことか覚えてないんだけど、読書会を通じて得た考え。人が成長するには、自分のボトルネックになってる無意識の前提に気づき、自発的に自分の行動を変える必要がある。するなら他人を成長させるにはどうすればよいかというと、自分の考えを相手に押し付けるのではなく、相手が気づきを得ることを手伝うのが有効なはず。そのためには相手の考えを聞き、それに共感し、事実に関してフィードバックするのが大事。回答になることを的確に相手に伝える必要はないし、それをすると逆に気付きが得られず、行動の変化につながらないことも多い。相手の心配に思ってることなどを聞く。それについて共感する。「そっかー、それは大変だね」「それはよかったね」と言ってあげるべきだ。それについての解答を最初に与えようとしてはいけない。それで相手は考えの整理が進む。次に事実についてフィードバックする。「間違ったSQLを実行してしまったために、そのリカバリーに半日かかったね」など。「そもそもなんで間違ったSQLであることに気づかなかったんだろう」というように、一緒に原因追求や、よりあるべきだった未来について考えてあげたりする。その中で、ボトルネックがどこにあるかを共有できて、それが自分の行動によって改善できる、と相手が気づけば、行動は変わるかもしれない。読書会を終えて定期的に学習時間を作って、ゆっくりとでも無理なく学習をつづけられたのは本当に良かったと感じています。同時に、もっとみんなに価値を感じてもらえる学習の仕組みを作っていきたいなあとも思ってます。無理なく、面白く、という両立は難しいだろうと思いますが、継続的に実験していきたいです。この本から学んだことを、実際のチームビルディングにも生かすことができました。調整役として最近まで参加していたプロジェクトで、各メンバーが懸念点を表明できる環境を保つことができたのですが、それにはこの本からの知見が活かせたと感じてます。何か別の本を読みませんか、という提案もいただけました。嬉しい申し出だし、僕以外の誰かに価値のある場と思ってもらえたこともすごく嬉しいです。次に何をやるかは決まってないんですが、みんなが興味を持てることをつづけられるといいなあと考えてます。抜粋です成長思考は"自分のスキルや知識は時間とともに変わると考える。今は特定の分野について大して知識がなくてもかまわない。十分な時間をかけて努力する。"固定思考と成長志向は、どこにプライドを持つかに関係あるのかなと思ったり。読書会よりメモdevopsが自動化やツールの話としてだけ語られるケースが多くあるが、それはおそらく、成果が定量化しやすく、聞く方も単純で理解がしやすいから。devopsの文化を説明・理解することはツールより難しい。devopsとは、ある意味では、アイデンティティだと思い込んでいるものを理解し、場合によっては変えていくことである。職務に基づいてアイデンティティだと思うものを内面化し、そのアイデンティティに一致しない行動を取る人たちを拒絶するとき、さまざまなことに影響を与える。どのようなエンジニアを尊敬するのか。採用活動のなかでどのような候補者を有望だと考え、どのように面接に臨むか。何を「内輪」だと思うかといったことだ。devopsとは、「私はもともとこういうことをしているので運用だ」と言うのではなく、「私は今こういうことをしているので運用だ」と言うべきということだ。これは、私達が固定思考に代えて成長思考を推奨していることに通じている。「devopsをしているかどうか」ではなく、問題をどのように分析し、アプローチしているかが大切だ。「devopsとは、アイデンティティだと思い込んでいるものを理解し、場合によっては変えていくこと」というのはすごく面白い。目標を立てて、それを組織で共有しつつ、かつ、それは固定の目標だと盲信せずに変えていくことが大切なんだろう。この「ある地点を目指しつつ、そこが正しいゴールかをたびたび見直す」感覚は、ただしいゴールに至るための大事な心構えだと思う。この考え方を忘れないようにしたい。DevOps読書会に出てきたいい言葉Tweet広告を非表示にするもっと読むコメントを書く2019-02-24スクラムフェス大阪2019が最高のカンファレンスだったスクラムフェス大阪、最高のカンファレンスでした。www.scrumosaka.orgパワーがすごい。様々な実践の共有があり、多様性もすごかった。スタッフの皆様のモチベーションも高く、しかもマネーに対するするどい嗅覚もそこここに見え隠れする。微笑ましい事例の紹介もあるし、そうかと思えば胡乱な取り組みを胡乱なスピーカーが発表し、場を胡乱な空気が支配するようなセッションもある。計画されたカオスがそこにあった。そこここに学びがあった。常に交流があり、お互いの状況を伝え合う中での自然なギブアンドテイクが生まれていた。主催者の提供するコンテンツを参加者が消費するような、一方向な情報の伝達ではなかった。主催者が提供していたのは、交流が起こる場だった。参加者はみなその場自体が価値を持っていることを理解していて、自主的に参加する。カオスはパワーを生み、予測できない相乗効果が発生した。メンバーのコミュニケーションを促進するのは消費行動ではなく学びであり、コミュニケーションを取るほどに創造性が生まれる。結果として、クリエイティブなカオスがそこに現出した。アジャイルの意義とは効率良く学習できることにある。いう意味で、スクラムフェス大阪はアジャイルの体現だった。統制の取れないすばやい学習がいたるところで行われていた。いろいろなスタイルの学びがあり、それで良いとする寛容があった。あふれるほどのリスペクトと感謝があった。「いかに儲けるか?」というビジネス目線の話も数多く、技術に偏ろうとしてしまう技術者とのバランスを取っていた。「ユーザーに価値を提供する、すると儲かる。俺達のスタイルは顧客に価値を届けるための手段だ。このやり方が正しいんだ!」そのような力強いメッセージが自信を持って語られ、実際利益を上げていることが説得力を与えていた。いう成功の匂いは、経営層にとって魅力的に映るだろうと感じた。素晴らしい場を提供していただいた、スタッフの皆様と参加者の皆様に感謝を。僕にできるせめてもの恩返しとして、僕が学んだことの一部をここに共有します。次回開催予定も決まっているとのことなので、興味ある方はぜひ参加してください。企業でOSSへのコミットを奨励する体制をつくりたい僕の兼ねてからの問題意識として、勤務先がスタッフにOSSへのコミットを許可、奨励するようにしていきたいということがありました。その理由は普段の仕事にOSSを使っているのだから、OSSに価値を返すべきだ、それが巡って自分たちにメリットとして返ってくるはずなので、長期的にメリットがあると思うからです。営利企業としては自分たちに利益がないとそのようには考えないので、どのように経営層に提案したら良いのか悩んでいました。そのような相談をしたところ、自分たちで使っているOSSを拡張するときにフォークするのではなく、OSS自身に取り込んでもらうのが良いと意見をもらいました。フォークしたプロジェクトはマージし続けなければならず、メンテコストが掛かるので取り込んでもらったほうが自社にとってメリットがあると伝えれば、OSSへのコミットを許可してもらえるようになるのではないか、という意見です。これは目から鱗が落ちる意見でした。「OSSへの貢献を許可してほしいと思ったときにはすでに!OSSへの貢献を終わらせているんだぜ!」ということですね。このやり方であれば、事実をもとに相談ができるので説得もしやすそうです。この問題は、個人的にずっと悩んできた問題だったので、その問題への見込みのありそうなアドバイスをいただけたのは本当にありがたかったです。実際に取り組んでみようと考えています。みな悩んでいるという気付き僕は自分の職場環境が、他の企業の職場のようにはうまくいっていないと感じてきました。話を聞いてみると、みなうまくいっていることばかりではなく、問題を抱えていて悩んでいるんだと驚きました。考えてみると、これは当たり前のことですね。問題というのは解決しても、また別の問題が出てきたり、問題を解決した事自体が新たな問題を生み出したりして、いつまで経っても問題は尽きないということです。みな今より良い状況を目指しますが、そこに到達すると次の目標が出てきてしまう。いつまで経っても問題がなくなることはなく、悩み続ける。みな悩んでいるんだと気づきました。考えて自分の歩いてきた道を振り返ってみると、強いプレッシャーの中でしたが、問題点に対処し続けてきました。対処だけではなく、問題の本質への対処も試してきた。いっしょに協力してきてくれたメンバーへの感謝がある。感謝を伝えあう文化が育ってきていて、以前に比べれば楽観的な会話が増えてきたと感じる。考えるといい方向には進んできているんだろう。そこにはコミュニティから今までにもらってきたアドバイスや、本から得た情報にも大きく助けていただきました。その恩返しとして、自分たちの取り組み、自分たちの成果、自分たちの失敗というものも、事例紹介してコミュニティに貢献してもいいのかもな、と思いました。大きな成功がなくてもスクラムをずっと続けているという事例confengine.com生存者バイアスというのは冷や水のような感覚があります。成功者によって自身の成功体験が語られても、「それはあなたがたまたま運が良かったからうまくいっただけでは?同じことを試して死んでいった無数の失敗事例を考慮に入れてないだけでは?」というような疑問が湧きます。いう意味で、この発表には勇気をもらいました。華々しい成功がなくてもずっと同じことを情熱を持って続けられる、それはそこにそれだけの情熱をかけるに値する価値があるのだという証だと思います。見返りがなかったとしてもそれを続けていくことができるか?それにYesと答えられることを人生で取り組めるなら、それは幸福な人生と言えるでしょう。この事例は、アジャイル開発に取り組むことに不安を持っている数多くの人に勇気を与えると思います。発表者の方と懇親会でお話することができましたが、情熱を持ったすばらしい方でした。参考になる事例の紹介を本当にありがとうございました。眺めたり、手に取ったり、パラ見したりしてみてください。会場に旅するアジャイル本箱というのが置かれてて、みなさんのオススメの本を知る機会になりました。それをキッカケに、僕もこの機会にいろんな本を買ったりウィッシュリストに追加したりしました。それらの本を共有します。見る最後にスクラムフェス大阪、本当に最高でした。ここには書ききれないくらいの数知れない学びと、勇気をいただきました。スタッフの皆様、本当にありがとうございました。16:42スクラムフェス大阪2019が最高のカンファレンスだったTweet広告を非表示にするもっと読むコメントを書く2019-02-22敬意の払い方スモールリーダーシップに、メンバーへの敬意の払い方について、すごくしっくりくる説明があった。一つ、メンバーはあなたと同じように横着だと思え...ここでいう「知性」とは、たとえ知らないことであっても、ミッションの達成に必要なことを学習して身につけていく能力を指しています。...メンバーをいわば「横着な賢者」だと考え、一緒に困難なミッションを達成しようとすると、リーダーが価値を置くべきことは大きく二つあります。なにより大切なのは、メンバーに「敬意」を払うこと、もう一つは「規律」の意識を持つことです。...ここでいう「敬意」とは、メンバーの持つ知性に対する敬意、すなわち、メンバーも自分と同じ情報を与えられれば、正しい解を導き出せると信じることです。相手が高い知性を持ってるとみなすことはすごく大事なことだと思う。自分と相手の認識や振る舞いに差異があるとき、相手の知性の不足だと考えるのは良くない。知性の不足が原因なのではなくて、今まで経験してきたことが違うために、同じものを見ていても違う側面を見ていることが差異の原因と考えるほうが健康的だし、人はみな自分が正しいと思いたがるバイアスが働いていることを考えると、おそらくこちらのほうが正しい。知性に対して敬意を払うということは「自分と同じ情報を与えられれば、正しい解を導き出せると信じる」ことだ、という説明はすごくしっくり来る。必要な情報を得れば、自ら考えて解決できると仮定して、その仮定から導き出される信頼ベースの付き合い方をすることが大事だと思う。これはメンバーのモチベーションにも良い影響を与えるはずだ。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。