デッドライン読書会#08「レガシーコードからの脱却」(後半)の感想文

課題図書

第8回目のデッドライン読書会(読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は第7回に引き続き、「レガシーコードからの脱却」の後半部分です。後半部分の範囲は、8章プラクティス4「協力しあう」から最後まででした。第7回の感想はこちら(デッドライン読書会#07「レガシーコードからの脱却」(前半)の感想文)です。

感想文

全体

あらためて本書で紹介しているプラクティスを転記すると、次の9つになります。

  • プラクティス1:やり方より先に目的、理由、誰のためかを伝える
  • プラクティス2:小さなバッチで作る
  • プラクティス3:継続的に統合する
  • プラクティス4:協力しあう
  • プラクティス5:「CLEAN」コードを作る
  • プラクティス6:まずテストを書く
  • プラクティス7:テストでふるまいを明示する
  • プラクティス8:設計は最後に行う
  • プラクティス9:レガシーコードをリファクタリングする

9つのプラクティスは、この書籍独自ではなく、これまでに他書で語られていたプラクティスで特に重要視すべきものをまとめた形をとっています。それぞれのプラクティスでは、概要、目的、はじめ方、制約などを語っています。さらにその詳細(いちおう各章に「実践しよう!」っていう節もありますが、それでも概要かな…)が必要なときには関連書籍へゴー!という位置づけです。後半部分を読んで特にそう感じました。

本書の概要の具合からすると、もしくは、「エンジニアはそういったことを気にする必要があるんだよ」というマネージャーなどの周辺の人向けの本なのかもしれないですね。

で、「関連書籍へゴー!」となると、主要どころでは次の本になると思います。

エクストリームプログラミング

リファクタリング(第2版): 既存のコードを安全に改善する

テスト駆動開発

本書の最後に「レガシーコードからの学び」というまとめの章があります。ここで著者のBerstein氏が強調していることは、アジャイル型の開発において、マネジメントプラクティスだけではなく、もっと技術プラクティスに着目しようと言っています。

技術プラクティスはアジャイルのマネジメントプラクティスと少なくとも同じくらいには重要である。しかし、多くの組織ではほとんど注意が向けられていない。アジャイルの技術プラクティス抜きでアジャイルのマネジメントプラクティスをやっても、多少は利益があるだろう。だが、アジャイルの本質的な価値は、エクストリームプログラミングの技術プラクティスを適用することによって得られるのだ。

14章 レガシーコードからの学び(P.243)

自分自身に当てはめても最近はソフトウェア開発のソフトな部分(コミュニケーションなど)によく興味を持っていました。原点回帰し、技術プラクティスを精進するのは重要ですね。ソフトウェア開発の、、、ハードな部分とでも言うんでしょうか^^;

個別

勉強になったところを個別に抜き出します。

私が「ユニットテスト」の「ユニット」といった場合、多くの開発者が想定しているメソッド、クラス、モジュール、関数などのようなエンティティを指すものではない。

 ユニットとはふるまいの単位、つまり独立した検証可能なふるまいのことだ。

10.3.2 振る舞いの集合体(P.169)

自分の中には「関数があってユニットテストがある」ということが染み付いているため、この整理はすっきりしますね。テストファースということは、振る舞いをテストする必要(このテストは、別名でいうと、チェック、ふるまい、設計、仕様、などか)があり、ふるまいの単位がユニットなのだと。

そこで私はクライアントに、シャント、依存性の注入、及びモックを使った…

10.7 テスト駆動開発は失敗することがある(P.173)

シャントがわからなかったので調べました。たぶんテスト駆動開発にある「Self Shunt(自己接続)パターン」のShuntだと思います。オブジェクトが他のオブジェクトときちんとやり取りしていることをテストするためのパターン。その他にも右記のサイトではモック、スタブと並列して解説されていました→CunninghamのWiki:Mock Stub Shunt

コードは読むためのものだ。本や新聞の記事と変わらない。平均して、コードは書かれる回数の10倍読まれている。

12.3 コーディング対クリーニング(P.208)

「1回書いたら終わり」って考える人は流石に少ないだろうけど、1回リリースできたらもういいかなっていう人は多そう。読めるコードでなくてはだめ。コメントで語るのも良くない。

次回(#09)

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

  • #09の候補書籍(検討中)
    • Design It!
    • INSPIRED 2nd Edition
    • フィンテックエンジニア養成読本
    • IT業界の病理学
  • デッドライン
    • #08の感想交換1Week(12/30〜1/5)
    • インターバル(1/6-1/12)
    • #09の読書する時間2Week(1/13~1/25)
    • #09のブログポスト期限(1/26)

デッドライン読書会#07「レガシーコードからの脱却」(前半)の感想文

課題図書

第7回目のデッドライン読書会(読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は、「レガシーコードからの脱却」です。原著は2015年発行、和訳の本書は2019年9月発行です。オライリーのソフトウェア開発の汎用スキル系(どういうカテゴリなのか良い名前が思い浮かばない…)の本です。

今回前半の範囲は、本書の最初から7章「プラクティス3 継続的に統合する」までの範囲です。

感想文

全体

本書で言う「レガシーコード」とは、変更ができないコードを指しています。ソフトウェア開発自体が発見的なプロセスであるべきで、つまり、変更が前提とされるのに、そもそも変更ができないコードのことをレガシーコードと呼んでいるわけです。

よくあるうまくいかないソフトウェア開発(例えば失敗するウォーターフォール型とか)っていうのは、レガシーコードを作り込み、あとから品質を作り込み(品質強化テストみたいな営みで)、そのなかでたくさん人が投入されて火消し役と呼ばれる人たちが活躍する、といった形が多いのかなと思います。レガシーコードを作り込むというのは、まさに最初のサービスインがゴールで一発勝負だという前提で進めている場合に起きやすいのだと思います。受託開発の形式で起きやすいとかあるんじゃないかなぁ。開発で儲けて、保守は手離れよく…みたいなマインドのときです。

この本では、それはもうやめにして、原理・原則を把握し、具体的なプラクティスを大工の道具箱のように備えることによって、世の中を良くしていこうという内容です。この大工の道具箱に入れるのが9つのプラクティスで、それはスクラムやリーンの考え方より具体的で、エクストリーム・プログラミングの考え方より抽象的(よりプラクティスの数を絞って)で、まとめられています。

脱線しますが、この「大工の道具箱」といった表現が私は好きです(本書では「自由に使える範囲の知的な道具」という表現もありましたね)。システムエンジニアの道具箱にはいったいどんなものが入っていると面白いのでしょうか。そのうちのソフトウェア開発の技術的な部分にあるのが、この本の9つのプラクティスでしょう。それ以外にも、人事、コミュニケーション、ビジネススキル、哲学、ワークライフバランス、などいろいろなものが入っていると面白いですね。

個別で気になった部分

気になった箇所を引用しつつ、一言コメントをします。

アジャイルやスクラムの目的は急いで仕事をすることではなく、小さなかたまりで仕事をすることだ。

3.3 アジャイルを実践する

これって、本当によくある勘違いを、正しくしているところです!スピードを早めるためにアジャイルやスクラムをやるんではない。小さなかたまりで仕事をすることによるメリットを享受することが一番の目的と思います。

コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。

4.1 専門家が知っていること

急がば廻れといいますか、丁寧にお仕事しようということですね。苦手だなぁ。精神的にどっしり構えらえることも実は重要そうですね。

ソフトウェア開発者として、プロダクトオーナーと顧客がを欲しいのか、なぜ欲しいのかを知りたい。そしてのためのものなのか知りたい。どうやってやるかは教えてほしくない。

5.2 やり方を目的に転換する

これは自分は比較的この通りやってこれたかなと思います。あんまりどうやってやるかを言われたことはないかなぁ。ただ「何」と比較し、「なぜ」や「誰」は深掘りが弱かったと感じます。ところで、逆に「どうやって」を顧客が言ってくれたとしたら、「そこまで分かってくれる人なのか!」と感心してしまうんだけど、その感覚はどうなんだろうか。

だが、私は10分でも遅いと思う。

7.4 ビルドを自動化する

手厳しい…「10分」はビルドの所要時間を指している、本書の最初の方でもビルド時間は3分とあった。そして多分この「ビルド」には、

  • コードの取得
  • ビルド
  • ユニットテスト
  • 受け入れ環境用の展開
  • 自動受け入れテスト
  • 各種フィードバック

などが含まれているんでないかと想像。(システム規模によると思いますが)システム全体のクリーンなビルド(ゼロからのビルド)で3分って難しいような気がするから、システムを小さく分割して差分的な技を駆使することにより短時間でビルドシステムからフィードバックを受け取れるように工夫しなさいということかなぁ(と、期待というか、甘えというか…)。

でもここで表現されているような高速なビルド・自動テストは憧れますね。気持ちよく開発できそうです。いまは高速な静的解析くらいは努力しなくてもツールによってできますが、高速なビルドと自動テストはエンジニアが頑張らなくてはいけないところだと思います。

次回(#08)

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

  • #07の書籍
    • レガシコードからの脱却(後半戦)
  • デッドライン
    • #07の感想交換1Week(12/9〜15)
    • #08の読書する時間2Week(12/15~12/28)
    • #08のブログポスト期限(12/29)

デッドライン読書会#06「ソフトウェア・ファースト」感想文

課題図書

久しぶりのデッドライン読書会#06の課題図書は及川卓也氏の「ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略」でした。

買ったあとに気づきましたが、400ページに迫る勢いの、がっつりとした本でした。

本を読んだ感想

本書について

本書はマイクロソフトやグーグル、スタートアップなどで働き、いまは大企業のデジタル変革の支援をされている及川氏が著者です。2019年10月15日発行のため、読書会としては早めに手を付けた方ですかね!(といっても2人の読書会ですが^^;)内容としては、すべての日本企業がIT活用を手の内化し、ソフトウェアを活用し外面的(ビジネス)にも、内面的(組織、ひと)にも変革していくためのアイデアを著者が経験してきた本物のソフトウェア・ファースト企業での実体験をもとに整理してくださっています。

本書においては周辺コンテンツが充実しており、私は本に手を付ける前に、Fukabori.fmでこの本に込められた想いも拝聴しました→Fukabori.fm ソフトウェア・ファースト w/ takoratta

それと本書の制作秘話(?)や、没稿となった情報などの補足情報が今後noteで公開されていくらしいです。そちらも要チェックですね。→ソフトウェア・ファースト制作委員会

全体の感想

私自身はSIerにつとめ、事業会社さまへデジタル変革(DX)を支援する仕事もさせてもらっています。その仕事を通して学ばせてもらったことが随所にありました。

  • 事業部門と、開発部門の連携の重要さ
    • どうしたら「全員がプロダクト志向」になれるのか?
    • みんなに自分ごととしてもらうための難しさ
  • ソフトウェア開発における外部調達を戦略的に行えているかどうか
    • 開発の工程にヒエラルキーをつけてしまっていないか、上流工程が偉い、など。
  • 本来の「マネージャー」とはチームにとってどうあるべきか
    • 改めて、スポーツにおける、監督やマネージャーの役割と比較してみる
  • 開発技術の進歩の早さと、それにいかに自分自身も追随するか

本のタイトルにある「ソフトウェア・ファースト」ですが、各所でこういった説明がありました。3箇所引用します。

事業やプロダクト開発を成功させるには、ソフトウェアの流儀を知り、ソフトウェアの可能性も知りつつも、現状のソフトウェアが抱える限界も理解して、開発に挑む姿勢が必要なのです。

P.35 ソフトウェアファーストとは

ソフトウェアの可能性を理解した上で、ユーザーの感情に訴えるプロダクト開発を目指す姿勢がソフトウェア・ファーストなのです。

P.146 ハードウェアはソフトウェアのためにある?

1. ハードウェアはソフトウェアのためにある
2. ソフトウェアはユーザーエクスペリエンスのためにある
3. ユーザーエクスペリエンスは人々の感情を満足させるためにある

P.182 ITがすべてではない

このようにソフトウェアをいかに活用・浸透させて、その先のユーザーの感情(行動)をいかに変革させていくかという点は、自分も今後携わってみたい働き方の一つでもあります。

これを読むと、ビジネスとはなんと広いことかと改めて思います。ソフトウェアが中心の仕事とはいえ、見るべきはソースコードだけではなく、ひと、組織、顧客、技術…etc。改めて書いても当たり前なのですが、たくさん。これらをあとからまとめて追おうとすると大変だろうな。日々精進と、T型プラスαの考え方が大事ってことでしょうか。

個別の感想

本書内の個別の記載についてコメントさせてもらいます。

各種方法論

ばりばりエンジニアの方以外も想定読者(【制作裏話】なぜペルソナを他者に作ってもらったのか)なので、開発方法論や、技術動向、組織論などの紹介もあります。本書では触りとなっていますので、文中に紹介されている参考文献に進んでいくと深掘りができそうです。(む。今気づいたけど、この本は最後に参考文献一覧がついていないのか。もったいない…)

インナーソース

オープンソースプロジェクトのやり方を、会社の組織内に持ち込んだ考え方をインナーソースと呼ぶようです。オープンソースのコミュニケーション手法や、コミュニティベースの活動(?)を良い文化として会社の中に持ち込むってこと。

「おもちゃ」が世界を変えたことです

本書で何度か出てきますが、ソフトウェア・ファーストの考え方になれるように、「おもちゃ」でたくさん遊ぼうと。新しいスマホのアプリをいれてみたり、SaaSの新しいサービスを触ってみたり、など。私もそれなりにいろいろ新しいもの触る性格ではあるんですが、もっと戦略的(!?)に触ってみようかなぁ。せっかく買ったHMDもあまり活躍していないし…。

次回(#07)

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

  • #07の書籍
    • レガシコードからの脱却(前半戦)
  • デッドライン
    • #06の感想交換1Week(11/11〜17)
    • #07の読書する時間2Week(11/25~12/7)
    • #07のブログポスト期限(12/8)

【読書メモ】ザッソウ 結果を出すチームの習慣

ソニックガーデンの倉貫さんが書いた「ザッソウ」を読みましたので、読書メモを残します。

本の紹介

倉貫 義人 氏「ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

読書メモ

ビジネスのコミュニケーションは、報・連・相(ホウレンソウ)で、というのが通説ですが、仕事の進め方が、労働力から創造力へ変わってきた現在では、ザッソウ(雑談と相談)こそが大事だよね、という本。「雑談」というとなんだかグレードダウンした感じがしますが、ザッソウはホウレンソウよりステージをあげるコミュニケーションです。心理的安全性を高め、難しい問題(クリエイティブな問題)を、よりチーム力で解決していくにはどうしたらよいかのヒントが得られると思いました。以降では、気になった箇所と感想を残します。

  • タックマンモデルの「ストーミング(混乱)」期における「まぁまぁ」という仲介は、70点のチームを作ってしてしまう。
    • 自分がすごくやりがちな行為…もしその期にチームがあるのであれば乗り越えるための施策は慎重に考えたほうが良かったなぁ。
  • 共通の話題がないと本来は盛り上がりにくい関係ですが、同じ本を読むことでザッソウをしやすくなるのです。(ザッソウしやすい職場の作り方)
    • 同意。同じ本を読んでいることで、同じ言葉が使えるのは心理的な壁を一つ破れるきっかけだと思います。
  • 3〜4人くらいでザッソウしやすい関係性を作っておくことが心理的安全性の高さを生み出します。
    • こういった仕掛けを意識的につくれるようになりたい。上の読書会も同じ仕掛け。
    • ザッソウしやすいように、雑談のネタをばらまいておくことも場を作る仕掛けなんだろうな。
  • 「気楽に真面目な話をする」(オフサイトミーティング)
    • 気軽な場で気軽な話をする(例、飲み会)、真面目な場で真面目な話をする(例、会議)、その中間の場としての「気軽に真面目な話をする」はすごく憧れる。1on1ではできる気がするけど、チームとしての気軽に真面目な話をするっていうのはなかなかできないなぁ。
    • 昔、戦略会議と銘打って何回か開いたことがある。それ自体は良かったけど、思い出せば会議の名称が固かったかな^^;(参加者からすると意図せず場所もちょっとだけオフサイトの形式を取っていた)
  • 人間は肯定されると調子に乗りますし
    • そのとおり。
  • 遠慮は自分のための行動ですが、配慮は相手のための行動
    • いい言葉。「遠慮しなくても良いんだよ」と声をかける(雰囲気を作る)のは、配慮の行動かしら。
  • やっている仕事の中身についてではなく、仕事のやり方について話をします(ふりかえりのザッソウからはじめよう)
    • 一つ抽象度をあげて。やり方のカイゼンですね。
  • 「脳のブレーキ」
    • 私も頻繁に脳のブレーキをかけている気がします。もっとお気楽に。

「ちょっとザッソウしない?」というのは少し気恥ずかしいですけど、「ちょっとお茶しませんか?」くらいでスタートするのは良いと思いました。本書も大変勉強になりました。ありがとうございました。

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

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