2020-08-23

Kotlin Courseの動画で得た学び

Kotlin Course - Tutorial for Beginners という動画があったので見てみた。いくつか学びがあって良かった。

private class として宣言すると、ファイルの中からのみ参照できるようになる。
class Entity() は、 class Entity constructor() の短縮記法。これを利用することで、 class Entity private constructor() のように constructor をprivate にすることができる。
クラス宣言内の init ブロックは複数設置できる。initブロックが書かれた順に実行される。
クラスはデフォルトで final。継承元クラスにしたければ、open class として宣言しないといけない。また、継承したいメンバーにも open を付ける必要がある。
val provider = object : Person { ... } と書くことで匿名クラスを作れる。読みにくそうなので使うことはなさそうな気がする。
companion object も継承できる。 companion object Factory : IdProvider {}
seales class の使い方

sealed class Entity() {
    data class Easy(val id: String, val name: String): Entity()
    data class Medium(val id: String, val name: String): Entity()
    data class Hard(val id: String, val name: String, val multiplier: Float): Entity()
}

プロパティを変えることができるので、そこが enum class との違い。

sealed class には class だけでなく、 object を含めることもできる。
String? に定義されてる orEmpty() メソッドは、null なら空文字を返す。 Array? や List? にも同様の orEmpty() メソッドがある。便利そう。

2020-02-16

凝集度の計測方法

ドメイン駆動設計入門に、凝集度を測る手法として LCOM(Lack of Cohesion in Methods) というものが紹介されていた。

ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本

作者:成瀬允宣
出版社/メーカー: 翔泳社
発売日: 2020/02/13
メディア: 単行本（ソフトカバー）

DDDとあまり関係ない話だったけど、便利そうな考え方なので紹介します。

LCOMにとっての凝集度最高の状態とはすべてのインスタンス変数がすべてのメソッドから使われている状態。メソッドから使われてないインスタンス変数が多いとき、凝集度が低いとみなす。

この考え方を聞いて最初戸惑ったけど、いくつかのケースをシミュレーションしてみたところ、なかなか有用な尺度な気がしてきた。

例として挙げられているのが、UserApplicationServiceがRegister, Deleteの2メソッドを持っていて、Deleteがインスタンス変数userServiceを使ってないとき、LCOMとしては凝集度が低い状態と言える。

f:id:kmdsbng:20200216154024p:plain — 凝集度の低いクラス

こういうケースの改善手法はクラスを分割すること。

f:id:kmdsbng:20200216154047p:plain — 凝集度の高いクラス

これで凝集度の高い2クラスに分割できた。

ただ、機械的にLCOMを適用して高凝集度を目指すのはよくない気がする。そうではなくクラスが複数の責務を背負ってそうなわだかまりを感じたとき、LCOMを利用してコードを改善するのが良さそう。 LCOMを使えば個人の感覚に依存せずに定量的な指標として使えるので、複数人で開発しているときに、コード修正方針への抵抗感を減らせて良さそう。

2020-01-19

ファクトリとリポジトリの違い

Eric Evansのドメイン駆動設計に、ファクトリとリポジトリの責務の違いが書かれていた。

ファクトリは新しくオブジェクトを作るのが責務で、リポジトリは古いオブジェクトを再構築するのが責務だ、とのこと。ファクトリとリポジトリの違いをはっきり意識してなかったので、へえー、となった。

この二つの責務は明確に分けておくべきとのこと。ORMツールには二つの挙動がわからないように隠蔽してしまうものもあるが、それは思いもかけない状態になってしまう場合があるので良くないとも書かれていた。

確かに、RailsのActiveRecordは、DBに保存されているオブジェクトなのか新規オブジェクトなのかで挙動が変わることがたまにあって、何度かハマったことがある。そういう点が嫌だなーと思っていたので、エヴァンスのこの意見はそうかもしれないなと思う。

ファクトリ/リポジトリの責務の区別を試してみてもいいかもしれない。

エリック・エヴァンスのドメイン駆動設計

作者:Eric Evans
出版社/メーカー: 翔泳社
発売日: 2013/11/20
メディア: Kindle版

2020-01-16

Conceptual Whole

IDDDで Conceptual Whole という便利な言葉を知ったので紹介する。

Conceptual Wholeは、値オブジェクト(Value Object)の特徴の一つだ。「概念的な統一体」と日本語訳されているが、この言葉は意味がわかりにくい。「概念のまとまり」とか「概念の単位」のほうが理解しやすいと思う。

1個以上の属性の集まりが、ある概念を形作るとき、その単位で値オブジェクトとして切り出すべきで、その単位をConceptual Wholeと呼ぶ。概念を部分的にしか表現できなかったり、逆に概念の表現以上に不要な属性がついてしまってるときにはConceptual Wholeとは呼べない。

Conceptual Wholeは値オブジェクトを切り出す単位の基準として使える。ユビキタス言語にマッピングされた概念を過不足なく表現できる属性の集合が、値オブジェクトとして切り出す単位として適切だと言える。

Conceptual Wholeとして適切な例を考えてみる。

郵便番号、都道府県、市区郡、その他住所を、「住所」という値オブジェクトに切り出す。
物件名、部屋番号を、「部屋識別名」という値オブジェクトに切り出す。
DHCP ON/OFF、IPアドレス、サブネットマスク、ルーター IPアドレスを、「IPアドレス設定」という値オブジェクトに切り出す。

プログラムの対象ドメインにとって意味のある(ユビキタス言語で名前付けできる)概念の単位で属性を集め、値オブジェクトとして切り出すのがConceptual Wholeの狙いだ。(値オブジェクトに限らず使えるテクニックだと思う。)

IDDDには以下のように書かれている。

各属性が重要なパーツとなり、それらが全体として、値について説明している。他と切り離して属性単体としてみると、意味のある内容がえられない。すべてが合わさって初めて、計測値や説明として意味をなすものとなる。これが、単にいくつかの属性をひとつにまとめただけのオブジェクトとは異なる点だ。単にまとめただけで、それ全体がモデル内の何かを的確に表しているのでなければ、まとめること自体にはあまり意味がない。

明快で力強い主張だ。

実践ドメイン駆動設計 (Object Oriented SELECTION)

作者:ヴァーン・ヴァーノン
出版社/メーカー: 翔泳社
発売日: 2015/03/17
メディア: 大型本

2019-07-13

ヌーラボさんと共同でやってたEffective DevOps読書会、やっと読了した

ゆっくりゆっくりと弊社とヌーラボさんで続けていた、Effecitve DevOps読書会がやっと読了しました。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

作者: Jennifer Davis,Ryn Daniels,吉羽龍太郎,長尾高弘
出版社/メーカー: オライリージャパン
発売日: 2018/03/24
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

本当に長かった...いつ読み始めたのか忘れるくらいに長かった。最初の読書会の記録を見返したところ、2018/6/15でした... 1年以上かけて1冊の本を読み切りました。

まず、これまでに読書会に参加していただいた皆様に感謝を申し上げます。僕にとっては学びの多い会を最後まで続けられたのは、参加していただいた皆様の協力のおかげです。本当にありがとうございました。

今のタイミングで、この読書会の経緯とこの会から学んだものを、僕の視点から整理してみます。

読書会を始めるきっかけ

たしか、読書会を始める数ヶ月前からEffective DevOps読みたいなーと個人的に考えてたと思います。チームビルディングについて悩んでたのもあったし、「組織の文化」というものが何なのか、何を重視したらいいのかとか、どうしたらいいのかもわからなかったし、そういうことへの解答があるんじゃないかと期待していました。

それで2018年の5月くらいに、品質管理のリーダーとして福田さんが入社して、福田さんと今後の会社の方向性について話し合ったときに、「すぐに効果を出す目的じゃなくて長期的に見ていい方向に会社を持っていくときに役立つ知識を学びませんか。ぼくはその知見が Effective DevOpsっていう本に書いてるんじゃないかと思ってます」みたいなアプローチをして、 Effective DevOpsを一緒に読んでいくことにした、んだったと思います。

せっかく2人で読むなら他の人も誘いましょうか、ということで社内チャットで呼びかけをして、読書会が始まりました。

f:id:kmdsbng:20190713094939p:plain — 最初の読書会開催の記録

初期

初期はもの珍しさも手伝って、まあまあ参加者が集まりました。「DevOpsっていうタイトルからは想像できないけど技術者以外の人にとっても役に立つ」みたいな誘い方をして、事務や営業の人にも参加してもらいました。

読書会を始めた頃に、興味を持ってもらおうと思ってまとめたDevOpsとは何かっていう箇条書き。これを書いた頃は、組織の文化って何？みたいな感じだった。

社内のEffective DevOps読書会向けに、devopsとは何かを整理してみた。
間違ってないかなー？ pic.twitter.com/edB0BsceWb
— Yoshihiro Kameda (@kmdsbng) 2018年6月21日

最初の方は結構飛ばしながら読んでいて、記録を見返すと1ヶ月くらいで半分くらい読んでた。超速い！

進め方は模索しながら進めていて、その中でペースが早すぎてあまり理解できてない、というフィードバックがあって、じゃあ1センテンスだけ読んだら感想をみんなで語り合うようにしよう、みたいなやり方に変えたのが大きな変換点だったと思います。ちょっとずつ読み進めるように変えたところ、いくつかいいところがありました。

言葉の意味や、書いてる内容がわからない点についての質問がいっぱい出てくるようになった。
自分の経験や気付きなどが語られるようになった。

これらの点は、僕にとってはすごく貴重なフィードバックだ、と感じました。みんなが考えてること、不安に思ってること、懸念してることを、書いてる内容ごとのテーマで表明してもらえるようになったので、これは効率性を犠牲にしたとしてもぜひ得たい情報だ、そこでお互いに情報交換することが、DevOpsにとって重要な「自分たちのことを知る」ことに向かっていくのですごく質の高い学習だと感じました。

参加者に聞いてみても好感触だったので、以降はこのスローペースでずっと読み続けました。 Effective DevOpsっていう本が、こういう読み方に向いていたなーとも思います。みんなでワイワイと俺はこう思う、僕はこうだ、と情報を交換し合うことで理解が進む本だった、と感じています。

社内でやってるEffective DevOps読書会は、これまでやってきた社内勉強会の中で一番うまくやれてる。しかもすごく楽。毎日開催してるのに楽というのがすごい。
— Yoshihiro Kameda (@kmdsbng) 2018年7月20日

ヌーラボさんを誘う

半分くらいまで社内で読み進めたあたりで、組織間の交流についての話が出てきて、他の会社の人を読書会に誘うのはどうだろう、というアイデアが出てきました。他社の参加者もいたほうが、フィードバックにより広がりが出るんじゃないか、という期待もあってぜひ実現したかったのですが、前に弊社に務めていてヌーラボに転職された中伏木さん経由でヌーラボさんに話を通していただき、リモートでの読書会が実現することになりました。ヌーラボさん、本当にありがとうございました！

新しく参加される人も増えるので、その時点でまた最初から読み直すことにしました。事例ごとにみんなの感想を聞くのが有益だとみんなが感じてたので、最初から読み直して新しい感想が聞けるならいいんじゃないか、とということになりました。

Effective Devopsの読書会は #ヌーラボエンジニアさんも有志が参加されてます
そして今晩Nulabさん京都オフィスでGeeks Who Drinkイベントhttps://t.co/VhKgZs4bpS

プログラマやデザイナなどを対象に、技術やデザインについて語りつつ飲みつつ交流。まだ数名申し込めそう！
ご興味ある方ぜひ
— メディアマックスジャパン株式会社 (@MediaMaxJapan) 2018年8月31日

ヌーラボさんからも興味を持った方に参加いただけて、フィードバックの幅がぐっと広がりました。会社がちがうと抱えてる問題や文化も違って、自分たちの無意識の前提にも数多く気づくことができました。

Effective Devops の #読書会、ゆっくりとしたペースで続けています。

学ぶほど、文化やマインドといった言語化しにくいものから、近年採用されてきた様々な開発手法やその考え方など、#devops は色々な概念を含んだ大きなムーブメントなのだという事が、少しづつ分かってきます。
— メディアマックスジャパン株式会社 (@MediaMaxJapan) 2018年8月24日

時間も毎日 12:00から30分というルールにして運用していきました。

2018年8月から年末くらいまで

このころから、読書会ができない日が多くなりました。初期はたまたま僕が時間が取れてる日が多かったのですが、このころ時間があまり取れないことが続いて、参加者もあまり集まらず、休会が多くなりました。

読書会、体幹トレーニング、地道に続けていますが、徐々に参加人数が減っていっています😥

どうしたって飽きてはくるので、どうやって乗り越えたらよいのかな？
— メディアマックスジャパン株式会社 (@MediaMaxJapan) 2018年11月14日

この時期は読書会の進め方について悩んでた時期で、僕が会に時間を割けないせいで、読書会というコミュニティのエネルギーが損なわれてるのではないか、と感じていました。

がんばって時間を割くようにテコ入れしようかと思ったこともあったのですが、結局は「休みが多くても良い」というポリシーにすることに決めました。

その理由は、この本で学習しているDevOpsというものが、ずっと続けられる文化を目指すものだというのが一つでした。継続可能な体勢を作るための学習が、誰かのがんばりに依存するようなものであってはうまくいかないはずです。であれば、目指すべきは無理をして短期間で終わらせることではなく、自分たちのペースでずっと学び続けることだ。なので休むことに罪悪感や引け目を感じることなく、堂々と「今日は参加できない」と言えるようにしようと思いました。

f:id:kmdsbng:20190713131220p:plain — 堂々と不参加表明する(堂々と...?)

また、この頃読んでた箇所に学習時間についての考え方のヒントがあって、学習時間を遊び(作業として割り当てない時間)として設定し、緊急作業が入ったときにはこれを消費するのが良い、ということが書かれてました。これを読んで、僕らの読書会は学習のための遊びの時間とみなして、作業が入ったらそちらに時間を割り当てるのは問題ないよね、ということをメンバーで共有して、会の開催形式についても会自体で調節していきました。

2019年以降

あいかわらず休みは多かったですが、特にそれは問題ではないと考えて運用を続けました。他に参加者がいないときは一人で読み進めることも考えたこともありましたが、それは採用しませんでした。この本については知識をえることよりも、それぞれのテーマについて参加者のフィードバックを得ることこそが有益だと考えていたので、ゆっくりとみんなで学習することを楽しもう、と思って一人で先に読むことはがまんしました。

あせらず、自分が楽しいと思える状況を維持することに気を付けて続けました。自分が面白いと感じることは、きっと他にも面白いと思う人はいるはずだし、そこを損なわないことに気をつければこの活動は続けられる。そう自分に言い聞かせつづけました。

そんな感じで読み進めてきた結果、ペースを保ったまま、なんとかこの分厚い本を読了することができました。

学んだこと

いろいろと学んだことは多かったのですが、今思いつく範囲でこういうことを話したよなー、ということをせっかくなのでいくつか書いていきます。

組織の文化とは何か

組織の文化というのは、組織が内外について伝えたり、メンバーが実際に行動によって作られる価値観やみんなが信じること。

主に文化について語られるのは組織の健全性について話すときで、メンバーが安全と感じているか、そうでないかというのが重要な観点になる。メンバーが安全と感じていれば、リスクを取って行動しようと考えるようになるし、安全でないと考えていれば、自分の身を守ろうと行動するようになる。

リスクを取ることを組織が奨励しているか、それが口だけでなく実際の行動でもリスクを取ったことを責めないようになってるか、という点が心理的安全性に影響を与える。

あとは何が重要かをはっきりさせていることも文化を作るのに重要。

それがないと、みんななにが目標で仕事しているのかわからないまま仕事することになる。そんな状況はまずいだろ、と感じるかもしれないが、そういう組織は結構ある。

固定思考と成長思考

固定思考は「人の能力は生まれつき決まったもので、行動によって変わらない」と信じること。成長思考は、人の能力は後天的に獲得できると考えること。能力の獲得だけじゃなくて、自分の無意識の前提に気づくことができれば、行動も変えられる、と考える。

この本では固定思考は悪で、成長思考が良いという考え方を取っている。固定思考なんているのか、と最初にこれを読んだときは思ったが、相手が固定思考か成長思考かどちらを信じているんだろいうと意識して話をするようになると、結構人は変わらないという前提で話している人は多いんだなーと今は感じている。

失敗は悪、と考えてしまうのも固定思考で、成長するなら失敗するでしょ、と考えるのが成長思考。失敗はまずいこと、と考えてしまうのはどっちかというと自然な心の動きのような気もするので、人間はデフォルトで固定思考なのかもと思う。仕様を最初にバシッと決めたらあとはそれを実装さえすればいい製品ができる、という考え方も固定思考の結果だと思う。

開発初期には自分たちは開発後期に比べて十分な知識がないはずなので、その時点の設計は間違っている可能性が高い、そう想定して開発することでリスクを減らせると考えるのが成長思考的だと思う。

今まで失敗したことがない人のほうが固定思考になる傾向があるらしい。

成長思考の考え方からすると、固定思考から成長思考に変わることも可能と考えるが、自分の中での気付きが得られないと、変われないので、なかなか難しいだろうなあとも思います。

人を成長させるために必要なこと

直接本に書いてあったことか覚えてないんだけど、読書会を通じて得た考え。

人が成長するには、自分のボトルネックになってる無意識の前提に気づき、自発的に自分の行動を変える必要がある。とするなら他人を成長させるにはどうすればよいかというと、自分の考えを相手に押し付けるのではなく、相手が気づきを得ることを手伝うのが有効なはず。そのためには相手の考えを聞き、それに共感し、事実に関してフィードバックするのが大事。回答になることを的確に相手に伝える必要はないし、それをすると逆に気付きが得られず、行動の変化につながらないことも多い。

例えば相手の心配に思ってることなどを聞く。まずはそれについて共感する。「そっかー、それは大変だね」「それはよかったね」と言ってあげるべきだ。

それについての解答を最初に与えようとしてはいけない。まず聞き、共感する。それで相手は考えの整理が進む。次に事実についてフィードバックする。「間違ったSQLを実行してしまったために、そのリカバリーに半日かかったね」など。「そもそもなんで間違ったSQLであることに気づかなかったんだろう」というように、一緒に原因追求や、よりあるべきだった未来について考えてあげたりする。

その中で、ボトルネックがどこにあるかを共有できて、それが自分の行動によって改善できる、と相手が気づけば、行動は変わるかもしれない。

読書会を終えて

定期的に学習時間を作って、ゆっくりとでも無理なく学習をつづけられたのは本当に良かったと感じています。同時に、もっとみんなに価値を感じてもらえる学習の仕組みを作っていきたいなあとも思ってます。無理なく、面白く、という両立は難しいだろうと思いますが、継続的に実験していきたいです。

この本から学んだことを、実際のチームビルディングにも生かすことができました。調整役として最近まで参加していたプロジェクトで、各メンバーが懸念点を表明できる環境を保つことができたのですが、それにはこの本からの知見が活かせたと感じてます。

また、最後まで一緒に読書会をつづけて頂いたヌーラボの中伏木さんから、これで終わらせるのはもったいないから何か別の本を読みませんか、という提案もいただけました。

大変嬉しい申し出だし、僕以外の誰かに価値のある場と思ってもらえたこともすごく嬉しいです。次に何をやるかは決まってないんですが、みんなが興味を持てることをつづけられるといいなあと考えてます。

読書会の感想など

Effective devops より抜粋です

固定思考は
"人の性質は生まれつきであり人は賢いかそうでないかのどちらかだ、と信じ込んでしまうと、自分に対しても周囲に対しても自分は賢いほうの人間であることを証明したがる"

これはつらみがある
— メディアマックスジャパン株式会社 (@MediaMaxJapan) 2018年9月7日

Effective devops より抜粋です

成長思考は
"自分のスキルや知識は時間とともに変わると考える。今は特定の分野について大して知識がなくてもかまわない。十分な時間をかけて努力する。"

固定思考と成長志向は、どこにプライドを持つかに関係あるのかなと思ったり。深いですね。
— メディアマックスジャパン株式会社 (@MediaMaxJapan) 2018年9月7日

難しい問題や未知の問題を「学習の機会」だと、ポジティブにとらえられるマインドセットを持てるように
不確実性に対してポジティブにそして戦略的に立ち向かえる組織づくり、一歩一歩頑張りたいところです！

そんなことを勉強会で感じました
— メディアマックスジャパン株式会社 (@MediaMaxJapan) 2018年9月7日

#devops 読書会よりメモ

devopsが自動化やツールの話としてだけ語られるケースが多くあるが、それはおそらく、成果が定量化しやすく、聞く方も単純で理解がしやすいから。
devopsの文化を説明・理解することはツールより難しい。
— メディアマックスジャパン株式会社 (@MediaMaxJapan) 2018年8月27日

2019-06-05

今日のEffective DevOps読書会に出てきたいい言葉

16.1 に出てきた言葉。

devopsとは、ある意味では、アイデンティティだと思い込んでいるものを理解し、場合によっては変えていくことである。職務に基づいてアイデンティティだと思うものを内面化し、そのアイデンティティに一致しない行動を取る人たちを拒絶するとき、さまざまなことに影響を与える。例えば、どのようなエンジニアを尊敬するのか。採用活動のなかでどのような候補者を有望だと考え、どのように面接に臨むか。何を「内輪」だと思うかといったことだ。devopsとは、「私はもともとこういうことをしているので運用だ」と言うのではなく、「私は今こういうことをしているので運用だ」と言うべきということだ。これは、私達が固定思考に代えて成長思考を推奨していることに通じている。「devopsをしているかどうか」ではなく、問題をどのように分析し、アプローチしているかが大切だ。

「devopsとは、アイデンティティだと思い込んでいるものを理解し、場合によっては変えていくこと」というのはすごく面白い。目標を立てて、それを組織で共有しつつ、かつ、それは固定の目標だと盲信せずに変えていくことが大切なんだろう。

この「ある地点を目指しつつ、そこが正しいゴールかをたびたび見直す」感覚は、ただしいゴールに至るための大事な心構えだと思う。この考え方を忘れないようにしたい。

2019-02-24

スクラムフェス大阪2019が最高のカンファレンスだった

スクラムフェス大阪、最高のカンファレンスでした。

www.scrumosaka.org

パワーがすごい。かつ様々な実践の共有があり、多様性もすごかった。スタッフの皆様のモチベーションも高く、しかもマネーに対するするどい嗅覚もそこここに見え隠れする。

微笑ましい事例の紹介もあるし、そうかと思えば胡乱な取り組みを胡乱なスピーカーが発表し、場を胡乱な空気が支配するようなセッションもある。計画されたカオスがそこにあった。

そこここに学びがあった。常に交流があり、お互いの状況を伝え合う中での自然なギブアンドテイクが生まれていた。

主催者の提供するコンテンツを参加者が消費するような、一方向な情報の伝達ではなかった。主催者が提供していたのは、交流が起こる場だった。参加者はみなその場自体が価値を持っていることを理解していて、自主的に参加する。

カオスはパワーを生み、予測できない相乗効果が発生した。メンバーのコミュニケーションを促進するのは消費行動ではなく学びであり、コミュニケーションを取るほどに創造性が生まれる。結果として、クリエイティブなカオスがそこに現出した。

アジャイルの意義とは効率良く学習できることにある。そういう意味で、スクラムフェス大阪はアジャイルの体現だった。統制の取れないすばやい学習がいたるところで行われていた。いろいろなスタイルの学びがあり、それで良いとする寛容があった。そしてあふれるほどのリスペクトと感謝があった。

一方「いかに儲けるか？」というビジネス目線の話も数多く、技術に偏ろうとしてしまう技術者とのバランスを取っていた。

「ユーザーに価値を提供する、すると儲かる。だから開発を続けていける。俺達のスタイルは顧客に価値を届けるための手段だ。つまりこのやり方が正しいんだ！」

そのような力強いメッセージが自信を持って語られ、実際利益を上げていることが説得力を与えていた。こういう成功の匂いは、経営層にとって魅力的に映るだろうと感じた。

素晴らしい場を提供していただいた、スタッフの皆様と参加者の皆様に感謝を。僕にできるせめてもの恩返しとして、僕が学んだことの一部をここに共有します。次回開催予定も決まっているとのことなので、興味ある方はぜひ参加してください。

企業でOSSへのコミットを奨励する体制をつくりたい

僕の兼ねてからの問題意識として、勤務先がスタッフにOSSへのコミットを許可、奨励するようにしていきたいということがありました。

その理由は普段の仕事にOSSを使っているのだから、OSSに価値を返すべきだ、それが巡って自分たちにメリットとして返ってくるはずなので、長期的にメリットがあると思うからです。

ただ、営利企業としては自分たちに利益がないとそのようには考えないので、どのように経営層に提案したら良いのか悩んでいました。

そのような相談をしたところ、自分たちで使っているOSSを拡張するときにフォークするのではなく、OSS自身に取り込んでもらうのが良いと意見をもらいました。

フォークしたプロジェクトはマージし続けなければならず、メンテコストが掛かるので取り込んでもらったほうが自社にとってメリットがあると伝えれば、OSSへのコミットを許可してもらえるようになるのではないか、という意見です。これは目から鱗が落ちる意見でした。

「OSSへの貢献を許可してほしいと思ったときにはすでに！OSSへの貢献を終わらせているんだぜ！」ということですね。このやり方であれば、事実をもとに相談ができるので説得もしやすそうです。

この問題は、個人的にずっと悩んできた問題だったので、その問題への見込みのありそうなアドバイスをいただけたのは本当にありがたかったです。実際に取り組んでみようと考えています。

みな悩んでいるという気付き

僕は自分の職場環境が、他の企業の職場のようにはうまくいっていないと感じてきました。しかし話を聞いてみると、みなうまくいっていることばかりではなく、問題を抱えていて悩んでいるんだと驚きました。

改めて考えてみると、これは当たり前のことですね。問題というのは解決しても、また別の問題が出てきたり、問題を解決した事自体が新たな問題を生み出したりして、いつまで経っても問題は尽きないということです。みな今より良い状況を目指しますが、そこに到達すると次の目標が出てきてしまう。

いつまで経っても問題がなくなることはなく、悩み続ける。なのでみな悩んでいるんだと気づきました。

そう考えて自分の歩いてきた道を振り返ってみると、強いプレッシャーの中でしたが、問題点に対処し続けてきました。とりあえずの対処だけではなく、問題の本質への対処も試してきた。そしていっしょに協力してきてくれたメンバーへの感謝がある。

感謝を伝えあう文化が育ってきていて、以前に比べれば楽観的な会話が増えてきたと感じる。そう考えるといい方向には進んできているんだろう。

そこにはコミュニティから今までにもらってきたアドバイスや、本から得た情報にも大きく助けていただきました。

その恩返しとして、自分たちの取り組み、自分たちの成果、自分たちの失敗というものも、事例紹介してコミュニティに貢献してもいいのかもな、と思いました。

大きな成功がなくてもスクラムをずっと続けているという事例

confengine.com

生存者バイアスというのは冷や水のような感覚があります。

成功者によって自身の成功体験が語られても、「それはあなたがたまたま運が良かったからうまくいっただけでは？同じことを試して死んでいった無数の失敗事例を考慮に入れてないだけでは？」というような疑問が湧きます。

そういう意味で、この発表には勇気をもらいました。華々しい成功がなくてもずっと同じことを情熱を持って続けられる、それはそこにそれだけの情熱をかけるに値する価値があるのだという証だと思います。

たとえずっと見返りがなかったとしてもそれを続けていくことができるか？それにYesと答えられることを人生で取り組めるなら、それは幸福な人生と言えるでしょう。この事例は、アジャイル開発に取り組むことに不安を持っている数多くの人に勇気を与えると思います。

発表者の方と懇親会でお話することができましたが、情熱を持ったすばらしい方でした。参考になる事例の紹介を本当にありがとうございました。

本をいっぱい知れた

#旅するアジャイル本箱を受付に置いています。ぜひ、眺めたり、手に取ったり、パラ見したりしてみてください。感想を書いていただけるようにもしたので、一言いただけると嬉しいです！ #scrumosaka pic.twitter.com/2TktDg8WKP
— YASUI Tsutomu (@yattom) 2019年2月23日

会場に旅するアジャイル本箱というのが置かれてて、みなさんのオススメの本を知る機会になりました。それをキッカケに、僕もこの機会にいろんな本を買ったりウィッシュリストに追加したりしました。それらの本を共有します。