お願いドリブンからの脱却
CI/CDに取り組むソフトウェア開発者に求められる「勇気」とは？
https://codezine.jp/article/detail/13692
ソースコードを修正したら、速やかにビルド、テスト、リリースへと進められればよいが、そこが自動化されておらず人依存になっていると、次に進むために「お願い」が必要な状況に陥りやすい。
CIが整備されてない場合もそうであるが、CIが不安定な場合にもお願いは発生する。
利益を産むビジネスロジックではなく、別の立ち回りにコストを割かれ『継続性』は損なわれていく。
CIにおいては、お願いドリブンの脱却が大事。
AWSコンテナサービスの変遷
AWSにおけるコンテナサービスの変化と今利用ユーザに求められることとは
https://qiita.com/yoshii0110/items/92a6abe212514f01a0ca
ECSからFargateやEKSでインフラとしての充実を図られた以降は、さらに包括的に楽に構築できる方向でサービス充実していっている。
基本的には包括的にできるようになればなるほど制約も増えていくのが悩ましいところではあるが、新規サービスを作っていく際には乗っけられるかを検討してみた方が良さそうである。
サーバレス界隈の傾き
熱量を失ったサーバーレスという世界（個人の所感）
https://www.keisuke69.net/entry/2022/12/29/135620
サーバレス
- AWS Lambdaに代表されるようなFaaS（Function as a Service） や
- Google CloudのCloud Run、AWS Fargateのようなコンテナの実行基盤といったコンピューティング環境を中心にフルマネージドで提供してくれるもの
- Firebase FirestoreやAmazon DynamoDBのようなデータベースなどの機能を独自の方式で提供してくれるもの
- 従来マネージドサービスとして提供されているものを拡張してインスタンス管理なども不要としたもの
- Firebase Authenticationのようにアプリケーション機能とその基盤を提供してくれるもの
記事にもある通り、サーバレスと一言で言っても連想されるものが多い。
個人的には身の回りではサーバレスは検討土台には上がるので、幻滅期というよりまだ普通に使おうとする意欲はあるように思う。
というより、まだそこまで試せていないので試行錯誤を続けている。
速度などの要件が厳しい既存システムに対してサーバレス化はできるかはわからないが、
非エンジニアがノーコードツールを作ることに慣れ、次第に簡易アプリに手を出すようになるとそこでより敷居を下げた拡がりが出てくる気はする。
AWSの知見調査方法
UIのトレンド
UIから「白」が消える日
https://note.com/ritar/n/n0f6aad6c2560
UIが脱色されていくのが流行っている話。
ダークモードの流行からデザイントークンが発展し、透明化が浸透していっている。
デザイントークンとは？
https://bagelee.com/design/basics-of-design-tokens/
デザイントークンとは、デザインシステムにおいて最小単位のスタイルを定義するもの ...
デザイントークンの中には最小単位のスタイルの情報が保存されます。 プロダクトの中でよく使われるデザインの要素をパッケージ化し、複数のプラットフォームに横断的に読み込んで使用します。 ...
デザイントークンは色、余白、行間、Elevation(高さ)、フォント、フォントサイズ、シャドウ、アニメーション時間など複数のコンポーネントやテキスト要素にまたいで使われる情報を保存します。 ...
デザイントークンは普通の変数よりも抽象度が高いもので、プラットフォームに依存しない情報です。抽象度の高いレイヤーで命名規則に則ってデザイントークンを設定することにより、プラットフォームやフレームワークをまたいだデザインの基礎となる部分の共有言語を作ることができます。
変更容易性のために共通化して規約にするもの。
Google four keysに学ぶパフォーマンス指標
エリート DevOps チームであることを Four Keys プロジェクトで確認する
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
パフォーマンス指標
- デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム - commit から本番環境稼働までの所要時間
- 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
- サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
Google re:Workによるマネジメント論
Google re:Work - マネージャー
https://rework.withgoogle.com/jp/subjects/managers
チームのビジョン
- コアバリュー
- チームの基盤となる信念。パーパスとミッションに繋がる
- パーパス
- チームの存在理由とチームが組織全体に与える影響
- ミッション
- 達成しようとしている目標
- ストラテジー
- ミッション達成のために将来にわたって展開する手段
- ゴール
- ストラテジーを短期的で達成可能な目標へと落とし込んだもの
権限を与える
- 自由にやらせつつも必要に応じて助言をする
- チームに対する信頼を明確に示す
チームの成果を周囲に伝える
意見を求める
- アイデアや知見を求める
- 肯定的なフィードバックを行う
コーチング
GROWコーチングモデル - goal 目標の明確化: 求めるものは何か - reality 現状の把握: 何が起こっているか - option 選択肢の検討: 何ができるか - will 意思の確認: 何をするか
1対１ - 「今日は何について話しましょうか？？」「最近どうですか？」 - 意見を求める:「これまでに私がしていないことで、何かできることはありますか？」「もっとうまく、あるいはもっと頻繁に行った方がいいことはありますか？」
優れたマネージャー要件を特定する
キャリア形成支援
- GROWコーチングモデル
- 仕事以外にも「シンプルな 1 つの目標」の設定
- 思いやりを育む
