DevLOVE97本読書会#1 - n3104のブログ

とても楽しめた！いづれ議事録が公開されると思う*1ので、振り返りながら考えたことについていくつかメモしておく。

時間が足りない、話し足りない

2時間の読書会で読めたエッセイは2本だった。このペースだと54回開催する必要がある。。*2

読書会の進め方
（１）人数が多い場合は、グループを分けます。
（２）読むエッセイを決めます。
（３）各グループにて、読み上げます。
（４）各グループにて、本の内容をベースに感想・意見交換をします。
（５）各グループで話した内容を全体で共有します。
※（２）〜（５）を繰り返します。

前述のような進め方で、グループ内で話すのは（２）〜（４）。ここに30分ぐらいかけていたのだけど、ちょうど盛り上がり始めたところで終了するぐらいの長さで、全然話し足りなかった。かといって、ここを増やすと、それこそ1回につき1本しか話せなくなる。まぁ、全エッセイを読むことを目的としている読書会ではないと思うので、それはそれでいい気もするけど。

定義の難しさ、そもそもなぜ読むのか

「ここに書いてある内容はどういう何だろう？」とか「ここはこういう意味で」みたいな意見があった。話し合いをする上で、定義を明確にするのってとても大切なことだとは思うのだけど、定義づけするのは手段であって目的ではない。定義とか解釈にとらわれてしまうと、せっかくのエッセイから受け取れるものが減ってしまう気がした。

97本はエッセイなので、相手の置かれている状況を踏まえて書いたものではなく、筆者の位置から思ったことを書いたものだと思う。なので、分かりづらかったり、共感できなかったりする部分があるのは当然のこと。どちらかというと、筆者が読者に近づくのではなく、読者のほうから筆者に近づく必要がある本で、少しでも感じ取れる部分を増やすため読者のほうで補う姿勢が求められる。

で、補う際に、人によって補い方が異なる。それは当然のことで読み手のバックグラウンドが異なる上、読んでいる対象が文字数の少ないエッセイであるため。なので、そもそもなぜ読んでいるのかという目的を意識する必要があるのかと。何かしらのヒントを得たいと思って読んでいるならば、正確な定義とはどーでもよくて、可能な限りポジティブに補って、得られる限りのエッセンスや勇気をもらえればいいのじゃないかな。

読書会という観点では、他人の視点とか解釈を聞くことに意味があるわけで、いかに解釈の幅を広げられるかに価値があるのだと思う。そして、読書会なのでそこで偶然生まれた話し合いにこそ価値があるのかと。

ちなみに、読書会自体はまさに他人の視点や解釈をお互いに聞こうという雰囲気で、とても楽しいもだった。ここで書いた内容はその中で定義に関する意見が少しだけあって、そういう意見を聞いて個人的に連想した思考。読書会では定義に関する意見はあるにはあったけれども、そこについて深めていくような雰囲気ではなかったので。DevLoveはとても楽しい集まりですｗ

誰のためにシステムを作るのか

「83:設計した通りにはならない」について話し合った際に、顧客のためにシステムを作っているのだということを再認識した。うちのチームでこのエッセイについて話し合った結果、「最初に設計した通りにならない。ではどうすればよい？」という所に行き着いた。その問題に対する解決策は以下のようなものだった。

実際にプロトタイプを作って検証する。このプロセスを繰り返す。アジャイルっぽい感じ。
最初の設計通りにならないことを受け入れる。具体的には、設計通りに行かない部分があったら、その部分は無理やり最初の設計にあわせるようにしない。そこはそこで個別対応とする。
最初の設計にあわない部分は要件を減らす。
変更しない幹となる部分と、変更可能な枝葉の部分を意識して設計する。

私が挙げたのは2の「最初の設計通りにならないことを受け入れる」というものである。アーキテクトは設計をきれいにしようとし過ぎる所があって、最初の設計で上手くいかない要件が出てきても、無理やり既存の枠組みに当てはめようとしてしまうことがある。その結果、かえって複雑になりすぎたりすることもある。言い方を変えると「やりすぎない」とも言える。SIって顧客のためにシステムを作っているので、投資対効果が一番重要になる。例えば、顧客からすれば目に見えない保守性を向上させるよりも、その時間でもう1つ追加機能を作ってくれる方がありがたいことがある。もちろん、保守性が低くて良いといっているわけではない。だけれども、期間と予算が決まっているのだから、その枠組みの中で投資対効果を最大化するのが目的なので、すべての要素にコストをかけられない*3。

ただ、これはあくまで当初の設計どおり上手くいかなかった場合の処し方、心の持ちようについての話であり、1とか4が重要であることは間違いない。また、保守性やC/Oの期限が最優先のシステムであれば3の方法も考えられる。要はどれもが有用である。なので、置かれている状況に応じて対応策は変わってくるわけである。そして対応策は手段であって目的ではない。目的は顧客にとって投資対効果が最大化されるシステムを作ることである。この目的を忘れなければ、具体的な対処方法は状況に応じて柔軟に考えればよいのではないだろうか。

で、最終的に思ったのが、普段からそこまで顧客のことを意識していなかったな〜と。特に忙しくなってくると目の前のタスクを片付けるのに精一杯で、むしろ面倒なことを言ってくる顧客への不満が募ったりすることもあった。なので、今後は顧客のためにシステムを作るということを常に意識しようと思った*4。この認識をプロジェクトメンバー全員が共有できると、いいシステムが作れるのではないかと思う*5。

まとめ

勉強会はブログを書くまでという方もいるが、その通りだと思う。言語化する過程で、考えを整理することが出来た。ただ、時間掛けすぎたかな〜とも思う。このエントリ書くのに3時間近く掛けた気がする。。まぁ、個人的にはとても重要なことについて再確認できたので、掛けた以上の価値はあると信じよう！
最後に毎度のことだけど運営してくれた方、参加してくれた方、みなさまに感謝である。ありがとうございました！！