デッドライン読書会#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回はすでに開始されていて、次の要領です。

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

1年間のやりたいことリストを作ってみた

やりたいことリストとは

正月ということで、1年の計画を立てました。その中の一つで、「やりたいことを100個あげる」ということに挑戦してみました。ここでいうやりたいことリストは、、、

  • やりたいこと
  • カテゴリ(仕事、プライベート、ファミリー)
  • やった日
  • メモ

の4つの項目を列にして、100個並べただけのリストです。いつでも見られるようにGoogleスプレッドシートにテンプレートを作成しました。やりたいことを100個もまとめられたらそれだけでも幸福な生活ができるんじゃないかなぁとおもって、その実験です。

100個埋めることに挑戦

元日の午前中(つまり、元旦)に作成しようと思いたち、頭を捻りながら実施。100個はなかなか難しい。私の場合は、40個くらいまではスラスラ出たんですが、そのさきがちょっと苦行でした。結局元日の夕方くらいまでかかりました。

作ってみて分かったこと

こつこつ上げると、「やりたいこと」にはそのときどきの自分の状況が現れるんじゃないかと気づきました。いまの私は子供が小さいこともあり、「子供が楽しめる工作系」、「体験系」が多いような気がします。プライベート面では「誰々と直接会って話してみたい」がいくつか出てきました。

あと、大量にやりたいことを考えようとすると、去年感じた「(他の人がやっている)羨ましそうなこと」もたくさん思い出せます。私も挑戦してみようかな〜という気分になるわけです。

作るときの注意事項

幸福になるため(?)の「やりたいこと」リストです。WANT-TOをまとめることに終始する必要があります。間違ってもHAVE-TOをまとめてはいけないです。そうなったらただの巨大なTO DOリストに追われる生活に、、、。

1年間で何個達成できるか

ちなみに、1月2日さっそく一つ目ができました!この調子で1年間で何個実行に移せるかなぁ。楽しみです。