mongolyyのブログ

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

「単体テストの考え方/使い方」を読んだ

はじめに

メーカーのコーポレート部門でテックリードをしているmongolyyです。

最近、単体テストの設計について考えることがあり、その参考として「単体テストの考え方/使い方」を読みました。
気づきを書いていこうと思います。

気づき

単体テストの良し悪しについて、判断する軸ができた

本書では次の観点が紹介されていました。

今までなんとなく良し悪しを判断していた単体テストのテストケースについて、最初の二つの観点により具体的にどう良いか、悪いか言えるようになりました。
業務でも早速この観点をもとに話せたので、役に立つ本だと感じました。

単体テストの手法について、整理できた

本書では次の手法が紹介されていました。

  • 出力値ベース・テスト
  • 状態ベース・テスト
  • コミュニケーション・ベース・テスト

今までは、「書いたことある、見たことあるパターンだなー」となんとなくでテストを書いていましたが、言われてみるとこの三つに集約できると思いました。
また、本書の中では出力値ベーステストが、リファクタリングへの耐性を維持する、保守しやすさを維持する観点でもっとものコストが低いと書かれていて、こういったテスト、インターフェースになるといいんだなーと改めて感じました。

リファクタリングが必要な兆候と改善のアプローチを知った

「コードの複雑さ/ドメインにおける重要性」「協力者オブジェクトの数」の二軸で考えるといいと書いてありました。
これに対して、協力者オブジェクトの数を少なくする、「ドメイン・モデル/アルゴリズム」を抽出するアプローチ、コードの複雑さ/ドメインにおける重要性を少なくする「コントローラ」を抽出するアプローチの2つ手法があることが書かれていました。

個人的には次のことについて、興味深いと感じました。

  • 二軸の改善を単体でするのもいいが、両方をすることで責務が明確になって認知負荷が減りそうであること
  • コードの複雑性だけでなく、ドメインにおける重要性も軸となっていること

おわりに

当たり前から一歩踏み込んだことについて、著者の意見が入っていたのがよかったです。
例えば次のようなものです。

  • 単体テストのテストメソッド名の話
  • AAAパターンの区切りとしての空行の話
  • ログ出力についてのテストの必要性の話

単体テストアンチパターンなど、レビューのコメントで使えそうだと感じるものも多く、「一通り単体テストわかってきた、もう一歩踏み込んで理解したいぜ」という方におすすめな一冊でした。

「エクストリームプログラミング」を読んだ

はじめに

メーカーのコーポレート部門でテックリードをしているmongolyyです。
今回は「エクストリームプログラミング」を読んだので感想を書いていきます。

きっかけとしては、「スクラムに拘らずにエクストリームプログラミングを基にチーム開発を進めるというやり方もあるのでは?」とアジャイルコーチからアドバイスがあり、原点となる本書を読んでみようと思ったからです。

読んでわかったこと

価値、プラクティス、原則の関係性が少しわかった

自分の理解ですが、次のように理解しました

  • 価値
    • チーム開発がうまくいくために大事にすることであり、チームが価値だと感じていること
      • チームがもたらす価値のことではなさそう
    • 普遍的であり、日常にも通じることが理想的
  • ラクティス
    • 価値を実践するために具体的に実践すること
    • ただし、ただ実践するだけでは価値を体現することは難しく、そのために原則を踏まえて価値と向き合う必要がある
  • 原則
    • ラクティスが価値につながるために必要な背景となる考え方、活動指針
    • 一つのプラクティスで複数の原則を踏まえて実践することで価値につなげることもできるし、複数のプラクティス、それぞれ原則を踏まえることで価値につなげることもできる

いかにして質の高い設計をやるか

本書を読んで、「質の高い設計」を目指すということに関して考えさせられました。

質の高い設計をするために、次のようなことが必要かなと感じました。

  • 環境を整える
    • 創造的な時間を持つ
    • 心の余裕を持つ
  • 知識をつける
    • 知識なしに創造はない
    • 今までの知識もそのまま受け入れるのではなく、改善しろがあったはずと考えて、批判的思考でより良い設計をする
  • フィードバックを得られるようにする
    • 一気に設計するのではなく、ぎりぎりで設計する
      • 一気に設計すると、そのプロダクト開発中の学習を活かす機会が生まれない
    • 本気で設計、実践する
      • 受け取ったフィードバックを学びレベルに昇華させるために、「本気」が重要
    • チームメンバーの学びを設計になるために、チームで一丸となる必要がある
      • コミュニケーションが大事

おわりに

エクストリームプログラミングを読んだのは実は2ヵ月ほど前で読み返しながら感想を書いていたのですが、読み返しても非常に勉強になることが多いなーと思いました。
本書でも、学ぶのと実践することには隔たりがあるという記述がありますし、たまに読み返して実践を広げていこうと思います。

「ソフトウェア設計のトレードオフと誤り」を読んだ

はじめに

メーカーのコーポレート部門でテックリードをしているモンゴルです。
設計の本が出たらついつい読んじゃう質なので、次の本を買って読んでみました。

わかったことを書いていこうと思います。

わかったこと

API、ライブラリ、ツール設計におけるトレードオフがちょっとわかった

API、ライブラリ、ツールにおいて、「内部で使っているライブラリの仕様をどこまで隠ぺい化するか?」という話が興味深かったです。
個人的にはあまり隠蔽しない派だったのですが、本書を読んで、共通して使われる社内向けAPI、ライブラリ、ツールを開発している場合は適切に隠蔽しないと、内部で使っているライブラリの変更の影響をもろに受け、メンテナンスコストが大きくなることが理解できました。

共通部分を作るチーム、それを使うチームは分かれることが多いですが、互いに歩み寄って全体としてどうあるべきかを考えないと、長期的に見て不満がたまる結果になりそうだと思いました。

日時の扱いの難しさを垣間見た

特に「UTCで保存すべきかどうか」の話は興味深かったです。
個人的にはUTCで保存すべきという考えでした。
しかし、本書の説明を読んで、「制度が変わってタイムゾーンが変更されたときに、日付をどう表示するかということを考えるとローカルタイムでもデータを保持したほうがいいんだなー」と理解できました。

また、一か月後の定義も閏年を考慮するとしっかりと考えるべきだなーと理解できました。
普段は日付を扱うためのライブラリを通して、例えば"一か月後"の設定などをしていますが、しっかり挙動を理解してやるべきだなーと思いました。

他にも、うるう秒、サマーゾーン、相対性理論を考慮した話は、実務にどこまで活きるかはわかりませんが、グローバルなシステム、日付の扱いにセンシティブなシステムの場合「こういうこともあるんやなー」と勉強になりました。

おわりに

パフォーマンスなどについて、実際に測定されている節がちらほらあったのが印象に残りました。
予測だけでなく、実測に基づいて考えるというのが大事だと再認識しました。

また、グローバルなシステム、大規模なシステムを経験してきたであろう筆者の、細かい考慮の話も勉強になりました。

「人を動かす」を読んだ

はじめに

メーカーのコーポレート部門でテックリードとして働いているモンゴルです。
テックリードというロールになったときにアジャイルコーチにおすすめの本を聞いたところ、「「人を動かす」がチームをリードするという視点で万能の本だから読んでみるといいで」と言われたので読んでみました。

印象に残ったことを綴っていきます。

印象に残ったこと

笑顔で接する

人に好かれる原則の一つになります。
笑顔であると、周囲の人間も明るくし、自身の精神状態も良いものになるということが書かれていたのですが、確かにそうだなと思いました。
厳しい状況、私が場に対して厳しい発言をするときにニコニコしている同僚がいるのですが、思い返すと自分は間違っていないんだなと認識できて励まされます。

人を説得する原則の一つとしても「穏やかに話す」として書かれていますが、口調も大事だと思っています。
笑顔であると勝手に引き出されるとも思いますが、ゆっくりと、明快に話すといいと思っています。

人の誤りは指摘しないが、自分の誤りを認める

人を説得する原則として「相手の意見に敬意を払い、誤りを指摘しない」「自分の誤りを直ちに快く認める」というのが紹介されていて面白いなと思いました。

相手の細かい誤りは触れず、自分が間違えた時はすぐに認める。
一見不公平にも見えますが、相手に対して敬意を払うとはこういうことなのかなと思いました。

人の美しい心情に呼びかける

美し心情とは、冷静に判断できる状態ということを表しているのですが、この状況を作ってそこに対して呼びかけるという考え方はいいなと思いました。

私は「私たちVS問題の構造」という言葉が好きなのですが、この言葉に通じるなと感じました。
また、本書を読んで、相手を信頼し、非難せずに冷静になってもらい、情報を整理して判断できる環境を整えるということが大事だと認識が整理できました。

おわりに

節毎の独立性が高いので、目次を読んで気になったところだけ読むというのもありだし、目次を読むだけでも学びがあるなと思いました。

文庫版でkindleだと700円台ということを考えると、相当お得だと感じました。(コスパで本は選ばないですが、安いのは助かる)

「抵抗勢力との向き合い方」を読んだ

はじめに

メーカーのコーポレート部門でテックリードとして働いてるモンゴルです。
JTCに所属していると、今までのやり方、考え方を踏襲したい人たちがおり、衝突することがあるので今まで悩んできました。
ちょうど良い本があったので読んでみました。わかったことと再認識したことを書いていこうと思います。

わかったこと

抵抗は生理現象であると考える

抵抗は悪いでもなく、駆逐する対象でもなく、向き合うものと捉えて対応していくことが大事と理解しました。
むしろ歓迎すべきものと捉えることができ、検討の甘さや抜け漏れが発見でき、企画の質を上げる機会になるということも書かれており、確かにポジティブに捉えると良さそうだと思いました。

自分が抵抗と遭遇しそうなときに気を付けているのは、フラットに複数のプランを出すということです。
こうすることで、自分への批判ではなく、自分たちが考え出せるプランに対する批判になるし、検討の観点も広がると思っています。
ただし、このやり方をしたとしても、自分の推しのプランがあったときにそれに対する反発の意見があると、ついついネガティブな気持ちになっていました。
しかし、本書を読んだことで、生理現象であること、プランが磨かれる機会だと捉えてフラットに、なんならポジティブに捉えて意見に向き合おうと思いました。

再認識したこと

抵抗は成長する

色々なリーダーと話していると、言葉の歯切れが悪いことがあります。
今までもその人に、裏側の問題に向き合うという目的で、その場、もしくは別の場で早期にもやもやを確認していました。

本書ではこのちいさなもやもやを放置していると抵抗の強さがどんどん高まるということが書かれていました。
強まっていくという認識はありませんでしたが、そういう認識も持って引き続き向き合っていこうと思いました。

考えをとりあえず書き出してみる

本書では思考が連鎖したり、整理されると書かれていました。

私はこれ以外に、周囲の安心につながるとも思っています。
最近若手から、「モンゴルさんがわからないと言ってくれると安心する。わからなくて普通だと思って気楽に発言できる」というFBを受けたことがあった。
私のふるまい的に、触れがたいオーラを放っているのかもしれませんが、自分の気持ちを素直に表現するほうが相手は自分や場を理解し、安心して話せるかもしれないと感じたのを思い出しました。

おわりに

抵抗と向き合うとは問題自体、人と向き合うことだ、ということが繰り返し書かれていることが印象的で、かつ分かりやすかったです。
人と向き合うということに近道はないですが、これを確実にやっていくことで信頼関係が構築され、今後も素直な筋道で議論が進められるようになると思うので、ひたむきにやっていこうと思います。

「ちょうぜつソフトウェア設計入門」を読んだ

はじめに

メーカーのコーポレート部門でテックリードとして働いてるモンゴルです。
今回はXで話題になっていた「ちょうぜつソフトウェア設計入門」を読みました。感想を書いていこうと思います。

感想

設計原理、原則に一歩近づけた

各章、例えば、クリーンアーキテクチャで4層構造が説明されますが、経緯、その根本にある原理が書いてあって腹落ちしやすかったです。
筆者がこれまで、設計概念を抽象的にとらえて理解していたんだなと感じ、ただただすごいと感じました。

自分の印象に残ったのは、安定度の話です。
安定度が高いもの、普遍的なものを中心とすることで、変更しやすいソフトウェアが開発できる。
そして中心にモデルを置き、その外側に人側がやりたいことに関するレイヤー、使用する技術に関するレイヤーを置くという依存関係にすることで安定度が高くなると理解しました。

オブジェクト指向の理解が深まった

今まで、「カプセル化、継承、ポリモーフィズムが実装可能であればオブジェクト指向だー」くらいの雑な理解でした。
本書を読んで、「オブジェクト指向は複雑なプログラムの設計に対峙した人間が理解しやすいようにメタファーを与えて整理しようとした試み」ということを初めて知りました。

この前提に立つと、ただやみくもに継承を使うということは発生しない思いました。
また、「業務分析、ビジネス分析をしたときに整理した考え方を設計、開発に生かすために存在するんだ」という意識が高まり、分析、設計、開発は連続性をもって取り組むと良さそうとも思いました。

情報のモデリングの中で、現実そのものを表すのではなく、恣意的に分析した部分的な断面という表現も印象に残りました。
ただやみくもに分析するのではなく、顧客価値、事業価値を見据えて分析することで価値のあるモデリングができるんだと思いました。

テスト駆動開発が設計手法だということを改めて理解できた

以前、研修でTDDはテストの手法ではなく設計の手法だということを聞いたことがありました。
その時は例もなかったのでしっくり来ていなかったのですが、本書はサンプルコードがあり、テストしやすくすることで、抽象化が発生し、その結果、単一責任原則、オープンクローズド原則などが保たれやすくなると理解しました。

逆にBDDについて、TDDと似た印象を持っていましたが、本書を読んで違う結果が得られる、長所が違うということも学べました。

おわりに

本当はもっと書きたかったのですが、字数もそこそこいったのでこの辺にしたいと思います。
Xでの話題通り、めちゃくちゃ良書でした。いい意味で表紙詐欺、タイトル詐欺でした。(笑)
章立てが秀逸で、扱っているテーマは広範囲のはずなのに、しっかり流れがあって筆者の言いたいことが伝わってきたのがすごかったです。

クリーンアーキテクチャ本やエヴァンス本を読んで、もやもやしている若手におすすめの本でした。

「ふりかえり」でうまくいっている兆候とは

はじめに

メーカーのコーポレート部門でテックリードとして働いているモンゴルです。
最近若手のスクラムマスターと話しているときに、自分が思ったことがあったので、備忘録として残しておこうと思います。
ちなみに、スクラムマスター時代にこんなことが完璧にできたかといわれると、そうでもないのですが、自分を棚に上げて書きたいと思います。
本記事は、スクラムマスターがふりかえりのファシリテーターをしているという前提で書きます。

若手スクラムマスターの参考になれば幸いです。

私が考える、うまくいっているふりかえりの兆候とは?

自分が思いつかないアイデア、意見が出ている だと思っています。
スクラムマスターとしては皆の能力を引き出し、コラボレーションを生み、チームでないと得られない視座、視野の考えが得られるようにリードし、サポートするというのがあると思っています。

極端な話、ふりかえりをやった結果が、毎回スクラムマスターが想像しうる範囲内で収まるのであれば、一人でやっていることと変わらず、スクラムマスターが1時間とって整理してもいいのでは、と思っています。
意見が収束することばかりを目指すのではなく、手が付けられねーぜーくらいにしてもOKな心の余裕を作れるといいと思います。

じゃあどうするか?

「いや、そんなこと言ったって難しいじゃん」といわれるかもしれないですが、個人的には次の3つを気をつけると変わると思っています。

  • 俯瞰した視点で話の流れを見る
  • 違う視点で意見、アイデアを見る
  • 自分たちは気づけていない、言語化できていない何かがある と考える

それぞれについて、深掘っていきます

俯瞰した視点で話の流れ、内容を見る

俯瞰していくと、場の流れが見えてきます。
議論の流れに集中できると、細かい話に行きすぎたり、変な方向に進んでいるときに、その状況を認知、「一旦止める」というアクションがとりやすくなります。

俯瞰して場の流れを見るためにできることは、「自分は意見を持たない。意見を持っても言わない」ことだと思います。
自分が意見を出すと細かい話に頭が持っていかれるので全体が見えなくなります。
なので、「通りがかりの人ですけど」くらいの気持ちで、ファシリテートするといいと思います。

そもそも、ファシリテーターなので、公平な立場で会議を導くというのが役割ですよね?

違う視点で意見、アイデアを見る

アジャイルコーチはだったらどう見るか?先輩スクラムマスターだったらどう見えるか?POはどう見えるか?マネージャーからはどう見えるか?ステークホルダーからどう見えるか? 違った視点で見ることで、新たな角度からの問いかけ、多様な観点のアイデアを誘発できます。

じゃあ、「この人たちの視点をどう取り入れるか?」ですが、積極的に本人に聞いてみる、FBをもらうというのが手っ取り早く、効率がいいと思います。
怖いと思いますが。
ただ、これをやらないといつまでたってもその人たちと視座はあわず、周りからすると「自分にベクトルが向いている。自分たちにベクトルが向いている」と思われます。

あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで - Speaker Deck

つまり、いつかは避けられないルートであり、早めに当たって仲良くなっている方が気楽じゃんと私は思っています。

また、これはスクラムマスターだけが背負う必要もなく、チームメンバーに役割を背負ってもらうことでもできますよね?

agile-monster.com

自分たちは気づけていない、言語化できていない何かがある と考える

チームメンバーに対して、HRTの原則に則って接していくと良いと思っています。

  • 謙虚
  • 尊敬
  • 信頼

自分が意見しなくてもうまく回っていくと信頼できてますか?どうやったら信頼できるようになりますか?を自問自答できていますか?

また、謙虚という言葉に関しては、今までの自分たちのプロセス、運営、考え方に対して謙虚であるか?もっといい方法ないですか?と、常に問い続けていきたいです。

これに関しては、技術選定でも同様のことがいえると思います。もっと良いものがあるに違いない。もっと進めようと追及する姿勢、行動がプロダクトの成長、チームの成長、個人の成長につながってくると思います。

mongolyy.hatenablog.com

悪手の中に良手が潜んでいると思って広い心、幅広い視点で物事を見るのも重要だと思っています。
良手の中の良手は誰でも思いつくことであり、それがやれていないということは、「その手はそこまで良い手ではない」 もしくは 「ふりかえる必要もなく、やりなよ」ということかもしれません。

おわりに

思った以上に長くなったのでこの辺にしようと思います。
こういうことが気になった方は、「チーム・ジャーニー」という本にめっちゃ良きことが書かれていておすすめなのでぜひ読んでみてください!