週刊ニュース Lv4（2022年12月3日～2022年12月9日）

今週も仕事がんばりました～。年末まで駆け抜けます。

12 月 3 日(土)

朝から[[TaskChute Cloud]]にログイン障害

朝はいつも[[TaskChute Cloud]]を起動するとルーチンタスクが実行する順番で並んでいるのでそれを元に実行していくのですが、この日はアプリでも web でもなぜかログインできないということが。後で調べてみると障害が起きていたようです。ログインできないのでしょうがなく、いつもやっていることを思い出しながらやるのですが「これで全部やっただろうか？」とか「思いついたタスクを即座に登録できないなあ」とか、この日はなんかモヤモヤしながら作業してました。自分は普段から[[TaskChute Cloud]]の恩恵を受けているのだなあとしみじみ思いました。
https://twitter.com/taskchute_cloud/status/1598926246918094848

数日前から左肩、左腕に違和感

ここ数日左肩から左腕にかけてなんか違和感を感じます。「カフェインとりすぎ」、「食生活、お菓子、肉、甘いものとりすぎ」、「デスクワークで動かない」など心当たりがありすぎます…調べてみるとちょっと怖そうな病気もたくさん出てきました…一旦整体を予約したので、体のコリや疲れなど来るものなのか見てもらおうと思います。

ソフトウェア開発はサービスの提供と似ている

リーンソフトウエア開発という本で印象に残った内容です。
生産は、顧客の期待値が変わらない前提でソフトウェア開発は顧客によって期待値が変わる前提という違いがあるんだなあと改めて思いました。
- アトミックノート
  - サービスでは、バリエーションを求めるのに対して生産は顧客の期待が変わらないことを前提にしている。そのため、毎回同じやり方で製品を作ることが目標。いつしか、ソフトウェア開発にもその考えが入ってしまった
  - ソフトウェア開発に生産のプラクティスを適用してもうまくいかないのはソフトウェア開発もサービスと同じでそれぞれの顧客の問題に適した解決をすることが求められるため。

12 月 4 日(日)

Go 言語のポインタはやっぱり難しい

&変数のように、変数の前に「&」をつけると、ポインタ型の変数にしてくれます。
var pointer *型名のように、変数宣言時の型名の前に「*」をつけると、ポインタ型の変数になります。
one := 1で、int 型の one という変数を作ります。次に、pointer := &oneとするとpointerはポインタ型の変数になります。*pointerのように、ポインタ変数の前に「*」をつけると、ポインタ変数のアドレスが指し示す値を間接参照してくれます。
個人的には「*」が型名の前につくか、ポインタ変数の前につくかで役割が変わるので覚え方に苦労しています…いい覚え方ないかな～

イテレーションを回すメリット

リーンソフトウエア開発という本で印象に残った内容です。
イテレーションを短いサイクルで回せる仕組みを作りたいと思いました。今の自社だとイテレーションのタイミングが数ヶ月単位とかなり時間がかかります（これは週 1 開発ができないという制約も大きく関わっています）。早く統合して学習するためのフィードバックサイクルを回すのは大事だと思いました。また、イテレーションは統合・リリースまでを含むというのもミソだと思いました。
このブログでいえば、週刊ニュースができるまでのデイリーノートに書く → 毎日振り返る → 週末に振り返る → 週刊ニュースをリリースというイテレーションを回しているのかもしれません。
- アトミックノート
  - イテレーションは、ソフトウェアを設計・実装・テスト・統合・リリースまでの短いサイクルのこと。
  - イテレーションを回すメリットは、製品の一部をきちんとテストし、きちんと動作するように作るため、次のイテレーションは前のイテレーションがきちんと動く状態で取り組むことができる。また、イテレーションはチーム内、他のチーム、チームと顧客との同期ポイントになる。頻繁に同期ポイントがあればチームがほかのチームの作業や、顧客の利益から遠くそれてしまわずに済む。

12 月 5 日(月)

結合テストに救われた

どれだけ単体テストで大丈夫だと思っていても結合テストは大事だなと思いました。ユーザーモデルと閲覧権限モデルに対して同期処理を行う callback を書いていたのですが、動くタイミングや動く順番が結構あり、それを網羅するまでに時間がかかたったのですが、それでも不安があったので自分で簡単な結合テストを作りテストしたところ、バグが 2,3 個出てきました。ちょっとした手間で今後どこでも動く同期処理のバグを検出できたのでコスパはすごい良かったと思いますし、やっぱりテストって大事だなと思いました。
バランスだとは思いますが、あとでバグを出して修正してユーザー影響が出たらユーザーに通知するコストやその間にかかるコミュニケーションコストなどを考えると、結合テストのコストは安いと思うのでこういうちょっとしたテストでバグを検出できるコスパ高い動きは意識してやっていきたいです。

AI と共同作業で作り上げる rake タスク

同期処理の兼ね合いで移行用の rake タスクを書いていたのですが、実行結果を表形式で出力したいと思いました。表形式で出力するには、その表の中の最大文字数に合わせてほかもスペースを入れて長さを揃えないといけないですが、どうやってやるんだと思い ChatGPT に聞いてみるといい感じのコードが返ってきました。その中でljustというメソッドが使われていて、こんなメソッドがあるのか、じゃあ、今度は最大文字数を取得して、その最大文字数に合わせて文字数を揃えてみたいな感じで言ってみると、またまたいい感じのコードが返ってきました。
こんな感じで出力された内容を元に自分で調べたり、動かしてみることで効率的にコードを書き進めることができました。

12 月 6 日(火)

特に書くことがないのでスキップ

12 月 7 日(水)

物腰の柔らかい話し方はどうしたら身につくのだろう

語彙力がなかったり、余裕がないときは後から振り返るとあの言い方だとトゲがあったかなとか、テキストだとトゲがあったかなとか思うことが多いです。
身近には嫌な気持ちにならないしすっと話が入ってくるな～という話す技術を持っている人がいるので今後聞いてみようと思いました。

DB 制約は弱い制約までとすることで変更に強くなる

DB 設定を見直すタイミングがあり、DB 定義書に合わせて制約がつけられていない箇所に制約をつける修正をしました。

最初、DB 側に文字数制限をつけていたのですが、レビュー時に指摘を頂きました。最終的には以下のような判断を行い変更にも強いいいとこ取りの判断ができたと思います。今後 DB 側で文字数制限をつけるか迷ったときは、文字数制限が守られていない場合になにかが壊れるなどあるような場合は制約をつけるようにしようと思いました。

DB側の文字数制限について
・文字数制限かけないとどこかが壊れる場合はDB側にも文字数制限かける
・上記以外のケースではDB側に文字数制限をかけず、アプリ側のバリデーションのみで文字数制限かける
DB側のその他の制限(NOT NULL、UNIQUE、外部キー)
・これは入れておかないとデータ不整合で致命的な不具合につながるため制限かける

12 月 8 日(木)

業務フローがわからない状態で機能仕様書を読むのは難しい

週 1 開発という限られた時間の中でキャッチアップして、開発するためには機能仕様書、ワイヤーフレームだけではコミュニケーションコストが増えてしまい、非同期で確認するのが難しいと思うことがありました。
最近は必要なドキュメントはコストをある程度かけてでも必要なものを用意するほうがスピード感を持って最速で進むことができるのかなと考えています。
そのうちのひとつが業務フロー図だと思いました。受託開発 1 社、自社開発 2 社を経験していて受託では顧客向けに作る必要があるため、必要なドキュメント類は揃っていました。受託でここまでするのかと経験を得て、自社開発を経験してみてスピードを理由に必要なドキュメントにかけるコストを惜しむケースが多いのかなと感じます。
顧客にむけた高品質な仕様書や業務フロー図も自社開発ではいらないと思っているのですが、開発者、経営者、CS などに向けた共通認識を持って進めるレベルの仕様書や業務フロー図は欲しいと思います。

12 月 9 日(金)

特に書くことがないのでスキップ