結婚式翌日におばあちゃんが亡くなった話

4月に京都の下鴨神社で結婚式をしました。無事にこの日を迎えることができてよかったです。妻とは大学の頃から足掛け8年の付き合いになりますが、これまで以上に楽しい日々を二人で築いていきたいです。

せっかくなので、いつものやつ貼っときます(人∀・)ﾀﾉﾑ

www.amazon.co.jp

そして題名にもあるように結婚式の翌日に、大好きだったおばあちゃんが亡くなりました。

突然逝ったというよりは、前々から弱って入退院を繰り返していて、いつまで生きられるだろうかという感じでした。もちろん結婚式には参加していませんが、少なくとも僕が結婚することは認識していて、自分の意思でご祝儀をつつみ、おばさんにことづけてくれたと聞いています。

今となっては確かめようもないし、単なる偶然なのかも知れないけど、式が終わるまで逝くのを待っててくれたのかなという気がしてなりません。

結婚式の記念日が来る度に、おばあちゃんのことを思い出し、手を合わせようと思います。

おばあちゃん、ありがとう。

アート・オブ・コミュニティ

『アート・オブ・コミュニティ』は長年Ubuntuコミュニティでマネージャー的なことをしてきた著者が、その経験に基いてコミュニティ運営について語る、なかなか他に類を見ないテーマを扱った書籍。OSSコミュニティのマネジメントについて書かれているが、会社組織に通じる話題も多い。

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

僕はQiitaというサービスを作っていて、ユーザの中にはOSS活動している人も大勢いるので（自分もその中の一人ではあるが）ユーザ理解の一環として読み始めたのだが、直ぐにチームマネジメント的な文脈で読む方が適切だなと姿勢を改めた。

というのも、OSSコミュニティは参加者たちの自発的な行動によって支えられている面が非常に大きい訳だけど、その姿はIncrementsが志向する「自律的な組織」と目指す方向性が近いと思ったからだ。

「Ubuntu流の自律的な組織」を運営するためにさまざまな点が語られているが、以下個人的に印象に残った点を書き記す。

とにかくオープンにする

本書を読んでいて特に印象的だったのは、OSSコミュニティというそもそもがオープンなソースコードを土台にした組織を運営するために、可能な限りあらゆることをオープンにしようと徹底している姿勢だった。

それは組織のミッション・ステートメントの策定に始まり、どういう領域で人材を必要としているか、プロジェクトに参加するための方法を書いた手順書、今期の戦略計画の目的とそれを構成する目標などなど。

どの章を読んでいても「これは誰でも読めるように公開しましょう」と書いてあるし、そのドキュメントをどういったツールで公開するのがいいか書かれている。

Qiita:Teamのドッグフーディングも兼ねて、普段から積極的に情報公開するように努めているつもりではあるが、もっともっとやれることはあるなと再認識した。

マネージャーの役割

マネージャーの役割として「チームがどのようにコミュニケーションをしているのか常に確認すること」を上げていたのも興味深かった。例えばデザインチームとWeb開発チームの間で十分に意思疎通ができているかを調べる、みたいなことなんだけど、ちょうど最近公開された伊藤直也さんとフリークアウトの明石信之さんの対談で同じようなことをいっていた。

naoya: 基本的には営業とエンジニアリングって、放っておくと逆を向いちゃう性質のある職業だから、現場の人たちだけで同じ方向を向くっていうのは、確率として相当低いんですよ。それを向いていくように組織の構造を調整するってなると、それはもうマネジメントの仕事だと僕は思ってて

【後編】大先輩のフリークアウトCTOが語ってくれた、マネジメントの深くてイイ話

変化しないプロセスが官僚制度をもたらす

参考にしたいなと思ったのは、プロセスの見直し方法について（ここでいうプロセスというのは「プロジェクトに興味をもった人が参加するためのプロセス」のように特定のゴールを達成するための一連の手順を定めたもののこと、と大雑把に理解してもらいたい）。

Ubuntuコミュニティにはさまざまなドキュメント化されたプロセスがあるが、それらは定期的に振り返って変更している。その振り返りを行う前の事前準備として以下のことをしているそうだ。

1. まず最初に、コミュニティ内にある全てのプロセスのリストを作ります。これはどのように新しい人が参加するか、どのように一緒に働くか、どのようにチームが働くかなどのトピックをすべてカバーするようにします。Wikiのようなオンライン上で行う方が良いでしょう。
2. それぞれのプロセスに対して、今まで聞いてきた良い点、悪い点のフィードバックを箇条書きにしていきます。
3. 次にできあがったリストを全て眺め、あなたが優先だと思う順序に並び替えます。多くの場合、コミュニティのボトルネックや問題を引き起こしているものを優先します。
4. 最後に、コミュニティ全体にこのリストを告知して、フィードバックのお願いをします。また、もっと議論が必要なプロセスについてもフィードバックを求めます。再評価のセッションの前に締め切りを設定します。このフィードバックをドキュメントにマージして、コンセンサスに基いて、優先順位を振り直します。

4.5.1 習慣化する より

こうして出来上がったリストをミーティングのアジェンダにして、Ubuntuコミュニティではプロセスの見直しを行っているらしい。

Incrementsでも定期的にKPTを軸にした振り返りの機会を設けているが、自由記述で問題点を出してくださいと言われても、質問が大きすぎてなかなか意見が出ない印象があった。振り返りの叩き台として既存のプロセスを一旦整理してそれぞれの良し悪しを上げてもらう、というアプローチはよさそうだと思った。

プロセスの導入は小数の主要メンバーから

Ubuntuコミュニティには大勢の人が参加している。何か新しいプロセスを導入しようと思ってもなかなか浸透していかない。

コミュニティの主要なメンバーの中から4〜5人選び、アナウンスを行ったプロセスがきちんと使えることを確認する方法が便利です。彼らがそのプロセスを使用することを定期的にチェックして、もし使用していなければその理由を聞くと同時に、そのプロセスが何故必要かを思い出してもらいます。

プロセスが無視された時は、それはプロセスの目的を再び告知する機会であると認識しましょう。2つの方法があります。1つめはプロセスを利用したおかげで、素晴らしい結果を得ることができたというサクセスストーリーを示す方法です。（略）もう一つは、プロセスの目的を思い出させる機会として、プロセスに従わないとさまざまな支障をきたす例を示す方法です。

4.4.3 プロセスを使用する より

Qiita:Teamを会社に導入しようと頑張ったが根付かなかったので止めます、みたいなことがたくさん起こっているような気がしていて、その問題に対するアプローチとして参考になる。

あと会社で何か新しいことを始める場合も。

---

このブログでは主に書籍の前半部分のことを取り上げた。後半はOSSをどうやって盛り上げていくか、的な話題になっていくので、地域コミュニティをどうやったら活性化できるのか、みたいなことに興味がある人なんかはそっちを読むといいかも知れない。

扱っている話題は非常に多岐にわたっているので、何かしら面白いと思う章があるだろうと思う。

インターフェイス指向設計

『インターフェイス指向設計』を読んだ。念の為に書き添えておくと、この本が指すインターフェイスというのは、いわゆるUIのことではなく、プログラミング部品としてのinterfaceのこと。

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

この本のいいところは

オブジェクト指向プログラミングの肝は 高凝集 で互いに 疎結合 なオブジェクトを用いてプログラムを構築することにある

という態度を一貫して保ち、その目的を達成するにはどうすべきかという観点からインターフェイスの利用について語っている点だと思う。

Bertrand Meyerが『オブジェクト指向入門』で提唱した「契約による設計」は、高品質なコードを実現するための重要な方針を示すものだが、本書ではMeyerが論じたメソッドと呼び出し側の間に成立させるべき契約の基準を議論の呼び水にして、インターフェイスの利用がいかに前述の目的の実現に有効であるかを論じる。特定の言語におけるinterfaceの使い方、のような込み入った話はほとんど出てこないのも良い。

オブジェクト指向にはインターフェイス以外にもクラスや継承、多態性などさまざまなキーワードがひしめき合っていて、「どれを使うか」ではなく、「何故それを使うべきか」「どうやって使うべきか」の方が余程大事だということは多くの人が感じていることだけど、WhyやHowを扱った書籍は全般的に重厚で手を出しにくい物が多い。そういう中で比較的薄くて読みやすいのも良かった。

これまで契約による設計という概念は知っていたがいまいち手に馴染みがないという人や、どういう時に継承とインターフェイスを使い分けるべきかが分からなかったり、良いインターフェイスとは何かをあまり考えたことが無いという人にオススメ。

そもそも本書を読んだのは、Qiitaのコードベースの見通しが悪いと感じていてそれをどうにかしたいと思ったからだった。QiitaはRubyで書かれているが、Rubyには型が存在しないので、インターフェイスの契約をちゃんと守っているかの確証を持てないという問題意識を最近感じてる。次はその間の橋渡しをするようなgemを作ろうと思う。