bon now

開発の現場を任されて「やべぇどうしよ」とか思ってる新米リーダーのみなさんこんばんわ。 僕もそういう1人であった。そして現在もまた新たな局面であーだこーだあーでもないこーでもないと苦しみながら みんなで幸せに前に進めるような未来を信じて努力しているつもりである。
さて、今回は僕のそれなりに成果を上げた取り組みとその方法、 および僕の理想についてを記事にしたためてみたのでぜひ読んでもらいたい。

目次
・長い序章
・開発プロセスを改善するきっかけ
・見える批判と見えざる批判
・小さな改善
・やがてビッグウェーブへ
・分化と文化

長い序章

僕の仕事がプログラミングより圧倒的にマネジメント（チームリードやリーダーシップ）に重きが変わってきた。 プログラマ35歳定年説みたいな感じだ。まぁ開発プロセスの関係でKubernetesやインフラ、CI/CD環境などの整備をやってるので、 全くプログラミングをやらなくなったわけではない。Go言語も他の関数型言語もちょいちょいカジッているし、 キャッチアップを忘れないようにするため（今更だけど）NoSQLベースのMongoDBとかVueとかにも手を出している。
ただ、仕事となるとそっちよりもなんちゃってマネジメントに思考を走らせることが多くなってきたということである。

自分の能力として、プログラミングはオブジェクト指向がイマイチ分からないし、リファクタリングもある程度でええやんとか思っちゃうし、 なにより人の作った構造プログラミングが読めないのと、Ruby/Ruby on Railsの作法にそろそろついていけなくなっている。 多分頑張れば人並みにできるんだろうが、そういう努力もなぜかやらなくなってしまった。 これは、消極的な理由ではなく、僕の周りに、僕の代わりに十分プログラミングできる人たちが大勢いるからだろう。 僕がいちいち手を動かさなくても、同じ価値観、同じ思考で課題に挑んでくれる人がいるのは大変心強い。 それでいて、彼らが目に留めないような小さいけど将来絶対に面倒なことになる問題や、見て見ぬふりの臭いものに蓋の難題とかを、 頭を捻りながら何とかするのが僕の役目みたいになっているのである。
さて、今日はその問題のなかから開発プロセスに焦点を当てようと思う。

開発プロセスの改善をするきっかけ

組織によってまちまちだと思うが、開発プロセスを改善しようという流れに至るのにはだいたい2つに絞られると思う。
1つは現状がやばいということ。やばいというのは例えば「新しいリリースのたびに不具合が増える」とか「品質が安定しない」とか、 「リリースがいつになるかわからなくて感覚で作業してる」みたいな、プロセスそのものにいろいろな問題がある場合だ。 もう1つは開発の現場が変わってしまったということ。これは要するに「人が増えた」とか「人が減った」とか、 「そもそも注力すべき製品が変わった」とか組織全体で方向性・スケールを変えざるを得ない状況に陥った場合だ。

理由はともあれ両者に共通するのは、開発プロセスに関わる人全員が改善の対象ということである。 でも、多くの人は知っている通り、多くの人に同じプロセスをいっぺんにやってもらおうとか、そもそも今あるルールを変えることの困難さは途方もない労力を要する。

見える批判と見えざる批判

大きく物事を変えるとき、初めて顕在化するのが見える批判と見えない批判である。 前者はマネジャーや経営側から見えるので対処はしやすい。どういうものかといえば、例えばエンジニアの生産性だ。 生産性の定義も曖昧だけど、ここでは「1つの改修を顧客に届けるまでの工数」としよう。これが伸びた場合、プロセスの改善は悪い方向に向かっていることがわかる。 それに、エンジニア自身も、馬鹿でない限り自分で効率の悪さに気づくので、その点は不満として面談時やフィードバック時に返ってくるだろう。

じゃあ見えざる批判とはなんだろう。
見えざる批判は結局、エンジニアのモチベーションの低下とか、考え方の違いによる悩みだとかいう不安・葛藤など負の感情である。 こいつはかなり厄介で、実は見える批判に対しても影響を与えている事が多い。 というのも、エンジニアのプログラミングは創作活動の域であるため、モチベーションや集中力がそれに与える影響は計り知れないものがある。 だから見えざる批判に対する考慮がかなり重要になる。 つまり、大革命を起こすのであれば、エンジニア各人の見えざる批判を見える化する手立てを事前に考えておくことが必要ということである。

急いては事を仕損じると昔の言葉にあるように、急いでも仕方がないことはたくさんある。 僕はそう思っているし、実体験でエンジニアを救う手立ては大きな変化ではなく、日々のコミュニケーションでしかないと考えている。 大きな変化が改善するのはあくまで組織上の問題であり、それは人としてのエンジニアの解決策とは必ずしも一致しないはずだからだ。

小さな改善

ここまででわかるように、僕自身も突然の変化は苦手である。もちろん大いなる夢を語るのは素晴らしいことだし、 大きな目標を掲げてチーム一丸となって突っ走るのも青春さながらの素敵な行動だと思う。 しかし、ことはそんなにキレイなものばかりではない。大体の大改革には泥臭く、面倒で、大変な作業が待っているわけだ。 こういう作業に向き合うにはそれなりのモチベーションはどうしても必要である。

ここで、僕はなんちゃってだがアジャイルという仕組みを使って仕事をしていることを説明しておく。 そのアジャイルの原則の1つに「大きなユーザーストーリーは小さく分割しよう」というものがある。 わかりきったことだが、改善も同じである。

僕がおすすめするのは、まずは組織のなかのチーム単位で改革を進めるというものだ。 僕の組織も、チームをまず2分割してその片方、8名程度のチームから改革を始めた。 こうすることの重要性は以下の点に集約される。

• 失敗したときのロールバックの影響を少なくできる
• ルールが広まる時間を短くできる
• 改善のスピードを上げることができる
• 1to1のコミュニケーションの単位を減らせる

まずこの時点で失敗を考えるのか？っていう話ではあるが、やっぱり失敗したときの影響は少ないほうが良い。 改善はそもそもリスクテイクの1つで、新しいことが成功するとも失敗するとも言えないが、やるしかない状況下ではやるしかないわけである。 それに対してある程度のリスクヘッジをするのは理に適うと言えるだろう。

また、チーム単位で小さく始めることで、ルールそのものをすばやくチームメンバーに広めることができる。 従業員規模がでかいほど浸透するまで時間がかかる。いわば伝言ゲームみたいなものだ。最後の人にルールがちゃんと行き届くまで、 何度も何度も同じことを繰り返さねばならないとすると、途中で飽きるなり嫌になるなりするエンジニアだって出てくると考えられる。
(彼らを排除すれば問題は解決するって？　僕はその考え方には賛成しない。同じチームのメンバーが困っているのに、突然突き放すのは見えざる批判を助長させるからだ。)

そして小さく始めると意見をまとめやすいという利点もある。ジェフ・ベゾスが言うように「2枚のピザで収まらない会議はしない」とはこういうことだ。 人が多すぎると意見がまとまらず創造的で前進できるような意見は封殺されるか、時間がかかってようやくまとまるかのどちらかであろう。 効率よく生産的に物事を進めるには、一旦小さく始めることは重要である。

最後に一番重要な点として、対面のコミュニケーションの単位を減らせることを推す。これは本当に重要。 というのも、こういう改革をしよう！という場面で、大抵のチームはリーダーとメンバーが1対1で定期的に会話するミーティングなんて存在しないことのほうが多いと僕が思っているからだ。 実際僕もこの取組を最初からやっていたわけではなく、どう考えてもこの時間は必要だと後々感じたからである。
リーダー各位に問おう。あなたは、あなたの下で働いている社員の家庭の人の数、仕事に対する意識、最近喜んだこと、悲しかったこと、なんとかしたいと思っていることを、 すべて的確に言えるだろうか？　わからないのであれば、今すぐ彼らの本音を聞き出せるようなコミュニケーションを取るべきだ。 結局、エンジニアも人であり家族の1人である。そして馬鹿じゃない。みんながそれぞれの考え方で会社や組織の問題に向き合い、仕事をしているのである。 それを無視して組織の改革なんてできるわけがない。
(これは後々わかったことだが、Team Geekにも同じようなことが書いてあった。僕は意図せずそれを実践していた)

やがてビッグウェーブへ

日本人は村社会と言われる性質の通り、ステレオタイプな意見では「みんなと違うことを嫌う」といわれている。 それに従うとすると、改革が少しずつ進んである程度組織のスタンダードなルールになった場合、 逆にそうなっていない組織のメンバーは「あれ？俺たちちょっと違くない？」と違和感を持ち出すはずだ。 こうなったらあとは布教活動をするだけである。

これまで少数のメンバーにルールを教え込み、伝播されていった開発プロセスを、今度はリーダーのみならず、 そのメンバーそれぞれが広めていく役目を担うのである。 リーダーは宣教師を派遣するだけで済む。この頃のリーダーの役目は、今度は小規模に構築され完成したプロセスを、 今度は大きな組織単位に適用する上で問題となる部分やリスクに対して思考を巡らすことになる。

そうやって、結果的には組織全体の開発プロセスが確立し、1つのビッグウェーブができるのである。

分化と文化

最終的に出来上がった開発プロセスは、当たり前だが組織それぞれで最適化されるべく日々改善が進められる（はず）。 そうやっていくと結果的に「統一的なプロセスじゃなくて、我が組織はこのほうが正しそう」という結論にいたることもあるだろう。 そういうふうに1つのプロセス改革案が分化していくこともまた正しい。Spotifyだってみんながカンバンを使っているわけではない。 しかし、組織全体に共通するのは物事を日々改善していくという文化である。 これは早々簡単に消えるものではない。なぜなら、ここに至るまでに苦労して培ってきたプロセス改善のプロセスが、 組織を支える土台になっているからだ。そしてもちろん、それを頑張って続けてくれたエンジニアが共通した気持ちで仕事をしているからに他ならない。

さあ、明日からでも始めてみようではないか。新しい道を。

※1 HRTとは
参照記事: HRTの原則 ～ソフトウェア開発はバーでしっとり語り合うように ～

参考文献：
・カイゼン・ジャーニー
・カンバン仕事術 チームではじめる見える化と改善