チームでアプリケーション開発するためにあるとうれしいガイドラインの雛形を公開しました

はじめに

この記事について

表題のとおりなんですが、私は仕事のスタイル上、1〜2年くらいで現場を移っていて、とくにスタートアップだとこうしたガイドラインの類が存在しないことがあるので、毎回（要請があれば）そのチームや状況に特化した形で書いてきました。これまではその都度イチから書いていたので、どこかにまとめておきたいと考えて、GitHub に載せておくことにしました。

github.com

補足

必要なことは README.md に書きましたが、このままだとこの記事自体が空っぽになってしまうので、重複する部分もありますが、少し補足します。

あまり需要があるとは思えませんが、CC0 なのでご自由にご利用ください。

重要なのは、そのチームや状況に応じてガイドラインの中身を最適化することです。メンバーの理解度やチームの共通認識がどれくらい揃っているか、プロダクトがどのような特性を持っているかなど、ガイドラインがどこまでの粒度でどのていどの規模必要なのかを左右する要素はいくつかありますし、なによりもチームで話し合って決めることが重要です。なので、あくまでもたたき台として使ってください。

ガイドラインがなぜ必要かというと、属人性をできるだけ排除することで、できるだけストレスなく他のメンバーが書いたコードを変更できるかとか、プロダクトの品質を揃えられるか、といった点に寄与できるのと、複数の選択肢があるときにどれを採用するかいちいち考えずに済む、という利点があるからです。

コーディング標準のように自動化されたガイドラインの場合、慣れてくるとそのうち、いちいち Linter を実行せずともそのスタイルで書けるようになるものですが、自動化してない部分であってもその作用はあると思います。自分のスタイルに固執するのではなく、チームで決めた標準に従うようにしてください。

コードとチームはチームみんなのもの、です。

おわりに

現場によってスタイルは様々ではありますが、比較的傾向というか類型みたいなのはあると思いますし、できればあるていどパターンに則って構築していくと、人が入れ替わる際にも素早くオンボードできると思うので、今後もできるだけ活用していきたい所存です。

50代のフルスタックエンジニア

はじめに

この記事について

以下の記事を読んでわりと「うんうんわかるわかる」と思いながら読みましたが、50歳に至るまでの間にもうひとつ別の景色も見えてきていたので、そのあたりを一度言語化してみようという試みです。

note.com

フルスタックとは

上記記事へのブコメには「フルスタック」と書きましたが、自分としてはあまりフルスタックと名乗りたくない、という気持ちはありまして、普段は「ウェブアプリケーションエンジニア」と自称しています。 ただ、今回は、元の記事に合わせるために本記事における「フルスタック」の定義を定めておきます。

以下の領域の技術を理解し使える

• インフラ
  • アプリケーションが動作するサーバや協調するミドルウェア
• バックエンド
  • サーバーサイドのアプリケーションに用いる言語やライブラリ
• フロントエンド
  • クライアントサイドのアプリケーションに用いる言語やライブラリ

すべてを理解している必要はなくて、3つの領域それぞれに1つでも使えるものがあり、一人でアプリケーションを作り動かすことができれば「フルスタック（アプリケーション）エンジニア」と自称していいのではないか、というスタンスです。自分はウェブサービスに従事することが多いので、必然的にウェブアプリケーション関連の技術になりますが、モバイルクライアントを含む場合もあるでしょうし、あまりないとは思いますが、Firebase や Supabase あたりを主なバックエンドとして使うこともあるでしょう。しかしそれらはあくまでバリエーションであって「これができないとフルスタックとはいえない」という技術ではないかなと思っています。

追記:「フルスタック」という言葉に関して補足記事を書きました

フルスタックエンジニアについて - nunulkのプログラミング徒然日記

技術領域（ハードスキル）

流行について

3つの領域すべてで、最新の情報をキャッチアップするのは無理になってきました（というか諦めつつある）。 「エンジニアに若いも若くないもない」というコメントもありましたが、個人的には年齢は間違いなく関係あると思っています。ただし、それは他者との比較ではなく過去の自分との比較です。元記事にも「若い頃の自分は〜」という記述もあるので、その視点は含まれているでしょう。

現在の視点から未来の視点を持つことは（若ければ若いほど）難しいと思います。年を取るにつれて（というより経験を積むにつれて）新規の技術や流行に対して昔ほど貪欲でなくなりました。いくつか例を挙げるとHotwire は出てわりとすぐ触りましたが htmx はまだ触ってません。Rust は最近使い始めましたが、去年からなのでだいぶ遅い部類でしょう。Go は自分には合わないと思うのでほとんど書いてませんし、仕事で使うつもりもいまのところありません。興味に任せて片っ端からやるのではなく、自分に合いそうか好きになれそうか、という視点でやる/やらないの判断するようになりました。そうした姿勢が選択の幅を狭めているともいえますし、効率が良くなったともいえると思います。

とはいえ、仕事で使う局面になったときにサッと使えるようにしておく、というのは大事だと思っていて、その辺の見極めもできるようになっておく必要があるので、とりあえず1回触っておくようにはしています。

具体例としては、DynamoDB、AWS Lambda、Next.js、辺りは実務で使う前にあるていど触っていたので、助かったです（その意味では、Go もいまの仕事で使うとなれば喜んで書くつもりではいます）。

その点、バックエンドは比較的安定してますね。どれか一つエキスパートレベルで使える言語やフレームワークがあれば（あとは SQL）、あまり流行を追う必要はなさそうです。

技術領域に関しては、イノベーター、アーリーアダプターである必要はありませんが、アーリーマジョリティーくらいの位置でいたいとは思います。

態度について

大事なことは、できないことはできないと自覚し、できる人の言うことを聞く、ということです。自分はフルスタックといえど、3つの中ではフロントエンドが苦手領域なので、チーム内に自分よりできるメンバーがいるときは弟子になったつもりで取り組むようにしていますし、得意な部分に関しても、自分がぜったい正しいとは思わないように、チーム内でのコミュニケーションは欠かさないようにはしています。

複数の選択肢があったとき、どれを採用するかは自分の得意不得意にかかわらず根拠を明確にしたいという気持ちがあって、得意な領域であればもちろん、不得意な領域に関しても不得意なりにそれぞれの選択肢についてその根拠に自分が納得できるかどうかは大事にしたいです。不得意であることをそのままにしておくのであれば、その領域には手を出さないほうがいいですし、やるからには常に上達できるように選択の根拠に限らず土台となるような部分を疎かにしないように心がけたいです。

非技術領域（ソフトスキル）

結婚について

元記事では結婚の話が出ていましたが、自分が結婚したのは32歳のときでした。当時は SI の仕事をしていてかなり忙しく、結婚する前のデートでは22時過ぎに待ち合わせして飲みに行く、みたいなこともしてました（よく付き合ってくれてましたね…）。

仕事一辺倒ではダメ、というのはわりと昔から思ってはいたものの、若い頃は深夜2時まで働いて翌日9時から仕事、みたいなことをやっていたので、どうしても活動範囲が狭くなりがちでした。幸い職場に女性がわりといたので（2割くらい）、社内恋愛もできましたし、出会いの場としての職場、というのは、結婚を考えると貴重な存在だったなぁと思います（といいつつ、妻は元同僚ではなく友人の紹介で知り合ったんですが）。

当時の自分はまったく結婚する気がなかったんですが、いまとなっては心の底から結婚してよかったと思うので、この選択をした過去の自分にこの場を借りて感謝します。ありがとう、よくやった、G☆J。

夢と希望について

個人的には「夢」とは「具体的施策のない遠い目標」のことだと思っていて、そこに至る道筋や施策を用意できればそれはもはや夢ではなく単なる目標だと思います。最終地点までの道筋は見えなくても、少なくとも次のマイルストーンが見える状態を維持できれば自然と実現できるものになるはずです。

熱意だけでなにかに挑むことは、この年齢ではできなくなってしまいました。それはいい面もあるし悪い面もあるだろうと思うんですが、自分は長所を伸ばすことを重視しているので、悪い面には目をつむり、経験を活かして確度を上げることに注力していきたい所存です。

ちなみに今年の目標の一つが「ハイキック」（正確には 蹬腳 という太極拳の動作）なんですが、いまはまったくできるイメージが持てず、すでに2ヶ月が経とうとしているので少し焦りが出てきています。

2023年のふりかえりと来年の抱負 - nunulkのプログラミング徒然日記

おわりに

自分はわりと過去を振り返らない質なので、あのときの態度や判断がどうだったかとかは普段あまり考えないんですが、過去の自分の態度や判断を正解にするような未来を作る、という姿勢はありだと思っていて、自分に都合のいいように解釈することで、得るものと失うものがあるわけですが、どうしたって自分のことなのでバイアスもありますし、いちいち過去の自分を否定していても疲れるだけなので、どうせならポジティブに捉えたい、という気持ちです。 50歳になったいま仕事・プライベートともに満足しているので、そういえるだけなのかもしれませんが、大事なのは、どのような結果であってもポジティブに捉える姿勢を持ちつつも、できるだけ未来の自分が満足できそうな結果を積み上げていけるかどうか、なのかなという気がします。

勢いで書いてしまったので、いつも以上に雑な文になってしまいました。読みづらかったらすみません（あとで清書するかも）。

自社サービス運営会社向け Notion データベース活用のポイント

はじめに

この記事について

表題のとおりですが、自分が自社サービス運営会社によく関わるので限定しているだけで、もしかしたらそれ以外でも通用する部分もあるかもしれません。 行く先々で Notion のレクチャーというか相談に乗ったりガイド書いたりしているので、どっかでまとめておきたいと思ったのが書いた動機です。

Notion とはなにか

Notion 自体についてはいまさら紹介の必要はないと思いますが、これから Notion を始める組織や使い始めたはいいけどどう使っていけばいいのかよく分からないという組織の場合は、まず Notion とはなんなのか、という認識を共有しておく必要はあると思います。 世間には、Notion をメモアプリと紹介してる媒体もありますが、ビジネスで使う上ではどちらかというと以下の認識を持っているほうが有用かと思います。

Notion とは「GUI を備えたデータベース」であり、もっというとノーコードアプリケーション開発ツールである

公式ドキュメントにも目を通しておいてください。

データベース – Notion (ノーション)ヘルプセンター

目次

1. データベースの分類

Notion におけるデータベースには種類はありませんが、運用する上では以下の二つに分けて考えるのをおすすめします。

1. マスターデータベース
2. トランザクションデータベース

以下に示すとおり、マスターデータとトランザクションデータは異なる性質を持っているので、そのデータベースもできるだけ分けて作成し、それぞれに適した管理方法を取るといいでしょう。

1.1. マスターデータとトランザクションデータの区別の仕方

マスターデータベースは、顧客や従業員が代表的ですが、いったん作成されたらほとんどデータの書き換えが起こらない類のデータです。会社の代表電話番号や従業員の氏名などは基本的には変わらないものなので、これらを属性として持つデータをマスターデータベースとしてまとめておきます。

一方、トランザクションデータベースは、なんらかの限定的な期間の間に頻繁に情報が変わる性質のあるデータです。代表的なものは、営業でいえば、リード獲得から成約に至るまでのタスク管理だったり、CSでいえば、顧客からの要望や不具合報告だったりです。トランザクションデータは、ほとんどは特定の部門が主導して管理するものなので、部門ごとにまとめるかどうかはその部門の方針次第でいいかとは思います。

2. 共通のポイント

マスターデータベースとトランザクションデータベースは性質や運用方法に違いがありますが、両方に共通するポイントもあります。

1. 選択肢はできるだけ単一にする
2. 他のデータベースにある情報は Relation を使って参照する

2.1. 選択肢はできるだけ単一にする

選択肢のプロパティは Multi-select と Select がありますが、できるだけ Select を選ぶといいでしょう。複数選択可能だと選択肢間の矛盾や曖昧さが生まれやすいので、まずは択一にできないかを検討し、どうしても複数設定したい、という順番にするといいと思います。複数設定したい場合は、デフォルトで設定されている「Tags」を使うのもいいと思います。

2.2. 他のデータベースにある情報は Relation を使って参照する

できるだけ同じ情報を複数箇所に置かないほうがいいので、マスターデータベースにあるプロパティを Relation にしましょう。

ただし、数が多くなるとマスターデータベースの情報をすべて覚えるのは不可能ですし、プロパティすべてを覚える必要性も薄いので、たしかこんなマスターあったよな、くらいのうっすらとした記憶を頼りに、まずは Relation で作成してみてデータベースを検索してみて、存在しなければ新たにマスターデータベースを作成するか、他で使わないような情報であれば Text などの他のタイプで作成してください。

リレーションとロールアップ – Notion (ノーション)ヘルプセンター

3. マスターデータベースのポイント

社内にデータベース設計に明るい方がいれば、その方にお任せでいいですが、いない場合は以下のポイントを抑えておけばいいかと思います。

1. 複数部門で共用するデータベースは情報システム部などのエキスパートが一元管理する
2. マスターデータベースであることがわかる名前にする（例：◯◯マスター、マスター：◯◯、など）
3. チームスペースの最上位のページにまとめて配置する
4. 情報はできるだけプロパティに持たせる（ページ内には書かない）
5. マスターデータベースを作成する前に、同じようなマスターデータベースがないかどうかチェックする（もしあれば、そちらを拡張する）

3.1. 複数部門で共用するデータベースは情報システム部などのエキスパートが一元管理する

マスターデータベースは色んな部門が横断的に利用することが多いため、各部門でほしい情報や形式が異なることがあります。それらを各自に任せているとカオスになるので、取りまとめる部署や担当者がいたほうがいいでしょう。場合によっては、部門の間に立って、どちらかに合わせてもらうなどの調整が必要になることがあります。

社内にエキスパートがいないのであれば、だれかいちばん適してそうな人を充てるしかないですが、Excel やスプレッドシートの表作成が上手な人であれば、だれでもいいと思います。

3.2. マスターデータベースであることがわかる名前にする（例：◯◯マスター、マスター：◯◯、など）

データベースを参照するときに、プルダウンリストで選択することになりますが、すべてのデータベースがリストに出てくるので、マスターデータベースであることを識別しやすくする必要があります。識別子やフォーマットはなんでもいいですが、マスターデータベースであることが分かる名前にすると検索が楽になります。

3.3. チームスペースの最上位のページにまとめて配置する

前述のとおり、マスターデータベースは一元管理したほうがいいので、一箇所にまとめておくといいでしょう。

3.4. 情報はできるだけプロパティに持たせる（ページ内には書かない）

データベースの各行には自動的にページもついてきますが、できるだけページ内には情報を入れないようにしましょう。フィルターやソートで利用できないからです。まずはプロパティで定義できないかどうか検討し、フィルターやソートでは絶対に使わないと断言できるような情報のみをメモ書きとしてページに書くようにしましょう。

ただし、ユーザーズマニュアルなどのドキュメントは、データベースとして管理するのであれば、マスターデータベースに分類されます。コンテンツが主体のデータは読みやすさを重視して、ページ内にコンテンツを書くほうがいいでしょう。

3.5. マスターデータベースを作成する前に、同じようなマスターデータベースがないかどうかチェックする（もしあれば、そちらを拡張する）

これも一元管理でないとなかなか難しいのではないかと思いますが、情報をなるべく重複させないようにするのが肝心です。情報が重複すると認識のずれが発生し、トラブルに繋がりますので、できるだけ事前にチェックするか、どのようなマスターデータベースがあるのかを常に把握しておくかするといいでしょう。

重複に気づいてから統合するという戦略でもいいですが、参照している他のデータベースを洗い出すのは大変なので、できれば事前に防ぐ戦略をおすすめします。

4. トランザクションデータベースのポイント

1. テンプレートを使う
2. 複数のビューを使う
3. Person プロパティの Limit をできるだけ1 にする
4. ボードビューのレーンは Status プロパティで分割する
5. フィルターはできるだけ全員同じ条件になるようにする

4.1. テンプレートを使う

マスターデータベースと違って、トランザクションデータベースではページ内にコンテンツを書くことも多いです。その場合、各ページに記載してほしい情報の種類は共通であることがほとんどなので、あらかじめテンプレートを作っておき、レコードを作成した人がどんな情報を書いたらいいのか、なるべく迷わないようにしておきましょう。

テンプレートに書くのは、最低限見出しがあればいいですが、ガイドメッセージを含んだコールアウトもあるといいでしょう。他にも、決まったフォーマットがあればすべて書いておきます。

テンプレートを作成したら忘れずにやってほしいことがあります。作成したテンプレート（複数ある場合はいちばん使うと思われるもの）を必ずデフォルトに設定してください。

テンプレートをデフォルトに設定

データベースにレコードを追加するのは、テーブルの最下行にある「+ New」ボタンと、右上にある「New」ボタンがありますが、最下行にあるほうはテンプレートを選べませんし、右上にあるほうはリストからテンプレートを選べますが、選ばない場合はデフォルトが適用されます。せっかくテンプレートを作成してもデフォルトを切り替えていないと空のページが生成されてしまいます。

4.2. 複数のビューを使う

テーブル、ボード、タイムライン、カレンダー、リスト、ギャラリーの6種類がありますが、大別すると以下の基準で選ぶことになります。

Notion データベース - ビューの種類

1. 一覧で見たい → リスト、テーブル、ギャラリー
   1. 画像を見たい → ギャラリー
   2. 主にタイトルだけ見たい → リスト
   3. プロパティを含めて見たい → テーブル
2. 時系列で見たい → ボード、タイムライン、カレンダー
   1. 日付や期間を正確に見たい → カレンダー
   2. 期間を俯瞰的に見たい → タイムライン
   3. 各アイテムがどの状態にあるのかを見たい → ボード

1 のケースでは、基本的にテーブルビューがおすすめです。もちろんリストビューでもプロパティは表示できますが、テーブルビューには罫線が出るので、プロパティが多くなってくるとその分だけやや視認性が高いです。テーブルビューとリストビューはほとんど違いはないので、迷うくらいならテーブルビューにしておきましょう。

2 のケースでは、それほど迷うこともないと思いますが、細かい粒度（日付）で見たい場合はカレンダー、大きな粒度で見たい場合はタイムライン、日付ではなく状態で見たい場合はボード、と使い分けるといいでしょう。同じ情報を扱うのであれば、できるだけデータベースは一つにして、目的に応じてビューを切り替えるのをおすすめします。

また、同じビューを使って異なるプロパティを見たい、というシチュエーションもあります。その場合は、同じビューを使いつつ、名前で区別できるようにしておくといいでしょう。基本的には、プロパティの表示非表示をその都度切り替えるよりは、ビューを複数作るほうが効率はいいです。

4.3. Person プロパティの Limit をできるだけ1 にする

「2.1. 選択肢はできるだけ単一にする」と同じ理由ですが、担当者を割り当てるようなケースでは、Person プロパティの Limit の値を 1 Person にしておきましょう。

Person - Limit - 1 Person

もし担当者を複数割り当てたくなった場合は、それぞれ一人ずつになるようにタスクを分割できる可能性がありますので検討してください。

担当者を複数割り当てたくなるということは、複数のタスクがまとまってしまっている可能性があり、一つのタスクに複数の担当者を割り当ててしまうと責任範囲が曖昧になり、タスクが停滞したときにだれのどのプロセスで止まっているのか確認する必要がでてきてしまいます。

また、状態によって担当する人が入れ替わる場合は、ボードビューでレーンを移動する際に担当者を変更することで対応可能です。どうしても複数割り当てられないと困る場合は、「主担当」と「副担当」のようにプロパティを分割するのも手です。

4.4. ボードビューのレーンは Status プロパティで分割する

ボードビューでは状態の変化に応じて左から右へカードを移動していくことになります。基本的には、時系列に沿って左から右へひとつずつ移動していくフローにすると分かりやすいですが、場合によっては右から左へ戻ることもありえます。ですが、混乱を避けるため、できるだけ左から右へ一方向に流れるように状態の設計をしてください。

デフォルトでは「Not started（To-do）」「In progress（In progress）」「Done（Complete）」の3つですが（括弧内はグループ）、通常はこの3つでは足りないので、自分たちで増やしていくことになります。状態を追加する際の原則として、それぞれの状態に遷移する条件を事前に決めておいて文書化しておくとスムーズに導入できます。また、「To-do」および「Complete」グループに分類される状態はできるだけ少なくしましょう（できればそれぞれ一つだけ）。「To-do」に入っているけど実はだれかがなんらかの作業を行っていた、「Complete」に入っているけど実はまだ終わってなかった、みたいなことが起きるとせっかくの状態管理が意味をなしません。

状態に関しては、事前の設計が重要とはいえ、最初から完璧を目指すのではなく運用しながら改善を重ねていきましょう。プロセス自体の見直しや外部要因の変化によって変更する必要が出てくることもありますので、永遠に見直し続けるつもりでいてください。

4.5. フィルターはできるだけ全員同じ条件になるようにする

フィルターは、下図の「Save for everyone」を忘れずに押して、全員が同じフィルターが適用された状態のデータを見るようにすると、人によって見えたり見えなかったりする結果起きる、無用な行き違いを避けることができます。自分の割り当てられているタスクだけを見たい、みたいな場合は、リンクドデータベースを使って個人のページに専用ビューを配置しましょう。

Save for everyone

おわりに

これまでいくつかの会社で Notion の導入支援をやってきたなかで、データベースを運用する上でのベストプラクティスっぽいものがぼんやり溜まってきていたので、また導入支援をすることになったタイミングで文書化してみました。漏れてるものやこれから溜まっていくものもあるかと思いますので、随時更改していくつもりです。

うちではこんなルールで運用しているよ、などのコメントがあれば、ぜひください。

再び台湾に行ってきました

はじめに

この記事について

なんかすっかり台湾を気に入ってしまって、前回からあまり間を開けずに2回目来ちゃったので、前回試してなかったことを中心にまとめておきます（すぐ忘れちゃうので）

前回の訪問記はこちら

台湾に行ってきました - nunulkのプログラミング徒然日記

目的地

高雄です。せっかく寒い日本から抜け出すんだから、台湾の中でもできるだけ南へと思って高雄にしました。

旅の目的

普洱茶を買いにきました。詳しくは省略しますが、プーアル茶はビンテージがあってめちゃくちゃ高いやつもあるらしいんですが、庶民なので普通のがあれば普通の買うつもりでした（別に日本でも買えるんですが、なんとなく）。

Taiwan the Lucky Land

前回も応募しましたが、今回ももちろん応募しました。抽選で5000元の入った悠遊卡（= Easy Card、ヨウヨウカー、Suica みたいなやつ）が当たる神キャンペーンです。

結果は

当たりました。やったー

知らなかったんですが、もらえる悠遊卡はチャージもリファンドもできないそうで、使い切る必要があります。

しかし、今回行った店はほとんど悠遊卡が使えなかったので、けっこう残っちゃいました。どうせまた来るからいいんだけど。

台灣高鐵（高速鉄道）

台北から高雄までは300km近く離れていますが、高鐵を使うと最速で1時間半ちょっとで着きます。チケットはアプリで買えるので、スマホでポチポチするだけでOKです。

注意点は、アプリからの予約は当日はできないということ。前日までに支払いまで済ませておく必要があります。

行きは時間が読めなかったので、直前に駅の発券機で買いました。

帰り、隣に座ったおばあさんが話しかけてくれて、本当に簡単なやりとりしかできませんでしたが、道中中国語で会話することができたので、とてもうれしかったです。80歳を越えている方でしたが、曰く、彼女のお母さんは日本語が話せるが、彼女は話せないそうで（といいつつ、簡単な単語はいくつかご存知でした）。太平洋戦争時、日本の統治下にあった台湾において、台湾に住む人々が日本の方針で日本語を覚えさせられたという話は知っていましたが、改めて、戦争はずいぶんと昔のことになってしまったのだなぁと思いました。

おばあさん、お話できてよかったです、どうもありがとう。

謝謝你跟我說話。很高興。

YouBike

前回行ったときにその存在は気付いたものの、使ってみようとは思わなかったレンタル自転車 YouBike。

今回、お土産爆買いツアーで高雄市内のあちこちに行く必要があったので借りてみました。

専用のアプリが必要なのでインストールし、台湾で使用可能な電話番号がない場合は、デポジット（3000元だったかな）を払って利用することになるのでクレジットカードを登録します（Google Pay でも OK）。

あとは、YouBike の置いてある場所（けっこうあちこちにある）でアプリから QR コードを読むだけ。便利。アプリの地図上に近くのステーションが表示され、ステーションごとに何台空きがあるか分かるようになっています。便利。もちろん返す場所は借りたのと別のステーションでもいいので、移動先にしばらく滞在する場合はいったん返却して、また移動するときに借りることができます、便利なだけでなく経済的でもありますね。

気をつけないといけないのは、台湾は（台北と高雄しか知らないですが）狭かったり段差があったりで歩道をあまり走れないので、車道を走ることになるんですが、バイクが多く、中には運転の荒いバイクもいるので、注意して運転する必要があります。

前回は Uber に何度もお世話になりましたが、今回は YouBike にお世話になりました（費用は10分の1以下？）。高雄は台北ほど地下鉄が縦横無尽に走ってるわけではなかったので、バス・タクシー・自転車という選択肢がありましたが、自転車がいちばん融通の効く移動手段ですね。次回以降は、どの都市に行くかわかりませんが、またお世話になると思います。

繁体字のソフトウェア関連書籍を買った

本当は、「プログラマー脳」を買いたかったんですが、なかったので、"Five Lines of Code: How and when to refactor" にしました。

買ったのは、台北で、検索して見つけたコンピューター関連書籍専門店（他にも理系のもちょっとある）です。簡体字の（大陸の出版社なのかな）本のほうが量的には多かったかな、でも、中国語のコンピューター関連書籍を買うならここですね（どれだけニーズあるか分からないけど笑）。

おわりに

今回もあっという間に時間が過ぎました。旅は楽しいですね。

あとはもうちょっと中国語なんとかしないと、コミュニケーションがとれないので、今年の抱負でもある中国語、ばんがります。

この5ヶ月中国語学習あまりやってなかったので、レベル自体は上がってない（むしろ下がってるはず）ですが、経験値は上がってたっぽくて値段の聞き取り精度が高まってた気がします（聞き返すことなく把握できる回数が多かった。高雄の中国語のほうが聞きやすかったりするのかな？）。

とはいえ、こちらからの簡単な意思表示はできても、店員さんからちょっとバーッと話されるとなんて言われたかほぼ分からないリスニング力＆語彙力なのは相変わらずなので、繰り返しになりますが、なんとかしたいと思います。

ではまた次回。再次見面！

2023年のふりかえりと来年の抱負

はじめに

この記事について

今年（2023年）を振り返って、悪かったところは反省し、良かったところは褒めたいと思います。完全に自分のための記事です、ご了承ください。今年はソフトウェアエンジニアを「サバティカルリタイア」した1年だったため仕事はほぼしてないので、今回もプログラミング成分は微量です。

ハイライト

4月

珍しく人前でしゃべってきた

フリーランスソフトウェアエンジニアの生存戦略について - nunulkのプログラミング徒然日記

あんまりお役に立てることはないんですが、同業者からの相談などはいつでもどんなときでも受けたいと思っています。

フリーランス仲間で開発合宿に行ってきた

ジェネレーティブAIとソフトウェアエンジニアの未来について - nunulkのプログラミング徒然日記

年イチくらいで集まって温泉とお酒（メイン）とセットで夜通し開発（とおしゃべり）する素敵な会です。主催者の方に毎回お任せしちゃって負担かけてしまっているので、来年は自分が音頭取りたい。

8月

台湾に行ってきた

台湾に行ってきました - nunulkのプログラミング徒然日記

イベント参加は完全におまけで、旨いもの食べまくる旅でした。台湾最高だったので、来年もまた行きます。

9月

「Laravel概論」という教材（？）を出した

「Laravel 概論」という教材（？）を出しました - nunulkのプログラミング徒然日記

なんだかんだで3冊目。予想どおり売れてません(笑)。

減量した

目標達成したので減量のためにやったことをメモ - nunulkのプログラミング徒然日記

2年目で目標達成したので GRIT（やり抜く力）の大切さを再認識しました。継続は力なり。

10月

Gleam に出会った

Gleam の第一印象 - nunulkのプログラミング徒然日記

今年は趣味プログラミングを Rust で始めて、Rust は Rust でときどき書いてますが、Gleam に出会って以降はちょっとしたプログラムは Gleam で書くようになりました、使い捨てのログ分析ツールとか。やっぱり Rust はめんどくさい(笑)

11月

一時的に仕事をした（してる）

3月末までの契約ですが、人が採れなくて困っているということだったので、引き受けることにしました。自分にしては珍しくレガシーな現場でなかなか歯応えがあるので、3月末まで全力で取り組んでいきます。

12月

技術顧問業終了

某社で長らくやっていた技術顧問（相談役？）的な仕事が終わりました。詳しくは書きませんが、色々反省すべきところがありました。主には、どれくらい開発メンバーに対してこちらからアプローチするか、の塩梅が難しかった、というところです。あくまでも依頼されたらやる、というスタンスでいましたが、もうちょっとできることがあったんじゃないか、という思いが残りました。後悔先に立たず。

良かったところ

飽きるかなぁと思っていた無職生活（技術顧問があったので厳密には無職じゃないんですが、ほとんど稼働してなかったので実質はって感じです）ですが、ぜんぜん飽きないので、来年4月以降も再び無職に戻ります。いまやってる仕事みたいな緊急案件を3ヶ月くらいやるのはいいかもしれませんが、基本的にはもう仕事はいいや、という思いは変わらないですね、仕事再開したらまた働きたい欲が戻ってくるかも？と想像したりもしたんですが。

悪かったところ

中国語がなかなか上達しないので、来年はもうちょっと腰を据えてやりたいです。いちおう HSK4級取ったんですが、簡単な意思疎通はできるものの、コミュニケーションが取れるとは言い難く、この1年なにをやっていたんだ、という思いが強いので、せめて英語のレベル（そこそこ会話できる、聞ける、読める）までには近づけたいです。

来年の抱負

• 中国語でコミュニケーション取れるようになる
• ハイキックできるようになる

おわりに

人との関わりはもともと少なかったのに、今年はさらに少なくなりました。その中でも、なんだかんだでずっと絡んでくれている人たちには感謝してもしきれません。みなさん、いつもありがとうございます！来年もよろしく！

レガシーコードと出会ったときにどう振る舞うか

この記事について

「レガシーコード」とは、「保守または拡張が困難な既存のプロジェクト」（レガシーソフトウェア改善ガイドにおける定義を流用）で書かれたコードを指します。場合によっては難解なコードに対する悪意を込めて「クソコード」などと呼ばれたりしますが、個人的にはこの名前が好きになれないので、本記事ではそういう含意があったとしても「レガシーコード」で統一します。

というわけで本記事では、レガシーコードに出会ったときに自分がこれまでどう振る舞ってきたか、これからどう振る舞っていきたいか、について備忘録がてらまとめておこうと思います。

レガシーコードとは

legacy という言葉の一般的な意味（遺産）が示すように、レガシープロジェクトは通常、前の開発者またはチームから引き継がれる。言い換えると、そのコードを最初に書いた人々と、いまそれを保守している人々は、同じではない。それどころか、間に何世代もの開発者が挟まっているかも知れない。したがって現在の保守担当者には、なぜコードが、そのような仕組みになっているのかを知るすべがなく、しばしば、それを書いた人々の意図と、設計上の暗黙の想定とを、推理する必要に迫られる。

クリス・バーチャル. レガシーソフトウェア改善ガイド (Japanese Edition) . 翔泳社.

私はキャリアの中で（とくに前半）いくつかのレガシープロジェクトに関わったことがあります。そのほとんどが、自動テストがない、コードが読みにくい、ドキュメントもない、の三拍子揃っているのが特徴で、下手に変更を加えると予期せぬところでエラーが出る、みたいなことが日常的に起こります。もちろん、レガシープロジェクトであっても、品質が高く、生産性もそれほど悪くない、みたいなケースもあるかと思いますが、少なくとも自分の経験ではそういうケースはありませんでした。

最近ではスタートアップに関わることが多いですが、意外と最初からテストコードがあり、ドキュメントも必要最低限書かれているような、優良なチームと関わることが多いです。全体的にそうなのか自分の関わるところがたまたまそうなのかは分かりませんが、最近の若者はしっかりしてんなーと思います。

なので、これは多分に偏見を含むと思いますが、（自分が50代なのを棚に上げて）比較的年齢が上の人たちのほうが、レガシーコードを生みがちであるなぁという印象を持っています。こと PHP に関しては、言語やフレームワークの進化についていけず、昔ながらのやり方を変えずに不具合を量産しているベテランが多い印象もあります。

これまでレガシーコードに出会ったときにどうしてきたか

典型的かつ極端な例として、とあるプロジェクトでの経験を元に、レガシーコードに対してどう対処したか、その結果どうなったか、というのを紹介します。

上手くいったケース：文化的に理解があり影響範囲が限定的かつコントロール可能なケース

1つ目は、文化的に理解があり影響範囲が限定的かつコントロール可能なケースです。ほとんどの仕事は途中から参画しますが、既存プロジェクトであっても新規の機能開発だったり、既存の機能の拡張であったり、なにをやるかはまちまちです。新規の機能開発の場合はわりとやりやすくて、自動テストがない場合はテスティングフレームワークの導入からやり、その機能に対して最初からテストコードが書けます。しかし、まずは自動テストを書くことを許可してもらう必要があるので、現場の社風だったり、マネジャーの価値観だったりによって、すんなり認めてもらえるか説得不可能かが決まります。数年前から自動テストのない現場の仕事は請けないようにしているので、最近は自動テストが存在しないプロダクトには関わっていませんが、昔は自動テストが書かれているプロダクトなんてほとんどなかったので、自分で導入するしかなかったケースもありました。環境さえ整えば、それに乗っかってテストを書く人も現れます（現れることもあります）。

上手くいったケースでは、テストを導入してくれて助かった、とか、あとから引き継いだ人に nunulk さんのコードはテストもあるし手を加えるのが楽だった、とか、感謝してもらえることもあります。

上手くやるには大前提として、マネジャーやチームからテスティングフレームワークの導入を歓迎される必要があります。自動テストを書いたことがないメンバーには、どうすればテスタブルなコードが書けるか書き方の手本を見せてやる必要があります。

最初からぜんぶのテストコードを書くのではなく、徐々に増やしていく地道な作業になります。機能の重要度やロジックの複雑度などによって優先順位をつけ、メンバー全員で（少なくとも何人かは）力を合わせて取り組む必要があります。一人でやっても自分の書いたコードの品質は上がりますが、プロダクト全体からみると一部にしかなりません。

上手くいかなかったケース：チームの中に導入したい人はいるが、難易度が高すぎるケース

私はここ数年は Laravel の仕事しかしないようにしていますが、その理由の1つとして、テストが書きやすいというのがあります。詳しくは省きますが、Laravel が PHPUnit を拡張し、テストコードが書きやすいように手を加えているのです。

大規模なレガシープロジェクトでも、自動テストを部分的に導入することは可能ですが、使っているフレームワークによっては、ほとんどテストが書けない場合があります（ありました）。

その現場ではとある古いフレームワーク（バージョン 0.x でα版でした）を何年も使っていて、フレームワーク自体が自動テストのことをまったく考慮しておらず、基盤を作るところから始めなければなりませんでした。また、アプリケーションもコピペが蔓延していたり、静的メソッドが大量にある巨大なクラスがあったり、テスタブルでない構成になっていて、リファクタリングしないとテストが書けない、テストがないとリファクタリングできない、というウロボロス状態でした。

マネジャーもどちらかというとテストコード書くくらいならプロダクションコードを書いてくれ、という感じの人だったので、けっきょく当時の自分のスキルでは難易度が高すぎて断念してしまいました。

メンバーと話すと、何人かは自動テストほしいですねぇという人はいたんですが、やはり同じように難しさを感じていたり、いままでこうやってきたから、みたいな諦観があったりしたように思います。

これがけっこう曲者で、信念を持って自動テストは要らない！という人に対しては、あ、そうですか、ではさようなら、で済むんですが、テストほしいですねぇ（だがやらない/できない）という人に対しては、書けるようになってほしい、という思いが出てきてしまいます。そこが自分の良くないところではあるなぁと思うんですが、けっきょくのところ、ほしいですねぇで止まってしまう人というのはそこまで欲してないわけで（欲していればやりますよね？）、他人にレールを引いてもらわなければやらない人に対して、お節介を焼くのはどうなんだ？っていう思いもあります。

これからレガシーコードに出会ったときにどうしていきたいか

これを言うと身も蓋もないんですが、まずは出会わないようにすることが第一だと思っています。テストがないのが当たり前、の世界観で長く働いてきたマネジャーやメンバーに対して自動テスト導入の心理的ハードルは非常に高いと感じます。いい悪いの話ではなくて、常識が違いすぎるのです。

相手の価値観を変える労力を考えると（しかもそれは本質的に必要な労力ではないと思いますし）価値観が一致するチームで働くのが楽です。いままでもそうですが、事前の面談で必ず自動テストはありますか？と聞き、ない場合は基本的にお断りするようにしていきます。

とはいえ、事情によりレガシーコードの面倒を見ることになることもなくはないと思うので、そうなったときにどう振る舞うべきか、というのは考えておく必要があると思います。

少なくとも、責任者にテスティングフレームワークの導入自体は認めてもらいたい、そこを最低限確保できないならどんなしがらみや報酬があっても断る、というのを原則にして、自分自身はテストコードを書く、他のメンバーには強制しない、書きたい人には教える、というスタンスでいこうと思います（いままでとほぼ変わらないですが）。

プロダクトの内部品質については、マネジャーの意向が大きく反映されますがそれがすべてではなく、チーム全体のマインドセットやスキルセットが大きく関わります。スキルは伸ばせばいいだけですが、マインドを変えるのは（相対的に）難しく、それは経験のある人ほど難しいのではないかと思います（統計的にどうなのかはわかりませんが、体感的に）。

大事なことなので二度書きますが、いい悪いの問題ではなく価値観の違いの問題だと捉えたいのです。

自分が正義だと考えてしまうと、テストコードを書かない人が悪になってしまい、悪を滅ぼすことが目的になってしまいます。ですが、たとえ不具合だらけであってもレガシーコードがサービスを動かし、会社に売上をもたらしていることは事実であり、その事実こそが正義だと思うのです。どんなコードであれ、世の中に価値を提供できるコードが善である、という前提は忘れないでおきたいし、仮に「エンジニアが音信不通になっちゃって…」みたいなケースであっても（実際ありました）、どの方角かはわかりませんが、前任者に向かって手を合わせたい、という気持ちはあります（実際にはしませんが）。

既存のコードをリスペクトするっていうのは大前提ですが、それはそれとして、自分のあとを引き継ぐまだ見ぬ人たちに対しては、少しでも「保守または拡張が困難な」部分を減らしたい、関わるプロダクトに対しては、市場の変化に迅速に追従できるような柔軟なソフトウェアにしたい、という思いは持ち続けたいです。

「諦めたらそこで試合終了ですよ」っていう安西先生の名言（スラムダンクは読んだことありませんが）を忘れずに、ホイッスルが鳴るその瞬間までベストを尽くしていく所存です。

おわりに

他人のマインドを変える労力は本質的に必要なものではなく、相手がベテランであればあるほど難しい、このことを踏まえると、相手の価値観は尊重し、業務委託である自分はプロダクト全体の品質向上に対する責任はないので、自身の仕事を全うすることに注力したほうがいい、という結論に自ずとなる気がします（なりました）。私の長所でもあり短所でもあるのですが、プロダクトやチームに対する熱量が高いために、ときに自分の責務を越えて手や口を出してしまう傾向があって、それが良い結果になることもあれば悪い結果になることもあるんですが、自分も相当なベテランなので、その辺もうちょっとうまくやればいいのに、とことあるごとに思います。

まだ精進が足りないですね。

いつもありがとう misskey.dev

はじめに

この記事について

misskey.dev ユーザー Advent Calendar 2023 の1日目の記事です。

https://misskey.dev/

X（旧 Twitter）の使用頻度がだんだん下がってきて、Nostr とか Bluesky とか Mastodon とか色々試した結果、Vivaldi Social に落ち着いてたんですが（自分が Vivaldi ユーザーであることもあり）、そこもだんだん投稿頻度が下がってきて、どうしよっかなーと思ったところに今年出会ったのが misskey.dev でした。

というわけで、今年はありがとう misskey.dev、そしてまた来年も、という願いを書き残しておこうと思います。

Misskey への挑戦

色々 SNS（ActivityPub 互換がよかった）を探してる中で、自分で misskey インスタンス建てようと思ってトライしてみたんですが、EC2 の t2.micro あたりだとぜんぜんスペックが足りなくて、一向にビルドが終わらなかったので諦めました。

なぜ misskey.dev を選んだか

• 人がそんなに多くない
• 同じ属性のユーザーがいる
• 絵文字リアクションが激しくない
• 月額利用料が払える

あたりが選んだ理由です。

Vivaldi Social もそんなに人が多くなかったんですが、同じ属性のユーザーがあまりいなかったので（Vivaldi ユーザーというのはあったけど、そんなに頻繁に話題にできる属性ではないので）。

misskey.io みたいな絵文字リアクションの激しいところは文化的に合わないなと思って避けました。

いちおう Premium 会員みたいなのがあって（特典とかはわからない笑）、月額で会費を払ってます。

個人がボランティアでサーバー管理をやられていて、ときどき（しょっちゅうか）深夜メンテナンスやってたりするので、少しでもモチベーションの足しになればいいんですが。

引き続きよろしくお願いします。

選んだ理由は上に書いた4つが主ですが、続いてるのはやっぱりそこにいる人たちがいい人が多いっていうのはあって、けんかしないし、ネガティブなことばっか書く人もいないし、たまに猫の画像流れてくるし、趣味や仕事ばんがってるなーというポストが多くて励まされるし、居心地いいです。この場を借りて皆さんにも感謝を。

使い方（現在と未来）

趣味でプログラミングをしているので、やっぱり API 使えるのがいいですね。週に2回ランニングしてるんですが、その際に Fitbit から取得した心拍数とか位置情報とかのデータを集計して Misskey にポストするのをやっていて、人が少ないのもあって、ハッシュタグには自分のポストしかほぼないので、前回の記録との比較とかやりやすくて助かってます。

SNS に仕事の愚痴はなるべく書かないようにしたいと思いつつ（業務委託が多いのでなおさら）ついつい書いちゃうのは反省してて、過激なのは出してない（はず）ですが、もうちょっと自制しないとな、とは思ってます。

議論も、あんまりしたくないのでなるべくしないようにはしてるんですが（自分はこう思うと1回書くだけに留めたい）、気になるネタが投稿されるとつい反応しちゃうことがあるので、それも気をつけたい。

おわりに

今年はありがとう misskey.dev、そしてまた来年もよろしくお願いします。

（とくに管理者の方、改めていつも本当にありがとうございます。）

いちおう自分のアカウント載せておきます。

フォロー・ブロックはお気軽に！ misskey.dev

反応しない練習　あらゆる悩みが消えていくブッダの超・合理的な「考え方」