ニワトリのたまご

【読書】エンジニアリングが好きな私たちのための エンジニアリングマネジャー入門

これからマネージャーを目指す、目指さないといけない立場のリーダクラスや、今マネジャーとして苦労している人のためのマネジャーの入門書。タイトルにある通り、本書は「マネジメント」の本ではなく「マネジャー」のための本である。そのため、人をマネジメントするための手法ではなく、マネジャーとしてどう振る舞うべきか、自分とチームにどう向かうべきかということが書かれている。

本書を通して感じたのは、この本は優しさでできているということ。まさに今マネジャーやそれに近い業務をして苦しんでいる人に向けて書かれたものである。仕事をどうコントロールするかではなく、チームや部下に対してどういう振る舞いをすると良い結果が得られるかや人として相手が成長できるか、そして他人だけではなく自分の価値観や自分の好きなことを知りそこに基づいて仕事をすること、といった人にフォーカスしたノウハウが詰まっている。マネジャーの業務としての1on1の重要性や進め方について書かれた本は、なかなかないのではないか?個人の仕事としても、自分の価値観の棚卸しや、週間プランナーの話はすぐにでも試してみたくなるような話もたくさんあった。

最初に読んだときは「優しさ」を感じる反面「刺激」が少ないように感じていたが、振り返ってまとめてみるとマネジャーやリーダとしての知見で自分に足りないことが多くあり、とても参考になる本であった。

Mac版のElectronでコピー&ペーストができない件を解決した

MacでElectronを使ったアプリを開発していますが、テキストボックス等でコピー&ペーストが効かないことがわかりました。 以下のサイトにあるように、Mac版のElectronアプリだとできないもんらしいです。 tech.kurojica.com

私の場合は以下のエラーが出て素直に実装できませんでした。

'selector' は型 'MenuItemConstructorOptions' に存在しません。

MenuItemConstructorOptionsにselectorというキーワードを足してやる必要があるようです。 以下のサイトではMenuItemConstructorOptionsを継承してselectorを追加しています。

qiita.com

この辺りを参考に私の環境では以下のようにすると無事Mac環境でもコピー&ペーストできました。

import { Menu, MenuItem } from "electron";
import { MenuItemConstructorOptions } from "electron/main";

const template: Array<MenuItemConstructorOptions | DarwinMenuItemConstructorOptions | MenuItem> = [];
interface DarwinMenuItemConstructorOptions extends MenuItemConstructorOptions {
  selector?: string;
  submenu?: DarwinMenuItemConstructorOptions[] | Menu;
}
template.push({
  label: "Edit",
  submenu: [
    { label: "Undo", accelerator: "CmdOrCtrl+Z", selector: "undo:" },
    { label: "Redo", accelerator: "Shift+CmdOrCtrl+Z", selector: "redo:" },
    { type: "separator" },
    { label: "Cut", accelerator: "CmdOrCtrl+X", selector: "cut:" },
    { label: "Copy", accelerator: "CmdOrCtrl+C", selector: "copy:" },
    { label: "Paste", accelerator: "CmdOrCtrl+V", selector: "paste:" },
    { label: "Select All", accelerator: "CmdOrCtrl+A", selector: "selectAll:" },
  ],
});
export const appMenu = Menu.buildFromTemplate(template);

Module XXX has no default export

scriptタグでsetup構文を設定しているモジュールを別ファイルからimportすると静的解析ツールからModule XXX has no default exportという警告が出ていた。 よく見るとVeturというツールによる警告らしい。 Vue3の公式ドキュメントを見るとVue3を使う場合はVeturは無効にすること、とある。

Vue - Official は Vue 2 用の以前の VS Code 拡張である Vetur を置き換えるものです。Vetur をインストールしている場合は、Vue 3 のプロジェクトでは無効にすることを忘れないでください。

ja.vuejs.org

VS Code拡張機能からVeturをアンインストールすると警告が出なくなった。 というか「no default export setup」でググると最初に出てくるstackoverflowにも書いてあった。えらい遠回りした。

stackoverflow.com

【読書】人工衛星・惑星探査機のための宇宙工学

軌道力学を学びたい人におすすめの教科書。ケプラーの法則、軌道6要素、ロケット方程式、各種軌道の説明、ランベルト問題、制限三体問題などが取り上げられている。 以下に示すように全体的にとても丁寧な説明になっておりわかりやすかった。

  • 行間が少なく非常に丁寧に書かれており、納得して読み進めることができる
  • 惑星方程式の導出など煩雑なところは思い切って省略されており、それぞれの式をどういうケースでどう使うかに主眼が置かれている
  • 例題・章末問題についても途中の計算や計算結果を省略することなく記載されており、内容の理解に大いに役立つ

例えば、この本を読み、例題を解くことで以下のようなことができるようになります。

  • グランドトレースからの軌道推定
  • ロケット方程式を用いた推進薬質量の推定
  • ΔVEGAを用いた木星到達軌道の計算
  • ケプラー方程式を数値計算して楕円軌道を計算

軌道力学を学びたい初学者に非常におすすめの一冊。

VSCodeのJest Runnerでnpmが見つからない

VSCode拡張機能Jest Runnerでdebug実行したところ「npm not found」となって実行できませんでした。

調べてみたところどうもJestは.zshrcなどの設定を読まないらしいです。

以下のページに対処法が詳しく書かれているので設定したところ解消できました。

 

zenn.dev

【書評】日本の宇宙開発最前線

スペースXはなぜあれだけ急成長できたのか、その裏で日本は何をしていたのか、これからの日本の発展の鍵になるのは何か、詳細に記されている。特にスペースXについては1章まるまるを割いており、同社が「狂気」と「合理性」によって急成長してきたことがよくわかる。一方で、日本の宇宙計画の中でも大規模な「みちびき」と「情報収集衛星」についてその成立と現在についても解説されている。情報収集衛星については、春原 剛著「誕生国産スパイ衛星」にも詳しいが、「みちびき」について筆者の推測もありながらもここまで日本の闇を詳細に記したものはないのではないだろうか。本書では、宇宙戦略基金についても触れられており、日本の宇宙開発史と最新の情報に触れたい方には非常におすすめである。

以下、気になった箇所

  • 通常、失敗が容易にできないロケット開発では一度出来上がった部分は変えないように開発するが、スペースXは「失敗」を許容しタブーとされている「改良」を高速で繰り返すことで技術成長している
  • スペースXの現在までの開発は「火星に人類を移民する」というイーロンマスクの狂気が源泉であり、全ての事業はその布石でしかない。そのための判断を合理的にし続けている。
  • スターリンクは自社で作ったロケットの需要を満たすために生み出した事業であり、自社のロケットに最適化した衛星を作ることで大幅にコストダウンするという垂直統合開発の強みを最大限に活かしている。
  • 測位衛星を配備する場合、世界システムとするか地域システムとするかで配備する軌道と機数が異なる。地域システムであるNavICなどは静止衛星と対地同期衛星の組み合わせで常に3機以上の衛星が見えるように配備する。しかし準天頂軌道は基本的には日本だけをカバーし、オセアニア等も見ることもできる程度。測位衛星は衛星も大型で非常にコストがかかるにも関わらず、地域衛星を組むのに最適ではない軌道で配備されている。これは経産省が日本の宇宙政策で存在感を出すための省庁間の争いの道具にされた結果生まれたシステムだから。
  • 情報収集衛星は目的に「外交・防衛等の安全保障及び大規模災害等への対応等」と記されているにも関わらず災害対策はおざなりである。2024年1月1日能登半島地震の衛星撮像データが公開されたのは1月11日であった。大規模災害では衛星データを役立てるにはどんなに遅くても24時間以内に公開する必要がある。自分もこれはいつ公開するんだろうと思っていたが、いつまで経っても公開されないので呆れた記憶がある。技術開発においてあまり税金がとは言いたくないが、開発の目的にあった運用を行っているかどうかは国民として厳しくチェックしないといけないと感じた。

開発生産性カンファレンス2024の参加レポート

先月末に実施された開発生産性カンファレンス2024に参加しました。とても勉強になったので自分の備忘録のためにも参加レポートを書きます。

1. カンファレンス概要

カンファレンス名:開発生産性カンファレンス2024

開催日時:2024年6月28日-2024年6月29日

場所:虎ノ門ヒルズフォーラム

URL:

dev-productivity-con.findy-code.io

2. どんなカンファレンス?

カンファレンスのページを抜粋しつつまとめると、国内外の企業の開発生産性に関するベストプラクティスや開発生産性向上への取り組みを共有し日本のエンジニアリングの向上につながることを目標とする、というようなカンファレンスです。

虎ノ門ヒルズフォーラムの4Fと5Fを使って4会場分のセッションが2日間続くなかなか盛りだくさんのカンファレンスでした。

3. 全体を通した所感

参加前は「開発生産性のカンファレンス」ということでforkeysなどの色んな指標や、それをどう集計するかのような技術的な話、つまり開発の内向きの話が多いのかと思っていました。

実際には、どちらかというと開発生産性を向上すると会社にとって何が嬉しいのか、何を目標に開発生産性向上の取り組みをすると良いのかといった、開発生産性向上の施策を事業部や会社視点で見たときに良い方法があるかというような話が多かったように思います。

それでいて、開発生産性がよくなるような開発の仕方(アーキテクチャ設計、自動テスト)の話もあり多様な話が聞けて非常に勉強になりました。

4. セッション各論

資料URLが見つけられなかったセッションは内容のメモを概要欄に記載しています。

E2Eテストを自動化したら開発生産性はどうなった?hacomonoの事例紹介

スピーカー: mabl株式会社 おだしょー、株式会社hacomono 森島 諒

資料URL:

speakerdeck.com

印象に残ったこと:

  • 自動テストが楽になっても開発のフィードバックが遅ければ開発自体の生産性は良くならない、てのは開発生産性向上の施策をよく設計しないといけないポイントだと思う

学んだこと:

  • E2Eテスト自動化でつまづきやすいポイントとそれをどう乗り越えたかという事例は参考になった
  • 流行の生成AIを使ったテスト自動化ツールの情報が知れた(めっちゃ便利そう)
    • mablとは、生成AIを使った自動UIツール

実践チームトポロジー:プラットフォーム性とイネーブリング性の戦略

スピーカー: 株式会社タイミー 赤澤 剛

資料URL: speakerdeck.com

印象に残ったこと:

  • イネイブリングチームとして「Dev Enable」という学習文化の推進をするチームを置いているのが印象的だった
    • 学習文化の推進とエンジニアがエンジニアリングに集中するための環境や制度の提供が目的
    • 学習の基盤があっていいなーという受け身の感覚というより、エンジニアを成長させるということを目的におい専門チームを置くというアプローチが他にはないなと思う

学んだこと:

  • ストリームアライアンドと最強の仲間たちという表現は、どこに軸を置いてチーム構成するべきなのかとてもしっくりきた
    • プラットフォームチームやイネイブリングチームはSAチームを強化するための最強のチームとなるべき
    • SAチームの課題感や将来どうなっていきたいかが、これらのチームの活動のトリガーになる
    • そのため、SAチームは自分たちに必要な能力は何で、何が不足しているのか自己診断を継続的に実施する必要がある

技術的負債の解消のための設計アプローチ hacomono編

スピーカー: 株式会社hacomono みゅーとん、野崎 才門

資料URL: なし

概要:

前半が技術的負債解消のためのリファクタリング、後半がAtomic Designの話

  • リファクタリング
    • まずテストコードがなかったのでとにかくテスト書く
    • 責務でロジックを割ってロジックの純度を上げたい->chain of responsibilityを適用して責務ごとに分割
    • 同じような処理があるが利用場面によって使う変数と使わない処変数がある->builderパターンで必須変数と任意変数を表現
  • Atomic Design
    • よく失敗するパターン=organisms配下のファイルが大量、organismsかmoleculesか判断に迷い時間がかかる
    • 原文に立ち返るとAtomic Designは最近のフロントエンド向けに考案されたモノではなくデザインについての問題提起である
    • 無理にフォルダ構成やコンポーネントを厳格に分けるのではなく、コンポーネントを階層化するとい考え方を取り込む程度にすると良さそう

印象に残ったこと:

  • テストコードを書くことで安心してリファクタリングできるというのと開発者のメンタルモデルの構築に繋がった
    • 開発の導入とか教育としてテストコードを書いてもらうってのはありかもしれない
  • Atomic Designはもともとデザイン向けの考え方なので無理にフロントエンド開発に当てはめるとうまくいかない

学んだこと:

  • Atomic Design適用の事例は普通に適用すると難しそうだなと思うところがうまく解消されていて参考になった

組織横断支援チームによるFour Keys計測基盤の構築と活用に向けた取り組み

スピーカー: サイボウズ株式会社 三村 遼

資料URL:

www.docswell.com

印象に残ったこと:

  • 指標があるから分析ができるというのは改善活動を回す第一歩で重要である
  • 組織横断支援チームとして開発チームの負担にならないようにの配慮が行き届いている

学んだこと:

  • 他チームを支援する施策を進める側としてのL&Lが参考になった
    • 各チームが使っているツールを無理に統制せず、指標集計用のWebAPIを提供して使ってもらう
    • Forkeysのお試しは全員強制ではなく挙手制にする
    • 施策を試す際は最も前向きなチームから始めること

Metrics-informed development; theory and practice

スピーカー: Gradle, Laurent Ploix

資料URL: なし

概要:

  • 開発生産性の指標に対するMental Frameworks
    • 開発生産性の指標のdependency graph : effort(実装) -> output(コード) -> outcome(開発の満足度) -> impact(利益)
    • 指標から示唆を導く際の階層構造 : Data -> information -> knwoledge (Dataが下層、knowledgeが上位層)
  • 指標のユースケースとL&L
    • 指標を調査するときにdependency graphの先行指標があるか確認する、現場に近い指標ほど計測しやすい
    • DORAメトリクスが使いにくいと思ったら、先行指標として現場に即したlocalなDORAを計測しても良い(運用環境ではなく開発環境の状態に置き換えるとか)
  • リスクと有効性に対する危うさ
    • メトリクスには必ずバグがあると念頭におくこと、イテレーションして改善すること
    • 指標はあくまでinformしてくれるだけ、仮説を持って指標を使うこと

印象に残ったこと:

  • 指標及びその源泉となるデータにはバグがあると念頭におく、指標を絶対視しないこと、これはスピーチの中でも何回か登場したキーワードであり重要な考えだと思う

学んだこと:

  • dependency graphに沿った先行指標の考え方として「技術的負債の可視化」が例に上がっていて参考になった
    • 技術的負債自体を集計するのは難しい、なので先行指標を見出すようにする
      • 技術的負債があると思われるソース、コンポーネントを決める(これは主観的な評価で良い)
      • 関連する指標を集計する(最終コミット時間、コード数...)
      • 技術的負債のあるソース/ないソースとの相関等をとって分析し、どの指標が技術的負債に通じるかを決定する

「開発生産性を上げる改善」って儲かるの?に答えられるようにする

スピーカー: DMM.com 石垣 雅人

資料URL:

speakerdeck.com

印象に残ったこと:

  • スピーカーがDMMの部長さんで、事業責任者の立ち位置からソフトウェア開発をどう見ているのか説明してくださり、普段のエンジニア目線とは違い印象的だった

学んだこと:

  • 開発生産性を語るには、事業責任者が何に関心があり、何を重視しているかを知ること、またソフトウェア開発に関する仕組みを理解する必要がある
    • 事業責任者は究極には「狙ったタイミングでモノが出てくるのかどうか」が知りたいので、管理上の指標は本来は必要ない
    • 信頼がないと(細かく)管理したくなる、信頼を得ることが重要、信頼を得る糸口として開発生産性のデータを使う
    • 利益を上げる見込みが高いモノは「資産」になる、そうでなければ「費用」として計上、「利益率の高い」製品を「たくさん」作る必要がある

アーキテクチャレベルで考える開発生産性

スピーカー: DMM.com ミノ駆動

資料URL:

speakerdeck.com

印象に残ったこと:

  • 「自社サービスの競争優位性はなんですか」と聞かれてパッと答えられなかった、重要なポイントを意識できていない証拠
  • 良い設計するという点においても重要な機能に時間をかけるべきというのは印象深かった(良い基盤的なアーキテクチャ、仕組みをどう作るかを意識していたので...)

学んだこと:

  • ドメイン駆動設計は「レイヤードアーキテクチャ」など「戦術的設計」が取り上げられがちだが、「コアドメイン」や「隔離されたコア」など「戦略的設計」も非常に重要
  • 漫然と良い設計を目指すのではなく自社サービスの競争優位性を分析し、競争優位性の高い機能に開発リソースを集中する
    • 競争優位性、つまり他社にない、そのサービスに求められている機能を識別する指標として、「頻繁に仕様変更される機能」を整理するのも一つ
    • コアドメインに優秀な人材(やこれからを担う人材)を配置、サブドメインは外部に委託したりサードパーティのサービスを使うことを検討する

開発生産性の観点から考える自動テスト

スピーカー: タワーズ・クエスト社 和田 卓人

資料URL:

speakerdeck.com

印象に残ったこと:

  • 開発生産性の観点から、自動テストの目的は「工数削減」と考えがちだが保守コスト等を考えるとこれはアンチパターン、「ソフトウェアの成長を持続可能にする」という中長期的なところを目的にするべき
  • 「テストでは品質は上がらない。テストは気づき。品質を上げるのはコーディング」は本当にその通り。テストからのフィードバックを早くして、テストしやすいコード=変更しやすいコードを目指したい

学んだこと:

  • 単体・結合という考えはいつもスコープに悩むのでTest Sizeという考えは線引きがはっきりしてていいと思った
    • 小テスト: 1プロセスの中で完結する(ファイルアクセスNG、データベースNG)
    • 中テスト: 1マシンの中で完結する(外部サービスアクセスNG、他サーバNG)
    • 大テスト: 任意の場所で実行可能