Small Changes

週刊ニュース Lv6（2022年12月17日～2022年12月23日）

Metadata

もうすごく年末な感じが漂ってきましたね。

今週も振り返っていきます。

12月17日(土)

Go 1.18では、go getはパッケージをビルドしなくなった

  • https://go.dev/doc/go-get-install-deprecation

  • Goにはgo getとgo installというコマンドがありますが、今は過渡期で色々動きがあるみたいです。こういう公式のソースがあるのは助かります。最新バージョンではどう使うのかについては「初めてのGo言語」の9章に詳しく書いてあるので触りながら理解していこうと思います。

新しい人にこそどんどん変化を生んで改善しやすい状態を作りたい

  • 今いる会社は「やってみる」が文化の会社です。やってみるという考えが土台にあるので変化を受け入れるスピードが早くと柔軟な会社だなと日々感じます。

  • その変化を生み出すのは一番誰だろうと考えてみると、新しく入った人だと思っています。とはいえ、今までの経験上自分が新人だったときに変えたいと思った時に中々変えることが難しかったり、会社が大きくなりすぎてガチガチの承認が通らないと変えられないみたいなジレンマがありました。

  • 今の会社は変化に柔軟で変わっていける土台があると思っているので、だからこそそういった経験がある自分が変化させすいような土台を作っていかなければと考えています。

  • 変化を起こすためには、現状を正しく理解できる環境作りが必要です。まずはデータベース設計と同じように「One Fact in One Place」という、1つの事実は1つの場所にのみ存在するというのをドキュメントで徹底していこうと思っています。

12月18日(日)

useOutletContextのバグに遭遇しました

  • ルーティングは/と/users/loginがあるとき。/も/users/loginも同じLoginコンポーネントを使っています。

    • export const Routes = [
  { path: '/', element: <Login /> },
  {
    path: '/users',
    element: <User />,
    children: [
      { path: 'login', element: <Login /> },
    ],
  },
]

  • このときに、/でアクセスしたときだけ次のようなエラーが出ました。

    • Uncaught TypeError: Cannot destructure property 'setHeaderTitle' of 'useOutletContext(...)' as it is null

  • /usersでは<Outlet>を使ってコンテキストをセットしていますが、/だと親ルートに何もいなくてコンテキストを取得するコードで失敗していたのが原因でした。

  • あまりフロントは得意じゃないですが調べてみるとuseOutletContextの仕組みが知れて面白かったです。

12月19日(月)

Goで小さいアウトプットをしました

手法はカルチャーであるという記事を書きました

  • そのうちdiddyworksのdiddy Magであがると思います。

12月20日(火)

ルールの改定とその検知ができる組織にする

  • 周知の仕方ひとつをとってもSlackに流すというだけだと流れていく。そして、組織が大きくなっていくとそれぞれの部署がそれぞれの中でルールの改定を行っていて経緯などを知りたいとなるとさらに難しい。やり方は何でもよいが、ルールの改定を行っているというのがまず見えるというのが大事だし、そこにたどり着けて誰でも見えるし議論に入れるのが重要だと思いました。組織に壁はないほうがスケールします。きっと。

12月21日(水)

決済機能がプロダクトに入る

  • 今プロダクトはまだ形になる途中で、決済など含めてプロダクトで対応できない箇所は人の手で行っています。これでは価値を届ける人が増えてくると、その対応で一杯一杯になってしまうためスケールするのが難しいです。多くの人に使ってもらうためにも決済機能が必要ということで早い段階で入れることが決まりました。

  • 決済機能に関してはStripeを使うみたいですが、全く未知の領域ですがとても楽しみです。

変化に強いチームと感じた

  • 先週同期ポイントと非同期ポイントをうまく使い分けをしようと提案したところ、早速全体定例では共有に留めて時間がかかりそうな質問への回答部分についてはNotionのDBに記載しておいて、あとで非同期で回答をするという取り組みを始めたのですが早速実践していてこのチームは変化に強いと感じることがありました。

12月22日(木)

もぐら叩き状態になってくると辛い

  • 長いプロダクトだとあるあるかもしれないですが、色んなところに共通化されないままのコードが散らばっていて修正するときに漏れないように色々なファイルを見に行かないといけないなどつらいですよね。

  • 今までお金を稼いでくれたコードに感謝しつつ、共通化できるところは、最初に実装する人が強い気持ちを持って共通化しようと思いました。

12月23日(金)

業務フロー図があると俯瞰的にキャッチアップできる

  • 業務フロー図がないと困る場面が多々あります。

    • ある程度規模の大きいプロダクトになり、影響範囲が多い場合に業務フロー図がなく影響してそうな箇所のコードを片っ端から追う場面

    • DBの変更を入れる際にテーブルがどの業務で使われているかを調べるときに業務フロー図がなくコードを片っ端から追う場面

    • プロジェクトに入ったときに、Aという業務に依存するBという業務の実装をする際に流れがコードを読まないとわからない場面

  • これはあくまでも例ですが、他にも業務フローが欲しい場面は結構あります。そして、こういう文化がない組織に途中から業務フロー図書くフローを入れようとしてもなかなか理解してもらえず導入自体が難しい気がします。

  • 自社では業務フロー図がないため、今の小さいプロダクトの段階でも全体像から詳細の業務を理解するのに仕様書を読み込む必要がありました。

  • 一般的な業務フロー図とは違った形で画面と操作という切り口で欲しい情報と共通認識を得られる粒度で業務フロー図を短時間で作っていただきました。（短時間で作れる粒度というのがポイントだと思ってます）

  • 業務フロー図があることで、全体像→業務フロー図→詳細の仕様書を読むという流れが自然にできそうでとても良さそうです。発案した本人なのでどういう場面で活用できたかなどは積極的に発信していこうと思います。

見積もりについていま時点の自分の考えを整理してみました。

  • 見積もりを無意識に機械的にやるようになると本質を見失う

    • アトミックノート

      • 見積もりを入力にする仕事(例えば、営業側への影響など、リリースの影響など)もあるが、見積もりは見積もりであってそれ以上ではないということに注意しなければならない。

      • なぜなら、ソフトウェア開発はサービスの提供と似ているため顧客の期待は動的に変わるからである。そして、タスク単位でみれば良構造(正解がある程度わかっている)もあれば、悪構造(正解が決まっていない問題)もある。

      • 良構造と悪構造の両方があるのに、他のプラクティスを参考に見積もりを機械的にやりだすとどこかに軋轢が生まれると考える。そのため、見積もりはあくまでも見積もりという共通認識を確立しながら、それよりも実際に着手しながら実測値、進捗を見ながらインクリメンタルに見積もるのが良いのではと思う。

      • とくに、作業に着手してフィードバックを統合するタイミングがあるのは大事で、共通認識を揃えやすく、次の到達ポイントへの非同期での作業を加速させてくれる。

References