-
Notifications
You must be signed in to change notification settings - Fork 22
/
Copy pathchap-hisa.re
164 lines (73 loc) · 17.2 KB
/
chap-hisa.re
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
= 「責任」という単語について考えてみる
//flushright{
Hisa @Ryuku_Hisa
//}
こんにちは、Hisaと申します。昨今は北海道函館市のとある大学で大学院生をしながら、とある会社で組織開発チームの一人として働いております。そんな私ですが、この度Agile Tech EXPOを運営されている方からお誘いをうけ、筆を取らせていただいております。
これまでの経歴的には、高校1年生から学部1年生までコンビニエンスストアでアルバイト勤務、高校3年生から現在まで長期休暇期間に住み込みで飲食店で働き、学部4年次から現在までとある企業で「組織がよりいきいきするにはどうすればよいか」ということについて日々考えるという活動をしております。加えて、学部1年生から現在までの5年間、課題解決型学習（PBL）のカリキュラムを活用しチーム開発を経験してきました。PBLで活動していく中で、多くのわからないこと・不安なことに直面しました。そのときに、様々なコミュニティにて多くの方が貴重なご意見やご助言をくださいました。
今回は、これまでアルバイトやPBLにて得られた経験と、私を支えてくださった数々のご助言をもとに、「責任」という単語について考えていきたいと思います。私が組織・チームで何かを行うときには、だれが何に対して責任を持っているか、ということをつねに意識しています。皆様のこれからの活動に少しでも役立てていただければ幸いです。
== 責任ってなんだろう？
「責任」という単語は非常に便利なので、これまで聞いたことも使ったこともあると思います。しかし、この単語について深く考える機会はあまり無いと感じています。せっかくの機会ですので、少し考えてみましょう。
みなさんは「責任」という単語を聞いたとき、どんなことを連想しますか？あなたの考える「責任」の定義について、1〜3のどれにあてはまるか考えてみてください：
1. とある企業の社長は、その企業が開発したシステムの問題により多大な迷惑をかけたとし、責任をもって辞職した
2. 社員Aは納期に間に合わせるため、責任を持って残業し業務を終わらせた
3. 社員Bは昨日発生したシステム障害について、責任を持って発生原因の分析と今後の対応方針を考案・公表した
上記の例は、想像しやすいよう少し大袈裟なものにしておりますが、現実社会でも起こり得るものだと思います。1〜3の事例はいずれも「責任を持って」という文章が入っていますが、各々の「責任」の種類が異なることがわかると思います。これらの責任は、いずれも「責任範囲を明確にする」ことで適切に運用することができます。各々がどのような「責任」なのか、もう少し詳しく説明します。
ただ、留意していただきたい事項なのですが、ここに述べている内容は過去に様々な方からいただいたアドバイスや複数の書籍を参考に、私なりに解釈したものとなっています。これから用いる「賠償責任」「実行責任」「説明責任」という単語ですら、人によって解釈が異なる場合があります。そのことを踏まえ、「責任に対する考え方の1つ」としてとらえていただければいいかと思います。
=== 賠償責任
賠償責任は、問題・課題に対し何かを差し出すことで果たすことができる責任です。差し出すものとしては、お金や立場などが多いです。この責任は多くの場合、問題に関係する一部の人間の怒りを治めるためにあります。なお、何かしらの不貞行為などをした際に「辞任」「減給」などの処置を行う場合があると思いますが、その場合は「責任」ではなく、ルール違反による「処罰」であると考え、今回は賠償責任の範囲から外します。
賠償責任に関するよくあるケースとして、「なにかミスした際に責任をとる」というケースですね。例えば、近年はあまりありませんし、幸いなことに私は体験したことがありませんが、コンビニや飲食店で働いている際にレジ金の差額が誤っていたら自分で払わされる、会計を誤った際には間違った金額を自分で払う、みたいなものもありました。
ですが、この本を読まれている方の多くはチームで何かしらの開発をしている人ですよね。そんな皆様の現場で考えたときの「賠償責任を取らされる良くないケース」は何でしょうか？有名なのは、部下がなにかミスをした際に責任を取らされ辞任や減給されるといったものです。部下がミスをしたケースの1つに「挑戦した結果のミス」が考えられます。現代において、新しいものに挑戦することはとても大切ですが、この賠償責任が多く課せられる会社の場合、上司は部下が挑戦することを拒むでしょう。
なにかしらのイノベーションを起こしたいのであれば、この賠償責任は足枷以外の何者でもありません。こんな無意味な賠償責任は無くしてしまいたいですね。
=== 実行責任
実行責任は、問題や課題を解決状態に持っていくことで果たすことができる責任です。例えば、業者に家を建ててもらう際にしっかり完成状態までもっていくことは実行責任です。
実行責任を果たす上で、メンバー各々が自身の役割を理解して適切な責任範囲を設定する必要があります。実行責任は、仕事をしていく中で非常に重要なファクタです。しかし、実行責任範囲を誤って小さくすると生み出される成果は小さくなり、大きくしすぎると残業や過労死などに繋がりブラック企業への第1歩です。
実行責任の管理は、上長が行うよりチーム全体で行う方が最適化されていきます。実行責任の管理をする際には、ガントチャートなどを用いて計画を立て、実施していくことが多いと思われます。しかし、このような計画を立てるという「予見的アプローチ」は多くの誤りを孕みます。この誤りは、チーム内のメンバー全員が定期的に検査・適応していくことで修正していくことが可能です。ですが、多くの人はその修正プロセスをあまり意識できていません。修正プロセスを意識するためには、後述する「説明責任」を明らかにするとうまくいくケースが多いです。
実行責任はあらゆるところで発生しやすい責任です。それゆえに、もしもチーム内で実行責任を割り振る際には、実行責任の管理はチーム全体で行い、つねに各々が有する実行責任範囲を検査して最適化していくことが大切になります。
=== 説明責任
説明責任は、問題・課題が発生した際に、どのように対応するか、どのように解決していくか説明することで果たすことができる責任です。
これまで述べてきた賠償責任や実行責任の場合、「責任者」というロールを与えられている人は、責任を果たせなかった場合に「責任を取る」というために辞職したり、家に帰れない生活を過ごすことになると思います。言い換えると、責任者は責任を果たすために何かしらの代償を支払い、場合によっては過労状態になる場合もあります。それに対し、説明責任はチームでどのように対応していくか考えることにフォーカスを置いています。チームメンバーの説明責任の範囲を明らかにすることで、何か問題が発生した際にも円滑に対応することができるようになります。
アジャイル開発においては、基本的に説明責任の範囲を重視しています。では、実際に責任範囲をイメージしやすいように、スクラムのロールを例に説明していきます。
== スクラムにおけるロールと説明責任
スクラムを構成するスクラムチームは、プロダクトオーナー、スクラムマスター、開発者という3つのロールに分けられます。ここからの内容は、スクラムというアジャイル開発のフレームワークについて理解していないと理解が難しいかもしれません。「スクラムよくわからん」という人は、軽く流し見ていただく形でいいかと思われます。では、各ロールと各々の責任について1つずつ見ていきましょう。
=== プロダクトオーナー
まず、プロダクトオーナーはプロダクトバックログについて説明責任を持ちます。スクラムガイドで定義されているプロダクトオーナーの責任範囲は以下の通りです。
//quote{
【プロダクトオーナーがもつ効果的なプロダクトバックログ管理】
・ プロダクトゴールを策定し、明⽰的に伝える。
・ プロダクトバックログアイテムを作成し、明確に伝える。
・ プロダクトバックログアイテムを並び替える。
・ プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
//}
また、スクラムガイドには以下の内容も書かれています：
//quote{
上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
//}
すなわち、プロダクトゴールの制定やプロダクトバックログアイテムの作成、並び替えや透明性の確保などの実行責任はプロダクトオーナー以外にも委任できるが、最終的な説明責任はプロダクトオーナーがもち、問題が起こったときには「チームでどのように対応していくか考えることにフォーカスを置いて」考え、それを説明する責任があります。間違っても、「自分はプロダクトオーナーじゃないから、プロダクトゴールとかはプロダクトオーナーに全部投げます」なんて思考はしないようにしましょう。
=== スクラムマスター
スクラムマスターはチームがスクラムの運営をできるようにすることに対して説明責任をもつ必要があります。すなわち、スクラムガイドという競技規則に則り、チームが正つねにスクラムを運用できていることを説明できるようになる必要があるわけですね。
スクラムマスターの役割としては「スクラムチームの支援」や「プロダクトオーナーの支援」などがあります。キーワードは「支援」ですね。では、スクラムマスターは具体的にどのようにして支援を行うのでしょうか。
スクラムマスターがプロダクトオーナーや開発者の支援をする際には、スクラムイベントの説明やプラクティス（チームがよりアジャイルになるための取り組みなど）の紹介をすることが多いと思います。しかし、スクラムイベントの開催やプラクティスを提案する際に、特にスクラム初心者のチームの場合、なぜこのプラクティスを提案しているのか説明しなければ乗り気になってくれません。チームが納得してスクラムを実践するために、スクラムチームは「透明性の確保→検査→適応」のプロセスを繰り返し行う必要となります。そして、このプロセスを繰り返し行うためにはスクラムイベントやプラクティスを活用するほかありません。つまり、これは「にわとりが先か、たまごが先か？」みたいな状態なわけですね。
長々と書いてきましたが、スクラムマスターはチームを支援するために、つねにチームに対して「Why」を問いかけることで透明性を確保し、スクラムイベントの必要性を説明し、チームがスクラムを運営できるよう支援していく必要があります。スクラムが運営できるようになるまでのプロセスはチームを構成する人や環境によって異なり、正解はありません。大切なことは、スクラムイベントやプラクティスがなぜ必要なのかを説明する責任になるわけです。
=== 開発者
開発者は、スプリントごとにインクリメントを生成することに説明責任をもちます。開発者の責任範囲には、 2 で述べた「実行責任」も含まれているように感じていますが、開発者が生成するインクリメントはあくまで「スプリントというタイムボックスの中で生成できる範囲」となります。ですから、開発者が持たなければならない責任とは、「スプリントバックログに示した内容をすべて完成させなければならない」という実行責任ではなく、「スプリントの中でどのくらいのインクリメントを生成でき、生成できなかったスプリントバックログの項目についてはなぜ完成できなかったのか」というところに説明責任を置くこととなります。
== 責任と一緒にでてくる「期待」
ここまで、責任のお話を多くしてきました。賠償責任は置いておいて、実行責任と説明責任においては「責任範囲を明らかにする」ことが大切ということをお伝えしました。そして、具体的にどのような責任の割り振りを行うのかということをスクラムのロールを例に説明していきました。
さて、突然ですが皆さんはだれかに「期待」したことはありますか？もしかしたら、この「期待」がチームを崩壊に導くかもしれません。というのも、責任の種類を意識し、責任範囲を明らかにするといっても、だれが責任を持っているかわからない問題が発生する可能性は十分考えられます。そのときに「これは自分の責任ではない」「Aさんの責任範囲っぽいし、自分には関係ない」などの行為をされると、問題が放置されてしまう結果となる可能性もあります。
だからといって「漏れがないように責任範囲を決めなければならない」というわけではありません。むしろその時間は無駄です。責任を意識する際には、現状得られている情報から考え得るリスクのみを明確にし、それらに対する責任の割り振りを行いましょう。そして、つねにチームの状態を意識し、問題が発生したときには「だれかが解決してくれるだろう」という期待で終わらせるのではなく、チーム全員が自分事として問題に向き合う必要があります。責任を意識するときには、このことを忘れないでください。
== おわりに
私たちは、「賠償責任」「実行責任」「説明責任」のいずれも一概に「責任」という単語で片付けることが多いです。そして、あなたが誰かに「責任」という単語を使った / 使われた場合には、もしかしたら「責任」という単語が違う意味をもっているかもしれません。責任分担などをした際には、「誰かがやってくれるだろう」という期待をしてしまう人がいて、問題が放置されるケースも考えられます。
これからチームでアジャイル開発する際には、「説明責任」にフォーカスをあて、必要十分な粒度で責任の範囲を明らかにし、チーム内で共通認識の「責任」を持てるようになるといいですね。
//embed{
\begin{minipage}{.1\linewidth}
\centering
\includegraphics[width=.75\linewidth]{images/Hisa.jpg}
\end{minipage}
\begin{minipage}{.89\linewidth}
Hisa @Ryuku\_Hisa https://twitter.com/Ryuku\_Hisa\\
\end{minipage}
\hspace{1ex}
//}
北海道のとある大学で大学院生しながら，東京のとある会社でリモート勤務しています．勤務先では組織開発職につき，コミュニティにてアジャイル開発に関する活動に参加．大学ではネットワークセキュリティの分野を研究．
国際チューター認証資格である ITTPC (International Tutor Training Program Certification) Level 1 を保有．
スノボとドライブとバスケが好きです．