クラウド的なアレ

そう遠くないうちに、自分の仕事上の役割が変わって、Product Owner（以下、PO）をやることになりそうな流れとなっている。 これまでもチームにPOはいたし、なんとなくやっていることは分かっていたつもりだけど、改めて、きちんと抑えたい気持ちになった。 何冊か関連する書籍を買ってみたけれど、まずは1冊目。 第1章 プロダクトオーナーの役割を理解する プロダクトオーナーとして望ましい特性： - 明確なビジョンを持った実行家：最終的な製品を心に描いて明確に伝えることができる - リーダーとチームプレイヤー：権限が与えられている一方でチームメンバーでもあるあるため、両立して、判断を強制しないようにしなければいけないし、異論を唱えるメンバーと議論をしなければいけない - コミュニケーターとネゴシエーター：顧客の声を代表してチームと会話したり、必要に応じて妥協の交渉をしたりする - 権限が付与された献身的な人物：リリースの一部として提供される機能を決定する権限を持っている持っており、開発の向上に献身的でなければならない、情熱的で信頼できる人物であることが必要 - 可用性と資質：過剰な負荷がかかると成果物が最適ではなくなる、顧客と市場に対する深い理解があり、ニーズを伝え、要件を説明できる能力が必要 よくある間違い（≒アンチパターン）： - 力不足のプロダクトオーナー：権限不足だったり十分な信頼や支援を得られていない - 働きすぎるプロダクトオーナー：負荷がかかりすぎて質問に即答できない、会議を欠席するなど、役割を全うできない、可用性の裏返し - 限定的なプロダクトオーナー：役割を組織の都合などで分解し、プロダクトマネージャーが外向きの活動を、プロダクトオーナーが内向きの活動を担うなど、この場合プロダクトオーナーはバックログの書き手に役割を少し追加しただけの存在になってしまう - 遠隔地のプロダクトオーナー：同じ建物の違う場所、別のタイムゾーン他、様々だが、遠隔地で対応すると不信感、伝達ミス、認識などのズレ、進捗遅延といった問題を繰り返す - 代理のプロダクトオーナー：本来のプロダクトオーナーが忙しすぎるため、十分な権限は付与されずに代理でプロダクトオーナーがやるような活動をし、最終決定・判断は本来のプロダクトオーナーが実施する、というようなことが起きると遠隔地のプロダクトオ

近頃、運用時の引き継ぎの不十分さに起因して、一定の標準項目があったほうが良いのではないか、なんて話があった。 この手の話で難しいのは、チェックリストにしてしまうと、リストにないものを想像するのが難しいみたいなやつがあると思っている。 会計の世界だと、原則主義と細則主義というのがある。 前者は、原則論、その考え方の背景や趣旨を述べて、個別の事象については都度原則に照らして考える主義。 後者はその逆で、個別の事象などについて言及することから考え方や趣旨を示すような主義。 個別の事象の種類の豊富さや変化の多さによってどちらがいいかは変わるけど、変化を前提にすると原則主義の方が結果として趣旨に沿った対応がなされる傾向にある、とされている。 で、運用の引き継ぎについても同様だと思っているというのが自分の考え。 細則主義で一挙一動個別事象について語るのは、手間がかかる上に実際には効果的ではないと思っているので、こういう項目について検討した方がいい、というレベルだけ標準化し、その中身は現場の個別の案件に委ねるのが効率的かつ効果的なのだろうと推測してる。 じゃあ何を、というあたりで少し困るので次の箇所から抜粋・意訳して標準項目を検討するたたき台とした。 "22. The Operational Viewpoint, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Second Edition" 関心事 内容や例 インストール・アップグレード インストールやアップグレードが必要な対象、またその方法など 提供機能移行 どんな提供機能があるか、当該機能の提供をやめたり別のものに置き換えたりする場合にはどんなことをしなければいけないか データ移行 どんなデータがどこにあるか、当該データを別の場所に移行する際に必要なことは何か（ ETL としてなにをしなければいけないか） 運用監視と管理 システムを動かし続けるためにしなければいけないこと、動いているかを確認するために見なければいけないことややらなければいけないこと（註：ここでの監視は Liveness の方） アラート システムが正常に動いているか、動いていない場合にどのようなアラートを