2時に寝て6時に起きた。疲れていたからよく眠れた。

mvp（minimum viable product）で対応した⌗

スクラムに限った話しではないと思うが、プロダクト開発をしていると mvp（minimum viable product）という言葉を聞くことがままある。昔ながらのイテレーション開発よりも、アジャイル開発の文脈でよく使われるように思う。というのは、短い開発期間でプロトタイプを作ったり、最低限の動く機能を作ったりすることをよしとする考え方があるから。昔ながらのやり方だと、イテレーション期間の中でそういった段階的な開発はするものの、外部からみたとき (もしくはマイルストーン) においてはそこそこの機能が提供されているので mvp といった言い方をすることはなかった。もしかしたらアルファとかベータとか呼んでいたかもしれない。最近ある lambda 関数の移行作業を行った。serverless framework でデプロイしていたリソースを cdk で一元管理する。その過程で既存のコードを読むと、ある id をハードコーディングで指定して FIXME がこんな感じに書いてあった。この id が指すリソースはその後なくなっており、本番環境で不要な処理が定期実行でずっと動き続けていたのと、本来は複数の id リソースに対して行うべき処理を実行していなかった。

# FIXME 対象 id 一覧を取得する。(Phase2までに対応します)
id = 'ABC001'

チームの開発リーダーはその存在を全く忘れていたし、このスクリプトを実装したさらに上位の開発リーダーからはこの処理の要否はよくわからないからチームで確認してという曖昧な返事が返ってきた。チームで確認したところ、この処理は必要だとわかり、この機に複数の id リソースに対して対応するようにした。何も知らない私が修正しても5分で対応を完了した。

mvp で対応したんで

このように実装者は話していたが、本当なのだろうか？と思えた。さらにこのスクリプトのエラーログのログストリームを監視して slack 通知する lambda 関数も移行対象で、コードの検証をしていたところ、slack 通知をするための lambda 関数が別途あり、その動作検証をしていたところ、その lambda 関数を呼び出す権限 lambda:InvokeFunction が足りないことに気付いた。これも実装者に問い合わせたところ、動作検証はやっていないし、過去に1度も slack 通知は発生していないという。状況証拠から考えると、権限が足りないために正常に動作していなかったと推測される。結果的に mvp で対応したという2つの lambda 関数は実運用で半年間、無駄にリソースを浪費して何の役にも立っていなかった。当然、引き継ぎも、課題管理システムのチケットも、ドキュメントも何ら残されていなかった。mvp で対応したという表現に開発で大事なものを誤魔化してはいないだろうか。