デッドライン読書会#05「マイクロサービスアーキテクチャ(後半)」感想文

課題図書

デッドライン読書会#05の課題図書はオライリー社の「マイクロサービスアーキテクチャ(後半)」です。後半の範囲は7章〜12章でした。前半部分の感想は「デッドライン読書会#04「マイクロサービスアーキテクチャ(前半)」感想文」です。

※デッドライン読書会とは何かについてはこちらのポスト:「読書×締切ではじめる「デッドライン読書会」を始めました」をご参照ください。

本を読んだ感想

ついに期限オーバー…

最初に正直に書きますが、公私ともに多忙を極め、トライアル期間(?)の回を含めた十数回目にして初の期限オーバーとなりました…無念。ほんのちょっとずつ気になったところしか読めませんでした。仕事、家族、プライベート、こういったお勉強、どのように時間を割くべきかを考え直す機会となりました。

それでも感想

それでもゼロのアウトプットはいまいちなので目を通した部分について感想を書きます。

後半部分は、テスト、監視、セキュリティ、コンウェイの法則とシステム設計、大規模なマイクロサービス、まとめ、が取り扱われていました。

「大規模なマイクロサービス」では、マイクロサービスの大規模化(日本語おかしいですが)に向かうための手順が整理されており、今後それらがパターンとして整ってくるのではと言及。規模が大きくなるにつれてシステム障害への対応の重要度(負荷の高さ)が増してくるわけですが、その参考として「Realese It!」がお勧めされていました。私も未読なので手に取ってみたい。

「コンウェイの法則とシステム設計」では、枯れたマイクロサービスの取り扱い方の解説がありました。面白かったのは枯れたマイクロサービス(つまり、機能としてよく使われるが修正が少ないようなしろもの)は「社内オープンソース化する」といった発想です。マイクロサービスではないですが自分の会社にも、共通フレームワークを管理している部門があります。実はそういったコードはOSSのように公開されPR受け入れられるようにしておくのは良いのかもしれません。興味を持つ開発者が相当数いる場合じゃないと健全に運営されないかもしれませんが。

今回、読み切れなかった分もこのあとの期間で読もうと思います。読み切ったらここに追記する予定です。

次回(#06)

スケジュールはGoogleカレンダーで分かるようにしています。第6回は次の要領です。

  • 書籍
    • 検討中
  • デッドライン
    • 感想交換1Week(7/3-8)
    • 読書する時間2Week(7/9~7/22)
    • ブログポスト期限(7/23)
広告

デッドライン読書会#04「マイクロサービスアーキテクチャ(前半)」感想文

課題図書

デッドライン読書会#04の課題図書はオライリー社の「マイクロサービスアーキテクチャ(前半)」です。前半の範囲は1章〜6章でした。表紙はミツバチです。

※デッドライン読書会とは何かについてはこちらのポスト:「読書×締切ではじめる「デッドライン読書会」を始めました」をご参照ください。

本を読んだ感想

本書について

本書はオライリー・ジャパンから2016年に出版されました。今回の範囲の章は次のとおりです。

  • 1章:マイクロサービス
  • 2章:進化的アーキテクト
  • 3章:サービスのモデル化方法
  • 4章:統合
  • 5章:モノリスの分割
  • 6章:デプロイ

運用やセキュリティ、スケーリングは7章以降になります。

前半全体

書名としてマイクロサービスアーキテクチャ(以降、MSAと略)でのアプリケーション構築・開発の詳細を議論しているのかと思いましたが、少し上位概念が多い印象。しかしながらよく考えてみれば、それはそうで、組織とアプリ/システムが一致するコンウェイ法則を体現したようなアーキテクチャ(というよりか、パターン?)であることからも、開発プロセス(CI、CDなど)、設計論(DDD)、インフラのあり方(インフラ構築の自動化、クラウド)、組織のあり方も関連するとなると、それなりに語るべき範囲は広くなるんだなぁと認識しました。

1章でそうそうに「MSAは銀の弾丸じゃないよ」と著者も言っており、その後の内容も慎重なイメージがありました。マイクロサービス化するための境界線の見つけ方、そのタイミングは適切な位置をじっくり時間をかけ把握し掴んでから実施すべしとのこと。

私自身MSAのアプリは作ったことがないですが、APIベースのアプリなら経験はちょっとあります。それを踏まえて具体的に学びに繋がった箇所について以下「個別」でまとめておこうかと思います。

個別

  1. MSAにおけるデータの持ち方
    • サービス間でのDB統合は極力避けるべし。
    • DB上のトランザクションが完結するように、マイクロサービスの境界を作るべし。
  2. REST/JSONだけが王道ではない
    • サポートツールが優れているからとの理由で、著者はややXMLを推している。
    • でも今ではますますJSONがデファクトかとも思います。
  3. APIエンドポイントのバージョンニングにおける過去バージョンの維持方法
    • 内部的にV1エンドポイントへのすべてのリクエストをV2リクエストに変換する。これによりアプリ全体を二重に管理・メンテナンスすることを防ぐことができる。
  4. ユーザインターフェイスの作り方
    • API合成するか、UI部品合成するか、フロントエンド向けバックエンド(BFF)を作るか、などの手法が選択できる。
  5. アーキテクトは都市計画家
    • なるほど、詳細に立ち入れないときもあるが、システム全体(都市全体)と、それぞれのマイクロサービスの役割(土地の用途)、マイクロサービス間のIF(道!?)に着目することが重要な任務。私としてはイメージしやすかった良いメタファーでした。

次回(#05)

スケジュールはGoogleカレンダーで分かるようにしています。第5回は次の要領です。

  • 書籍
  • デッドライン
    • 感想交換1Week(6/12〜17)
    • 読書する時間2Week(6/18~7/1)
    • ブログポスト期限(7/2)
    • 感想交換1Week(7/3-8)

デッドライン読書会#03「業務デザインの発想法」感想文

課題図書

デッドライン読書会#03の課題図書は「業務デザインの発想法」でした。今回は1冊を2週間で読破するコースです。

※デッドライン読書会とは何かについてはこちらのポスト:「読書×締切ではじめる「デッドライン読書会」を始めました」をご参照ください。

本を読んだ感想

全体

「○○の問題地図」や「職場の問題かるた」など見える化・言える化についてたくさん書かれている沢渡あまねさんの本。SNSでの活動も見させてもらっているので、私としては馴染みの深い内容が多かったです。

本書は題材として「ハンバーガーショップの開店からの運営」を扱っています。私はシステム開発と運用のコンテキストをもとに本書を読みましたが、ITに範囲は絞られない内容です。第1章から第4章は、(システム開発だと)非機能要求・要件定義、運用設計、運用に関わることが網羅的に書かれていました。私も一通り経験したことがあるので新しい発見はありませんでしたが、丁寧に書かれている(かつ、ITよりに感じた)ので、初めてITでこの領域を経験する人にはちょうどよい参考書になると思います。よくこれだけ平易な言葉でまとめたなぁ。。。

後半の第5章「業務の価値を高める」、第6章「人と組織を継続的に成長させる」、第7章「で、どうやったらなれる?」は、刺さった内容でした。特に5章と6章は仕事でも携わっていることでピンポイント。よくをいえば、業務が定着化するような活動(コラムの「そばうどんコーナー」の内容はそれに近いかも!?)や、業務が大きく変わったときのチェンジマネジメント活動などにも言及があると嬉しかったなぁという感想でした。

個別

個別のテーマで本書内で気になったことを箇条書きします。

  • 5.1. ナレッジマネジメント
    • 情報の共有は難しい。本書では「短期」、「中長期」、「限定的」と分けて分類している。
    • 私がいま仕事を通して考えているのは、情報の方向と、それをいかに知識に変換するかというところ。 整理すると次の4つになった:「TAKE(教えられて知識を獲得する)」、「GIVE(教えることにより知識を整理する)」、「GIVE&TAKE(情報を行き来して知識に昇格する)」、「SHARE(時間や人をまたいで情報・知識を行き渡らせる)」。でも、これは、情報や知識の領域のことであって、自律的なチームとする場合は、情報・知識を知恵に昇格する仕組み・仕掛けがいると思っている。それにはまだ現場コーチ的な方法しか見つかっていない。ダイアログなど語りつくすところに別の答えがありそうだなーといったもやもや感はあるけど。
  • 5.1. コミュニケーションは設計8割、スキル2割
    • 私には、設計5割、勇気3割、スキル2割かな。
  • 6.1. 自己開示による相互理解を促進する
    • 「自己開示のための質問リスト」は良い質問リストと思ったけど、どこかからの出典だろうか。
  • 6.2. DevOps

次のスケジュール(#03〜#04)

スケジュールはGoogleカレンダーで分かるようにしています。

  • レビュー(感想の共有)とプラニング(次の書籍選定)
    • レビュー(5/15〜5/20)
    • プランニング(5/21〜5/27)
  • #04の書籍
    • 未定、プランニング終了までに決まります。
  • #04のデッドライン(予定)
    • 読書する時間2Week(5/28~6/10)
    • ブログポスト期限(6/11)

デッドライン読書会#02「Effective DevOps(後半)」感想文

課題図書

デッドライン読書会#02の課題図書は「Effective DevOps ―4本柱による持続可能な組織文化の育て方(前半)」です。長い本なので半分ずつで今回は後半の第V部〜最後が範囲です。前半の感想文はこちら(デッドライン読書会#01「Effective DevOps(前半)」感想文)です。

※デッドライン読書会とは何かについてはこちらのポスト:「読書×締切ではじめる「デッドライン読書会」を始めました」をご参照ください。

 

本を読んだ感想

全体

devopsの実現に向けた4本柱の4本目「スケーリング」と、devops文化を実現するための架け橋に関する話が対象でした。ここでいうスケーリングとは、単に大企業へのdevopsの導入を指すだけではなく、企業(組織)の拡大・縮小に対する柔軟な対応にはどうしたらよいか、その時々のライフサイクルで適した技術的なこと、文化的なことに焦点をあてている。

後半部分で身にしみたのは、「明示的か?」・「明文化されているか?」といった記述が多いことだった。価値観や文化は明文化されているか?(私のチームはされていない)。されていれば、共有もできるし、改善もできるため、そこから学ぶことができる。では、なぜ無い場合が多いのかと考えると、現業で忙しいことを言い訳にしたり、なくても成り立つ(ように勘違いしている)と思っていたり、そもそも必要性を感じないからだろう。技術だけでなく、文化もアップデートする必要があると説く本書からすると、明文化は必須事項だと思った。最近経営理念に関する本を2冊ほど読んだので、それに通ずるところも感じた(「実践経営哲学」、「いい経営理念が会社を変える」)。そこからすると、「明文化することも難しい」が、「文化として浸透させることも難しい」という2つの課題がある。ひょっとしたら浸透させる部分はシステム開発よりで考えてもよいのかもしれない。ツールチェインに想いを入れ込んでみたり、コーディングルールや設計のガイドラインに入れ込んだりできるかもしれない。

もう一点共通して面白かったことは、本書では、仕事の外のことをとても多く扱っていることだった。(狭義的な仕事の範囲で)仕事の外とはつまり、休暇・休息・充電、業務後のコミュニケーション、学習、カンファレンスへの参加、社外のコミュニティ活動、食事、健康など。本書は「文化こそがdevops運動の本質」と銘打っていることもあり、何もシステム開発の一部分を改善するといったことが目的でないことがみてとれた。文化を含めて改善するためには、チームとメンバーを広い範囲で捉えてサポートできるようになれるかが重要なのだろう。

個別

個別のテーマで本書内で気になったことを箇条書きします。『』(二重括弧)部分は本書内の引用です。

  • 14.7 チームのスケーリング
    • 『効果的な仕事をするリーダーは、決して「私」とは言わないように思う。…彼らが考えるのは「私たち」のこと』
    • 組織が大きくなると、仕事は分割され一部だけ担当するというのはよくある。そうならないようにしなくてはいけないと思うし、なった場合でも「私たち」という表現が指すように、個人のスキル(責任)をオーバーラップしてみれるリーダーになることが重要だと思う。
  • 14.8.1.1 社員の募集と面接
    • 『強い意見と弱い執着』
    • すごく参考になった。特定の技術や開発プロセスに対して、強い意見を持とう。誤りを証明されたら弱い執着を発揮しようということ。なんとなく「弱い意見と強い執着」が大半を占めていると思います。「昔からこうなんです」ってやつ。強い意見が持てるということはその方法に腹落ちしているわけであって、弱い執着でいられるというのは人の意見をちゃんと聞くことができるという姿勢を示しているんだと解釈しました。
  • 14.8.3.3 見当違いの技術重視
    • 『重要な文化的価値を強調する』
    • チームが何を目指すか、何を理想とするか、決定はどう行われるのか、などチームの文化を明文化することをできていないなぁ(過去にクレド的なものは定めたことがあったがいつの間にかなくなってたことに今気づいた)。前述したが、明文化できれば改善ができるということを忘れてしまっていた。
  • 16章 devopsの4本柱を使って架け橋をつくる
    • 『異なるチームや組織を、サイロではなく島だと考える』
    • 良くない組織の状態を「サイロ化」だとか「井の中の蛙」だとか表現する。これはネガティブなメタファーである。改善をしたいと思うなら、建設的なメタファーを使わなくてはいけない。語彙は豊富に。文化を変えるということはそういった表現にも気を使えるかは大事。

次のスケジュール(#02〜#03)

スケジュールはGoogleカレンダーで分かるようにしています。

  • レビュー(感想の共有)とプラニング(次の書籍選定)
  •  #03の書籍
    • 未定、プランニング終了までに決まります。
  • #03のデッドライン(予定)
    • 読書する時間2Week(4/30~5/13)
    •  ブログポスト期限(5/14)
    • 感想交換1Week(5/15-21)

デッドライン読書会#01「Effective DevOps(前半)」感想文

課題図書

デッドライン読書会#01の課題図書は「Effective DevOps ―4本柱による持続可能な組織文化の育て方(前半)」です。第I部〜第Ⅳ部。表紙はヤクですね。

※デッドライン読書会とは何かについてはこちらのポスト:「読書×締切ではじめる「デッドライン読書会」を始めました」をご参照ください。

 

本を読んだ感想

全体

良い意味でタイトルに裏切られました!DevOpsに関するプラクティス(ツールや、狭義でのデリバリーにおける組織間の連携など)の本かと思いましたが、devops(本書での表記通り)を使い効果的に仕事をするための文化の醸成を語った本でした。

ちょうど最近自分の活動では、アジャイル型の開発(スクラム)、CI/CD、ダイアローグなどを深く考える機会があったんですが、本書を読むことで幅が広がりそうな感覚があります。というのも著者は文化の醸成に関することについて幅広く見識があるようで、認知のスタイル、育成におけるフィードバック、チーミング、採用、ファシリティ、といった部分からもちろん関連するITの開発の事情まで含めて参考情報込みで展開してくれています。TEDの動画や参考書籍・サイトへのリンクも細かく入っているため理解を掘り下げやすく、助かりました。(ただその分読むのはなかなか進まない。。。)

なお本書での言う四本柱とは、次のとおりでした。

  • コラボレーション
  • アフィニティ
  • ツール(今回の#01はここまでが対象)
  • スケーリング

個別

個別のテーマで本書内で気になったことを箇条書きします。

  • 4.1.2 devopsは単なるアジャイルなのか
    • アジャイル以上に広さがあると(私はちょっと異論がある)。devopsはどんな組織でも適用ができる。気をつけなくてはいけないのは、Dev(開発チーム)とOps(運用チーム)だけに適用するといったことだけを考えてはいけないこと。それは解消しようとしたサイロ化を別のサイロに取り替えているだけ。
  • 8.2.3 私は働きすぎだ、ストレスが溜まっている、燃え尽きた
    • 業務後にジムに行って身体を鍛える人がいるように(世の中には筋肉がすべてを解決するという人もいるw)、業務外でメンタルを鍛えるという活動をしても良いと思う。ジムのトレーナーに身体にあったトレーニング方法を教えてもらうように、精神についてもプロから指導を受けるといいのかもと思った。それは瞑想かもしれないし、カウンセリングかもしれない。
  • 9.3.5.1 内集団・外集団理論(チームの団結力)
    • チーム外からの圧力が、チームの結束を強めるというのは私も経験がある。この効果と、チーム間の連携(経験の共有など)によるお互いのブラッシュアップを活用すると、組織としての力が上がるのだろうか。競い合いつつ(競い合わせつつ)、情報もちゃんと共有して、、とか難易度が高そうなチーム運営だなぁ。
  • 9.3.6 多様性
    • この本は多様性の充実と脱差別を何度も繰り返し記している。おかげで自分の見識の狭さと経験の少なさを思い知った感じ(LGBTQの「Q」の存在をこの本で知ったくらい!)。多様性とインターセクショナリティについてもう少しちゃんと現実味を持って知らなくてはいけないと気づきました。
  • 11.2.2 インフラストラクチャーの自動化
    • 「構成ドリフト」と「スノーフレークサーバー」は初耳のキーワード。インフラの管理に手作業がはいるためにできてしまう状態。IaCで管理すべし。

 

次回(#02)

スケジュールはGoogleカレンダーで分かるようにしています。第2回は次の要領です。

読書×締切ではじめる「デッドライン読書会」を始めました

エンジニアにとっても、ビジネスパーソンにとっても、書籍から情報を得ることは価値があると思っています。でもついつい積読してしまったり、途中まで読んでそのままおいてある本は多いのではないでしょうか。そういったときにおすすめな方法は、「リズミカル」に「共読」する方法です。それらを実現する方法として私はアクティブ・ブック・ダイアローグ(ABD)という読書法も好きですが、実は昨年から自社の中で試していた読書習慣を作る方法がありまして、それを自社の中に限るのではなく、オンライン上で実施することにしました。その名も…

デッドライン読書会!!

デッドライン読書会の目的は次の2つです。

  • リズミカルに本を読む習慣をつけること(締切とリズム)
  • 複数人で同じ本を読むことにより、理解を深めること(共読)

進め方は次の通り。

  1.  1冊書籍を決めます。(ジャンルは広く問わず)
  2.  2週間かけて本を読み、最終日までに感想文を書きます。(ブログや、Qiitaなど共有できるところ)
  3.  その感想文を1週間かけて、facebookやTwitter上で意見交換を行います。
  4.  イメージとしてはスプリント2Week+レビューと計画1Weekです。
  5.  オンライン上のハッシュタグは #デッドライン読書会 です。
  6.  スケジュールはGoogleカレンダーで分かるようにしています。

実は第1回はすでに開始されていて、次の要領です。

正直少々ハードな取り組みですが、やってみると面白い。読み切れると自信につながる(というか締め切りがあるので、ちゃんと読み切れる^^;)。ぜひ一緒にやりませんか?

Teal組織をABDで読みました

 

いま流行りの「Teal組織~マネジメントの常識を覆す次世代型組織の出現」を、これまた流行りのABD(Active Book Dialogue)で読むということに挑戦しました。以前からとても期待した読書方法だったのですが、その期待通りの結果が得られ、とても満足しています。ぜひ広まって欲しいので、私が体験したABDを記録に残したいと思います。

 

Active Book Dialogueとは?

Active Book Dialogue、略してABDと読みます。およそ1年前の2017年春にアクティブ・ブック・ダイアローグ協会が発明した読書法とのことです。ポイントをあげると、「事前の準備なしで、大人数で分担し、数時間で要約し、共有することによって、分厚い本を読破する」といった手法です。実は具体的なマニュアルも前述の協会にて無料で公開されています(http://www.abd-abd.com/)。

 

Teal組織とは?

2018年1月に邦訳版が出版された、次世代の進化型組織(ティール)に関する書籍です。内容としては、

  • これまでの組織の進化の歴史
  • 進化型組織の事例
  • 理想的なプラクティスやツール
  • 進化型組織を作るために我々はどうしたら良いか

といったテーマでまとめられています。いまふと検索して気づいたんですが、「ティール」とは邦訳すると「鴨の羽(かものは)色」なんですね。だから本の表紙もあの色だったんだ。ページ数は592頁。一人で読むには相当大変な部類です。

 

Teal組織をABDでどうやって読んだの?

今回は25名(うち1名はファシリテータ兼務)でABDを実践しました。

 

0. 準備(開始前まで)

ABDを実施する前には、こんな段取りが必要です。

  • (運営側)集客
    • 対象の書籍の総ページ数から算出して、一人20~30頁分ほどが担当になるようメンバーを集めます。
  • (運営側)本の準備
    • 本を参加者の人数に合わせて、分割します。目次で区切ったり、章で区切ったり、します。
    • 物理的に本を裁断して用意する場合もあれば、参加者に本を持ち寄ってもらいページでくぎって共有するという方法もあります。
  • (参加者)心の準備
    • 特に何も準備しなくてよいです。
    • 本を事前に読む必要は本当にないです。
    • あと、ABDも分かりやすい手法なので予習不要です。

 

1. チェックイン(00:00~00:30)

ABDを実施するグループのコミュニケーションがよくなるように、場の準備体操をします。

  • 自己紹介
  • アイスブレイク
  • 対象の書籍の共有と、参加者が担当する箇所の共有
  • 会場のルール、進め方の確認

 

2. メイン(00:30~03:45)

ABDのメインどころです。参加者は担当範囲を読書し、まとめ(コ・サマライズ)、共有(リレー・プレゼン)、対話(ダイアログ)の順に進んでいきます。

  • コ・サマライズ(60分)
    • 担当する20~30頁の範囲を個人で読み進めます。
    • 読み進めつつ、B5用紙最大6枚ほどに要約文を作ります。
    • 紙にまとめた要約文に基づいて、のちほど全員の前で共有(リレー・プレゼン)するため、文字は大きく書くのがこつです。
    • 自分の前後の担当は気にせず、とにかく担当のページを深く理解すればよいです。
    • 他の参加者へちゃんと伝えなくてはいけないという、心地よい緊張感をもって読書ができます。
  • リレー・プレゼン(3分×参加者、90分)
    • コ・サマライズした紙を壁一面に貼ります。壮観です(後載)。
    • 一人3分間を制限時間で、担当した箇所をプレゼンします。
    • この時、自分の担当範囲より前の人の内容を聞いていると、「自分の担当の章の位置づけはこうだったのか!」と気付き、コ・サマライズしていたときのちょっとしたモヤモヤ感が解消していきます。
  • ダイアログとギャラリーウォーク(45分)
    • コ・サマライズとリレー・プレゼンで読破した1冊についてダイアログで理解を深めます。
    • 方式はどのようにしてもOK。円座で会話しても良いし、グループを作り共有しても良い。
    • 対象の本の深堀りも良いですし、周辺分野の知識を披露・共有しても良い。多くの方が参加していると様々な観点で話ができるためとても贅沢な時間です。
    • 最後に、壁に貼ってあるコ・サマライズをゆっくり見て回りましょう。

ギャラリーの様子

IMG-2510

 

3. クロージング(03:45~04:00)

今回のABDを振り返ります。3名くらいのグループで感想を共有するのがよさそうです。最後に後片付けと会場の原状復帰をしておしまいです。

 

今回のABDはどうだったか?

流れは上で説明したような進め方でした。準備は本当に要らないのか?という最初の不安はあっさり裏切られました。コ・サマライズで挑戦するのは30頁ほどであるため、それさえ読めて要約できればOKです。書籍の前提知識も不要でした。

次に書籍に対する理解はどうか?この4時間ほどの時間で、600頁弱の書籍を大まかながら理解することができました。普段一人で読んだ場合と比べて短時間で書籍の要点を見ることができるため、肝心な部分の理解が深くなると感じました。ただどうしても細かい事例や、ちょっとした用語の定義はコ・サマライズの段階で省かれてしまう場合が多いようです(私もいくつか初出の言葉の定義を省いていたことに、リレー・プレゼン中に気づきました)。隅々まで理解するためにはじっくり時間をかけて読む方法をとる必要がありそうです。ただ、ビジネス書の類の本の読み方(理解の深さ)としてはABDはちょうど良いと感じました。とくにちょっとしたブームとなった本の場合、参加者を集めやすいという側面もあると思います。

最後にABDでそれほど期待していなかったが良かった点として、ダイアログでの話の広がりかたです。参加者のバックグラウンドやメンバーの多様性によってダイアログの質は変わってくると思いますが、リレー・プレゼンで何度も出てきた考え方を深堀できたり、別の書籍でも言及していると教えてもらえたり、または自分の現場での経験など、多岐に渡る議論ができると思います。

 

今後どうしようかな?

実践方法は簡単なのに効果があって楽しいという素敵な読書法でした。問題は良い書籍が選べられるか?と、多様なメンバーを集められるか?ですね。ぜひ自分の周りでも実践してみようと思います。