23時に寝て3時に起きて軽く apple イベントをみて寝て6時に起きた。

画面周りのリファクタリング

週明けに私が作った画面が本番環境にリリースされて運用を経てフィードバックが返ってきた。主には使い勝手の改善や要望だけど、何にしても実際に使ってもらってフォードバックがくるのは楽しい。丸1日リファクタリングしていて要望があったものはすべて改善できた。インフラ・バッチ処理、サーバーサイド、フロントエンドのすべてを担当しているから私が関わっているところなら適材適所にリファクタリングできる。システム全体を通してやりたいことを独力でできると楽しい。これは人間の独占欲や支配欲を刺激する。おそらくマズローの欲求でも高次の欲求に属するのだと思う。

v-data-table の props headers でカラムの値に対してソートができる。ソート可能に設定すればあとは自動的にやってくれるのかと思いきや、自分で key function を実装しないとソートはされるけど正しい並び順にはならない。key functoin の返り値が number なので -1, 0, 1 の値でソートの入れ替えを実現しているようにみえる。javascript は true => 1, false => 0 と評価されるので単純な比較演算の結果からは意図したソートにならないからではないかと推測する。このやり方が正しい実装かはわからないけど、次のような key function を定義してあげることでソートを実行したときに意図した並び順になることを確認した。すべてのカラムにこんな実装書くの？というところに懸念はある。

{
  value: 'date',
  sortable: true,
  sort: (x: Date, y: Date) => {
    return x < y ? -1 : 1;
  },
},

3時に寝て7時に起きた。眠れない。

github リポジトリとシステム間連携

社員さんが運用対応に忙しくてスプリントタスクがなくなって暇なのでドキュメントを書いてた。github に新規リポジトリを作成したときに行う初期設定の作業が増えてきた。大半は私が導入した仕組みや機能のための初期設定になるが、私はリポジトリの管理権限をもっていないので、社員さんにお願いして、この設定して、あの設定してとお願いして対応してきた。もうすぐ辞めるので引き継ぎできるようにやっていることのドキュメントを整理した。

• slack 連携
• backlog 連携
• github
  • pull requests テンプレート
  • github actions
    • github apps
    • github environments

リポジトリと他システムとの連携を効率化しようとすればするほど設定や背景が煩雑になる。とくに認証や権限周りのセキュリティを考慮した仕組みはサービスとのトレードオフになるので設定が面倒になりがちではある。とくに github actions のワークフローは 【登壇報告】JJUG CCC 2022 Spring で語りきれなかった技術的なお話 にあるように、世の中のプラクティスに依らず、私が設計して整備したものなので他メンバーにとって身近ではない。

backlog の wiki にプロジェクトのドキュメントを書いている。開発メンバーでドキュメントを定期的に書くのはほぼ私だけで、他メンバーはほとんど書かない。なぜそうなるのかな？と考えたときに思いつくことの1つとして、開発全般の業務としてやることを、誰でもできる汎用的な仕組みに落とし込むことを考慮して設計していないからではないかと思う。あるアプリケーションが内製／外部システム／外部ライブラリに関わらず、こういう機能や仕組みを使って、こんな課題を解決して、こんな機能を実現していますという構成にはなっていない。発生している問題に対して動けばいいといったレベルでしか開発していないから、本来どう在るべきなのか、どういった設計思想なのか、今後はどうやって保守していけばいいのかの指針を提供できない。これは私の言葉だと設計ができないということと同義だと思う。他に思いつくこととしては、既存アプリケーションにない新規の仕組みを定期的に設計しているのは私しかいないのかもしれない。言い換えれば、言われたことしかやらない人しかいない。

0時に寝て7時に起きた。あまりよく眠れない。新しい施設のサービスインで社員さんは忙しそうなので画面のバグ修正をしたりレビューの検証をしたりしていた。

スクラムイベント

Scrum Developers Night! Online #11 に参加した。過去にストーリーポイント運用がうまくいってないという話題を書いてきたけど、他の組織やチームだとうまくいっているのか、どんな感じなのかを聞いてみようという意図で参加した。他のスクラムやっている人たちの話しを聞いてみたかったんだけど、割とこっちのやり方や運用を聞かれるような展開になったのでこちら側の話しが主になってしまった。相談してわかったことなどをざっくりまとめる。

• ストーリーポイント運用の方法自体は間違っていない
  • ストーリーポイント運用とは別のところに課題があるようにみえる
• スプリントで決めたことをできないのは問題
  • 1週間の見積もりすら合わないのだからそれ以上の期間の見積もりはあわないのは自明
• プランニングやリファイメントなどでタスク分割や見積もりの精度をあげないといけない
  • 大きな機能の見積もり後にタスクが増えるような精度が問題
• スプリントがある週の実稼働時間を考慮して見積もりしていないのは問題
  • 休みがあったり社内イベントがあったり実稼働時間によってベロシティはブレるはず

全体として総括すると、ストーリーポイント運用以前に、チームの問題が大きいのだろうと他の人たちと話していて実感した。スクラムの実践についての細かい改善点はあるものの、それ以上にチーム事情によるものや体制の問題の方が大きいということに気付いた。

0時に寝て6時に起きた。

vuejs のライフサイクル

先日 vuejs で 画面作り に挑戦して出来たと喜んでいたが、検索して一覧画面のデータを更新した際に、フォームも再レンダリングされないといけないところがそうなっておらず、データは置き換わっているが画面に表示される値は変わっていないという致命的なバグがあることに気付いた。普通に開発していたら気付きそうなものだが、ローカルの dev server で動かしているとコードを更新すると再レンダリングが実行されるので検索後に画面の一覧が更新されないということを見逃したんだと思う。Lifecycle Diagram もみながら適切なフックポイントの振る舞いを確認したりしていた。setup 後、初期化されてその後に mounted が動いて、その後パラメーターが更新されたときに watch して再更新をかけるといった次のコードでも意図した振る舞いになることは確認した。

  setup(props, context) {
    const data: { [key: string]: any } = {};
    return { _data: ref(data), loading: false };
  },
  mounted() {
    this._data = JSON.parse(this.item.data);
  },
  watch: {
    item(value: any) {
      this._data = JSON.parse(value.data);
    },
  },

レビューしてもらったら、それよりもパラメーターをリアクティブにした方がよいのではないかと教えてもらって次のようにした。本当は setter は不要なんだけど、なぜか初期化のタイミングで setter が呼ばれるので設けた。私の作ったコンポーネントの設計が悪いせいかもしれない。

  setup(props, context) {
    const _item = toRef(props, 'item');
    return { _item };
  },
  computed: {
   _data: {
     get(): { [key: string]: any } {
       return JSON.parse(this._item.data);
     },
     set(value: any) {
       this.$emit('update:_data', value);
     },
    },
  },

これは vue2 の Options API と呼ばれる記法で、vue3 だと Composition API を使って次のような書き方ができるというのも教えてもらった。getter だけなら Composition API でもよさそうだけど、setter もあるとこのコードはまったく簡潔じゃないなと思って Options API を使うことにした。

  setup(props, context) {
    const _item = toRef(props, 'item');
    const _data = computed({
      get: () => JSON.parse(_item.value.data),
      set: (value: any) => this.$emit('update:_data', value),
    });
    return { _item, _data };
  },

0時に寝て6時に起きた。たまたま見かけた記事から昔読んだ本を思い出した。

40代は改革と革命

たまたまタイムラインでこんな記事をみかけた。

30代のころは「改善」でいいと思うのです。30代のうちに仕事の基礎をガッチリ身につけ、40代以降は改革と革命に取り組む。私はいつも、40代以上の社員に「改善をするな」と言っているんですよ。

ニトリ会長が斎藤佑樹にアツく語る、「30代にするべきこと」「40代にやるべきこと」

私の生き方に近い考え方だったので印象に残った。私はもともと sier 出身なので働き始めた頃からマネージャー側にいた。たまたまトラブルプロジェクトに参加してひたむきに1年半ほど働き通したら大きな成果が出て、組織からプロジェクトマネージャーになることを嘱望されるようになってしまった。私はただの議事録係だったが、結果的に事実上のプロジェクトを仕切るようになった。それはそれで誇らしかったのはあるけど、それと同時にマネージャーはだいたい分かったという気持ちにもなった。そしてマネージャーの働き方は自分の意思ともあわなかったので潔く辞めた。おそらく自分がやったことのないことに挑戦するという生き方の基礎が最初の退職と同時に出来た。転職じゃなくて退職なのは辞めることを決めてから次のお仕事を探したから。閑話休題。30代のときにひたすらコードを読んで、ひたすらコードを書いてきた動機づけの1つとして、昔読んだ本の１つに リーダーの易経 がある。著者によると、易経とは時の変化の原理原則が書かれていて、時を読むための専門書と言えるらしい。時の第三段階として次の言葉がある。

君子終日乾乾 (けんけん) し、夕べに惕若 (てきじゃく) たり。厲 (あや) うけれども咎なし。

(要約) 朝から晩まで、繰り返し邁進して努力する。そして、夜、独りになったときに、1日を恐懼 (きょうく) して省みる。そのようであれば、危うい時ではあるが、咎めはない

「乾乾 (けんけん) す」とは高揚感、充実感をもって進む、「厲 (あや) うけれども咎なし。」とは省みることを怠らなければ、危うい立場ではあるが、大きな失敗はないという意味になるらしい。

自分の力、自分でないとできないことを創出するためには、なかったものを創り出すわけです。そのために必要なものは、毎日朝から晩まで同じことを繰り返すことです。継続は力なりというのは、この段階です。

同じことを繰り返すことが創出につながるというのはおもしろい話しで、同じことを繰り返すうちにちょっとしたミスや失敗が創意工夫や技を磨くきっかけになるという。失敗したで終わらせずに省みることで気付きを蓄積していくことがオリジナリティを育てる。乾乾 (けんけん) という言葉の響きを気に入ったのか、おそらく2007年頃に読んだ本なのに15年経ってもいまも記憶に残っているというのは人生において影響を受けたと言っていいだろう。

若い頃からマネージャーをやってくれという依頼を断り続けて、いま満を持して次のお仕事ではマネージャーをやろうと考えている。メンバーとして経験を得た上でマネージャーとして自分が何をできるかを確認したい。一方でマネージャーの仕事を未経験／業務委託で探すのがなかなか難しくて苦戦している。私には課題管理というたった1つの武器しかないが、それをマネージャーとしてどう活用できるのか。組織で働く人は言われたことをやる人が多い。私は課題管理を用いて然るべきことをやることに重きを置いている。課題管理で業務を改革や革命のレベルまで昇華できるかどうかを実践の場で確かめたい。

1時に寝て7時に起きた。開発の作業しようかと思っていたけど、なんか気分が乗らなくて本を読んでただけだった。

ストレッチ

今日の開脚幅は開始前158cmで、ストレッチ後162cmだった。まずまずの数値でストレッチを受けていても調子がよかった。気温が下がって暑さが和らいできて体調もよくなってきた感じがある。以前から姿勢があまりよくないといったアドバイスを受けていて、前側の筋肉に比べて後側の方が相対的に強いから後側の筋肉を多用しようとして腰に負担がきているといった話しがある。姿勢を保つときに腹筋を使うように意識した方がよいといったアドバイスをトレーナーさんからもらった。

正史 諸葛亮孔明

「第四章 赤壁の戦い」を読んだ。

孔明が軍事の指揮をとるのは劉備の死後になるので、劉備の生前に起こった赤壁の戦いで伝えられる孔明の逸話は基本的にすべて嘘になる。演義では十万本の矢、東南の風、龐統による連環の計までもが創作らしい。赤壁の戦いの功労者は呉の都督だった周瑜の戦略によるもので戦う前から結果がみえていた。周瑜が用意周到に準備した戦略通りに魏軍がはまり、そこに周瑜の部下である黄蓋が提案した火計が成功をおさめたという。これはこれでおもしろくて戦いとはその前の準備の段階で決着がついているという見方ができる。周瑜は都督で全体の戦略を描くものの、実際の戦場における戦術は積極的に部下に任せるというスタンスをとっていた。また実際にはこれは大きな戦ではなく、小競り合いと決定打だとなった火計はあったものの、魏軍で流行した疫病による撤退というのが史実だと言えるらしい。演義における赤壁の戦いが大創作になっている背景として、三国志演義が編纂された時代 (実際の赤壁の戦いから千年後) にあった 鄱陽湖の戦い がモデルになっているのではないか。また孔明の神算鬼謀も朱元璋に仕えた 劉基 からきているのではないかという話しでもあるらしい。

0時に寝て3時に起きて2時間だらだらしていて6時に寝て7時半に起きた。ここ1週間ほどこういう寝方が続く。

運用対応の続き

昨日からまだトラブルが続いているらしく運用対応がてんやわんやになっている。私は本番環境のログもデータもみれないから社員さんから伝え聞く分しか状況がわからない。そのため、現状の運用でうまくいっているのかと思ってたら、たまたま他の要因が重なって発生しているのかもしれないけど、大きな障害に発展しているのかもしれない。従来の正しいと思われていた運用ツールにも誤りがあったらしく、これまでの運用は正しかったんやろか？という懸念も出てきた。スクラムマスターからも、既知の課題を放置してトラブルが常態化して運用対応に工数を割いて他の仕事ができなくなっているのではないか、仮説の検証をちゃんとやってないんじゃないかとかツッコミが入ってた。PO が未熟と言ってしまえばそうなのだけど、スクラムの悪いところは問題が起こっても責任の所在を曖昧に終わらせることがうちのチームでは多々ある。責任の所在をちゃんとふりかえらないと、再発防止やその対応に誰も責任をもたないという状況が発生する。今回のふりかえりがどうなるのかは来週にならないとわからない。ちゃんと反省してチームとしてふりかえりできるかどうかも観察してみようと思う。

次のお仕事探し

以前から勝手に私が応援している地元の会社の求人情報をみかけた。それは正社員しか募集していないのだけど、ダメ元で業務委託を雇っていないか問い合わせてみるかを迷っていた。そこで地元のコミュニティの知人が、地元の会社の中の人を知っていると話していたことを思い出して、その知人に業務委託で雇っているかどうかを試しに聞いてもらえるかを尋ねた。快く聞いてくれて、直接つながって問い合わせてくれて本当にありがたい。そしたら業務委託は採用していないらしいのだけど、一応は経歴はみるかも？といった返事だった。じゃあ、ダメ元で採用情報のページから応募しようかと考えていたら、その知人経由で経歴がわかるものがあったらそれでいいという話しになって linkedin と会社の事例紹介の url を転送してもらった。普通に応募するなら履歴書と職務経歴書をファイルで送らないといけない。仮に不採用になっても url を送るだけの手間しかかかっていない。わずか1時間ほどのやり取り。そう思うと人材求人プラットフォームに登録して、定型的な資料を用意して、手続きをとって、先方からの返信を待つといったワークフローはなんと無駄の多いことかとか考えたりしていた。

0時に寝て4時に起きた。5時からドラクエタクトしてた。

運用対応と遊休

今日も本番環境でトラブルがあったらしく、その対応で開発リーダーが忙しくて、お昼にあるチケットの仕様を決める小さい打ち合わせ (15分程度) を経て対応しようと思っていたのに、最終的にそれができたのは19時半になった。当然、実作業もやってない。昼間の3時間を休憩時間として別のお仕事をしていた。9月から新たにフロントエンド開発者が入って、チームの開発者が7人になって開発者が遊休する状態に拍車がかかった。本当はチームを分割すればいいけど、チーム事情でできず混乱している状態。権限委譲もできてないのでチームを任せられる開発者が他にいないのだと思う。人を教育せずに人数だけ採用して開発チームを拡充してきたのが垣間見える。古いプラットフォームの仕様を知っている人が1人しかいないといった状況は大変そう。そういう開発や組織を是としてきた先駆者の責任でもある。そんな組織の開発者が外部でいいことばかりを言っているのをみると、よい開発者が入ってきても騙されたと思って定着しないのではないかと思う。私がみえる範囲でもよい開発者がいないので組織における開発リーダーの重要性を実感する。

次のお仕事探し

たまたま求人検索していて Offers「オファーズ」 - エンジニア・デザイナーのための副業・複業・転職サービス というサービスをみつけた。ちょっと前に求人プラットフォームを開発していたのでいくつかの求人サイトに登録して調査したりしていた。その中でもこのサイトは上位に入る優れた品質だと思う。一番嬉しいのが職務経歴を linkedin からインポートしてくれる。求人プラットフォームでもっとも嫌なことは、それぞれのサイトごとに職務経歴書を作らないといけないところ。プログラマー的に同じ作業を何度も繰り返すことに苦痛を感じる。比較的新しいサイトなのでどういったものか、わかっていないけど、サイトの使い勝手がよかったので縁があれば面談もやってみようと思う。