ConfluxDigital/software-delivery-assessment: The Multi-team Software Delivery Assessment is a simple, easy-to-execute approach to assessing software delivery across many different teams within an organisation. に、software-delivery-assessment/team-health.md at master · ConfluxDigital/software-delivery-assessment というチームの健康状態を評価するためのアンケートがあります。
アンケート項目は良い感じなのですが、回答の結果でばらつく部分や、前提知識でとして持っておいたほうが良いものがあると思いましたので、以下に、項目ごとに補足と、参考記事のリンクを記載します。
1. リリースが容易 - 作業中のソフトウェア変更をリリースするのは簡単ですか?
リリースが容易かを確認する設問です。
継続的デリバリーや、継続的インテグレーションの組織での適用具合でスコアが変わってくるのかと思います。
-
参考記事
-
書籍
2. 適切なプロセス - ソフトウェアの開発とリリースのプロセスは適切ですか?
これは、CMMIが思い浮かびました。
ただ、闇雲に重厚で重いプロセスを適用すれば良いというわけではなく、プロダクトのサービスレベルにあったリリースプロセスを適用する必要があるかと思います。
リリース承認のためのコミニケーションルールが決まっていて、影響範囲により、エスカレーションが必要なマネージャーのレベルが決まっているとスムーズなプロセスになるのかもしれません。
-
参考記事
-
書籍
3. 技術品質 (コードベースの健全性) - コードベースはどれくらい健全ですか?
これは、リファクタリングや、TDDのイメージを思い浮かべました。
技術的負債の可視化、返済のどれだけ予算を確保しているかが、スコアが変わってくるポイントになりそうに思います。
-
参考記事
-
書籍
- 新装版 リファクタリング 既存のコードを安全に改善する | MartinFowler, 児玉公信, 友野晶夫, 平澤章, 梅澤真史 | 工学 | Kindleストア | Amazon
- レガシーコード改善ガイド | マイケル・C・フェザーズ, 平澤章, 越智典子, 稲葉信之, 田村友彦, 小堀真義, ウルシステムズ株式会社 | コンピュータ・IT | Kindleストア | Amazon
- レガシーソフトウェア改善ガイド | クリス・バーチャル, 吉川邦夫 | コンピュータ・IT | Kindleストア | Amazon
- リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) | Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典 |本 | 通販 | Amazon
- テスト駆動開発 | Kent Beck, 和田 卓人 |本 | 通販 | Amazon
4. 顧客またはユーザーの価値 - チームはビジネスとして価値あることに取り組んでいますか?
元々が漠然とした質問なのかもしれません。以下のような問いが浮かびました。
- 取り組んでいることについて情報を、チームは伝えられているか?
- 取り組んでいることをチームは知ろうとしているか?
- 取り組んでいることに対する問題、事象に対してチームの知識はあるか?
- 取り組みが、ビジネス上価値があるかを評価できるか?
要求工学
、デザイン思考
、Analytics
が浮かびましたので、そのあたりの記事や書籍のリンクを記載します。
-
参考記事
-
書籍
5. スピード - チームとしてどれくらい迅速に仕事をしていますか?
チームとしての開発速度についての問いかと思います。
個人的に意思疎通のスピード、認識齟齬の発生回数等が思い浮かびました。
設計レビュー、実装レビュー、QAの解答速度などが影響している項目に思います。
スコアに対して以下のような質問をすると良いのかと思います。
- アンケート結果に対して、どこに対してのスピードの評価をしたか?
- どの工程、イベントでのスピードが気になるか?
個人的にCCPM
が思い浮かびましたので、関連記事と、書籍のリンクを記載します。
後は、正しいものを正しくつくる
考えも必要に思いました。
-
参考記事
-
書籍
6. ミッション - ミッションに取り組んでいる理由をどれだけ知っていますか?
チームのミッションの設定理由についての質問です。チームのミッションの上位ミッションが設定されている、会社、組織のミッションが設定されていれば、良いスコアになりそうに思います。
THE TEAM 5つの法則 (NewsPicks Book) | 麻野耕司 | 実践経営・リーダーシップ | Kindleストア | Amazon の言葉で言うと、チームのミッションが成果目標になっているのであれば、意義目標が設定されているかどうかがスコアの増減に関係しそうです。
7. 楽しさ - チームで働くのはどれほど楽しいですか? 仲間意識とチームワークの意識はどのくらいですか?
楽しさとは抽象的な言葉で、以下のような質問をして、楽しさとは何かをチームで話した方が良いかなと思いました。
- 仕事で楽しさを感じるポイントは何ですか?
- 仕事が楽しくないとしたら、楽しいと感じる仕事以外のことは何ですか?
- 仕事の何が楽しくないですか?
様々な要素が総合的に絡んでスコア化される項目に思います。
8. 学び - チームとしてどれくらい学びがありますか?
チームでの作業の中にどれくらいの学びがあるのかを評価する項目です。
以下のような状況にあるとスコアが増減するのかと思います。
- 新しい技術に触れる機会がある。
- 作業の中に未経験の要素が含まれている。
使用技術がエキサイティングではなくても、開発プロセスのカイゼン
により少しずつ変化がある状況である、社内勉強会の実施
でも、スコアは向上するかと思います。
後は、ふりかえり
でしょうか。
-
参考記事
-
書籍
9. サポート - チームとしてどれくらいのサポートが得られますか?
チームとしてサポートがどれくらい得られるかを確認する質問です。
追加で以下を確認した方が良いかと思いました。
-
チームメンバーからのサポートについて評価しましたか?
-
チーム外のメンバーからのサポートについて評価しましたか?
-
サポートを受けた事例としてどのような事例がありますか?
-
サポートを受けられない事例としてどのような事例がありますか?
以下のような状況の場合、スコアが下がると思いました。
-
マネージャーがチームをサポートしていない。
-
アプリケーションチームと、インフラチームに別れており、2つのチームがコミュニケーションできていない。
-
参考記事
10. ポーンか?プレイヤーか? - 作業内容とその手段をどの程度管理していますか?
チームがどの程度権限が与えられていて、自分達で自分達をどの程度変化させることができるかを確認する質問です。
以下のような状況の場合、得点が下がる傾向があると思いました。
- 意思決定プロセスに時間がかかる。
- 改善予算(エンジニアが自由に使える時間)が与えられていない。
-
ビジネスサイドの主導権力が強すぎる。
-
参考記事
11. 心理的安全性 - 懸念を提起することに対する安全性はどの程度ですか?
チームにどの程度の心理的安全性があるかを確認する質問です。
追加で以下のような質問をしてもよいかと思います。
-
チームのマネージャに懸念を提起することに対する心理的安全性を評価しましたか?
-
チーム内のメンバーに懸念を提起することに対する心理的安全性を評価しましたか?
-
他のチームにメンバーに懸念を提起することに対する心理的安全性を評価しましたか?
-
懸念を提起することを諦めてはいませんか?
この項目のスコアが高くなると芋づるで他の項目の評価も上がるのかなと思います。
- 参考記事
12. 周りのチーム - あなたの周りのチームはあなたとあなたのチームとどれくらいうまく働いていますか?
周りのチームとの関係性を評価する質問です。
オフィシャルでもアンオフィシャルでも周りのチームとのコミュニケーションする機会を持つと、スコアが向上するのかと思います。
シャッフルランチ
という制度を設けている企業もあって、このスコアに良い影響を与えそうだなと思いました。
交流の機会を増やし、人となりを知る努力をする必要があります。
- 参考記事
13. ソフトウェア・デリバリープラットフォーム - チームのソフトウェア・デリバリーを支えるソフトウェア・デリバリープラットフォームはどれほど効果的で使いやすいですか?
ソフトウェア・デリバリープラットフォーム
という単語に個人的に馴染みがないのですが、ソフトウェア開発、ソフトウェア・デリバリーを支援する仕組みと考えました。
リリースが容易
という質問とも関連すると思いますが、SRE
の導入具合、監視機能の充実具合がスコアに良い影響を与えるのかと思います。
-
参考記事
-
書籍
14. 経営スタイル - 経営陣やその他の上級管理者によるアプローチは、どの程度効果的かつ適切ですか?
経営スタイル
で経営陣、上級管理者に対するチームからみた評価なので、チームがこのスコアに影響を与えるのは、難しいかなと思いました。
できることがあるとしたら得点をエスカレーションするだけかもしれません。
ただ、CTOや、技術関連役員、執行役員がどのようなことを考えているのかを知ろうとするのは悪いことではないかと思います。
-
参考記事
-
書籍
以上が、各アンケート項目の補足です。
software-delivery-assessment
自体については、ソフトウェアの開発チームを評価する Multi-team Software Delivery Assessment について | Monotalk で紹介記事を記載しましたので、そちらをご確認ください。
コメント