社長のブログで紹介されてました

2024 年の 1 月より SIVA という会社で働いています。

フクロウラボに引き続きまたも広告系の会社でして、別に業界的に広告系にこだわりがあるわけではまったくないんですが、妙に縁があるようでして…。

そんな中、なぜか社長が運用しているブログで自分が紹介されていました、誰か教えてよ！！

トップダウンにならないように気をつけていたらトップダウンになってしまった話

URL がかわいいですね、notopdown はセンスがすごい。

URL はさておき、まぁなんか偉そうなフロントエンドプログラマーが SIVA に入社したみたいですね。

「この会社はボトムアップが無い、トップダウンな雰囲気を感じます」

とか、

「トップダウンが無いからボトムアップもないんだと思います。命令されるトップダウンと言うわけではく、トップがもっと現場にゴールやビジョン、課題を表明して下に考えさせるトップダウンがないと下は「関心を持たれてない」と思うし、そうなると「意見を言おう」となりにくい。そうなるとボトムアップは生まれず、良くない無関心なトップダウンになると思います」

とか、よくもまぁ面接時に CEO に対してこんな偉そうなことが言えるプログラマーがいるもんですね、顔を見たいもんだわ。

茶番はともかく、自分はフロントエンドプログラマーなので、仕様的なフローで考えるとポジションは一番下になります。

たとえばスクラム開発を導入した場合、以下のようなケースは一般的だと思うのですが。

【上流】CEO ↔ CTO（ステークホルダー）↔ プロダクトオーナー ↔ 開発メンバー（フロントエンドプログラマーなど）【下流】

CEO から開発メンバーに仕様が降りてくるのがトップダウンで、開発メンバーから CEO に要求や要望が上がるのがボトムアップになります。

で、ボトムアップ、つまりステークホルダーやさらに上流のメンバーに対して開発メンバーの声が上がるというのは非常に重要だと思っていまして。

現場レベルの問題や課題感というのは、開発メンバーが声を上げなければプロダクトオーナー以上のメンバーはそれに気づくことができません。

たとえばデータベースの設計が悪いとか、必要なテストが書かれていないとか、バグがあるとか、実装が汚いとか。

例を挙げたらキリがないのですが、とかくこういった現状をしっかり上流のメンバーが把握しておくことが大切なわけです。

なぜなら、上流のメンバーは基本的に『開発は円滑に進むものだ』と思っています。

が、現実はもちろんそんなに甘くなく、基本的には予定通りに進みません。

ではなぜ予定通りに進まないのか、理由はさまざまあるのですが、大きな理由の 1 つにボトムアップが弱いケースが挙げられます。

ボトムアップが弱いから上流のメンバーは『開発はうまくいっているのに速度が出ない、ということは人が足りないんだな』という結論に至って採用を進めます。

で、採用を進めた結果人が増えるのですが、そもそも上に書いたような根本的な問題が解決されていないので、コミュニケーションコストが嵩みさらに開発速度が落ちていきます。

アホですね、でも会社の規模感を問わず、日本の開発の現場なんてこんなのばっかりです。

ではボトムアップを円滑に回すために必要なことはなにか、それはトップダウンをしっかりと行うことだと思います。

トップダウンを嫌う人って比較的多い印象がありますが、個人的にトップダウンってめっちゃ大事だと思います。

先のポジションの例でいうと、上流のメンバーから仕様が降りてきてはじめて開発メンバーは開発を始めることができるわけで。

上流のメンバーから仕様が降りてこなければ開発メンバーは身動きがとれないわけです。

ということは、裏を返せば円滑なトップダウンが絶対に必要なわけで。

おそらくトップダウンが嫌いな人というのは、トップダウンが嫌いというよりは、円滑でないトップダウンが嫌いなんだろうなーとなんとなく推測しています。

トップダウンというのは「あれをやれ」「これをやれ」と指示を出すことではありません、そんな指示を出されたら下流のメンバーはムカつきますよね。

トップダウンというのは、仕様を降ろすことも含めてフィードバックを返すこと、つまり上流と下流のメンバーがフラットにコミュニケーションを行うこと、ここが 1 番大切なのかなーと思います。

自分の場合、創業から数年経ったベンチャー企業から「開発チームにスクラムを導入してほしい」とか「ジュニアメンバーの育成をしてほしい」とか「実装が悪いからプロジェクトを立て直してほしい」といった理由で呼ばれることが比較的多かったりします。

で、こういった問題の解決に尽力するのですが、こういうケースでは意外と上流のメンバーがボトルネックになっていることが多いです。

経験上、上流のメンバーが「プロダクトの具体的なビジョンを持っていない」ケースが多く、下流のメンバーからしてみれば『持てよ！！』としか思えないのですが。

上流のメンバーがプロダクトの具体的なビジョンを持っていないからリプレイスでお茶を濁すケースってめちゃくちゃ多いよなぁと個人的には思います。

ただビジネス的に考えて、リプレイスってあんまりマネタイズに繋がらないですし、会社にとってはむしろデメリットになるケースのほうが多い気がします。

だって既存のプロダクトは問題を抱えているかもしれないですが動いているわけですから、それならリプレイスなんかせずに新たなプロダクトを作ったほうが単純に得じゃんと。

とはいえこれは起業すらしたことないパンピープログラマーの戯言でしかないので『そんな簡単な話じゃないんだよバカタレ』と思われたら、それはそれでしょうがないかなと。

話をまとめると、ボトムアップを発生させるためにはトップダウンが必要であって、トップダウンを行うためには上流のメンバーがプロダクトに対する具体的なビジョンを持つことが重要だと思います。

でもプロダクトに対する具体的なビジョンを持つのって難しいですよね、難しいんですかね？こればっかりはよくわからないんですが。

【Yes &】で考えるなら、とりあえずやってみるってスタンスが重要だと思います。

ゆえに上流のメンバーはプロダクトに対して具体的なビジョンを持つためにはどうしたら良いのか、そこで自分も力になれたら良いなーと思う、今日このごろです。