Let's write β

プログラミング中にできたことか、思ったこととか

2022年 棚おろし

例年書いている、一年間の棚おろし記事です。後から見かえしたときに自分で振り返る事ができるようにメモ

去年のもの:

tech-blog.pocket7878.com

チーム関連の棚おろし

DDDを中心としたアーキテクチャへの移行

love-from.azit.co.jp

配送業務というドメインを扱うなかで、1つのプロダクト内に領域によって同じ言葉であってもまったく異なる価値観やとりあつかいをする必要がある 別々のコンテキストが同居する大きなアプリケーションになっていったため、シンプルなMVCアーキテクチャで進めていくなかで扱うのが困難になった事もあり DDDを中心としたアーキテクチャへ移行する事にし、推進してくれるメンバーを採用し勉強会などをしながら皆で導入をすすめています。

メンバーが書いてくださった記事:

qiita.com qiita.com

私はPdMに注力してプロダクト開発をすすめる(年の後半)

年の後半に正社員のバックエンドのメンバーがジョインしてくださった事で、2021年の頃のフルタイムの開発に自分が注力する必要がある状況が変化しました。 そのため、僕はメンバーがパフォーマンスを発揮できるように支援すると共に、直接コードを書いて「機能を実現する」役割から「どんなものをつくるかを決める」役割にシフトしました。 ここ数年を鑑みても組織の成熟度があがり「やる事になった事を実行する」のは十分にできるようになってきた実感があったので より事業としての確度を上げるためには「何をやるのか」の検討の方に自分はコミットした方が良いと考え今はそのような役割に重心を置いています。

「やる事」だけではなく「やらないこと」「やめること」も決める

やる事を決めるだけではなく、将来のプロダクトの拡張を考慮した時に仕様的や保守の面で負債になりそうな機能があり 実際の利用率やその仕様や機能を廃止する事で将来のプロダクト拡張にたいしてどういう影響があるのかなどを検討していくつかの機能を廃止したりしました。

「実例マッピング」を通して現場からのフィードバックを貰う

また、ビジネス的な要求だけではなく実際に画面を操作するユーザーへの解像度が高いオペレーションのチームからの目線で 既存のユーザーにたいして影響がないかであったり、現場のオペで発生するエッジケースなどで解決不能な状態にならないかなどをPdM一人で想像しながら完璧な要件をつくりあげるというのは困難なため オペレーションチームからのフィードバックを得られるようにしたく、pmconf2022で発表されていた「実例マッピング」をオペレーションチームと実施し、 イレギュラーケースなどについてや、特定の状況でプロダクトとしてどのような挙動が必要とされているかなどを拾いあげる試みをしました。

speakerdeck.com

PdMとしては要件をまとめるにあたり、抽象度の高い機能や価値の観点で考えてしまいがちな事が多く、論理的に一つ一つの機能の境界やステップを決めようとしていきますが そのような抽象的で論理の話だけをすすめてもなかなか現場で発生するイレギュラーなケースは避けられないケースなどについてフィードバックを貰うのは難しいと感じていましたが 実例マッピングをとおしてオペレーションの現場から「具体的な事象にたいする」質問を上げてもらう事でオペレーションの現場のメンバー側で抽象的な質問にまとめてもらうハードルを無くす(減らす)事で 質問やフィードバックが出てきやすくなり、それを通して改善点を発見しやすい良いイベントだと感じています。

PRDとDesignDocを分離し、モブ設計を実施した

PdMとして要求分析を実施しそれを開発メンバーに伝達して実現していくというフローの中で、 数ヶ月程度の開発期間を必要とするような大規模かつ既存のモデリングを大幅に変更する必要があるような機能の場合は そもそもの要件の認識をきちんと揃える必要があります。 また、大規模な機能を分担して開発しつつ相互にレビューをするような関係を安定して構築するためには 箱をあけてみたら設計方針に大きなフィードバックが入ってしまったり、全体像を誰も把握しないままにパーツだけのPRをレビューするのも困難です。

大きな機能の認識を揃えるには、 文書だけで単純に伝達をすることは難しく相互のコミュニケーションを通して互いの頭の中に描いているものが同じものかどうかを確認しあう必要があります。 始めは、事前設計的に概念設計やクラス設計、メソッドのシグネチャの設計等を実施してみましたが、 かけた時間にたいして実装してみてわかる発見を得られるタイミングが遅れるなどリターンとしては悪く、 コードの事前設計を目的とせず仕様や実装の大方針の認識齟齬を減らす事を目的して適切な度合いを模索するなかで皆で通話をつなぎなら1~2時間程度で開発チームで協力してDesign Docを作成するイベントを実施しました。 イベントを通してユースケース毎の受け入れ条件やモデリングの図や疑似コードなどを書きながら期待されている挙動や責務の齟齬がないかを確認していく事で大きな認識齟齬を避けながら安定して実装に入れるようになったと感じています。

そのようにDesign Docを作成するようになり、従来のPRDの各ユースケースのセクションに直接実装方針などを記載する方式では文書全体が煩雑になってしまいました。 PdMとしてはPRDはステークホルダーと対話しながら端的にユーザー目線でどういう価値を得るためにどういう挙動を期待しているかを書きたいのに対して、 DesignDocと一体化してしまうと文書全体の比率としては具体的なコードの分量が増えていき、文書として後から見かえした時に内容が掴めないような文書になってしまうため、PRDとリンクしたDesign Docと2つの文書に分けて管理するように変更しました。

個人のふりかえり

都内から引っ越した

昨年末から今年の頭にかけて都内からすこし遠方に引っ越しました。 フルリモートになりオフィスに行く事ももともとほぼ無かったので、 より生活環境を改善する方向に投資したほうがパフォーマンスも出るという事で都内からすこし離れた、作業部屋と寝室などを分けられるサイズの部屋に転居しました。

CTO Night 2022に参加した

aws.amazon.com

CTO Night 2022に参加し長崎でCTOの方々と交流してきました。 様々なセッションを通して学びを得たり、自分の今かかえている悩みについて相談させていただいたり非常に良い場でした。

趣味の写真も会場付近で撮っていました

no-logic.hatenablog.jp

no-logic.hatenablog.jp

O'Reilly Online Learningに加入した

円安の影響もあって色々なサービスが値上りしていますが、オライリーのオンラインのサブスクに再契約しました。 月7000円は高いなと最初おもっていましたが、 - 月にその分だけの技術書を「読みきるのか」 という問いとに比較対象にすると、毎月コンスタントにそれほど読みきれる事はないですが - 月にその分だけの技術書を「中身の一部(究極1ページ)だけでも目にするのか」 の問いにしたら全然ペイ事に気がついたので解消しました。

購入してみたけど自分にはタイミングや内容的に合わない本にあたる可能性を考えて購入に慎重になって良い本にあたる率を下げてしまうことが避けられ、 一部の章にだけ興味がある本にもアクセスしやすいって考えると全然数十冊の規模で月にペラペラ見るわけでペイしているとおもいます。 以前契約していた時にくらべてオライリージャパンの本もそれなりに入っているのでありがたいので、それがもっとどういう基準で入るのかはいらないのか明確になるとより有り難いです。 また、自動変換の関係なのか固定レイアウト形式のままHTMLに移植されているような表示になってしまっている本もあったので、そのあたりも改善されてくるとより便利になりそうです。

vec-reg

RustでVecにたいして関数をつかって正規表現風にマッチができるライブラリをつくりました

zenn.dev

お遊びですがPikeVMについて勉強したり、Rustのマクロの勉強になったりしました

37.5inchのウルトラワイドモニターを買った

作業環境の改善の一貫でウルトラワイドモニターをAmazonのセールで購入しました。 4Kのモニターとも迷いましたが、自分の作業としては複数の文書を開きながら作業したり、オンラインのビデオミーティングをしながら議事録をまとめたりする機会も増えてきたので 解像度よりも作業スペースのサイズを確保したいとおもい37.5inchのワイドモニターを選択しました。

作業部屋の改善のために他に買ったもの

タイムタイマー

写真ではデジタルのタイマーが写っていますが、シンプルなものに切りかえようとおもいタイムタイマーを購入しました

デジタル時計

現在時刻をパっと見られるように見やすいデジタル時計を購入しました。 デジタル時計は角度によっては見えづらい時計が多い中、 このモデルはACアダプターで給電する事もあり明暗がはっきりしており、席にすわった時の角度でもハッキリと見やすいです。

AirPods Pro

初期モデルのAirPods Proに飛びついていた加減で半年毎に片耳ずつ故障する体験があったので イマイチなイメージがあってここ数年避けていたのですが、久々にメンバーに聴いてみたら現在のラインでは改善されているという事を聴いて購入しました。

有線イヤホン

スプラ3をやる事が増えてきたので、多少遮音性があって定位感のあるイヤホンを買おうかなとおもい 本格的なヘッドホンはヘッドホンで首や顎関節が痛くなる事が多いのでイヤホンを選びたく、 髪が長く眼鏡を掛けているので耳に掛けるタイプのイヤホンは耳の上部に負担がかかって痛くなったり痒みが生じたり取り回しに苦労する事が多かったので 以下のイヤホンを購入してみました

オーディオスイッチャー

イヤホンを買ったのでスピーカーとイヤホンをサっと切りかえたり音量調節をしやすいようにオーディオスイッチャーを買ってみました