2018/4に読んだ本

やはりゲームがないと読書が捗りますね。今月は漫画が多かったですが。

先月読んだ本

• ダンナ様はＦＢＩ (幻冬舎文庫)
• 統計思考入門 ― プロの分析スキルで「ひらめき」をつかむ
• 鞄図書館1
• 怪盗ルパン伝アバンチュリエ【著者再編集版】 1: 怪盗紳士ルパン・上 (ルパン帝国再誕計画コミックス) 1〜7
• 菩薩の山: 『天顕祭』番外編
• ダンジョン飯 6巻 (ハルタコミックス)
• 超人間要塞　ヒロシ戦記（１） (イブニングコミックス)
• プシスファイラ
• ウイスキーと私
• 水上悟志短編集「放浪世界」 (コミックガーデン)
• ホクサイと飯さえあれば（１） (ヤングマガジンコミックス)
• 逃げるは恥だが役に立つ（１） (Ｋｉｓｓコミックス)
• 甘々と稲妻（１） (アフタヌーンコミックス)
• スティーブズ 1 (ビッグコミックス)
• ランド(6) (モーニング KC)
• サーバントであれ――奉仕して導く、リーダーの生き方

印象的な本

フィクション

フィクションが非常に収穫多かったです。もともと追いかけていたダンジョン飯とランドの最新刊は安定の面白さだったのですが、それ以外に良かった作品もほとんどがあたりという確変月。

ダンジョン飯は若干当初の趣旨から離れていっている感があって、その意味でドラゴンボール的な流れを思い起こさせます。メインキャラクターがライオスのサイコパスっぷりに慣れてきてたところなので、新しいツッコミ役が来たのは良かったと思います。というか、このサイコパスが主人公で大丈夫か？

ダンジョン飯 6巻 (ハルタコミックス)

ランドは、世界の内情が少しずつ見えて来た感じですね。どこに着地させようとしているのかはまだわかりませんが。続きが楽しみです。

ランド(6) (モーニング KC)

そして、唐突に出会った「ズルい枠」。ダンジョン飯に初めて出会った時のような感覚でした。同じ事象が異なるスケールで描写されるだけで、こんなにも感覚にズレが出て来て面白いのか、と思わせる作品。

超人間要塞　ヒロシ戦記（１） (イブニングコミックス)

それから、何と言っても「プシスファイラ」ですね。Kindle Unlimitedにあったので何気なく読むリストに放り込んでいたのですが、これがまた注釈も含めた情報量的に偏執狂としか言いようがない感じで。内容としてもディアスポラに行き着くまでという世界観で良いです。ネットワークに対して深い知識を持っていると思われるので、その点でも読み応えあり。

プシスファイラ

後は、「水上悟志短編集 放浪世界」と「怪盗ルパン伝 アバンチュリエ」と「甘々と稲妻」が良かったですね。いやあ、あたり月です。

水上悟志短編集「放浪世界」 (コミックガーデン)

「虚無をゆく」がとにかく良い。

怪盗ルパン伝アバンチュリエ【著者再編集版】 1: 怪盗紳士ルパン・上 (ルパン帝国再誕計画コミックス)

ルパン作品はあまり読んだことがないので、新鮮でした。

甘々と稲妻（１） (アフタヌーンコミックス)

ちょっと「うさぎドロップ」あたりにも感じが似てて好きです。

ノンフィクション

読み物系ノンフィクションかな？と思ったら、案外ビジネスにも使える本だったのが「ダンナ様はＦＢＩ」でした。文章も軽めなだし、Kindle Unlimited契約している方は読んでみてもいいと思います。

ダンナ様はＦＢＩ (幻冬舎文庫)

「サーバントであれ」は、サーバントリーダーが必要な理由についての説明が中心の小論集でした。いい本でしたが、若干今求めているものとは違うかな、と。サーバントリーダーシップの方を読むべきか。ブックオフで見つけたのがこっちだったので文句は言えませんが。

サーバントであれ――奉仕して導く、リーダーの生き方

2018/3に読んだ本

先月は大物が多くて、あまり数読めませんでした。

妻の退院とその辺に関わる諸々が少し落ち着いてきて、生活サイクルも少し落ち着きました。

先月読んだ本

• イルミナエ・ファイル
• Team Geek ―Googleのギークたちはいかにしてチームを作るのか
• Adaptive Code ~ C#実践開発手法 第2版 (マイクロソフト関連書)
• 0 to 100 会社を育てる戦略地図

印象的な本

フィクション系

先月読んだフィクションと言えば「イルミナエ・ファイル」一作なんですが、これがすごくいいです。お値段張るから文庫待ち、とか思ってるそこの諸兄、この本絶対に文庫化されないと思うので今買いましょう。

イルミナエ・ファイル

この本の魅力はなんと言っても、フォーマットから何からこだわって書かれた表現方法と、それを翻訳した執念です。「印刷されたあらゆるもの」に情報量が入り込みすぎて、文章の軽く2〜3倍の情報量があります。SF的に目新しいことがあるわけではなく、むしろオーソドックスな題材の組み合わせですが、この手法をエンターテインメントとして仕上げるためにはこのくらいのベタさ加減でちょうどいいと思うくらい。

ノンフィクション系

今回は全て印象的でした。「Adaptive Code 第２版」については先日書いた記事に任せるとして、他２冊。

mao-instantlife.hatenablog.com

「チームギーク」は今更ながらなんですが、よかったですね。ただ、自分がマネージャの仕事として思ってたあれやこれやがリーダーの仕事となっていて、マネージャ・リーダー観ってのはまだまだ人によってブレがありそうだな、と感じました。どんなつもりでその人が説明しようとしているのか、というのは話聞くときに考えておいた方が良さそう。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

「会社を育てる戦略地図」は、これからのキャリアパスで捉えた方がいい本だと感じました。自分がいる会社がどのフェーズにいるのか、は別に経営者だけの話ではなくて、社員としても要求される振る舞いに合わせないと評価されない、という話になりますので。

0 to 100 会社を育てる戦略地図

Serverless Application Repositoryからデプロイしたアプリケーションのアップデートを試す

まだ検証したいことはいくつか残っていますが、話題としてキリがよくなってきたので一旦エントリにまとめます。

Serverless Application Repositoryとは、っていう話はこちらから。

dev.classmethod.jp

アプリケーションの公開も、既に記事になっています。

dev.classmethod.jp

で、こういうのを見るとアプリケーションのライフサイクルとか更新時どうなってるんだろう、とか諸々考えてしまう性癖なのが私です。

やること

• テスト用のアプリケーションを公開してデプロイ
• アプリケーションの変更をして公開しなおして(同じスタックに)デプロイ

のライフサイクルを実際にやってみて、以下の点について現状の仕様を確認してみようと思います。

• デプロイ済みアプリケーションへの更新通知とか
• アプリケーションの更新手順

これからやりたいこと

以下はこれから検証したいこと。

• デプロイした後にCloudFormationの設定を変更してからアプリケーションの更新
• デプロイした複数のアプリケーションを取りまとめて一つのアプリケーションにするための良いプラクティスの模索

検証

さて、ここから検証です。

アプリケーションの1stバージョンのpublishとデプロイ

これについては先ほどあげたクラスメソッドさんの記事のママで問題ないでしょう。

dev.classmethod.jp

この記事の通りにやらなかったこととか、書かれていない範囲での気づきは以下の通りです。

• デフォルトでの公開範囲はプライベートで、その場合は作成アカウントから同リージョンのLambdaにのみ作成可能
• 公開でpublishされたアプリケーションは東京リージョンのLambdaへもデプロイ可能
• ライセンスは一度publishすると編集できないっぽい
• デプロイ時にAuthorizerの追加とかデプロイのカスタマイズの設定がない

今回は、適当なJSONレスポンスを返すものを作ってみました。

github.com

で、デプロイした時のスタックログとLamndaのテスト実行の結果は以下です。

SAMアプリケーション前提とはいえ、Lambdaのコンソールからデプロイなんだなあ、と少ししっくりきていないところです。

2ndバージョンのpublish

さて、実際のアプリケーションの運用においては、一度publishされたアプリケーションが更新されないことはないと思いますので、アプリケーションを変更してみます。DynamoDBをリソースに追加して、JSONレスポンスに追記してみました。これを、新たなバージョンとしてpublishしてみましょう。

新しいバージョンを追加するには、リポジトリの「マイアプリケーション」からpublish済みアプリケーションのページを開きます。右側のバージョンリストに「新しいバージョンを発行」というボタンが出てるのでそれをクリック。

新しいバージョン番号とyamlを指定します。

「公開バージョン」をクリックすればpublishされます。

2ndバージョンの更新検知の有無を確認

デプロイ済みのアプリケーションに何か通知があったりするかなあ、とか思ってしばらく待っていたのですが、そんなことはありませんでした。

まあ、パッケージリポジトリとパッケージの関係のようなものなので、リポジトリからプッシュ通知みたいなことはしないのでしょう。ましてや問答無用でバージョンアップとかされても怖いですし。

2ndバージョンのデプロイ

同じアプリケーションに更新デプロイしてみます。ここがまだ流れとして不自然だな、と感じたところ。

CloudFormationのスタックからはリポジトリ参照で更新みたいな流れは見つけられなかったので少し逡巡してしまいました。結論としては、Lambdaから新規関数の作成に進んで、リポジトリから選択、スタック名を同じにしてデプロイするという感じです。

デプロイ済みの関数が更新され、関連するCloudFormationスタックのリソースやイベントが更新されています。

まとめ

このリポジトリに公開できるのはSAMなので、どちらかというとこれだけで完結するというよりは、gradleやmavenやGemのようにパッケージとして扱って組合わせてアプリケーションを構築する、みたいな未来をAWSは想像しているはずです。そういう未来になるのは、まだアプリケーションのライフサイクルだったり、パッケージ管理に相当するものだったりが足りないなあ、という印象。同じスタックで新規作成というのも少し迷いました。

ただ、この辺は順次解決されていくでしょう、AWSですから。CloudFormationがServerless Application Respositoryに対応して、パッケージマネージャみたいな位置付けになっていくんじゃないかな、と思います。パッケージマネージャ的なものを自力で作るという手もありますが(Serverless Frameworkのプラグインとか？)。

Adaptive Code 第2版を読んだ

長澤さんよりご恵投いただきました(厳正なる抽選の上)。多謝。

Adaptive Code ~ C#実践開発手法 第2版 (マイクロソフト関連書)

3行所感

• いいか、戦争は兵站からだ
• インターフェイスを使え
• 御託はいいからインターフェイスを使え

所感

本の内容をなぞるだけのレビューは大嫌いなので、ここは読みながら私が感じたことを書いてみたいと思います。

コードは書いた瞬間から鮮度が落ちていくもので、それに抗う必要がある

致し方ないことですよね。プロダクトが未来永劫同じ使われ方をして、同じニーズにこたえ続けるわけではなく、ユーザや市場も変化し続けているわけです。そのため、プロダクトが果たさなければならない役割も変化し続ける。

で、これも仕方のないことですが、コード自体はリリースしたタイミングを起点に次のリリースまでどんどん鮮度が落ちていきます。書き逃げのようなプロダクトならともかく、ユーザとともに育っていくつもりのプロダクトなら、この変化に対応しないといけないわけです。本書ではこの変化に対応しやすいコードのことを「Adaptive Code(適応的なコード)」と称しているわけです。

そして、これにどうやって抗うのか、ということが書いてあります。中でも重要なポイントは以下の3点だと思いました。

• 適時にリリースできるようにする
• コードの上でも抽象と具象を分ける
• 抽象ベースに依存関係を作りやすい構成にする

デリバリーフレームワークという言葉と構成に感じる強い意志

「Adaptive Code」というタイトルながら、本書の頭1/3くらいは「デリバリーフレームワーク」と表現された開発プロセス(Scrumとカンバン)と、コードの配置の仕方について力を入れて書かれています。いうなれば兵站に相当するようなことなわけですが、具体的なコーディングテクニックの前にやるべきこと、考えることについて目を向けており、章立てから非常に強い意志を感じる構成です。個人的にはやっぱりカンバンが好きだなあ、と思いました。

それはそうと「デリバリーフレームワーク」というのは良い表現ですね。コードもデリバリーも適応的にいくべきだ、という思いを感じる表現です。著者がカンバンを成熟したチームのためのフレームワークと表現しているのは、カンバンの方がよりシンプルでかつ適応的であると考えているのでしょう。

ただ、カンバンのところにある「サービスクラス」と「SLA」の例えは、ちょっと唐突な感じがしました。このところは理解するのに少し時間がかかったというか、まだちゃんと理解できているか怪しいところです。

すべてはインターフェイスのために(違

Javaを使い始めのころは、インターフェイスの利点をよくわかっていませんでした。そのころに入った案件では、結構うまくインターフェイスを利用していたのですが、「どうせ実装クラス出てくるのにぶっちゃけ邪魔だなー」としか。それからデザインパターンを知り、インターフェイスを使って柔軟性を確保する方法を知り、今となってはインターフェイスの恩恵を受けないことなど考えられないくらいです。

で、本書では、段階的にその利点を感じながら使いどころを抑えていくためのサンプルとコーディングテクニックにあふれています。それはもう、インターフェイスを使いやすくするために各種パターンやコーディングテクニックがあるのだ、と言わんばかり(あくまで「言わんばかり」ですよ)。

まとめ

長澤さん、ありがとうございます。とても良い本でした。

初学者の段階からすべてを把握することは厳しいかもしれませんが、備えておくべき資質になると思うので、早いうちから読んでいく本だと思います。また、C Sharpに限らず(第2版は原題から外されている模様)、オブジェクト指向言語を扱ってコードを書いている人には有用な本だと思います。

オープンセミナー2018@広島でお話ししようと思っていたこと

まず初めに、オファーいただいた後も数々の準備・公式サイトでの告知などお手数かけていただきながら、直前に参加できなくなってしまったこと残念に思います。運営の皆様には直前でご迷惑をおかけしました。致し方ないこととは言え、私も当日に向けて積み上げてきたものがありますので、同様に残念です。いずれ、ブラッシュアップしてどこかでお話できるといいな、と思ってます。

妻の退院当日に片付けをしながらTwitterを見ていましたが非常に濃い内容だったようで、私もその場に行って他の方のお話しも聞きたかったところです。

togetter.com

今回、それなりに準備をしてきたということもあり、そのままお蔵入りというのも勿体無い話だなあ、と感じました。そこで、どういうことを話そうとしていたか、ブログに要点をまとめたいと思います。

一番言いたかったこと

「これをやれば必ずチームがよくなる」方法はないので、チームに合わせて考えるのが唯一の解になります、という身もふたもないお話し。

これは、それぞれ置かれた状況が異なる複数のチームでマネジメントをした経験の中で、同じことが同じように効果があった訳ではなかったという背景に基づいています。それを踏まえて、実際にやった取り組みの具体例よりも、理由に遡ってから少しそれを抽象化して実施に繋げるためのどんなアプローチをしたか、を主題としました。そのメタファーとして取り上げていたのはグラウンドキーパーです。実際にスライドに書いたアプローチは以下です。

• チームへの仕事の入り方をコントロールする
• チームの仕事の仕方を確立する
• イレギュラーに気付きやすい良いグラウンドにする

まあ、もう少し言葉を洗練させたかったな、とは思いますが、抽象化したアプローチとして正確さを損なわないレベル、と言うことで。

良かった点

スライドやスクリプトを作っていく中で、今回オファーいただいてよかったな、と感じたこと。

複数のチームでやってきたことを抽象化するきっかけになった

今の会社に入ってから3チーム、プライベートでも少し似たような入り方をしているので1チーム、それぞれでやってきたことを抽象化して共通項を見つけていくきっかけになりました。少し時間がたっているからこそ、冷静に思い返して理由や背景について整理できる、という側面もあったと思います。

この辺りは、最近チームに関するブログが減っている理由にもなっていて、チームで取り組んだ話をしようと思うと、チームが置かれている状況だとか、歩みとか、そういったものへの言及が避けて通れないよな、となっている訳です。そうなると書かなきゃいけないことや書く上で考慮しないといけないことが増えてきます。すべての取り組みは背景が諸々あって、まずはこれを選んでいる、という状態なわけです。

で、こういったものを記述すること自体は有益なことだと思うので、適した言葉がないかなあ、と探してはいるわけです。で、たどり着く結論は大体パタン・ランゲージ。結局そこに行き着くのかよ、パタンのメンテナンスしんどいから一人でやるようなもんじゃないよなあ、とかなってなかなか踏み出せず、といった状況です。

過去のスライドから自分にとって普遍的なことを見つけた

これも収穫でした。できてないときもあるけど、軌道修正するのに必要な言葉が書いてあります。過去の自分すごい。

具体的には以下2枚。これが他の人に響くかどうかは別として、自分の中では常に気をつけたいことです。自分に言い聞かせるためにも、定番的に入れ込んで行こうかな、と思いました。

反省点

当然、今冷静に読み返してみると反省点も多々あります。

詰め込みすぎた

上記の一番言いたかったことの他にも、ドメイン知識ないところからマネージャとして入っていることとか、自分の考える良いチームの定義みたいなことなんかもスライドに入っていました。今思うととてもじゃないけど、30分に収まりそうにないですね。もっと伝わらない部分を覚悟の上で話題を絞り込めば良かったと思います。

言い訳がましく言ってしまうと、広島でお話しするのが初めてなので、自分の背景について知ってもらおうと考えて色々と書きすぎたのだと思っています。

タイトルミスった

「プロジェクトXのないチームを目指したマネージャが取り組んだこと」じゃなくて、もっと色々あったよなあ、とは。「グラウンドキーパー的マネジメント」とか端的な表現でも良かったのではないか、とも思います。

上記の詰め込みすぎ、のところにもかかる訳ですが、トピックを分離すると「ドメイン知識ゼロから始めるチームビルディング」と言うタイトルも出てきそうです。このように、スライド見ながら複数のタイトルが切り出せそうなこと自体が話題が絞り込めてない証拠ですよね。

タックマンモデルなどチームのモデルについてもう少し触れればよかった

上記詰め込みすぎ、に矛盾するように見えますが、トピックが絞り込まれていればもっとこの辺のモデルの背景に触れることは可能だったように思います。元スライドでは、自分の背景と理由が中心でしたから。

抽象化が足りない

これはもう少し言葉を洗練させれば改善していくのではないかと思います。今回オファーいただいてからすべてのスクリプトを起こしたので、流れも含めて準備を結構突貫でやってしまったところがあるかもしれません。表現の質という意味では、自分にとって定番な表現タームというか、そういうものを作ってしまってもいいのかもしれないです。

その後

TLを追いかけながら触発されて、チームギークを速攻ポチったわけなんですが、理由や背景の面で近いところに至っていたのか、と思うようなことがいくつもありました。今回中途半端な表現になってしまったところなんかを、この本とも絡めてブラッシュアップして、どこかでリベンジしたい。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

t.co