この記事は ANDPAD Advent Calendar 2023 の 7日目の記事です。
1年ぶりの登場となります、後藤です。 全然こちらではネタを書かずに1年経ってしましました。おかげさまで毎日忙しく組織課題に立ち向かっています。 そんな中で今日は少し一般論的な話にもなりますが役割と責任みたいなネタを整理したものを書いてみようと思います。
ResponsibilityとAccountabilityで語られるような話です。 だいぶ前の話なんですが、社外のCTOの方とお話しをさせていただく機会があった時に似た話になったのと、EMFMというpodcastの話とつながって、そういうことかーとなった話なのでまとめて書いてみました。
この概念は元々存在していて、RACI図とかにおけるRとAに相当します。言葉尻だけでインターネットで調べてみると色々出てくると思いますが、今回ここで私が書こうと思っている考え方というか、捉え方をまとめてみたいなと思います。
2種類の責任
- 説明責任（Accountability）
- 実行責任（Responsibility）
仕事における責任はものすごく大雑把に言えば、上記の2種類しかないと捉えています。 役割や職位によってこの割合が自然と変わってくるのが組織上の責任分担のメカニズムになっています。 役割や職位が高くなればなるほど、実行責任よりも説明責任の方がその責務の重要度が増してくるわけです。
説明責任（Accountability）
「上司が責任取ってるな」的な感じでみんなが比較的イメージするのが、”何かやらかして更に上役の人に自分の代わりに怒られてる”みたいな状態をイメージするんじゃないかと思います。 実際のところでは、まあまああってますが答えとしては△。これはネガティブな局面だけですし、さらに責任のポイントがズレています。 ズレてるポイントとしては、怒られることが責任を取っていることではなく、その前段で「報告」という形で説明をしているというところが本質的に果たしている局面です。 結果として、怒られていたりそうじゃなかったりと言う所しか見えてないので、そう見えやすいですがちょっと違います。
ポジティブというか平時における説明責任というと、最も分かりやすく会社として最も大きな説明責任を果たしている場は「株主総会」でしょう。 取締役という最も重い説明責任を負う役目を負う人が株主に対して、会社の業績や今後の方針等を説明し、今後の企業運営の信任を得るという行事です。 兎に角相手に説明し理解してもらうこと、その説明通りを組織全体として実施し達成すること、その結果をまた説明し理解してもらうの繰り返しです。
実行責任（Responsibility）
実行責任は、お願いされた事託されたことや任されていることに対して、求められる（＋α？の）成果を出すというところです。 エンジニアであればコードを書いて求められている動くものを期限内に作るというところ、確実に運用し続けるなど状態としての結果が出るものに対して責を負います。 多くの場合で、日常で仕事をしているケースにおいてはほぼこちら側が多いだろうと思います。 説明責任と実行責任の関係性を図を書いてみましたが↓こんな感じ。横軸がその責任の割合です。
つまり現場に近ければ近いほど実行責任が重要視され、職位が上がれば上がるほど説明責任が重要視されます。
職位別の責任
新入社員・駆け出しぐらい
新入社員として社会人になると、例にもれず「ホウレンソウ」とか言われますし、言います。ここには2つ意味があります。
今後役割として職位が上がってくると必ず説明責任側の割合が増えてくるので、若いうちから業務上のコミュニケーションを鍛えましょうという話が一つ。 もう一つはそもそも新卒と一緒に仕事をする先輩が、上長への説明責任や自身の実行責任を果たすために状況を知りたがっている。が故に、報告が必要であるという状況です。 それぞれの職種によるスキルの獲得というところは、実行責任を果たすために必要であるということそのものが前提として自明ですが、組織の中で必要なコミュニケーションの部分に関してはあまり自明ではないので、ことさらどの職種でも口酸っぱく言われます。 但し、そこが実際の責任領域としてはものすごく小さいため、いまいち理解しづらい、それを怠ったときに発生する状態がイメージしづらいということになります。 結果としていくつかの失敗を経ることによって、その必要性を徐々に認知していきます。
中堅クラス
徐々に実行責任そのものは果たせる状態であり、なんなら自分に求められることは一通り全部出来るという状態にもなり得るタイミングだと思います。 この時もまだ、説明責任よりも実行責任の方がその割合が大きいので、説明するぐらいなら作ってしまって見せたほうが早いみたいなことが往々にして発生します。 そんなまどろっこしい説明責任果たすぐらいなら、それよりもチャッチャと手を動かして重要度が高い実行責任を果たしてしまった方が手っ取り早いというわけですね。 なんとなくそれでも仕事は成立しますし、評価もそれなりにされます。それはそれで大丈夫です。
リーダーなど横断的な役割を担うクラス
このあたりから徐々に変わってきます。アンドパッドでは、例えばプロダクトテックリードというロールがありますが、この辺りに該当して来るのかなと思います。概ね実行責任と説明責任がトントンかやや説明責任側が重くなるイメージです。 でも、なんかヤバい時には自分の腕っぷしで何とか乗り越えてチームとしての実行責任を果たすみたいなことでも乗り越えることが可能な領域です。 図にするとこの赤い帯ぐらいがリーダークラスになります。
結果として、この役割ぐらいから求められる責任の比率が説明責任の比重が大きくなり始めるので、みんな「最近コード書けない」「ずっと調整ばっかりやってる」と感じる状況になります。 これはアンドパッドだけではなく多くの開発チームでリーダーシップを発揮されている人は共通して抱えているのではないでしょうか。
もうこれは多人数で役割分担して責任分担をしている以上、構造上そうなるメカニズムです。結果としてこのあたりで違和感が出る事もあるかと思います。 基本的にこれ以降は手を動かすということも必要ではあるものの、仕事の役割としての実行責任は徐々に少なくなってきます。 ただし、その一方でその説明責任をきちんと果たしたり、チームのメンバーに実際の仕事を託すのにあたって、該当個人もそれ相応の技術力を有している必要があります。 チーム外のステークホルダーへの説明だけで足りるわけでもなく、チームのメンバーとっても、なぜやるのか、なぜこのやり方のか、なぜこれだと良くて、これだとダメなのかということを説明する必要があります。 この辺りはアンドパッドではDesignDocという形で仕組み化もしているので、みんな意識できている部分もあるのかなと思います。良い制度ですよねー。
まとめ
エンジニアのスキルセットの話やキャリアの話になるとどの技術で食っていくかとかそういうことはよく記事としても見かけると思います。 それらの話は上記の図の青色部分の話が大半なのですが、実際にはあまり語られていない緑色の部分もキャリアを構成していくうえで大切かなと考えています。
周囲への説明をして納得してもらって巻き込んでいくというところに関しては実際のところ職位はそれほど関係なく日常的に発生していたりするものです。 「今は現場だからまだいいや」ということではなく、それぞれ今の立ち位置の中でもこれらの役割、責務を少なからず持っていることを意識してコミュニケーションを図っていくことが自分の望むキャリアへもつながっていくのではないかと思います。 この説明責任を果たせている状態の一部が、世にいう「コミュニケーション力」や「巻き込み力」を発揮できている状態だと思っています。 必ずしも、人との会話が上手い、すぐ友達になれるとか、そういうことがコミュニケーション力が高いということではなく、 この説明責任を果たせているかどうかであり、そして会話が上手い人、友達を作りやすい人はその状態を作るのが比較的上手であるというレベルのものです。 上手くコミュニケーションは取れなかった時、その瞬間において、何が大事だったのか、自分には何を求められていたのかを考えてみるのも良いのではないかと思います。 これはセンスなど先天的なものではなく、「スキル」であり誰でも身につけられるものではあるということなので、意識できるといいなと思います。
最後に
アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。 会社や事業、開発チームにご興味を持たれた方は、下記のサイトをぜひご覧ください。
