結果
ブログ
目標：月 8 回（週2回）更新
結果：月 2 回 更新
読書
目標：月 1 冊
結果：月 1 冊
反省点など
この歳になって料理作るとか掃除するとか生活をしっかりしはじめてしまって、なかなかスキルアップに気が回りません。
2月までの勢いが自分のペースでは異常だったのですが、どこかで切り替えしないとなあと感じています。
来月に向けて
引っ越しなど色々終わらせてすっきりした状態になっていればいいなと思います。
【読書メモ】みんなのAWS 〜AWSの基本を最新アーキテクチャでまるごと理解！
ゴールデンウィークだけど外出もできないのでだらだら1冊だけ読みました。
目次
ざっくりですが、第1章はAWSというよりクラウド（インフラ）の歴史から責任共有モデル、Well-Architectedフレームワークについて、IAMのアカウント管理やCloudWatchのモニタリングに関して触れています。
第2章でネットワーク、コンテナ、CI/CD環境...といったカテゴリー別にAWSサービスの紹介。
第3、4章でサーバーレスアプリ、データ収集基盤を実際に構築するハンズオン形式の解説となっています。
良かった点
ポイント・概要的なことはまとめるとキリないので良かった点だけ。
実際の構築に近い視点でAWSサービスを理解できる
これまで認定試験のAWS勉強だけだったので表層的な知識習得だったと思うのですが、この本では
- どのような考えでアーキテクチャを設計するのか
- 運用やセキュリティ目線ではどのようなことを考える必要があるのか
等、実際の案件に近そうな感じでシミュレーションができ理解が深まったように思います。
たぶん、他のAWS本でも同じ方向性の内容だとは思うのですが、特に良かったのはタイトルに「みんなの」って書いている通り、初学者の人にとっても学びやすい内容だったことです。
例えば、第2章でコンテナの説明を扱っていますが、ECRやECS、EKSの説明の前にそもそもコンテナとはなにか、向いているケースはどのようなケースかみたいな話が丁寧に説明されています。
解説されていることのほとんどは何となくは知っていたけれど、背景的な話や実際の構築に近い話が出てくるのでこれまでの本とは違う観点でAWSやそのサービスを見れるようになったかなと思います。
コンソールのキャプチャが多い
3、4章のハンズオンの中でキャプチャ多用されているので、実際にいじってなくても本の中だけで完結できるのはよかったです。寝る前とかに読めるので。
情報が新しい
試験本は若干古い情報が載ってたりするのですがこの本は新しいので、この比較表は内容古そうだからググって調べなきゃな的なバイアス抜けれるだけでだいぶ読むの楽だった感じがします。特にS3のストレージクラスなど。
まとめ・感想
もっとAWSのこと試験対策だけじゃなくで理解しようというふうに思いました。
1年ほど前からプラクティショナーの勉強始めて、そう思えるまでに時間かかってしまいましたが他の本なども読んでみたいと思います。
2020年4月 振り返り
結果
ブログ
目標：月 8 回（週2回）更新
結果：月 2 回 更新
読書
目標：月 1 冊
結果：月 2 冊
反省点など
なんででしょう。あれだけ欲しいと思っていた時間がすぐそこにたくさんできたはずですが、インプットもアウトプットもペースが落ちてしまっています。
来月に向けて
長い目でみてもう少し状況に慣れて、あまり無理せずやっていきたいと思います。
【読書メモ】他者と働く──「わかりあえなさ」から始める組織論
技術本ではないですが気になっていてほしいものリストにずっと入れてた本。
前回 読んだチーム・ジャーニーでハンガーフライトの解説で、対話に関して詳しく理解したい人におすすめの本として挙げられていたので、次に読んでみようと思っていました。
他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)
- 作者:宇田川 元一
- 発売日: 2019/10/04
- メディア: 単行本
目次
- はじめに 正しい知識はなぜ実践できないのか
- 第1章 組織の厄介な問題は「合理的」に起きている
- 第2章 ナラティヴの溝を渡るための4つのプロセス
- 第3章 実践1.総論賛成・各論反対の溝に挑む
- 第4章 実践2.正論の届かない溝に挑む
- 第5章 実践3.権力が生み出す溝に挑む
- 第6章 対話を阻む5つの罠
- 第7章 ナラティヴの限界の先にあるもの
2章までが枠組みや、本で扱う問題や解決方法について、3章以降は事例を元に解説されています。
概要・ポイント
対話
知識として正しいこと、でも実践でもそれが正しいとは限らない。その問題を解決するために行うのが対話。
本の中での定義としては「新しい関係性を構築すること」
そもそもそのような問題が起こる要因、解決法としての対話のステップと方法はこうですよという話がこの本の大
技術的問題
既存の方法で解決できる問題
適応課題
既存の方法で一方的に解決ができない複雑で困難な問題
他の部署に協力を求めることが必要な課題を例とした関係性の中で生じる問題
関係性の改善
「私とそれ」という道具的な関係から「私とあなた」という固有の関係へシフトする。
自分の中に相手を見出すこと、相手の中に自分を見出すことが対話の意味である。
適応課題のタイプ
- ギャップ型 価値観と実際の行動にギャップが生じるケース
- 対立型 互いのコミットが対立するケース
- 抑圧型 言いにくいことを言わないケース
- 回避型 痛みを伴う行動に向き合わないケース
ナラティブ
物語、つまりその語りを生み出す「解釈の枠組み」のこと。それぞれ人がみんなもつもの。
ビジネス上では「専門性」「職業倫理」「組織文化」などに基づいた解釈が一般的。その人にとっての一般常識。
ナラティブ・アプローチとは、「どう相手に話をするか」よりも「どう相手を捉える私の物語を対話に向けていくか」を主軸にしたもの。
解釈
相手のナラティブにおいても意味があるようにするにはどうしたらよいのかを考えること
できれば信頼のおける仲間や相棒と一緒にやるのが望ましい
対話のプロセス
- 準備 「溝に気づく」
- 自分から見える景色を疑う
- あたりを見回す
- 溝があることに気づく
- 観察 「溝の向こうを眺める」
- 相手との溝に向き合う
- 対岸の相手の振る舞いをよく見る
- 相手を取り巻く対岸の状況をよく見る
- 解釈 「溝を渡り橋を設計する」
- 溝を越え、対岸に渡る
- 対岸からこちらの岸をよく見る
- 橋を架けるポイントを探して設計する
- 介入 「溝に橋を架ける」
- 橋を架ける
- 橋を往復して検証する
- 橋を補強したり、新しい橋を架ける
「準備」段階は歯がゆく勇気がいる。一度自分のナラティブを脇においてみることが大事。
対話の罠
- 気づくと迎合になっている
- 相手への押しつけになっている
- 相手と馴れ合いになる
- 他の集団から孤立する
- 結果が出ずに徒労感に支配される
読みながら1.は自分もそうなりそうだよなと感じていたが、迎合（忖度）は相手へ隷属すること、自ら気づいた課題意識や問題点を見ないようにすること、すなわち、諦めることを意味しているので、そこが対話との違い。（プロセスでいえば橋を渡ったまま帰ってこないのといっしょ）
あとは最後の辞めたり、休んだりすることも重要というのは大事な気がしました。
良かった点
- 最後エモかった
- インテル、レッドハットなどIT企業の例が多い
惜しかった点
- 特になし
まとめ・感想
大学のときにメディア学すこしかじってて、ナラティブとか物語性（人は物語をつけたがる・求める）みたいな話に通ずるところがあり、今になってこういうテーマを見ることになるとはなあという感じでした。
例えば第3章の新規部門と既存部門の話など結構いまの仕事というか会社内でも関連する話がありました。
去年結構売れている本のようなのですが、こういう類の本が売れる（みんなが関心を持つ）っていうのはいいなあと思いました。
【読書メモ】チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
市谷聡啓さんの上記2冊に続いて、チーム・ジャーニーを読みました。
カイゼン・ジャーニーの続編ぽい感じだったので（実際には単体でも読める）2月の発売から楽しみにしており、3月に内容も多めだったのですが、ちょっとだらだらしながらになってしまいましたが読みました。
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
- 作者:市谷 聡啓
- 発売日: 2020/02/17
- メディア: 単行本（ソフトカバー）
目次
第1部 僕らが開発チームになるまで─1チームのジャーニー
- 単一チーム 基本編
- 単一チーム 応用編
第2部 僕らがプロダクトチームになるまで─複数チームによるジャーニー
- 複数チーム 基本編
- 複数チーム 応用編
カイゼン・ジャーニーは、1人から始められるカイゼンを繰り返しチームが遷移していく（だけど焦点は個人に合っている）物語でした。
対してチーム・ジャーニーは、チームマネジメントやチームづくりについて、よりチーム全体に焦点を当てた内容になっています。
物語方式にて、まず問題（ストーリー・問題編）、次に課題（ストーリー・解決編）、最後に解説が各章にておかれています。
基本編で4章、応用編で4章、それが1部+2部なので全16章というボリュームになっています。
概要・ポイント
大枠として、度々書かれていたこと
- なめらかに進める
- 解像度を意識する
- 状況によってフォーメーションを組む
チームマネジメントにおいて、一気に状況を変えようと思っても無理は利かないので段階的に予定を立て進めていく。
人によってその情報や状況に対する捉え方（視座=高低/視野=広狭）が違うので念頭におく。
ひとつの固定の役割、既存の概念に囚われず状況に応じて柔軟に配置転換、役割の創出などを行なう。
その他、気になったこと、なるほどと思ったことなど。
コンウェイの法則
プロダクトやシステム設計が、組織構造（チーム分割等）を反映したものになることをいう。
逆にプロダクトの機能などから組織構造を作ることを逆コンウェイの法則という。
取引コスト
もとは経済学の言葉で、違う文脈を持っている相手に対してコミュニケーション取ることは取引コストが高い、などという。
「リード」という役割
「リーダー」とは別の「リード」という役割
・リーダー => 組織上の職位として定義
・リード => ある状況において前進を先導する「役割」。例）テクニカルリード、仮説検証リード、テストリード
情報の解像度
レイヤーによって粒度分けて展開するのが望ましい。
例えばPOなどのレイヤーで細かな機能についてまで話を展開してしまうと、開発者メンバー側では情報を受け取って「ただそれを実装する人」になってしまう。
ある程度は余白もたせて PO => リード => 開発者 などに受け渡ししていき細部を詰める流れがよい。
番頭の輪番化
担当をローテーションすることで、トラックナンバー1問題（誰々しかこのコードを触れない問題）につながらないようにすること。
ただし、チームメンバーの専門性や関心などで、あるメンバーに依存する領域が生まれてしまうこと自体は悪いことではありません。むしろメンバーの多様性がいきている状態ともいえます。属人性を排除することを過度に目指すのではなく、何かが起きたときに他の人でプランB（本人ほど最適ではないが、他の人でもなんとか対応できる作戦）が立てられるかどうかを明らかにしましょう。
事前に許可を求めるより、後でゆるしを得たほうがたやすい
先に動いてしまって後でゆるしを得にいくということ
これ結構メンバー側目線で自分も意識していて、ケースバイケースではあるものの決裁権持っているひとにいちいち確認しても時間もったいない（=ボトルネックになる）と判断したら答え確定して出した方がいいなと
視座と視野で決まる視点
物事をどこからどこまでを見るようにするか、「どこから」というのは「視座」、「どこまで」とは「視野」にあたる。
その上で
・視座や視野への偏りをつくらないこと
・視座の高低と視野の広狭を自分たちの意思で行き来できること
が重要。
良かった点
- 少し登場人物の名前が分かりづらいが、相変わらずストーリーがおもしろい。
- 問題：課題：解説の割合、1:1:1 くらいですが、ある問題に対して内容割いている本も少ないように思うのでためになる。
惜しかった点
- 特になし
まとめ
本に解説してある内容でも実際の現場では状況も違うので、その都度ベストな選択や考えを結局自分自身がしたり持ったりしなくてはいけないのだけれど、その幅が広がったり選択がしやすくなるような内容の本だと思う。
いっぽうで結局正解はないので読者の主観に後は委ねられる部分も多くある、そういう不確定要素を好まないひとには向いていないかもしれないが、筆者の「正しいものを正しくつくる」でさんざん語られていたように今の時代そういう開発形態も考えも主流になっていくなかでうまく自分も適用できるようにならないとと感じた。
最近発売されたオライリーの みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた の説明にも
本書では、「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」をアジャイルの3つの原則とし、...
と書かれています。
自分も今の会社に入って分かったのですが、結構クライアント側の方が開発に入ってくることが多く、その良い面みたいなのはすごく感じています。それでいて知識も豊富だと後ででてくる要件も出づらいのでやりやすいなと。
今回の本はチームビルディング的な観点だったので、いちメンバーである自分には適用しづらい内容も多かったですが、そういう視点も持ちながら働く/働かないではわりと違うんでは、と思っているのでもちょっと視野広げてやっていきたいと感じられました。
2020年3月 振り返り
結果
ブログ
目標：月 8 回（週2回）更新
結果：月 15 回 更新
読書
目標：月 1 冊
結果：月 2 冊
反省点など
ブログ前半は調子良かったが後半失速気味になってしまった。
仕事の業務でフロントエンドできているのが収穫です。
来月に向けて
新たにコレを勉強する、っていうのが今のところない..
Vue or Nuxt もうちょっと勉強でもするか、この機会にAWSのSAP勉強するか悩み中です。
3月からフルでリモートでした。
当初の慣れのなさからは落ち着いてできるようになったので、もう一度もとに戻すところは戻してやっていきたい。
Netlify で $ gulp build がビルドエラーになってしまう
いつもどおりNetlifyでGulp使ったプロジェクトをデプロイしようとしたらエラーが出てちょっと詰まったのでメモ。
管理画面側でDeploy Settingsからもビルドコマンドなど設定してましたがログに
Error running command: Build script returned non-zero exit code: 127
みたいに出て、ググってみるとビルドコマンドがないよ的な内容らしい。
ただローカルでは $ gulp build でうまくいってるのでイメージのバージョンとかかなと思いつつ公式見てみると、
Eleventy starter with serverless functions というのがあり、
https://templates.netlify.com/template/eleventy-starter-with-functions/
リポジトリ内に netlify.toml てのを見つけました。
https://github.com/philhawksworth/eleventyone
この netlify.toml は設定ファイルをコードベースで管理できるそうなので、
netlify.toml の中身
[build] command = "gulp build" publish = "dist"
とりあえずこれだけ書いてルート階層に置いてプッシュしてみました。
結果、うまくいった。
厳密な原因分からずですが、とりあえずGulp使って自動デプロイまでの調査結果でした。