Magnolia Tech

いつもコードのことばかり考えている人のために。

『どんな仕事も「25分+5分」で結果が出る ポモドーロ・テクニック入門』を読んで、改めて知る”正しい”ポモドーロ・テクニック

これまで自分の作業管理というと、おおまかな1日のスケジュール割(30分とか、1時間単位)に合わせて、todoリストを消化する方法を採っていた。しかし、割と通知に気を取られるタイプだし、チャットはすぐに応答したいタイプで、思った通りに進捗しないことも多かった。

そこで、1年ほど前からTimeTimerというタイマーを使って「技術書を読む」「資料を作成する」といった一定時間自分の作業に集中しないといけない時には、25分+5分の所謂ポモドーロ・テクニックを導入して自分自身の作業を管理してきた。

それなりに集中したい時間の時には、「25分の間は他のことはしない」と決めることで集中できてきた気もするけど、「これでいいのか?」と思い始めたところだった。

そんな時に先日開催された大吉祥寺.pmでのLTを聴いていて「なるほど?」と思ったところがあった。

speakerdeck.com

  • まず、ポモドーロ・テクニックに合わせた計画を立てていない
  • 終わったあとの振り返りをやっていない(todoの消し込みをやって終わり)
  • そもそも「ポモドーロ・テクニックの解説書」なるものが有ったのか!

LTの中で紹介されていた本は絶版らしく入手できなかったが、ポモドーロ・テクニックの提唱者であるフランチェスコ・シリロ著の『どんな仕事も「25分+5分」で結果が出る ポモドーロ・テクニック入門』は今でも入手できたので早速読んでみた。

ちなみに意外だったのは、原著は2018年に改訂版が出て、日本語版は2019年出版と非常に最近だったこと...もっと前からあるのかと思っていた。


ポモドーロ・テクニック、25分作業したら5分休憩を取る、くらいの雑な理解だったので改めて読んでみると、ポイントはそこじゃなかったことに気づく

  • 事前の計画、その日になにをやるのかをリストアップすること
  • やったことを消し込み、振り返りを行うこと
  • 「中断」に着目し、その発生原因を記録すること
  • 上記を繰り返していく中で、最初の見通しと、実際の誤差を小さくいくこと(3回目の見直しが必要になる回数を減らす、2回目の見直しが必要になる回数を減らす...)

先に時間を固定化することで、それ以外の調整要素に焦点を当てやすくし、活動を計画、記録することで予測精度を上げていく...これがポモドーロ・テクニックの肝で、タイマーよりも記録用紙の方がよっぽど大事なんだな、と気づきがありました

次からは、事前の予測と、振り返りをしっかり進めていくことにします。


また、本書で一番興味深かったのはチームにポモドーロ・テクニックを導入する方法。

マイクロチーム単位でポモドーロ・テクニックを導入する、その際の分割単位は「作業時間」ではなく、「休憩時間の長さ」を基準に検討する、というのが実に興味深い着眼点。

たしかに!

(まぁ、作業時間は25分と決まっているので、それ以外の要素になるのは、それはそう、という話なのだけど)


詳しいやり方は当然本を読んでほしいのだけど、タイマーで時間を測ることが目的じゃないんだな、という気づきが得られるので、ぜひみんな読んでみてください

あと、めちゃめちゃ大事なこととして、能率が下がるし、回復期間も必要になるので「残業を5日以上続けないこと」と書かれている

うん、ほんと大事

この本は働く時間よりも、それ以外の時間の大切さを語っているのが非常に良い


これが自分が使っているTimeTimer、視覚的に残り時間がわかりやすいのと、余計な機能が一切付いていないところがよい。

『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を読んだ

訳者の増田亨様より献本いただきました ありがとうございます

さっそく読んでみました


システムは、なぜ必要とされるか?という「why」が有り、次に何を作るべきか?という「what」が有り、それを受けての「how」が有る。

(たまに突然「what」だけが有ったり、なぜか「how」の議論だけが先行する事例も聞くけど、それは順番が間違っているだけなので、その問題はここでは触れない)

この「why」と「what」と「how」が上手く繋がった状態を作り上げていくために、過去にさまざまな開発方法論が考案され、語られてきた。

ドメイン駆動設計」は、開発方法論として「名前がついて、生き残ってきた手法」の一つであり、昨今複数の解説書が発行されている唯一の手法と言える。

ドメイン駆動設計をはじめよう』は、他のドメイン駆動設計の解説書よりも更にこの「why」に踏み込み、事業活動における対象領域の位置付けや、特性を分析し、そこから「what」や、「how」につなげていくことを試みている本だ。


そのシステムのステージというか、作られている状況はさまざまで、「構想だけはある」「だいたい何を作ればいいのか決まっている」「全体の構成は決まっているが、実装のための細部は決まっていない」「すでに全て実装され、稼働中のシステムがある」といった「段階」がある。

また、そのシステムへの関わり方も「経営として投資の意思決定をする」「責任者として開発の意思決定をする」「開発リーダーとして実装の意思決定をする」「開発担当者として分解された要素の設計、実装をする」といった、いろいろな関わり方がある。

本書のように、「まずは事業活動を分析し、何が中核の業務領域なのか?、どこに複雑さが有るか?、自分たちの競争優位性の源泉はどこにあるか?」と言われても、「もう開発計画が決まっている」とか、「そもそももう完成されたシステムの一部の機能追加をする立場だし」とか、「指示されたのは、この機能の実装だけだし」といった「状況」に対する「関わり方」も千差万別な中、こんな一番ゼロベースの段階から関われる人、意思決定できる人ってどれだけ居るんだっけ?となるかもしれない。

たぶん自分もひとりのパーツを作る開発者だったらそう思っていたに違いない。

「そこは自分が踏み込む領域でもないし」と。

ただ、結局「より正しい実装」を考える上では、「そもそもの要求はなんだっけ?」「この機能を提供するとどんな価値があるんだっけ?」というところに繋がっていくので、どんな立場の人でも読む価値はあるし、考えるきっかけになる。

そんなきっかけのフックが欲しい人には最適の本。

ただ、第I部で語られていることは「ドメイン駆動設計という手法によりもたらされる結果」というよりは、ちゃんと事業活動に合わせたシステム構想を描いていけば自然とそうなる(ならないと逆におかしい)ことを、その後の第II部の具体的な設計、実装方法につなげていくために「ドメイン駆動設計の語彙で」定義、解釈したものと捉える方が適切。

別にドメイン駆動設計だから重要な業務に注目するわけでも、システムのスコープを区切る訳でもないし、用語を定義するわけでもないので。

あくまで、分析と、設計・実装を分離させないためのベースラインを揃えるために定義されていると捉える方がいい。


本書は364ページと、一気に読むにはだいぶ厚いのと、少しずつ理解を深めていきながら読んだ方がいい本なので、ぜひ読書会などで色々な人の意見とか、見方を聞きながら、読み進めるといいでしょう。

なお、本書の冒頭でも触れられていますが、翻訳については著者の許諾のもと、割と他のドメイン駆動設計の文献とは、使い回しとは異なる訳が充てられているところもありますので、他のドメイン駆動設計本と並行で読む時はその辺りを気をつけながら読むといいでしょう。

『アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築』を読みました

米久保 剛さんが執筆された『アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築』という本が出版されました

https://x.com/tyonekubo

設計ナイト2024大吉祥寺.pmと、最近の自分主催のイベントで立て続けに発表頂いたご縁もあり、献本頂きました。

ありがとうございます>米久保 剛さん


一口に「アーキテクト」と言っても、期待される役割はけっこうプロジェクトによっても違っていて、インフラ寄りだったり、アプリ寄りだったり、データベース寄りだったりと、そのプロジェクトの特性や、組織構成によっても千差万別です。

そのため、「アーキテクトができます」「アーキテクトをやってほしい」というだけではなかなか期待値も合わないことが多いです。

本書では、以下の6章に渡って「プロジェクトにおいてアーキテクトが実践する内容」が解説されています。

第1章 アーキテクトの仕事
第2章 ソフトウェア設計
第3章 アーキテクチャの設計
第4章 アーキテクチャの実装
第5章 品質保証とテスト
第6章 アーキテクトとしての学習と成長

当然、書かれている内容を読んで、「自分の思っているアーキテクト像と違う!」とか、「こんなこと、全部はやれないよ」という感想も有るかもしれません。しかし、こうやって定義されることで、共通理解が進み、プロジェクトメンバ内で認識を合わせることはできます。

この本の良いところは、設計手法や観点だけでなく、「第6章 アーキテクトとしての学習と成長」のような、なかなか普段のプロジェクトの中で表立って取り上げられることの無いテーマもきちんと言及されている点だと思います。「自分がアーキテクトになっていくためにどんな心構えが必要なのか」と悩んでいる人にはとても学びの多い本だと言えます。


特に自分がいいな、と思ったのが第2章です。

ゼロからのソフトウェア設計、最初はどこから手をつけていったらいいのか全然分からないんですよ

第2章「ソフトウェア設計」では、基本的な設計のアクティビティ(V字モデル)、4つの抽象(アーキテクチャ設計、モジュール設計、コンポーネント設計、クラス設計)、プラクティス(SOLID原則)、設計パターンと、設計を語っていく上での基本概念が、密度高く語られていきます。とりあえず、この章だけでも読んでおけば戦場で丸腰になることだけは無い...なんか喋っている内容がわかるようになります。

コミュニケーションを成立させるためにも第2章は必ず読みましょう。

その後、第3章と第4章で具体的な設計のやり方、実装のやり方につながっていきます。ただ、ここはいきなり本を読んで学ぶ、というより、実際の設計成果物と比較しながら読んでいく方が、より理解が高まってよいと思いました。


本書は「包括的な設計手順書」でもないし、「あらゆる場面で利用できるソフトウェア設計手引き」でもないので、この本を頭から読んで全部頭の中に入れればアーキテクトとしての設計ができる、わけではない点は注意しましょう。あくまで自分が普段接している、もしくはこれから接する課題に対して、先人たちはどのように解決してきたのか、その視点や、おおまかな手順を学ぶためのものとして取り入れるのが良くて、やみくもにこの本に書かれている通りの用語や、手法にこだわる必要は無く、プロジェクトにおける課題を解決するにあたって、「このような考え方、手法もある」といってメンバと共有するために使う、というやり方が良いでしょう。

プロジェクトメンバと一度読書会をやって、アーキテクトとしての知識や、振る舞いに対するベースラインを合わせておく、などの使い方に向いています(拾い読みもしやすい構成になっていますし)


というわけで、メンバと設計や開発プロセスの会話をする時に、すぐに取り出せるように、机の脇に常備しておくと良い本です。

ぜひ、読む用、貸す用、あげる用とみんな3冊ずつ買っておきましょう。

オマケ

「incase Tracks Backpack 18L」を買った

ここ数年使っていたリュック、サイドポケットが無いのが不満で買い替えることにした

トラックスバックパック18(Tracks Backpack 18L) -黒(ブラック)-軽量-Incase(インケース)公式通販 – Incase(インケース) 公式通販

買ったのは、incaseの新作「Tracks Backpack」の18Lのモデル

ラインナップには18Lと25Lが有って、18Lは日常使い用でノートPCとガジェット、本数冊を運ぶのにちょうど良いサイズ、25Lは1〜2泊くらいの着替えも一緒に入れられるサイズ(前面のファスナーを開けると靴も入るとショップで言われた)

25Lはメインコンパートメントと、PC用が分かれているところが使いやすそうで、どっちにするか迷ったけど、結局普段の荷物の量を考えて18Lを選択

いつものincaseらしく、16inchまでのノートPCが収まる起毛のコンパートメントがノートPCケースを別に用意しなくて済むので便利

トップにもスマホを入れるのにちょうどよい起毛のポケットが用意されてて、つくづくガジェットを持ち歩く人向けの構成

小物類を入れるコンパートメントもしっかり用意されている


一番の目当てだったサイドボケット

ここに折りたたみ傘を刺したかったけど、サイドボケットが有るリュックはどれもサイズが大きいものばかりだったので、18Lという小さいサイズでもサイドボケットが有るのが良かった

ただ、ちょっと細めなので、太めの傘とか、水筒だと入らないみたいなので、そこは現物を見た方が良さそう


今日時点では、公式通販サイトではどちらのサイズも品切れ、新宿にある公式ショップは今月7/28にクローズ(現物見ようと思ってショップに行ったら書いてあった)、他のお店ではまだ取り扱いなし(通販も公式以外はほとんどない)、という状態なので、現物を見て買うのが難しいけど、今までのincaseのリュックとデザインラインが違っててお勧めです

『「入門」ドメイン駆動 基礎と実践・クリーンアーキテクチャ』を読んだ

ここ2年ほどのSoftware Design誌の「ドメイン駆動設計」と「クリーンアーキテクチャ」の特集をまとめた、特別号『「入門」ドメイン駆動 基礎と実践・クリーンアーキテクチャ』を買ってきた。

雑誌に掲載されていた時から、「これは完全保存版」と思っていたけど、やっぱりみんなそう思っていたのか独立した1冊に纏まりました。

一家に一冊、一企業に一冊。


ドメイン駆動設計」といえば、原典とも言うべき『エリック・エヴァンスのドメイン駆動設計』という本が最も有名なのだけど、2024年の現代でこの本を読みこなすのはけっこう難しい......というか、出版された当時のシステム開発の時代背景、技術的な動向などを理解した上で読まないと意図が汲み取りづらいのと、単純に日本語版で538ページも有って、最後まで読める気が全然しない。

もっと内容を噛み砕き、現代の開発事情に合わせて内容をアップデートし、雑誌の紙面に合わせて理解し易いようにまとめられた本が有る、というのは本当に幸せなことです(10年以上前、いくら読んでもさっぱり分からなかったので......)

この本に書かれていることを頭から理解して、その通りにやれば、「はい、ドメイン駆動設計に基づく設計成果物ができあがりました」とはならない......そもそも「ドメイン駆動設計」自体が何らかの「設計の手順」や「フレームワーク」「ツール」などを提供してくれる訳ではない。何か画期的なモデリング手法や、「”高価な”モデリングツール」が有る訳でもない。

それにもっと極端なことを言えば、「対象の業務をちゃんと理解してアプリケーションを書きましょう」以上のことは言ってないので、ある程度ベテランの人から見えれば「それはそうでは?」以上の感想が出てこないかもしれない。

一方で、システム設計の初学者からすれば「なかなか具体的な話にならないな」と思えるかもしれない。

極論を言えば、分析と実装の分断を止めよう、複雑な要件に対してはちゃんとモデルを書こう、くらいしか言ってない。

「要求に合わせて、実装しているだけで、目新しいことは言ってないのでは?」みたいにも読めてしまう。

そういう意味では、限られた紙面では難しいのかもしれないけど、「順次増えてる複雑性に耐えられなくなった事例」「ドメインモデルを描かずに実装を続けていって一貫性や、整合性が崩れてしまった事例」みたいなのがあるとわかりやすかったのかもしれない。

でも理解が進めば、「あー確かに正しいことが正しく書かれている...!!!」と分かる日が来ると思いました。


一方でクリーンアーキテクチャの章は、「あの4つの円の図に沿った設計をすればクリーンアーキテクチャになるわけではない」と最初に宣言されているのが良いですね


この本だけを読んで、ドメイン駆動設計を理解する、というのは難しいと思うのですが(元が雑誌の特集記事という、情報量が限られたところが出発点なので)、まずはざっと何が主張されていることなのか?というのを理解するにはいい本だと思います。

ダメな事例は周りで聞いてみましょう!

「Bellroy Lite Laptop Sleeve 14inch」を買った

ノートPC、それなりに重いので日常的に持ち歩かないようにしている

けれど、さすがにまったく持ち歩かずに済む、というときばかりではないので、「Bellroy Lite Laptop Sleeve 14inch」というスリーブケースを買った

この手のケースは値段もピンキリだけど、しっかりとしたクッションが入っていて、手触りが良さそう、という点で選択

ファスナーの感じがいいよね

MacBook Proを入れてファスナーを閉めると、クッションも含めてなかなかの厚みになるけど、これなら安心できる

毎日持ち歩くなら色は黒でもよかったけど、たまにしか使わないので今回は白を選択

荷物の中で紛れないように

(自分が買ったら、Amazonの白の在庫が無くなったみたいだけど)

macOS Sonomaのインストールメモ 2024/7時点

新しいマシンが来ると本格的に使い始める前に、2回くらいは再インストールしたり、工場出荷状態に戻したりして、セットアップ手順を確認するようにしている

その作業メモ

事前準備

  • インストール対象のデバイスとは別のAppleバイス(iPhoneか、iPadか、他のmacか)を1台用意しておく

    認証コードの表示など、Appleバイスの方が楽なので、とにかく一台はあった方が良い あらかじめ同じApple IDでログインしておくこと

  • Apple IDのパスワードを変更しておく

    Appleバイスのセットアップが上手くいかない理由の一つにApple IDのアカウントロックが挙げられる 以前はApple IDのサービスサイトからロック状態の確認や解除ができたが、今では状態の確認もロック解除もできなくなっているので、事前にAppleバイスからパスワード変更を行なっておくと安心

    support.apple.com

再インストールの準備

工場出荷状態へ戻すのはログアウト等色々と面倒くさいので、単に自分のPCを再インストールするだけなら再インストールを行なった方が良い

通常の再インストール方法

support.apple.com

工場出荷状態へ戻す方法

support.apple.com

初期設定

言語(Select Language)

最初の設定は「言語」選択

日本で販売されているmacなら「言語」と表示される

ここでは「English」を選ぶ(ただの個人の好みの問題)-> 表示が「Select Language」に変わる

Select Your Country or Region

「Japan」

Written and Spoken Languages

「Dictation」の設定を「Japanese(Japan)」のみにする

その他はデフォルトのまま

Accessibility

何も設定しない

Select Your Wi-Fi Network

利用するWi-Fiのアクセスポイントを選択し、パスワードを入力する

Data & Privacy

特に設定項目なし

Migration Assistant

この時点では特に設定しない

(必要なドキュメントはiCloudか、外付けSSDに保存する)

Sign In with Your Apple ID

用意したApple IDでサインインする

なるべくiCloudのアカウントと同一の方がおすすめ(別のものを利用することもできる)

Apple IDと、パスワードを入力すると認証コードを求められるので、同じApple IDでログインしているデバイスに表示される認証コードを入力する

Create a Computer Account

アカウントを作成する

Full NameがApple IDから同期されるが、Account nameも同じにするとパス名が長くなってしまうので、短いものに変える

Make This Your New Mac

いくつかのカスタマイズができるが、ここでは何も設定しない

Touch ID

画面の指示に従って、設定する

Card Details

Apple IDに紐づいているクレジットカードが連携される

(Card Verificationが表示されるが、特に完了しないまま先に進んでしまった...なぜ?)

各種設定

Local hostname

Local hostnameで設定されているマシン名が、ターミナルのコマンドプロンプトに表示されるマシン名になる。

この名前がデフォルトではApple IDのFullnameと機種名から生成されるため、デフォルトでは非常に長い文字列となる

  1. 「General」→「Sharing」→「Local hostname」
  2. Editボタンで変更
  3. 「mbp2023」などの短い名前にする

Trackpad

「Tap to click」をオンにする(なぜこれがデフォルトで有効になっていないのか不思議なくらいの必須設定)

Keyboard

US配列キーボードの場合、絶妙な位置にcaps lockキーが配置されていて全然役にたたないので、controlキーに置き換える

「shortcuts」->「Modifier」で「caps lock」キーを「control」キーに設定

homebrewのインストール

macOS必須のソフトウェア、homebrewのインストール

brew.sh

インストールの途中で、Xcode Command line toolsも自動的に一緒にインストールされる、便利

SDKMANのインストール

JVMや、Scala、sbtなどのインストール管理用に、SDKMANをインストール

sdkman.io

その他

細かいことを言えば、Musicや、Finderの表示設定も変更するが、見た目の話だけなので割愛

意外と、最近はデフォルト設定から変えることが少ないなーと思った