後回しにしない組織はどう作る？論文『銀の弾丸』から紐解く「あの時やっておけば」と決別する方法【ログラスVPoE伊藤】

直近1年で組織が2倍に拡大。クラウド経営管理システム「Loglass」シリーズを開発・提供している株式会社ログラスは、社内外からしばしば「エンジニア組織が強い」と評されています。

「強い」とはどういう意味なのか？　2022年にエンジニアとして入社し、2024年6月に開発本部長／事業執行役員VPoEに就任した伊藤博志さんに詳しく聞くと、「“やった方がいいこと”をあとに残さない組織だと思う。そのおかげで“あの時こうしておけば”と後悔することが、すごく少なくなる」といいます。

やった方がいいとわかっていること、例えば組織体制の整理や評価テーブルの変更、いちエンジニアにおいては採用活動や技術発信、開発者テストなどは、取り組み始めてから目立った成果が出るまでに少し時間がかかるからこそ、「今じゃない」と見送らざるを得ないこともあります。そしてそれが、後々の開発にすごく響いてきて、後悔することもあるでしょう。

ログラスは、なぜそうなっていないと言い切れるのか？　その答えは、1986年に発表されたフレデリック・ブルックス氏の論文『銀の弾丸などない――ソフトウェアエンジニアリングの本質と偶有的事項』の考え方にありました。

• keyboard_arrow_down 後回しにしない＝「偶有的な作業」を溜め込まない
• keyboard_arrow_down 偶有的な作業に振り回されないようになると、より険しい道が待っている
• keyboard_arrow_down まずは「偶有的な作業」「本質的な作業」を整理するところから

――伊藤さんが入社した当初のnoteでは、ログラスの開発組織は「当たり前のことが当たり前にできる」と記載がありました。約2年経った今、どう感じていますか？

伊藤：抽象的な表現ですが、多くの組織で「やっておいた方がいいけど、今じゃない」と後回しにされがちなことを、ちゃんと日々やりきっていると思います。

スタートアップでありながら、初期からエンジニア全員で品質に責任を持ちテストを書いていたり、技術的負債の解消に一定のリソースを常に割いていたりします。これらは経営陣の判断によるものでもありますが、現場のエンジニアも「短期的には効果を測りづらいが、中長期的に効いてくる施策」を自主的に探し、取り組んでくれているように思います。

――多くの開発組織が悩みがちな問題を、先回りして解決しているのですね。なぜそのような動きができるのでしょうか。

伊藤：ソフトウェア開発に「銀の弾丸などない」という言葉があります。これはアメリカのフレデリック・ブルックスが1986年に書いた論文のタイトルが出自です。この論文の内容が、まさにその答えだと考えています。

この論文では、ソフトウェア開発には「本質的な作業」と「偶有的な作業」の2つが存在していると語られています。

伊藤：偶有的な作業というのは、プロダクトの本質ではない、いわば副次的な作業を指します。開発組織にとっては目に見えている課題であることが多いです。ビルドを早くするとか、技術的負債を解消するとか、品質に関する取り組みなど、「やった方がいいけど、今じゃない」とされてしまいがちなものを指しています。プロダクトの成長につれて、偶有的な作業はどんどん増えていきます。

では本質的な作業は何かというと、ユーザーのペインをシステムに落とし込むことです。ビジネスサイド・プロダクトサイド問わず、ユーザーのペインを追い求め、それをプロダクトによって最適な形で解決するために行う業務を指します。プロダクトがより良いものになるかは、どれだけ本質的な作業ができるか次第です。本質的な作業は、課題を見つけるところから始めなければならず、本当に難しいし、まとまった時間や人的リソースが必要です。これらを確保するには、偶有的な作業に振り回されているわけにはいきません。

つまり、本質的な作業に取り組むために、偶有的な作業を溜め込まないようにする必要があるのです。そのために経営メンバーは「短期的には効果を測りづらいが、中長期的に効いてくる施策」に投資しています。現場のエンジニアもこの考え方に基づき、目に見えている偶有的な作業に、自律的に取り組んでくれています。

――偶有的な作業を溜め込まないために、現場ではどんな工夫をしているのですか？

伊藤：いわゆる「ベストプラクティス」を愚直に実践するようにしています。

例えば、常にリファクタリングに取り組むとか、開発者自身がテストコードを書くというのは、その取り組みの有効性が広く認知されているからこそ、世の中では「ベストプラクティス」といわれています。これらを「当たり前にやるべきこと」として実践しながら、さらにどう改善していくかを考え、ブラッシュアップしていくのです。

例えばテストの整備を進めることはもちろん、テストを書くスキルを向上するための輪読会も有志で行っています。また「シフトレフト」と呼ばれる、開発サイクルのより早いフェーズで、テストの観点から仕様を確認したり、テスト設計を行ったりするような取り組みも実施しています。

こうした取り組みは、メンバーが増えても、入れ替わりが起こっても、プロダクトがある限りずっと続けていくべきです。そのため組織の文化として根付かせていかなくては、と考えています。

――偶有的な作業を溜め込まないようにするという考え方は、どういった背景から生まれたのですか。

伊藤：当社の経営レイヤーやEMには「2周目エンジニア」といいますか、過去に偶有的な作業を溜め込んだことで苦しんできたエンジニアが、創業期から数多く集まっているからだろうと思います。

彼らはそれぞれ過去に、偶有的な作業に対する「やった方がいいけど、後で」を繰り返した結果、「あの時ああしておけば」と強く後悔した経験を持っています。そして私自身も、その一人です。

あの後悔を繰り返したくないという強い思いが原動力となり、プロダクト開発における中長期的な課題に、日々自主的に取り組み続けるのが当たり前になっています。VPoEとしては、こうした開発組織の文化によって、助けられている部分が多々あります。

しかし、私自身に限って言えば、実は過去のキャリアを振り返っても、正直今が一番しんどいと言えるかもしれません……。

――なぜそう思うんですか？

伊藤：ログラスで取り組んでいることは、過去に経験していないことばかりだからです。偶有的な作業をある程度片付けたうえで本質的な作業を見つけることも、そうして見つけた本質的な作業に取り組む優先順位付けも、過去にやったことがない。なぜなら、偶有的な作業を溜め込んでいない開発組織で働いた経験がないからです。

偶有的な作業に振り回されてる間は本当につらいですが、ある意味ラクでもあるんです。やるべきことが目の前にたくさん転がっている状態だから、それをどう片付けていくのか考えて実行するだけでいい。

でも本質的な作業は顕在化していないことがほとんどですから、やるべきことを見つけるところから始めなくちゃいけない。顕在化していないものって、見つけるのはもちろん、探し続けるのも、ものすごくパワーが要るんです。「顕在化している課題がないから、今のままでいいんじゃないか」と思ってしまう気持ちと、戦い続けることになりますから。

――「顕在化していないけれども本質的にやるべきこと」は、どのようにして探しているのでしょうか。

伊藤：私がVPoEとして主に担当している組織と技術においては、未来から逆算して、今やっておくべきことがないか探しています。例えば「〇年後にはエンジニアの人数が〇人になる。今何もしなかったら、きっとこうなるだろう。だったら今これをやっておくべきではないか」といった具合に。

過去の経験を生かすとすると、今ある課題をフックとして、それが今後どうなるかを予測して打ち手を考える、といった頭の使い方をすることになります。しかし当社では、今ある課題は現場のエンジニアが自律的に解決してくれているから、未来の課題が見えづらくなっている。過去にやっていた方法が通用しないので、開発組織のあるべき姿を定義して、それにどう近づいていくべきかを考えなくてはなりません。

――伊藤さんが今までに経験した「本質的な作業」では、どのように課題を見つけ、どう解決したのですか。

伊藤：組織における例を挙げましょう。今後予定している、開発組織の急拡大の後を考えたとき、今まで「やって当たり前」として明文化されていなかった、偶有的な作業を溜めないための取り組みなどが、拡大とともに薄れていってしまうのではないかと危機感を感じました。

今まで培ってきた開発組織の「当たり前」を文化として継承していくためには、明文化し、浸透させていかなくてはならない。そう考え、開発組織の価値観をまとめたものをつくるべく動きだしました。

そして2024年の2月に、「Update Normal」というTech Valueを策定しました。当社の開発組織が共有している価値観を、「顧客への本質的な価値提供」「学びと適応」「技術的卓越性の追究と還元」という3つに分解し、これらに関する「当たり前基準の高さにこだわり続けたい」という共通の価値観を言語化したのです。

また、今取り組んでいるのは、プロダクトの成長を見据えた組織体制の変更です。ユーザーや機能が増えると、偶有的な作業も一気に増え、自助努力で減らすのが難しくなってくるはず。となると、今やっているように「全員が少しずつ」といった方法ではなく、偶有的な作業に注力する組織も必要になるでしょう。今はそうした組織変更を見据えて、組織の設計をしているところです。今のチーム構成が少し変わる可能性もありますから、メンバーにはそれなりに負荷がかかってしまうだろうと思っています。

――現場のメンバーにとっては、偶有的な作業に日々向き合ってる中だからこそ、未来を見据えた取り組みについていけないと感じてしまうときもありそうです。

伊藤：その通りです。メンバーにとって、私の言葉がピンとこないのは当然だと思います。私の役割はn年先に生じうる課題を今から解決しておくことであり、メンバーの役割は今ある課題を解決すること。見ている時間軸が違うから、「なぜ今その話を？」といった反応になることもしばしばあります。

――メンバーには、どうやって理解してもらっているのでしょうか。

伊藤：私にできるのは、私が見ている景色を伝えることだと思います。実は今回のような抽象的な話も、約1年くらい前からメンバーにときどき話しています。今すぐには伝わらなくても、時間をかけて少しずつ伝えていけば、メンバーにとって「あのときの話って、これのことだったんだ」と合点がいくタイミングがくるはずですから。

また私は、CBDOの斉藤が言っていた「合議で決めたいわけではないけれど、集合知で助けてほしい」というスタンスがとても好きで、真似するようにしています。

どんな課題でも、トップダウンでメンバーにお願いするのではなく、メンバーの集合知に助けてもらいながら、最適な解決方法を見つけたい。その結果どんな方法をとるのかといった決断は、経営レイヤーが責任を持って背負う。経営の視点から組織や技術をマネジメントする私たちが、このスタンスであり続ければ、現場に責任を背負わせない形で、メンバーに助けてもらうことができるはずです。そうして1つずつメンバーに助けてもらう中で、メンバーにも、私たち経営レイヤーがやりたいことや見ている景色が伝わっていけばいいなと考えています。

――偶有的な作業に対して自律的に動けたり、本質的な作業にも取り組めるようになるための雰囲気づくりに重要なのは、やはり組織のカルチャーや価値観なのでしょうか。

伊藤：元も子もないことをいうと、そうだと思っています。『銀の弾丸などない』というように、単純な解決策は本当になくて。創業期から積み上げてきたカルチャーによるところも大きく、私が途中から自分ひとりでこの状態をつくり上げるのは無理だったはずです。

――そうなると再現性は乏しいのかもしれませんが、とはいえ一部でも真似できるヒントはありませんか。

伊藤：まず「本質的な作業」と「偶有的な作業」を明確に意識するところがスタートラインになると思います。今の組織の動き方を改めて整理すると、偶有的な作業の多さに愕然とするはず。「本質的な作業にまったく向かえていない」という事実に向き合うのは結構タフなことです。

本質的な作業に向き合いたいと思ったら、ビジネスサイドとプロダクトサイドの適切なコミュニケーションは必須で、場合によって組織を変える必要も出てくる。多くの人を巻き込んで、変える意義を説明して、力強くそこへ向かっていく。もし私がログラス以外のそういう組織にいたら、そうすると思いますよ。やっぱり本質的な課題に向き合っていかなければ、プロダクトをつくる意味がないと思っているから。ただ、ものすごく大変だから、簡単に「やってみなよ」とは言えないですね。

――組織を変えるのも大変なら、変えた先で本質的な課題に取り組むのも大変。価値あるものを届け続けるのは、平坦な道ではないですね。ちなみに開発組織を拡大しながら、このハイパフォーマンスをどうやって維持していこうと考えていますか。

伊藤：私たちが考える「プロダクト開発とは」を伝え続けることに尽きるのかなと思っています。

私たちは、当社にとってのみ最適な価値観をつくりあげるのではなく「プロダクト開発とは」を言語化しようとしています。私たちの発信に共感してくれる人が増えれば、きっと日本におけるプロダクト開発はもっと良くなっていくだろうと信じています。さらにはそこから当社に共感し、「ログラスで働きたい」と思ってくれる人も増えてくれたら嬉しいですね。

取材・執筆：古屋 江美子
編集：光松 瞳
撮影：赤松 洋太