msksgm’s blog

msksgm’s blog

Webエンジニアです。日々の勉強記録、技術書感想、美術観賞感想を投稿します。

7月の振り返り

7月の振り返り

生活習慣

運動習慣を継続中です。
健康的なのですが、同じことを繰り返しているのでメリハリがなくなってきました。

プログラミング関連

個人開発

個人開発をおこなっていました。
主に、「認証認可」、「API 設計」、「ER 図」、「デザインカンプ」、「Atomic Design」などに取り組んでいました。
「テスト」がまったく手をつけられていないので、着手したいですが、「Atomic Design」を意識したフロントエンドの実装が難しくで時間をとっています。
また、インフラ、ネットワークの方に時間をまったくとれていないです。

1 週目

一般的な攻撃方法と,Node.js のアプリケーションの脆弱性を学びました.
Firebase Authentication から passport.js と jwt を用いた認証認可の実装に挑戦しました.
一応できましたが,脆弱性がどこにあるのか怖いです.

2 週目

Firebase Authentication を使うと,セッションの管理が難しそうなのと,DB も Firebase に依存してしまいそうなので,やめました.
なので jwt を用いた,認証を導入していました.
時間がかかりましたが,一応完成しました.
次から,認可処理について取り組んでいきます.

3 週目

個人開発をすすめています。
バックエンドの改修していました。
フロントエンドで Atomic Design の練習をしていました。
設計として、draw.io を使って ER 図と画面遷移を作成していました。

4 週目

個人開発を進めました。
バックエンドは一通り完成したので、フロントエンドを作成していきます。

5 週目

フロントエンドを主に注力していました。

フロントエンド

1 週目

useContext を用いた,ログインユーザ情報,ログイン関数,ログアウト関数をグローバルに取得する方法を作りました.
また react-router-dom を用いたルーティングによって,ログイン状態によってリダイレクトするかどうかの処理(と Layout を付与する処理)ができるようになりました.

2 週目

react-router-dom を用いたルーティング処理に,リロード時にもログイン状態を保存する処理を追加しました.
また,AtomicDesign にも興味がでてきたので,この本で学んでいます.

3 週目

AtomicDesign をこの本で学びました。
フロントエンドのパフォーマンスやテストについて学ぶことができました。

4 週目

デザインカンプを作成していました。
配色の選び方が難しいですね。

5 週目

Atomic Design を実践していました。
実践しようとすると逃げ道がいくらでもあること、デザインカンプ通りにつくれないこと、storybook の仕様になれないことなどに苦戦しています。

バックエンド

1 週目

今まで作成したバックエンドに passport-jwt を組み込んでいました.
routing-controller と組み合わせることもできましたが,Cookie にデフォルトで組み込む方法がなさそうなのが残念です.

2 週目

routing-controllers は,いろいろ不完全な箇所があるので,express を用いた,一般的なバックエンドを作ることにしました.
この記事ソースコードがとても参考になります.
過去に参考にしたときには,よくわからない箇所が多くありましたが,今読むと重要性がわかります.
SignIn,SignUp,の API/user/meのエンドポイントを作成しました.

3 週目

typedi やリファクタリングをおこないました。

4 週目

API の作成をしました。
typeorm の中間テーブル作成方法を学びながら実装していました。
orm は多対多を簡単に対応できるのがいいですね。
また、Swagger で OpenAPI の設計もおこなっていました。
一通りの API を作成できたとおもいます。

5 週目

API の修正をすこしだけおこないました。

インフラ

1 週目

特になし

2 週目

特になし

3 週目

特になし

4 週目

特になし

5 週目

特になし

データベース

1 週目

特になし

2 週目

typeorm を使っています.

3 週目

ER 図を作成しました。

4 週目

特になし

5 週目

typedi で中間テーブルを自動生成する方法について学びました。

ネットワーク

1 週目

特になし

2 週目

特になし

3 週目

特になし

4 週目

特になし

英語

7 月 11 日に TOEIC を受け、結果は 835 点でした。
目標点は 900 点なので、道のりが長く感じました。

技術記事

1 記事目 「TypeScript で passport-jwt を用いた api サーバー作成」

7/2(金)に作成

msksgm.hatenablog.com

2 記事目 「"Error: invalid expiresIn option for string payload" の解決方法 (Node.js, passport.js, jwt)」

7/9(金)に作成

msksgm.hatenablog.com

3 記事目 「routing-controllers に passport を適用させる方法」

7/16(金)に作成

msksgm.hatenablog.com

4 記事目 「jwt-decode で unknown」

7/23(金)に作成

msksgm.hatenablog.com

5 記事目 「react-router-domでLayoutとPrivateRouteを導入する」

7/30(金)に作成

msksgm.hatenablog.com

知識の Buffer

  • winston
  • mailggun
  • agenda
  • async await
  • helth エンドポイントパタ=ン
  • nestjs
  • node.js から DB サーバーにヘルスチェックをおこなう
  • jwt

趣味

読書

1冊目「Clean Architecture  達人に学ぶソフトウェアの構造と設計」[2018, Robert C.Martin]

msksgm.hatenablog.com

2冊目「Team Geek Googleギークたちはいかにしてチームを作るのか」[2013, BrianW.Fitzpatrick/BenCollins‐Sussman]

msksgm.hatenablog.com

3冊目 「Atomic Design ~堅牢で使いやすい UI を効率良く設計する」[2018, 五藤佑典]

msksgm.hatenablog.com

4冊目 「ハッカーと画家 コンピュータ時代の創造者たち」[2005, ポール グレアム (著), Paul Graham (原著), 川合 史朗 (翻訳)]

msksgm.hatenablog.com

映画観賞 「龍とそばかすの姫」

msksgm.hatenablog.com

美術観賞 STEPS AHEAD: Recent Acquisitions

msksgm.hatenablog.com

絵を書く

90 秒ドローイングを引き続き続けています。
あまり時間をとれていないのですが、藤本タツキ先生のルックバックを見て創作意欲がわきました。
何か描きたいです。

最後に

モチベーションが低下していて、個人開発の進捗がイマイチなのですが、記録をつけるといがいと進んでいることがわかりました。
8月中にはテストも含めて完成を目指します。

「Clean Architecture  達人に学ぶソフトウェアの構造と設計」 感想 まとめ

「Clean Architecture  達人に学ぶソフトウェアの構造と設計」[2018, Robert C.Martin]を読みました.

感想

設計の本の名著の一つです.

アーキテクチャによって,プロジェクトが肥大化しても,運用コストを抑えることができることを筆者は述べており,

アーキテクチャのルールはどれも同じである ソフトウェアアーキテクチャのルールはその他すべての変数から独立している 時代が進んでもやることはかわっていない.だからアーキテクチャの有効性もかわていない 時代を超越した不変のルールたち.それこそが本書のすべて

という条文から本書は始まります.

「Clean Architecture」というタイトルから,手を動かしながら,学ぶ本だと思っていましたが.筆者の体験談から裏打ちされる,設計のあり方について述べていきます.

結構設計になれていないと難解な本だと思いました.(自分は難しくて途中から斜め読みしていました.)
実際に設計の面においてつまづいたりや改善したりした経験がなければ難しい内容が多かったです.

それでも,有名な円の図(内部は外部のことをしらない,依存していない)や,依存関係が単一方向になるようにする原則は,今後の多くの場合において役立ちそうなので,つかっていきたいと思います.

概要

SOLID 原則

SOLID 原則の目的は,以下のような性質を持つ中間レベルのソフトウェア構造を作ること

  • 変更に強いこと
  • 理解しやすいこと
  • コンポーネントの基盤として,多くのソフトウェアシステムで利用できること

SOLID 原則一覧

  • 単一責任の原則(SRP: Single Responsibility Principle)
    • ソフトウェアシステムの構造がそれを使う組織の社会的構造に大きな影響をうけるようにする
  • オープン・クローズドの原則(OCP: Open-Cloesed Principle)
    • ソフトウェアを変更しやすくするために,既存のコードの変更よりも新しいコードの追加によって,システムの振る舞いを変更できるようにする.
  • リスコフの置換原則(LSP: Liskov Substituion Principle)
    • 個々のパーツが交換可能になる
  • インターフェース分離の原則(ISP: Interface Segregation Principle)
    • 使っていないものへの依存を回避すべきだという原則
  • 依存関係逆転の原則(DIP: Dependency Inversion Principle)
    • 上位レベルの方針の実装コードは,下位レベルの詳細の実装コードに依存すべきではなく,逆に詳細側が方針に依存するべきだという原則

コンポーネントの原則

コンポーネントとは,デプロイの単位.システムの一部としてデプロイできる,最小限のまとまり.

コンポーネント凝集時の原則

  • 再利用・リリース等価の原則(REP)
    • 再利用性のためのグループ化
  • 閉鎖性共通の原則(CCP)
    • 保守性のためのグループ化
  • 全再利用の原則(CRP)
    • 不要なリリース作業を減らすための分割

この3つはトレードオフの関係になっている.
凝集性は「ひとつのモジュールはひとつだけの機能を持っている」という属性ではなくなっている.
最適なバランスを考える必要がある.

「二日酔い症候群」(非循環依存関係の原則(ADP))と呼ばれる,他人がデプロイしたために次の日には動かなくなる現象がある.

アーキテクチャ

ソフトウェアアーキテクトはプログラマである.プログラムを続けておかなければいけない.
コードを書かないというのはデマである.

アーキテクチャの形状の目的は,そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を用意にすること.
それらを用意にするための戦略は,できるだけ長い期間,できるだけ多く選択肢を残すこと

  • 開発
    • 開発が難しいソフトウェアシステムは,ライフタイムが長くて健全である可能性が低い.だからこそ,システムのアーキテクチャによって,開発チームが開発しやすくなるようなシステムにするべき
  • デプロイ
    • システムを単一のアクションで簡単にデプロイできるようにする
  • 運用
  • 保守

選択肢を残しておく
「残すべき選択肢」とは,重要ではない詳細
アーキテクトの目的は,方針とは無関係に詳細を決めながら,方針をシステムの最も重要な要素と認識するシステムの形状を作ること

優れたアーキテクチャは以下のことをサポートする

  • システムのユースケース
  • システムの運用
  • システムの開発
  • システムのデプロイ

ソフトウェアアーキテクチャとは境界線を引く技芸である.(著者はバウンダリーと呼ぶ)
ソフトウェアの要素を分離し,お互いのことがわからないように制限するものである.
初期に境界線を引くのは,決定をできるだけ遅らせるためである.

結合は,アーキテクトによる,システムを構築し維持するためのパワーを奪う. 早すぎる結合は,フレームワーク,データベース,ウェブサーバー,ユーティリティライブラリ,DI などのビジネス要件に関係ない決定のことを言う

過去のアーキテクチャは,「関心事の分離」という同じ目的を持っている

それらのアーキテクチャは,以下の特性を持つシステムを生み出す

  • フレームワーク非依存
  • テスト可能
  • UI 非依存
  • データベース非依存
  • 外部エージェント非依存

アーキテクチャを動作させる最も重要なルールは依存性のルール

ソースコードの依存性は,内側(上位レベルの方針)だけに向かっていなければならい

  • エンティティは,企業全体の最重要ビジネスルールをカプセル化したもの
    • 外部で何か変化がおきても,それが変化する可能性は低い
  • ユースケースは,アプリケーション固有のビジネスルールが含まれている
    • レイヤーの変更がエンティティに影響を与えることはない
  • インターフェースアダプター.ユースケースに便利なフォーマットから,データベースやウェブなどの外部エージェントに便利なフォーマットにデータを変換するアダプター
  • フレームワークとドライバ

詳細

データの構造であるデータモデルは,アーキテクチャ的には重要である.
データを移動させる技術やシステムは,アーキテクチャ的には重要ではない.
データこそが重要でありデータベースは詳細である.

フレームワークアーキテクチャではない.

フレームワークのリスク

解決策は,フレームワークと結婚してはいけない

ノンデザイナーズ・デザインブック 感想 まとめ

「ノンデザイナーズ・デザインブック」[2016, Robin Williams]を読みました.

感想

言わずとしれたデザイン入門書です.

デザインの4大原則はパワポなどをつかった発表資料にすぐに適用できるため,学生だったり発表する機会が多い人ほど早く知った方がいい知識です.
むしろ,すでにデザインの四大原則についてネット上でわかりやすい解説があるため,先に学んだ方が答え合わせのように理解が進んでいいと思います.
自分はこの資料で初めてデザインの四大原則について知り,実践していました. (2021 年 6 月 27 日最終確認)
カラーホイールとタイポグラフィについては,デザイナー以外は日々の実践が難しいため,カラーホイールはお気に入りのカラーパレッドを見つけて,タイポグラフィは世の中のテンプレートを参考にした方がいいと思います.

この本は,デザイン改善前後の比較があり,具体的な問題もあるため,問題集のように使うことも可能です.
デバックがプログラミングのスキルが向上する手段の一つであるよに,デザインもゼロから作成して学ぶだけでなく,改善によって向上する技術だと思っています.
慣れてくると世の中の広告が洗練されたデザインであることに気がつき,わかりにくい資料がどのようなもので,脳を疲れさせやすいものだとにも気がついてきます.

Web エンジニアは,CSS の使い方を覚えても,具体的にどのようにしたら見やすくなるかわからない人が大半だと思います.
そのため,この本を読むことで Web デザインに限らないデザインの原則について学ぶことができると思います.
もう少し Web デザインについて適用できる内容が欲しければ,他の書籍を1冊選ぶといいと思います.(自分も知りたい)

概要・まとめ

全体感

タイトル通り,非デザイナーのためのデザイン入門書.
チラシや広告を作りたいひとだけでなく,エンジニアが Web デザインに適用できる内容が多く記載されています.
内容は大きく分けて,デザインの四大原則,カラーホイール,タイポグラフィについてです.
具体的なデザインに対して改善前後の比較によって,解説が進みます. 基本的に英語を用いたデザインについての解説ですが,第4版(それ以前も?)には訳者による日本語への適用があります.

簡単なまとめ

デザインの四大原則

近接

  • 目的
    • 組織化
    • 情報が組織化すれば読んでもらえる可能性が高くなり覚えてもらえる可能性が高くなる
  • 実現方法
    • 視線が止まった数を数える.3~5 回に抑える
  • 避けること
    • 増やしすぎないこと
    • 要素ごとに均等の空白を作らないこと

整列

  • 目的
    • 一体化と組織化
  • 実現方法
    • 意図的に要素を配置する.
    • 物理的に離れていても,そろえることができるほかの要素を見つける
  • 避けること
    • 同じページで2種類委譲の文字揃えを用いないこと(中央揃えと右揃えを両方用いるとか)

反復

  • 目的
    • 一体化と視覚的なおもしろさを加えること
  • 実現方法
    • すでに存在する一貫性を,もう一歩進める
    • 一貫性のある要素を,意識的なグラフィック・デザインの一部に変える
    • ただ反復を作り出すためだけに,要素を加えることを考える
  • 避けること
    • 要素を,うるさく強迫的に感じるほどに反復させるないように,コントラストの価値を意識する

コントラスト

  • 目的
    • おもしろみを作り出すこと
      • ページがおもしろそうに見えれば,読んでもらえる可能性が高くなる
    • 情報の組織化を支援する
      • ある項目から次の項目への論理の流れが一瞬でわかるようにする
  • 実現方法
    • 線の太さ,色,形,サイズ,空きなどでコントラストを付ける
  • 避けること
    • コントラストを付けるなら,力づくつくる
    • よく似た書体を複数使ってはいけない

カラーホイール

原色(プライマリーカラー)

他の色から作れない色

2次色(セカンダリーカラー)

  • 緑(黄+青)
  • 紫(赤+青)
  • オレンジ(黄+赤)

3次色(テリタリーカラー)

  • イエローオレンジ(黄+オレンジ)
  • オレンジ+赤
  • 赤+紫
  • 紫+青
  • 青緑(青+緑)
  • 緑+黄

補色

カラーホイールの反対に位置する色

トライアド

3つの組み合わせ,心地よい色のトライアドを必ず作れる
カラーホイールで 120 度ごとに結ぶ

  • プライマリートライアド
    • 原色によるトライアド
  • セコンダリートライアド

スリットコンプリメントトライアド

1つの色の補色に隣接する2つの色によるトライアド

類似色

隣り合う3つの色の組み合わせ

シェードとチント

シェードとチントを使うことで,色に幅が生まれる

  • ヒュー
    • カラーホイールの色
  • シェード
    • ヒューに黒を加える
  • テント
    • ヒューに白を加える

トーン

  • トーン
    • ある色のヒューの濃淡の特定の質を示す言葉
    • 色が近すぎるとみづらくなる

暖色対寒色

  • 寒色は背景に「引っ込む」
  • 暖色は画面に「出る」

タイポグラフィ

あまり理解できなかったのと,再現できないため省略...

日本語と英語のタイポグラフィの性質は大きく異なる
英語を大文字にするとみづらくなるのは,文字の大きさが揃って,塊がみづらくなるため

エンジニアリング組織論への招待 感想 まとめ

「エンジニアリング組織論への招待」[2018, 広木 大地]を読み始めました.

概要・まとめ

全体感

エンジニアリング組織論とは,本文によると「不確実性に向き合う」というたった1つの原則から,エンジニアリング問題の解決方法を体系的に捉える組織論です.
なので,5 つの CHAPTER で順番に不確実性について記述しています.

抽象的な説明から,具体的な説明が5回続きます.
CHAPTER 1 思考のリファクタリング
CHAPTER 2 メンタリングの技術
CHAPTER 3 アジャイルなチームの原理
CHAPTER 4 学習するチームと不確実性マネジメント
CHAPTER 5 技術組織の力学とアーキテクチャ

不確実性への対処方法を
個人の話,対話の話,チームの話(アジャイルとマネジメント),組織の話
という順番で進んでいきます.

まとめ

CHAPTER 1 思考のリファクタリング

「思考のリファクタリング」」とは,「不確実性に向き合う」考え方. エンジニアリングとは「実現」の科学
「実現」のはじめとおわり
ソフトウェアにおける実現とは,「曖昧さ」を減らし,「具体性・明確さ」を増やす行為 人間が正しく論理的に思考するには,以下の二つが必要

  • 事実を正しく認知できる
  • 感情にとらわれず判断できる

非論理的に考えない=論理的に考える 「人は正しく事実を認知できない.」ことを認知する

不確実性は,「未来」と「他人」である 「未来」=環境不確実性 -> 経験主義.仮説思考で対処する 「他人」=通信不確実性 -> コミュニケーションで対処する

  • 情報の非対称性
    • 同じ目的をもった集団で,何かの情報を片方の人が知っていて,もう片方がしらない状態
  • 限定合理性
    • 認知範囲や能力の限界から,限られた範囲でしか合理的な行動が取れない性質
    • 個人的に最適な戦略が,全体にとって最適になるとは限らない

真に組織に求められるコミュニケーション能力とは,コミュニケーションの不確実性を減少させる能力のこと

CHAPTER 2 メンタリングの技術

「思考のリファクタリング」の考えかたを使い,対象となる人自体の考え方をすこしずつ変えることで,問題解決の力を育みます.

効果的なメンター・メンティの関係性

  • 謙虚;お互いに弱さを見せられる
  • 敬意:お互いに敬意を持っている
  • 信頼:お互いにメンティ(自身)の成長期待を持っている

心理的安全性と責任による4つのメトリックス
メンティをラーニングゾーンに運ことがメンターの役割

  1. 無関心ゾーン 心理的安全性が低い,責任も軽い
  2. 不安ゾーン 心理的安全性が低い,責任が重い
  3. コンフォートゾーン 心理的安全性が高い,責任が軽い
  4. ラーニングゾーン 心理的安全性が高い,責任が重い

ジャハリの窓

  1. 開放の窓 自分はわかっている,他人はわかっている
  2. 盲点の窓 自分はわかっていない,他人はわかっている
  3. 秘密の窓 自分はわかっている,他人はわかっていない
  4. 未知の窓 自分はわかっていない,他人はわかっていない

能力と成果はコントロールできない
習慣と行動はコントロールできる

CHAPTER 3 アジャイルなチームの原理

アジャイル開発」はチーム全体に対してメンタリングを行い開発出力を向上させる方法論
「ソフトウェアをどのように作るか?」はアジャイルの主眼ではない

日本では,アジャイル実践者の数が圧倒的に少ない

アジャイル開発が必要とされた2つの理由

  • ソフトウェアが大規模化・複雑化
  • マーケットの複雑性に対応する

スケジュールとマーケットという2つの不安

  • 目的不確実性
  • 方法不確実性

アジャイルをするなアジャイルになれ

「Do Agile」は誤り,「Be Agile」が正しい

アジャイルであるとは,

  • 情報の非対称性が小さい
  • 認知の歪みが少ない
  • チームより小さい限定合理性が働かない
  • 対人リスクを取れていて心理的安全性が高い
  • 課題・不安に向き合い不確実性の削減が効率よくできている
  • チーム全体のゴール認識レベルが高い

アジャイルな方法論

  • 不安に向き合うこと
  • 少人数の対話を重視する
  • 役割を分けない
  • 経験のみを知識に変える
  • 意思決定を遅延する
  • 価値の流れを最適化する

アジャイルソフトウェア開発宣言
参照

アジャイル開発は「脱構築」される

アジャイルの起点は「アジャイルへ至るために,私たちは何をすべきか」「どうしたら,もっとチームの抱える不確実性を減らしていけるのか」考えること
アジャイルな方法論」を「チームメンタリング」する
脱構築」とは,対話により自分たちの対立を解消し,再構築すること
外でうまくいっているなにかを探し出すことではなく,しっかりと自分たちをとりまく環境を観察すること,そして何か流行りのかっこよさを教条的に取り入れるのではなく,今何をすべきかをしっかりと周囲に対話していくこと.
それが,チームをアジャイルにする最も効率的な道

CHAPTER 4 学習するチームと不確実性マネジメント

不確実性マネジメント

不確実性とは

  • 方法不確実性:スケジュール予測と見積もりの手法
  • 目的不確実性:要求と仮説検証の手法
  • 通信不確実性:振り返りの手法

スケジュール予測と不確実性

スケジュールマネジメントの基本

  • 制約スラックを削減する
  • 見積もりの予測可能性をあげる
  • プロジェクトバッファの消費を可視化する

不安に向き合うフレームワークとしてのスクラム

役割

  • プロダクトオーナー:プロダクトの品質を担当
  • 開発チーム:開発を担当
  • スクラムマスター:「プロダクトオーナー」と「開発チーム」の間のボトルネックを解消する

不安への対処

  • 目的不確実性にともなうマーケット不安に向き合う
  • 方法不確実性にともなうスケジュール不安に向き合う
  • 通信不確実性にともなう「情報の非対称性」を減らす

チームの学習

  • スプリント計画
  • デイリースクラム
  • スプリントレビュー
  • レトロスペクティブ

ゴール認識にはインセプションデッキを使う

権限と情報処理能力

上司のみが権限を持ち,部下に具体的で細かい指示をださなければならない組織は,情報処理能力が低い
部下にも権限があり,抽象的で自由度のある指示をだせる組織は,情報処理能力が高い

権限と組織設計からみる組織設計のポイント

  • 明示的な権限と責任の委譲を行う
  • 権限と責任の不一致をなくす
  • 権限動詞の衝突を最小にする
  • 権限の衝突解消レベルを最小にする

技術的負債

最初のコードを出荷することは,借金をしにいくのと同じである.
負債が生まれる.その時の利息によっては借金に頭を抱えることになる.

システム開発は「何かをできる機能を作る」ということと同時に,「何かができないところを作る」という作業であるという理解が必要不可欠.

イメージとしては,「ジェンガ

以下の心情はありえない
「今は急いでいるから,早いけど将来困りそうなコードを書こう」
「今は時間があるから将来を見越したコードを書こう」

「見ることができない」という非対称性が,技術的負債が問題になる最大の理由

以下が技術的負債が生まれる2つの情報非対称性.これらを対処できないのがコミュニケーションそのものに原因がある.

技術的負債の可視化には「アーキテクチャの複雑性」と「将来要件の不確実性」に対処する必要がある.

アーキテクチャの複雑性には以下で対処する

  • 循環複雑度の可視化
  • 依存関係の分析
  • コードチャーンの分析

将来要件の不確実性

  • 非機能要件の具体化
  • 仮説・戦略の透明化
  • ユビキタス言語の作成

CHAPTER 5 技術組織の力学とアーキテクチャ

組織設計とアーキテクチャ

取引コストが高く情報処理能力が低い組織では「コンウェイの法則」から,技術的負債が生まれる 「逆コンウェイの法則」により,取引コストが低く情報処理能力が高い組織になる

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャにより,切り離した組織とシステムを作ることができるが,無理な導入にはデメリットもある.

マイクロサービスの特徴

  • サービスによるコンポーネント
  • 分散ガバナンス
  • スマートエンドポイント
  • 分散データ管理
  • プロジェクトではなくプロダクト
  • インフラ自動化
  • 進化的設計
  • ビジネスケイバビリティによるチーム化
  • 失敗のための設計

エンジニアリングカンパニー

構造上の問題は,誰かのせいでないのと同じぐらい,私たち自身を含んだ全員の責任でもある
解決すべき問題はその姿が見えてしまえば,「悩み」は「考える」に変わる
必要なのはシステムの「エンジニアリング」

所感

組織論について書籍で読んだことがなかったのと,4 月から新社会人になり組織について気になったのでジャケット買いした本です. 「不確実性」への対処がこの本で一貫したテーマなので,込み入った話をしていても頭の片隅に置いておくと読みやすいです.

新卒エンジニアでも,読んでいて学びの多い本なので読むタイミングは選ばない本だと思います.強いて言うなら働き方や将来像に対して「不安」を感じたときに読むのがベストかもしれません.

個人であっても,複数人であっても,チームや組織であっても,「不安」に駆り立てられないときはないと思います.
そこで,この本に書いてある通り,見えないものを見えるように行動することで,不安ではなくなり,悩みは考えるへと変化します.
それは,技術的なことでも,経営においても,アジャイルにおいても同様です.
見えないから不安であり,情報が非対称だから思い通りにならないことが一貫してかかれています.
この本の良いところは,個人から集団へとシフトして説明していくことだと思います.
そのおかげで,大体の立場において通じる考えを得ることができる本となっています.

不確実性を対処できることが,「エンジニアリング」ということを考えると全てのエンジニアが目指す像はこれなのかもしれない,と思いました.

「特別展 国宝 鳥獣戯画のすべて」感想

特別展 国宝 鳥獣戯画のすべてにいってきました.

特別展 概要

鳥獣戯画展は,緊急事態宣言により会期が 6 月 20 日までになっていました.
チケット争いは熾烈で,発売時刻になってもチケット購入ページに遷移するまで,20 分ほど必要でした.

鳥獣戯画の公開は今回が初めてではなく,過去に何度か行われたそうです.
しかし,全4巻(甲,乙,丙,丁)を公開したのは初めてです.

特別展は,甲,乙+丙+丁,明恵上人の順番に展示が進みます.
甲の箇所で鳥獣戯画の全体的な解説が入り,乙+丙+丁で鳥獣戯画のあまり有名ではない情報の解説があります. 最後に明恵上人の人生について描かれた絵巻と関連品の展示で終了します.

作品 概要

鳥獣戯画とは,平安時代から鎌倉時代にかけて作られた作品です.
擬人化したような動物たちが有名で,光を使わずに線だけで絵を書かれており,漫画の原点の一つだと言われています.

兎とカエルが相撲をとっている絵が最も有名ですが,兎とカエルだけでなく,猿,狐,猫なども登場します. また,動物メインで書かれていると思われがちですが,全部で4巻のうち,甲が主に擬人化したような動物たちの絵がメインとなっています.
乙が幻獣である麒麟と龍が書かれていたり,写実的に描かれている鶏,象,サイ(または玄武)などが書かれていたりします.
残りの丙と丁では,人間が主に書かれており,当時の暮らしぶりが描画されています.

全ての作品を通して同じ作者によって作られたわけではなく,複数人が時代を隔てて作成しました.
そのため,全4巻で作品の対象が異なると考えられます.
また,作品に対して上から加筆した跡や,作品ごとに絵のタッチの違いなどを確認することができます.

鳥獣戯画には,断簡(鳥獣戯画の一部を切り取り,掛け軸などにして飾ったり保存できるようにした作品)と模本(鳥獣戯画を真似て作られた作品)が存在します.
それらを用いることによって,オリジナルの鳥獣戯画の劣化した箇所や,失われた箇所の構図を推測することが可能になっています.

時代を隔てて作成された全4巻の鳥獣戯画は,作品の成功な技術や奥深さを学べるだけでなく,作者の動物や人間に対する感性,そして受け継がれていく医師についても感じとることができる内容となっています.

感想

個人的によかった2点ついて列挙していきます

鳥獣戯画の全4巻を揃えている

鳥獣戯画は京都,東京,アメリカなどから取り揃えられています. 断簡と模本なども揃えていることから,再現できる全体図は,なかなか見ることができない展示だと思いました. 鳥獣戯画が展示してあるだけでなく,それらに関する情報も詳細に書かれています.
作者が時代ごとに異なるため,絵のタッチの違い,動物の描写の仕方の違いなども楽しむことができます.
また,複数人の人が模写や続編を描こうとしたことから,鳥獣戯画は多くの人を魅了したことがわかります.

兎と猫がモフモフに描かれている

水墨画で描かれており,現在とは違うタッチで描かれている作品です.
しかし,兎と猫に対する感性は変わらないらしく,毛並みをモフモフに描かれていることが印象的でした.
カエルが二足歩行なのに写実的にかかれていることも,現在の感性とは違う観点から描かれていて興味深いです.
また,動物でも猪や鹿は家畜のように描かれていることから,作者の基準についても考えさせられる作品となっています.

まとめ

特別展 国宝 鳥獣戯画のすべては,鳥獣戯画を展示だけでなく,それらに付随する情報も知ることができます.
平安時代に作られた作品ですが,現在観賞しても新しさを感じることができます.
今年は東京開催のみかもしれませんが,数年おきに開催されているらしいので,機会があれば是非おすすめです.