リソースの限界とステークホルダー

スクラムマスターとしてのキャリアをぼちぼち積みつつある自分ですが。

スクラムを回すにおいて、開発の序盤はプロダクトオーナーがボトルネックになりやすいのかなーと思うのですが、開発の終盤に差し掛かってくるとほとんどのケースでステークホルダーがボトルネックになっていると感じるのは、個人的に非常に興味深いです。

多くの現場において、ステークホルダーは CTO あたりが割り当てられるケースが多いのかなと思うのですが。

どこの現場もそうなんですが、ステークホルダーってスクラムを正しく理解しようとしないのが不思議です。

自分は大丈夫って思っちゃうんですかね？個人的にはあまり理解できません。

確かにステークホルダーはスクラムチームの外側のロールであるため、一定理解の余地が残されていると言えなくもないのですが…とはいえスクラムマスターとしては、ちゃんと理解してほしいと強く思ってしまいます。

で、やっかいなステークホルダーの例として、スクラムチームの実力以上のことを頼んでくるケースというのが挙がります。

自分がもっとも目にしてきたケースとしては、開発メンバーの実力がそこまで揃っていないにも関わらず、ややこしい仕様のタスクをおろしてくるとかあるあるかなと。

他にもめちゃくちゃてきとうなタイムスケジュールでタスクを振ってきたりなんかもよくある話ですよね。

上記の話より、しばしばステークホルダーとスクラムチームが、とくにプロダクトオーナーが対立関係になるケースも目にしますが。

同じ会社の仲間なんだから、対立や派閥なんか作ってる暇があったりさっさと解決方法を模索せーやと思わざるを得ないのは自分だけですかね？

会社からお金をもらっている立場だということを忘れがちなのは正直わからなくもないですが、その先にいるエンドユーザーのことを考えたらとてもじゃないけどそういったプロセスは経ないだろうと。

改めてスクラムマスターとしてスクラムを回していると、当たり前ですがスクラムチームごとに持ち合わせているマンパワーが存在していて、それを自分はリソースとよく呼んでいるのですが。

それは同時にステークホルダー側にもリソースが存在するわけで、ステークホルダーもまたカイゼンを繰り返して成長していく必要があるよなと、常々感じます。

リソースの限界を遥かに超えたトップダウンやボトムアップを発生させるべきではないわけです、個人的には言わずもがなだと思うのですが。

これができて日の浅いスタートアップやベンチャー企業であればなおさらなわけで、一人一人を尊重する一方、一人一人がスペシャリストとして力を発揮する必要があります。

特に開発なんかは絶対に一人で完結させられるものではありません、フルスタックなんてもってのほかです。

今の時代、どれだけ情報や AI が発達しようとも、まだ一人で多くの人にインパクトを与えられるプロダクトが開発可能な状態には至っていないと思っています。

これがスタートアップやベンチャー企業であったとしても、短期的な目線でプロダクトの開発を行い過ぎてはダメかなと。

創業当初にテキトーに作った結果負の遺産となってしまったモノが延々足を引っ張ってしまっているケースは嫌と言うほど目にしてきました。

今ドワンゴがランサムウェアによってサービスが落ちているのも同じことだよなーと思っていまして。

十中八九、内部のエンジニアの何人かは間違いなく脆弱性に気づいていたはずです。

が、そこでトップダウンならではの『まぁなんとかなるだろう』とか『自分には関係ないし』みたいな思考が走って放置されていたのは間違いないかなと。

例えばニコニコ動画などは歴史が深く、かつ日本有数の動画サイトであるがゆえに、脆弱性をきちんと修正するコストはかなり大きかったと思われます。

それでもちゃんと対応しなければいけなかったはずで、まぁもう後の祭りですね。

自分は常々「自分たちの身の丈にあった技術選定や開発フロー、プロジェクト進行を選択しましょう」と言っています。

よく仕事における開発をお試しの場だと勘違いしているバカが多いですが、会社に失礼だと思わないんですかね？もちろん程度の話もありますが。

ともかく、背伸びというのは基本的にしてはいけません、背伸びしたいときはそのヒトをちゃんとマネジメントできるヒトがいて、初めて許される行為だと思います。

それがスタートアップやベンチャー企業であればそこまでの余裕なんてありません、これは言わずもがなだと思うのですが。

一方、マネジメント側もリソースを意識して行うべきです。

まずなによりも自身の性格やコミュニケーション能力を把握し、トップダウンとボトムアップを円滑に回すことを意識することが大切です。

そのうえで開発を円滑に回すためにどういった採用を行うべきか、スクラムチームが間違った方向に進もうとしていないか、自身がスクラムの理解を行わず、スクラムチームの足を引っ張っていないか。

自身のタスクとこなせるタスク感のバランスを図りつつ、バランサーとしてうまい具合に物事を運べるよう、日々精進すべきかなと。

ドワンゴのケースもそうですが、どこかのタイミングで『この脆弱性は本当に放置して良いのか？』と気づくことができれば、このような大惨事は引き起こされなかったはずです。

開発チームにおいてリソースの総量は各々のリソースを足した合計値には残念ながらなりません。

どうしても技術力が低いメンバーがいたり、コミュニケーション能力に欠けたメンバーがいたり、能力の高い人は低い人に一定合わせてあげなければいけません。

もちろん性格の合う合わない、思想の合う合わないなど、様々な要因が絡み合ってリソースが定まる以上、少人数のプロフェッショナルで固めるのが得策なのは言わずもがなです。

また日本は終身雇用制度であるがゆえに、ますます採用は慎重に行わなければなりません。

自分がマネジメント側だとしても、自分がプレーヤー側だとしても、常に成長を意識することが重要だよなーと。

とくにマネジメント側がボトルネックになっては悲惨です。

自分もぼちぼちアラフォー、マネジメント側になることもかなり増えてきました。

もっともっと成長しないとあかんなと強く思う、今日このごろです。