こんにちはcolor_boxです。
この半年くらい、社内でBliki (ja) を読む勉強会をしています。
まず、Bliki (ja) とは何か？ Bliki (ja) とは、マーチン・ファウラー氏の個人サイト Martin Fowler's Bliki の日本語翻訳サイトです。
マーチン・ファウラー氏の記事が邦訳されて公開されており、このサイトの記事を読書会で読む対象としています。
書籍を題材とした読書会と異なり、1回の中で記事を1つか2つ指定し、それをその場で読みます。読んだらその内容について集まったメンバーでディスカッションするという流れです。チームや知見の異なるメンバーが参加するとディスカッションでその人ならではの興味深い話が聞けたりします。
本記事では、このような読書会を紹介するとともに、会の中でなされた会話や参考として貼られた書籍、Webページなどを紹介していきます。読書会の雰囲気を感じ取っていただければ幸いです。
XPのベロシティ
ベロシティについての記事で、参加者内のディスカッションでは下記のような話題について派生しました。
- ベロシティはこれまで3週間分のベロシティの平均であり、計測値でしかない
- 「ベロシティを加速させたい」みたいなことをよく聞くがちょっと違う
- チームの生産性そのものを上げるという話になるので、一朝一夕には実現できない
- 「ベロシティを加速させたい」みたいな発言には気をつけるべきである
- 何らかの機能実装について、それが「いつまでに終わるか？」といった話は、(特に初期は)シングルポイントではなく幅で伝えたい
- 基本的に開発には不確定要素が多くそれが、見積もった後の幅として現れるためだ
こちらの記事では下記の記事へのリンクが存在しているため、時間が許す範囲でそれらも読みました。
関係する話であれば参加者の頭に入れてしまった方が多くの話題が出てきてディスカッションが盛り上がるためです。
初期の苦痛
プロジェクト初期に発生する事象についての記事です。ディスカッションでは下記のような話題で掘り下げられました。
- ここで書かれている苦痛とは「リスク」と読み替えることができる
- 具体的には「要検証技術」「難易度の高い設計や実装」などがそれにあたる
- 「予告していた納期が大幅にずれる」「当初想定していたランニングコストが大幅に上振れる」などが具体的に顕在化した問題となる
- 記事内で言及されている初期の「面倒」とは具体的には、おそらく初期に起こるあらゆることであろう
読書会の参加メンバによって新規プロダクト開発に初期から関わる経験があったりなかったりします。こういったディスカッションがあると、実際にやってみるほどではないものの、メンバ間で知見共有できるという利点が発生します。
犠牲的アーキテクチャ
所謂MVP (Minimum Viable Product) を思い起こすという話からプロトタイプや曳光弾開発の話題になりました。「曳光弾開発」や「プロトタイプ」との違いについて議論の中で、特にプロトタイプについては下記のような話も聞くことができました。
- プロトタイプは捨てる前提で作り、曳光弾開発は作ったものを徐々に育てていくものという違いがある
- プロトタイプ開発では、開発者の中に知見を育てるのが目的となる
- プロトタイピングをするときは「それは捨てるべきものである」という前提について合意しておく必要がある。なぜなら、プロトタイプを見て「もう出来てるから出そう」となるとややこしいことになるから
- 開発メンバの中に知見を育てるために作っているプロトタイプは設計が最適でないため、それをそのままリリースしてしまうと長期的に不利になる可能性が高いからだ
この回は実際にやってみた人ならではの活きた知見を得られた回だったと言えます。有名な人月の神話でも似た話があることが指摘され、色んなところで似た概念が話されているということが話題になりました。
以下は Wikipedia の『人月の神話』 からの引用です。
したがって、捨てるプランを立てるべきである。いずれにせよ、そうするだろう。
他にディスカッションの中で、これも読んでおくと良い、これも関係していそう、という形で言及された記事などに下記のようなものがありましたので、リンクを記載しておきます。
- ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
- The three great virtues are important - Speaker Deck
- https://www.jasst.jp/symposium/jasst20niigata/pdf/S1.pdf
- Continuous Architecting and Rails: From rails new to Your Own Architecture - Speaker Deck
- ISO/IEC 9126 - Wikipedia
まとめ
弊社で実施しているBliki (ja) 読書会について紹介させていただきました。
ディスカッションしていると、参加者から参考にできそうな情報 (Webページや参考書籍の引用、その他の関連資料) がどんどん集まってきます。ファウラー氏の記事は含蓄に富み、昨今のプロジェクト運営の様々な箇所で彼の知見に触れる機会があります。ディスカッションの中でメンバの持っている具体的な関連エピソードや知見をメンバ間で共有し、伝達する場としてこの読書会が活用されています。
書籍をまるごと読むほど重くなく、ブログ記事を読む程度の重さで実施可能です。回ごとの独立性が高いため、新規の方も参加しやすく、途中抜けていた方も復帰しやすい構成となっています。
ファウラー先生の含蓄に富んだ記事から色んな話を引き出せて、参加者間で知見を共有できるるBliki (ja) 読書会、おすすめです。
最後になりますが、こんな読書会を開催している永和システムマネジメントではエンジニアを絶賛募集中です！
