パルカワ2

最近はFlutterをやっています

EM終了!

3年ほどエンジニアリングマネージャーとして活動してきたが、自分がEMのチームと別のチームが合体し、そのチームのEMは別の人に任せることになったのでエンジニアリングマネージャーではなくなった。

自分が直近興味を持ってる労働のテーマが比較的マネジメント寄りのテーマだったのでどうしたもんかという感じだけど、自分が手を動かすことで解決する領域はあるしそこで得た知見を広げることはそこそこテーマに沿う活動かなと思うので、最近はいろんな実装を書き直したりDesign Docを書いたり資料を作ったりしています。

X-E5買った

買おうかな!うーん!やっぱ買わない!!と決めたはずが、触ったら欲しくなってしまい買ってしまった。散歩がかなり捗るようになった。冬はパジャマの上に羽織るだけで散歩に出れて便利

FUJI X Weeklyにある設定にするとバッキバキの写真になったりしておもしろい。

Design Docは読み手のことを考えて書く

最近Design Docを書いている。25年の6月にDesign Docのフォーマットを本部で見直してチームとしてもここに書きまくろう!と決めたのだが、そこから我々のチームだけで6ヶ月くらいで50本くらい書いている*1

そうしてDesign Docを書いたり読んだりしていて、Design Docは読み手のことを考えて書く必要があるなと思うようになった。

  • 結論は極力短くする
  • 結論は早めに見せる
  • 1つのDesign Docに1つのことを書く。多くなりそうだったら分割する
  • 調査のときに書いたメモはDesign Docからリンクするようにして、Design Doc自体には書かない
  • AIは書きまくるので、そのままコピペせずに必要な情報だけに添削する
  • 書き手向けのテンプレート文言は消す
  • 自分で「何も知らないフリ」をしながら読み返して添削する

まとめ

ドキュメントを書くのは、コードを書くのと同じだよね〜という話を同僚としていた。自分も完全に出来ている気はしないが気を付けてやりたいねという感じもコードと一緒ですね。

*1:とはいえ書いてる途中のものも多くある

画面のWidgetテストはなにをテストするべきか

最近はよくWidgetテストを書いている。Presentational Widget と Container Widgetに分けていて、Presentational Widgetは、Riverpodなどに依存せず、見た目のことにだけ集中出来て大変よい。テストも見た目のテストのことだけに集中できる。

zenn.dev

Container WidgetがPresentational Widgetを使うという関係性なのだが、Container WidgetのテストではPresentational Widgetでテストしたことはテストしない。小さくテスト出来るのであれば、Presentational Widget側でテストするべきだと思う。

一方で、Widgetは他のWidgetの影響を受けやすいように感じる。例えば、状態AのときにBとCの項目が表示されていて、状態Dのときは表示されていないとか。1つのWidgetで完結していればいいが、離れている場所にあるとかだと難しい。そのときはうまく連携しているのかのテストを書く。Presentational Widgetに変更が入るとContainer Widgetのテストもコケて正直めんどいが、変更が入ったことに気づけてどのように変化するのか見れるのは良いことだと思う。

加えて、妙に長いテキストが入ったときとか文字サイズが変わったときとか、Widget同士で干渉してRenderFlex Overflowが起きないかというのは見たいように思える。Presentational Widgetごとに確認しても、結局他Widgetとの関係が影響するように思うので、広めで見てもいいように思える。

このあたりはGolden testである必要はなく、ランダムの値を使ってProperty based testingのようにテストするというのも出来て面白いかもしれない。

衝動を育む場

孤独に生きよを読んで、岡本太郎の自分の中に孤独を抱けを思い出したので読み返していた。別に孤独に悩んでいるわけではないです。

全体的に"挑め!!!戦え!!!考えよ!!!"という話だと自分は理解したのだが、衝動の話が面白かった。太郎いわく衝動という内側から湧き上がる根源的なエネルギーは誰しもが持っていて、生きがいをもたらす原動力らしい。

 「創造すること」は人間の本能的な衝動だ。

岡本 太郎. 自分の中に孤独を抱け (p. 121). (Function). Kindle Edition. 
 〝描きたい〟というのはつまり、なにか外のものではなく、内にあるものを溢れ出させたい、表現したいという衝動のはずだ。

岡本 太郎. 自分の中に孤独を抱け (p. 122). (Function). Kindle Edition. 

仕事においてもこういう表現したい衝動はある気がしていて、自己形成やキャリア形成で話される「こういう人間になりたい」「こういうことをテーマとしてやりたい」は言い換えると「こういう表現が出来るようになりたい」といえる気がする。

例えば自分は数年前は「変化につよいエンジニアになりたい」がソフトウェアエンジニアとしてのテーマだったわけですが、それに対する衝動はあってそうなるために色々挑戦してきたし、それが支援されていたように思う。今は別のテーマを持っていて活動しているのだが、やることが変わるのでテーマも変わるかもしれない。

この衝動が減退している状態が、孤独に生きよなどで語られる思考停止状態なのではないかと思った。

みんなで衝動を育む

衝動が減退することあるよなぁ!と思っていて調べたら、問いかけの作法に「衝動の枯渇」という定義があった。衝動が枯渇しているときは、思考停止するという話。読んだときにも言及していた。

このように「逸脱の抑止」は、チームメンバーの内発的な動機を阻害する「衝動の枯渇」という現代病を生み出します。衝動とは、人の内側から湧き上がる欲求のことで、子どもの頃から誰しもが持っている本能的な感覚です。ところが、規範から逸脱することを恐れ、関係性が凝り固まったままでは、それが主体的な行動や発想のストッパーとして働き、本来あるはずの衝動に「蓋」がされた状態になります。

安斎勇樹. 問いかけの作法 チームの魅力と才能を引き出す技術【DL特典付き(未収録原稿)】 (p. 54). (Function). Kindle Edition. 

枯渇まではいかなくても減退することは「逸脱の抑止」以外にもあるように思える。

  • 取り掛かりたいテーマが巨大すぎて一人ではどうにかするには大変すぎるが時間もないし周りからの支援がない
  • 取り掛かりたいテーマを見つけて、直すように周りに提言をしたが、周りが「言い出しっぺだからやってよ」と言ってきて、全部やることになるのが続いている
  • 諦める理由が大量にあり、諦めることが常態化している
  • そもそも取り掛かりたいテーマがわからない

これ以外にも子どもが生まれたとか介護が始まったとかの変化によって集中したいものが変わることもあるとは思うし、どうにか出来ることとどうにも出来ないことはあるだろうが組織による支援によってみんなで衝動は育むことも減退させることも出来るんじゃないかと思える。

ここまで書いて気付いたが、衝動を育むにはどうすればいいかは、内発的動機づけでめちゃくちゃ語られているような気がするし、衝動と内発的動機は一緒じゃんってかなり今更気づいた。

人はなぜ働くかでいえば「お金」と「自己形成」のためでしかないと自分は思っていて、自分は比較的お金の優先順位は低いほうなので、自分にとっては職場がみんなで衝動を育む場であることがかなり重要だなと思った。

孤独に生きよを読んだ

「奴隷になるな」というのがこの本のパンチラインだと自分は思っていて、ここでの"奴隷"とは外圧によって思考停止に立たされた人を指している。この本に書かれているのは、その奴隷にならないために、思考し続けなさいという話であると自分は理解した。

人間同士だからそういう食い違いは日常茶飯事のはずですが、では実際に疑問を相手に伝えているかといえば、多くの場合は伝えていない。実害があるわけではないし、それはそれでそこそこやっていけているから、なんとなく黙したままで済ませてしまっている。  こうした状態も思考停止ですから、奴隷だと言えます。

田中慎弥. 孤独に生きよ 逃げるが勝ちの思考 増補改訂版・孤独論 (p. 15). (Function). Kindle Edition.

孤独に生きよでは、内容を理解できなくてもいいから本を読むことが思考することになり奴隷から脱出できる方法であると書かれている。

本を読まなくても生きてはいけます。本を読まないからといって飢えるわけでも、病気になるわけでもない。  それでもわたしは、読書を強く勧めます。  いまあなたを取り巻く環境とまったく異なる世界が、この世のどこかに間違いなく存在するという実感を書物はもたらしてくれます。読書を通してあなたはいろいろな人生を体験することができる。

田中慎弥. 孤独に生きよ 逃げるが勝ちの思考 増補改訂版・孤独論 (p. 73). (Function). Kindle Edition.

これは、結構人それぞれ方法があるんじゃないかと思っていて、自分の場合は読書もそうなんだけど、最近だと山に登っている間に「山登りはプロダクト開発と同じだ…」と類推したり、早朝の新幹線の中で「怠惰であれ!」と書いたりする時間も本を読むことと同じように思考する時間だと思える。

少なくとも自分は、20代と比べると本を読む時間がかなり減っている。これは、環境による衝動の減少や思考停止して見れるエンタメに触れる機会が多くなったからだと思うのだが、あえてそこから離れて孤独になる時間、思考する時間を取るようにするというのは、生きていくうえで非常に重要なのだろうと思う。

一方で、独りで思考するだけではなく、他の人と考えたことを共有することで自分だけでは発見出来なかったことが発見出来るとも思っていて、1 on 1とかでこういう本を読んでこういうことを考えてるんですよねから色々話がつながって自分では発見出来なかったことが見つかったりするので、孤独時々対話くらいがちょうどいいのかもしれないと思った。

返済しやすい技術的負債

技術的負債について自分が考えたことをメモする。

意図的な技術的負債と不注意な技術的負債

  • 技術的負債を負うとき、意図的に負うか不注意で負うかがある。いわゆる、技術的負債の4象限
  • 「期日があるから負債を負うが、改めてあとで直しましょう」で生まれた負債と「何も考えずに実装しました」で生まれた負債は全く異なる

開発中、技術的負債を意図的に負うかどうかの判断力は人やチームによって異なる

  • 意図的に負債を負うか判断する力を持っているかは、人やチームによって異なりそう
  • 意図的に負債を負うか判断する力は、経験と内省で得る再現性が高い能力な気がする。少し前に技術力とはなにかで話した訂正しやすくつくる力の一部だと自分は思う
  • とはいえ、能力の問題だけではなく期日に追われていて正しい判断ができる状態になかったなど組織的な問題もあるはず。個人だけのせいではない。

意図的な技術的負債と不注意な技術的負債の違いは、返済しやすく出来るか

  • 意図的な技術的負債は、返済することを前提に出来るのでコードやGitHubのプルリクエストにコメントを残したり、テストを書いておくなど後々返済しやすいようにするための活動ができる
  • 不注意な技術的負債は、そもそも負債だと気づいていないのでそういう活動は一切ない。なので、コードを読んで直すしかない。どんなにコードを読み書き出来ようが所詮人間なので読み間違えたりするとバグが起きる。なので、かなり気をつけて作り直したりする必要があってコストが大きくかかり返済がしにくい

返済しにくい意図的な技術的負債もある

  • 意図的に技術的負債を積んだからといって、自動的に返済しやすくなるわけではない
  • 返済しやすいように活動する必要はあり、それが出来るかは人やチームによって異なる
  • これもやれるかどうかは、経験と内省で得る再現性が高い能力な気がする。これも訂正しやすくつくる力の一部だと自分は思う

技術的負債を作る人間と返す人間が別だと良いことがない

  • 他人の借金をずっと返していると「なぜ私が返しているのか?」となる。技術的負債も同じで、技術的負債を作る人と返す人が別だと技術的負債を返す人は「なぜ私が…」となる気はする。
  • 「仕事だから」で片付けられる人も片付けられない人もいる。人間だもの。
  • また、技術的な負債を作る人も返すことがないので、経験と内省ができず、訂正しやすくつくる力を身に付けられない

まとめ

  • 意図的に負債を負うか判断していくぞ
  • 意図的に負債を負うときは返済しやすいようにコメントやテストなりを書いていくぞ
  • 負債を作ったら返すぞ