mongolyyのブログ

開発(Javascript, Typescript, React, Next.js)や開発手法(スクラム, アジャイル)、勉強したことについて色々書ければと。

TypeScriptにおいて、とある型の一部のプロパティのみを必須にする型エイリアスを定義する

何がしたいか?

TypeScriptにおいて、とある型の一部のプロパティのみを必須にした型を作りたいとします。
次の例で言うと、とある型(User)を元に、一部のプロパティ(age)を必須にした新たな型(AdultUser)を作りたいとします。

type User = {
  name: string
  mail: string
  age?: number
  phone?: string
}

// 成人のユーザーの年齢プロパティは必須
type AdultUser = {
  name: string
  mail: string
  age: number
  phone?: string
}

// ageがundefinedになっていることを防ぎたい
const adult: AdultUser = {
  name: 'テスト太郎',
  mail: 'test@example.com'
}
// 次のエラーが発生する
// Property 'age' is missing in type '{ name: string; mail: string; }' but required in type 'AdultUser'.

上記の例の場合はプロパティの数が少なかったので良かったですが、実際はもっと項目が多かったり、Userのプロパティが頻繁に変更されるとミスが出てくると思います。
今回はそのために簡単な型エイリアスを作りましたので、紹介したいと思います。

どんな型エイリアス

type SomeRequired<T, K extends keyof T> = Omit<T, K> & Required<Pick<T, K>>

Utility Typesを使いました。
Utility Typesについては公式のドキュメントを読んでください。 www.typescriptlang.org

新たに定義したSomeRequiredを使うと、次のようにAdultUser型を定義することができます。

type AdultUser = SomeRequired<User, 'age'>

const adult: AdultUser = {
  name: 'テスト太郎',
  mail: 'test@example.com'
}
// 次のエラーが発生する
// Type '{ name: string; mail: string; }' is not assignable to type 'AdultUser'.
//   Property 'age' is missing in type '{ name: string; mail: string; }' but required in type 'Required<Pick<User, "age">>'.

また、OmitPick と同様に、| を使うことで複数の項目を必須にすることができます。

type NewAdultUser = SomeRequired<User, 'age' | 'phone'>

const newAdult: NewAdultUser = {
  name: 'テスト太郎',
  mail: 'test@example.com',
}
// Type '{ name: string; mail: string; }' is not assignable to type 'NewAdultUser'.
//   Type '{ name: string; mail: string; }' is missing the following properties from type 'Required<Pick<User, "age" | "phone">>': age, phone

終わりに

Utility typesを知っている方なら簡単にわかる型エイリアスだと思いますが、知らなかった方は是非使ってみてください!

「レガシーコードからの脱却」を読んだ

はじめに

こんにちは。メーカーのコーポレート部門でソフトウェアエンジニアとして働いているモンゴルです。
最近David Bernsteinさんの研修を受ける機会があり、これをきっかけに、積んでいた「レガシーコードからの脱却」を読みました。
本の感想を残しておこうと思います。

感想

守破離について

本書では「守破離」が紹介されており、とりあえず何も考えずに師匠に言われるがままにやって(=守)、その後、その背景にある理論を理解し、実践する(=破)というステップがアジャイルにはあると書かれていました。

確かに、実体験として、理論はわからずに上司や先輩から教えてもらって、数年がむしゃらにやって、その上で「クリーンアーキテクチャ」や「ドメイン駆動設計」を読んでしっくり来たという経験がありました。
人にもよるとは思いますが、腹落ちさせるためにも、とりあえず言われるがままにやってみるというのは重要かと思いました。

一方、私見ですが、自分自身含めて周りを見ていると、「守」に慣れて、同じプロセスを改善する方に行ってしまい、破の領域に行かなかったり、違う方に行ってしまうことがあるなーとも思っています。
面倒かもしれないですが、自分自身、周囲を鼓舞、刺激し、破(≒理論の理解)の領域に達せられるようにしたいなと感じました。

第一原理について

第一原理や原則について深く書かれているなとも感じました。
今まで読んだ本ではあまり言及されていなかったようにも思います。
私は本書を通して、「第一原理が存在し、その上に原則が存在し、その原理、原則を背景として、XPやスクラムのプラクティスが存在する」というように理解しました。
スクラムをやっていると、プラクティスに目が行ってしまう人を見かけることがありますが、スクラムマスターとして、そのプラクティスの背景を理解し、そういう人に説明していくべきだなーと、感じました。

全ては会話から

ラクティス1の「やり方より先に目的、理由、誰のためかを伝える」、プラクティス4の「協力しあう」を読んで、コミュニケーションの重要性を再認識しました。
スクラムやXPでも色々なプラクティスがありますが、共通して「コミュニケーションを取る」ということを背景に作られているものも多そうだと感じました。
更に、コミュニケーションにより、共通認識を育てたいというのが大きな目標としてあるようにも感じています。
共通認識があると、モチベーションが上がるだけでなく、業務とプロダクトの乖離が少なくなるので、より変更容易性の高い、高品質なプロダクトができるとも思うようになりました。

テスト駆動開発について

テスト駆動開発を行うことで、良いプロセス、設計をもたらし、結果として高い品質のプロダクトが作られるというように理解しました。
今までは、"良いプロセス、設計"の意識がまったくなかったのですが、ふるまいを考えて、テストしやすさを考えて作っていくことによって、良い設計になりそうだなと、本書を読んで感じました。
また、「小さく作る。リファクタリングをする。」という健全なプロセスが自然と入ることにもなるので、そういう観点でも高品質なプロダクトが生み出せそうだと感じました。

終わりに

レガシーコードをリファクタリングして良くするというお話かと思いきや、普通にチームビルディング、ソフトウェア開発に生きそうなプラクティスとその背景が丁寧に書かれており、非常に良かったです。
他にも、良いコードの特徴(「CLEAN」コード)なども紹介されており、エンジニアとして参考になる部分もありました。
各章が比較的独立しているので、興味のある章だけをチームで輪読するのも良さそうだと感じました。

ドメイン駆動設計における「エンティティ」と「値オブジェクト」の違いについて

はじめに

同僚と「ドメインオブジェクトが~~」みたいな話をしていて、「ドメイン駆動におけるドメインオブジェクトの扱いってなんだったっけ?」と思ったことをきっかけに、調べたり、考えたりしました。
また忘れるので書き留めておこうと思います。

本題

ざっくりですが、次のような違いがあると思っています。

  • エンティティ
    • 同一性の概念がある
  • 値オブジェクト
    • 同一性の概念がない

それによって、次のような特徴が生まれてきます

  • エンティティ
    • 同一性を判別するためのキーが存在する
    • キー以外の項目は変更される可能性がある
  • 値オブジェクト
    • 全てのフィールドが同一であれば、振る舞いは同一になるので同一とみなせる
    • 逆にどれかのフィールドが変更されると同一とは見なせないので、不変であるべき
    • String, Intのようなプリミティブな型の代替として、表現力を増すために使われることが多そう

ここからは私見です。
書籍でエンティティも可変となっていますが、"不変であっても良く、むしろそのほうが、バグは発生しにくいのではないか" とも思っています。

参考書籍

終わりに

よく忘れてしまうので、書き留めておきました。
他の特徴があればまた追記しようと思います。

2ヶ月でUMTP L1~L3 を取得したので、その合格体験記

はじめに

メーカーのコーポレート部門でソフトウェアエンジニアとして働いているモンゴルです。
11月中旬頃から勉強を初めて、1月中旬に無事UMTP L1~L3まで取得することができたので、その記録を残しておこうと思います。
UMTPに興味を持たれている方のお役に立てれば幸いです。

どんな資格?

UMTP/JAPAN 特定非営利活動法人UMLモデリング推進協議会」が主催している、UMLの理解、モデリング能力が問われる試験になっています。
求められるレベルは、それぞれのレベルで異なっており、公式サイトの説明では次のようになっています。

UMTP L1:UMLなどを使ってモデリングを行う最低限の知識を持っている。
UMTP L2:UMLモデルの読み書きが普通にできる。 開発範囲の一部を担当し、モデリングができ、他者のモデルの意味を理解できる。
UMTP L3:実務でモデリングが実施できる ・拡張性や変更容易性などの点で高品質なモデルを定義できる。 ・特定分野の専門的な知識を備えている

試験概要 より抜粋

なぜ取ろうと思ったか?

  • Clean Architecture本を始め、設計の書籍では共通言語としてUMLが当たり前に出てくる。しかし、自分のUMLの理解が不十分であることにより、書籍の理解が中途半端になっていそうと感じたから
  • チームで設計について議論するときに、標準を知っておくことで、より効率的にモデリングの議論ができるようになりそうだと思ったから
  • 最近、「現場から学ぶモデル駆動設計」勉強会が頻繁に開催されており、自分の中でモデリング熱が上がってきたから

勉強法

UMTP L1試験

参考書を解きました。
今回購入した本以外は絶版になっていそうであったので、消去法で選択しました。

選択理由はポジティブではありませんでしたが、内容は非常に丁寧で、UML自体の理解が不足していた自分にとっては丁度いい本でした。

勉強期間:一ヶ月(11月中旬~12月中旬)
参考書:次の書籍を購入


受験した感想:
思った以上に簡単、かつ、短時間で解けました(時間は半分も使っていなかったように思います)
点数は96%でした。(80%で合格)

UMTP L2試験

こちらも参考書を解きました。
UML自体はUMTP L1の学習のときに把握できており、モデリング自体は自分は好きなのでサクサク進められました。

勉強期間:二週間(12月中旬~12月末)
参考書:次の書籍のオンデマンド(ペーパーブック)版を購入


受験した感想:
当然L1より難しさは増したものの、短時間で解けました(時間は三分の一~半分くらいは残っていたと思います)
点数は86%でした。(65%で合格)

UMTP L3試験

参考書がないので、いい勉強方法はわからなかったです。
やったことは、公式のサンプル問題とUML関係の書籍を読むくらいです。

勉強期間:二週間(1月上旬~1月中旬)
参考サイト:
umtp-japan.org
読んだUML関係の書籍:


読んだ感想は mongolyy.hatenablog.com
その他過去読んだもので参考になった書籍:

クラス設計の指針を把握する上で参考になりました。
受験した感想:
L2よりも難易度はかなり上がっていました。
ITSSによると、レベル3(=応用情報と同じ)とのことでしたが、問題のレベル的には、レベル4のデータベーススペシャリストにも近いように感じました。
時間もギリギリで、7分くらいしか残っていなかったと思います。
点数は82%でした。(60%で合格)
問題数が少ないので、部分点がもらえない採点方式だとすると、一問落とすとだいぶ点数が削られそうな気がしています。(採点方式をご存知の方、教えていただけると幸いです)

取得した後の変化

取得してから二週間程しか経過していませんが、よかったことは次の二点です。

  • 設計の書籍を読むときに、一々調べることが減った
  • モデリングとは?設計書とは」を見直すきっかけになり、自分の考えを明確にすることができるようになった
    • どう思うようになったか?について、詳しくは、 mongolyy.hatenablog.com の記事をご覧ください

最後に

UMTPを取得している人って、あまり見たことなかったですが、UMLを知っている、モデリングできるというのは開発手法によらず大事なことだと思っています。
それに目覚めるためにも、是非UMTP試験にチャレンジしてみてください!

「エンジニアのためのマネジメントキャリアパス」を読んだ。そしたら、キャリアについて少しスッキリした

はじめに

メーカーでコーポレート部門でソフトウェアエンジニアをやっているモンゴルです。
最近、自分のキャリアであったり、自分の周囲の体制について考えることがあり、なにか参考にしたいと思い、次の本を読みました。

感想

特に印象に残った2つのことを示したいと思います。

職位と職責を分けるべきということ

筆者が「テックリードは職位ではなく、職責として扱われている、言い換えると、テックリードだから偉いとかはなく、シニアレベルのスキルを持ちつつピープルマネジメントできる人が担当し、定期的に交代している」という旨の記述があったのが興味深かったです。
過去、「このポジションが空いているから、能力に不安があるが担当する」「能力はあるけど、ポジションが空いていないから上に上がれない」みたいな事象を見ていて"もやっ"たことがあったので、こういう考え方は非常にいいな~と思い、自分がチームを作るときも取り入れたいなと思いました。

本書で書かれている、テックリードが担っている役割も PM + スクラムマスター + エンジニアリングマネージャー のようなものであり、たしかに人間力と開発力がある開発者であれば務まるし、そうなると、PMやスクラムマスター、エンジニアリングマネージャーというロールは不要で、テックリードがいるだけでいいのではないかなー?と、思いました。 また、テックリードというのも名前はどうでも良くて、マネージャーやステークホルダーが望む形に合わせてチームメンバーが分担してその役割を担っていくという形もありなのではないか?と、思いました。

最近は「テックリードを目指すのか?」「エンジニアリングマネージャーを目指すのか?」ということで悩んでいたのですが、どちらも求められる要素は同じ(各要素のレベルは違うかもだが)なので、現段階では道は絞らず、愚直に技術力を高め、仕事を通してピープルマネジメントも成長させていく、そうやってエンジニア、社会人としての価値を高めていくのが結果的に自分がやりたいことを実現するための近道になりそうとも思うようになりました。

また、先日、 RSGT2022で牛尾さんの話 のなかでは、"優秀なマネージャーとエンジニアだけがいる"というシンプルな構造になっていそうだったので、そこの話を受けても、「エンジニアとしての腕を磨き、ピープルマネジメント力もつけていき、マネージャーを目指す」というのが今の自分の理想だなーと思うようになりました。

1on1の進め方

スクラムマスターとして1on1をすることがよくあるのですが、自分の勘を頼りに、相手や目的に合わせて方式を変えていました。
本書では以下の型が紹介されており、あまり固定せず、もうちょっといろいろ試してみてもいいかもと思いました。

  • TODOリスト型
  • キャッチアップ型
  • フィードバック型
  • 経過報告型

ただ、どういう方法をやるにしても「相手を理解する」という気持ちは忘れずに取り組みたいと思いました。

終わりに

マネージャーとしても、マネジメントされる人としても、転職しようとする人としても、体制を作っていく人も、色んな立場の人の役に立ちそうな情報満載でした。
ただ、まえがきでも書かれていますが、アメリカでの話がメインになっているので、現在の日本と思想が異なるところもほんの一部ありますが、そういった章もむしろ考え方は参考になると感じました。

また、以下のようなことも思いました。

また、時が経ったら立場も変わると思うので、そのときに読み返してみようと思います。

「UMLモデリングのエッセンス 第3版」を読んだ

はじめに

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)エリック・エヴァンスのドメイン駆動設計を読んでいて、UMLが当たり前のように出てくるので、この機会にちゃんと学んでおこうと思い、下の本を読んでみました。

自分は最初の全体の話とクラス図、シーケンス図の章を読みました。
クラス図とシーケンス図を読んだのは他の書籍でもよく出てくるからです。
簡単に感想を書いておこうと思います。

感想

本書を読んで、正確性、網羅性よりも手早く、(UMLの規約的に正しくなくてもいいので)意図が伝わり、UMLを通じてドメインのコミュニケーションをすることが重要だと理解しました。
この点について、DDD本と似たことが書かれていることから、昔から思想はあまり変わっていない(もしくはUMLが自分が思った以上に最近のツールである)と感じ、驚きました。

また、以下のような詳細な気づきも得ました。


UMLと一言で言っても3種類のモードがあるということがわかりました。今後人と話すときは使い分けていきたいです。

また、2つの観点が存在するとも書いてありました。

個人的には概念的観点というのは初めて知りました。
最近読んだDDD本で、「UMLドメインエキスパートと共有しながらドメインの会話をする」の旨の記述があって、「無理じゃね?」と思っていたのですが、本書により「概念的観点でのUMLを共有するということだったのかな?」ということで納得できました。

終わりに

UMLの記載方法はなんとなくわかっている人が、より理解を深めるための本でした。
マーチン・ファウラーさんの主観で、モデリングをする意味、ドキュメントを作る意味などが書かれており、大変勉強になりました。
また、UML自体はアジャイル開発と相性の良いツールとして作られたんだなーと理解し、今後私のチームでも積極的に使っていきたいなーと思いました。

私のスキルマップ作成の進め方

はじめに

mongolyy.hatenablog.com に続き、スキルマップ作成の進め方についてここに整理してまとめておこうと思います。

進行役としてやること

  • 事前準備
    • スプレッドシート、miro、notion等で表を作っておく
    • 説明資料をwiki等に書いておき、参加メンバーに事前準備の依頼をする
  • 当日やること
    • 楽しんで進行する

以下説明資料

チームビルディングの目的は 過去記事 と同様なので省略します。

スキルマップの目的

個人的には次のことに尽きると思っています。

これらの目的が達成されることにより、

  • あうんの呼吸でサポートしあえる
  • チームの弱い部分をカバーするような立ち回りが、チーム全体で自然とできるようになる
  • 自分で宣言すること、周囲とのベクトル合わせにより自己学習に対するモチベーションアップ

といった効果が期待でき、チーム活動がよりスムーズになります。

スキルマップ作成のアンチパターン

  • 人事評価とからめる
    • 過大申告すると、スキルマップの目的が失われるので
    • 目標管理とスキルマップの「今後習得したいスキル」が同じになる場合もあるかもしれませんが、過大申告につながると良くないので分けて考えるようにしましょう
    • この場も、人事評価とは関係ないので、ありのままのスキルを書くようにしましょう
  • スキルマップの項目を固定にする
    • チームの成長、プロジェクト/プロダクトの状況により必要なスキルも変化します
    • 定期的に見直しましょう
      • 最初の頃は1ヶ月周期、プロジェクト/プロダクトが落ち着いてきたら半年で見直せばいいと思います

事前準備

スキルマップのたたき台を作成しておきますので、以下の凡例に従って入力をお願いします。

◎ :人に教えられる
○ :一人でできる
△ :サポートがあればできる
・ :今後習得したい
空欄:できない

また、追加したい項目、削除したい項目があればその列挙もお願いします。(実際に追加・削除の投票はワークショップ当日に行います)

当日の流れ

  • アイスブレイク (2分)
    • 今のお気持ちを書く時間 (1分)
    • 共有する時間 (1分)
  • 改めて説明 (3分)
  • 追加、削除したい項目の議論(10分)
    • 追加したい項目、削除したい項目の列挙(2分)
    • 追加したい項目、削除したい項目の理由の説明(5分)
    • 追加したい項目の投票、削除したい項目の投票(2分)
      • 追加する項目は最大m票、削除したい項目も最大n票というように制限をつける
    • 投票によって決まった、追加される項目と削除する項目を表に反映(1分)
  • スキルマップに自分のスキルの入力(3分)
  • スキルマップに書いた自分のスキルの説明 (1分/人)
    • 特に、こういうサポートができるとか、今後、こういうことをできるようにしたいとか
  • クロージング (30秒/人)
    • 一人一言感想を言う。気づいたことでも、今後の抱負でも。

参考資料


終わりに

私は、こういう風に進行しているよ!など、意見ありましたらコメントで反応していただけると嬉しいです。