見出し画像

エンジニア同士で技術書の『ペア読書』をしてみた

先日、『ペア読書』なるものを目にしました。

ペア読書とは、読みたい本と制限時間を決めて、読み終わった後に2人で議論をして理解を深めようという試みです。


僕はエンジニアなので、技術書をペア読書したら効果的に技術を学べるのは?と思い、エンジニアの友達と2人でやってみました。実際にやってみて、本の内容とそれぞれの経験を元に話ができたので、とても有意義な時間を過ごせました。

今回はペア読書したその方法と、過程を書きます。


今回読んだ本はこちら!

「Domain Driven Design(ドメイン駆動設計)Quickly 日本語版」です

巷では DDD と呼ばれる設計手法の要約版です。

なんと上記のリンクから無料でダウンロードすることができます。

二人とも DDD に興味があったのでこちらを題材に進めました。


さて、ペア読書には制限時間があります。

今回は例にならって読書時間を30分に設定しました。

30分に設定すると読む時間が限られるので、上記の pdf で言うと 1p ~ 18p までを30分で読み切った後、それぞれの経験を踏まえて議論します。ページ数は感覚値で決めたのですが、結果的に30分でちょうどいい時間に読み終わりました。

2人が入っている Slack チームがあるので、 #pair_reading というチャンネルを作成し、読み終わった後に以下を書いた上で議論するようにしました。

1. こういうことが書かれていた
2. 特に気になった箇所。なぜ気になったか
3. よく分からなかったこと
4. これを受けて日常で実践すること
5. 次に学びたいこと

読むときのコツとしては、気になった一文はメモアプリ等にコピペしたり、思ったことは随時メモをすると後々振り返りやすいです。

そして、僕が実際に DDD Quickly を読んでまとめた内容が以下になります。

1. こういうことが書かれていた
- ドメインを理解していなければシステムを構築することはできない
- ドメインの中でも何を取り込み・取り込まないのかを考えることが設計作業
- ドメインの専門家とソフトウェア開発者の間での共通言語を作る。どんな形態のコミュニケーションであれ、常にこの言語で表現する。さらにはコードにも使うように。これを「ユビキタス言語」という。
- ユビキタス言語を作る際には、ドメインを表現するのには不十分で、不適切な用語やモデルの構造担っていないか、設計に紛れ込みやすい曖昧さや矛盾が現われていないか注意する
- ユビキタス言語は明確に、そして正確に意思伝達をする手助けをしてくれる

2. 特に気になった箇所。なぜ気になったか
- ユビキタス言語を考えるの大事。すでに名前が決まってる場合は名前を考える時間が省けるため、開発効率も上がりそう。
- wiki にユビキタス言語がまとまってるとその後も開発しやすそう。

3. よく分からなかったこと
- ユビキタスな言語名がすんなり決まるのかどうかはやってみないと分からない

4. これを受けて日常で実践すること
- ユビキタス言語の wiki を作る

5. 次に学ぶこと
- 実際にやってみる
- ユビキタス言語を決めた後のより良い設計について

2人ともまとめを #pair_reading に投稿した後に、議論をしました。

画像1

↑ 実際の投稿

議論の内容としては、実際はユビキタス言語を決めずに色々な単語でコミュニケーションとってるよねとか、ユビキタス言語を wiki 等にまとめることで、誤認の相違を回避、修正ができそうねとか、名前を考える時間が省けるため、開発効率も上がりそうだよね等を話しました。 

ユビキタス言語 ... ドメインの専門家とソフトウェア開発者の間での共通言語。どんな形態のコミュニケーションであれ、常にこの言語で表現する。

我々ソフトウェアを設計・開発する立場としては、「ドメインの専門家と会話をし、ドメインを理解しつつ、ユビキタス言語を決めて使っていこう」が今回読んだページまでの結論になります。

ペア読書を終えて、技術書をペア読書してみた感想を友達に聞いてみました。

友達「ガッツリ技術書を読むという習慣がないから良いきっかけになる」

とのこと。

実際、30分の制限時間があるので緊張感を持って読めるのと、議論をすることで理解が深まって行動に移しやすくなるのでまたやろうと思っています。気になる方は友達と時間が合う時にやってみることをオススメします!


記事が良いと思ったらサポートをお願いします!