なぜ記事を書こうと思ったか
この記事をご覧の皆様同様、我々も例に漏れず技術的負債の返済には、悩んでおります。
まだ返済には届かずとも一定の見通しが立ったため、我々が当たったケースをもとに反省と宣言を込めて認めようという試みです。
とはいえ、見返してみると当たり前のことであり、当たり前のことを当たり前にやってくのって難しいよねっていう吐き出しに仕上がってたりします。
お忙しい人は、「反省点と結論」をみてください！
サマリー
テーマの技術的負債を返済していくには、これら問題を評価し継続的に施策を打ち出せるリソースの確保と関係者の属性(と彼らとの関わり合いかた)が非常に重要だと感じました。
前者のリソースが不在だとスタートはできても継続はできずうやむやになりがちです。
後者の文脈に関して特に注意すべき点は、非IT人材のビジネス領域の人たちとの折り合いの付け方です。
我々にも知らないことがあるのと同じように彼らにも知らないことがあり、一歩間違えるとお互いに「あいつ分かってない」という状況に陥ります(念の為補足しておくと、今のチームはそういう状況には陥ってはいません。私の経験上、こういう現場がかなり多かったというあくまで経験上の注釈です。)。
前提(登場人物)
- PO: ビジネス領域スキルセット持ち。
問題解決
まずは問題を正しく認知すること
問題を認知するには到達すべき目標を正しく認識する必要があります。我々の場合は、下記のような問題を認知しました。
(色々取り組むべき課題はたくさんありますが)技術的観点では、下記を「社内の技術スタック・市場を鑑み上記目標達成できるか」を評価しました。
- ビジネス要件を満たせるか
- 非機能要件を満たせるか(☆)
我々の組織には、ビジネス側のスキルスタックは多かったため、特に後者の問題が顕著でした。
ということで、非機能(セキュリティ、性能・拡張性、運用・保守性などなど)にコミットできるような場づくりをしていくことにしました。
計画-実施
その上でこれらに対する計画です。中期計画に対して、半年〜1年の短期目標を定めました。
冒頭にも書きましたが、一番エネルギーを使ったのは特に非エンジニアであるPOに向けて、スクラムイベント内で結果をどうアピールしていくかという点です。
言い換えると、単にコーディングやCD/CIの範疇にとどまらず、スクラムイベントという単位で生産性を評価するということになります。
※(エンジニアのみなさまはここが一番気になると思うので軽く触れます)余談ですが、この課題を解決するのに、storybookというライブラリを使用しました。
具体的な方法については、コードベースのソリューションでまた別途リリースする予定です。
反省点と結論
この記事の肝部分です。
- 技術的負債などを(再)評価できるソフトウェアエンジニアリングに精通したリソースを確保する
- PO含むステークホルダーにどう可視化するか
技術的負債とよく付き合っていくには上記の点と折り合いつけていくいことが肝要と考えます。
特に前者に関しては、計画-実施にて記載しましたが、後者の点が初期計画の時点で盲点でした(下で補足します。)。
「ソフトウェアエンジニアリングに精通したリソースを確保する」について補足すると、この計画自体スタートはかなり良好に進んでおりましたが、実は技術的負債を先導していた者の異動を機にその後滞りがみえるようになりました。
技術的負債に対するアンテナは、そこそこにハードスキルスタックがものをいうところがあると考えております(アーキテクチャーだったり運用だったりを複数経験しないと比較し得ないため)。
問題解決プロセス上本来は、「振り返りポイントによって再評価がなされるべき」ところですが、根本原因を探ると人事異動によって再評価できるリソースが不在になったというのが私の評価になります(この文章読みにくいですね。。)。
ちょっと念の為補足しておくと、今この記事が書けているのも、実はその状態はある程度改善していて、技術的負債に対する評価ができるリソースがたまたまアサインできたからだったりします。
(まだまだ解決の余地が見えなかったら書けません！)
最後に
硬い文章を書いてきたので最後ちょっと緩和させるためにこんなこと書くのですが、実はこの文章アドベントカレンダーの中でリリース予定ですた。
色々訳あってズレ込んでのリリースになるのですが、まだ俺たちのクリスマスは終わっちゃいない！ドン！ ということでクリスマス兼2022年の締めくくりとしたいと思います。