システムの悪い部分やバグを生み出しているものはなにか？　開発者を置き去りにしないDXの考え方

バグやシステムの悪い部分を生み出しているものはなにか？

広木大地氏：好きなことってなんだったんだろう。最初は、いいコードを書きたい、悪いコードをリファクタリングしたい、もっと良いサービスにしたい、もっと社会のためになることをしたい、もっとみんなを驚かせたいと考えていました。そのための仕組みや仕掛けやライブラリなど、いろいろなものを考えて作っていこうと。

一生懸命やっていく中で、技術的なものはある種の手段だけど、手段にこだわるのも愛だ。愛のない目的は無意味だし、その逆もそうだなと思うようになりました。自分の中でやりたいと思うことや、好きだと思えること。ハンマーを持ったら全部釘に見える話を避けながら、ハンマーが好きだ、使ってみたいと思う技術者魂はとても大事だと思っています。

いい物を作るために、背後にあるバグやシステムの悪い部分を生み出しているものはなにかと考えたら、組織や文化だと感じるようになってきました。

ソフトウェアの開発効率をよくしたい、ライブラリや仕掛けを作っていきたい。そのためにはなにか問題を定義しなければいけない。その問題ってなんだろうと深掘りしていくと、どうしても人間関係の複雑さが入り込んできて。人はそういった構造の前では論理的や完全にロジカルではいられないから、その構造に従ってしまう。

今は“逆コンウェイ戦略”などと言いますが、当時も“コンウェイの法則”という言葉自体はありました。組織の情報構造はシステムのフレーミングを規定してしまい、その逆の、システムの構造は人の思考をフレーミングする。僕には組織自体も、大学院の時にやっていた分散システムの問題に見えたんです。

そう考えると、生産性を上げるためには、どうすればロックフリーにできるかとか、どうすればコンセンサス問題を解決できるかとか。プロジェクトでもアムダールの法則が成り立つとか、分散システムで培ってきた考え方やアルゴリズムの考え方が、組織にも適用できそうだと気づいていきました。

そうすると、システムを作ること、組織を作ること、経営することの背後にあるなにかが、実はとても重要な、統一した法則なのではないか、これを解き明かしたい、この部分を深掘りしたいと考えるようになります。

当時は、ある程度まで行ったら、スペシャリストとして人生を歩むか、マネジメントになるかをキャリア選択し、技術者としてがんばりたい人や成果を出した人はスペシャリストになっていきました。

僕はスペシャリストのキャリアを歩んでいたけれど、マネジメントに転向しました。組織の考え方、思考、組織自体をリファクタリングしなければいいものは生み出せないし、いいコードは生まれない。いいコードを生み出すためには、それをやらなければいけないと考えるようになりました。

組織の“知の深化”と“知の探索”

小野（小野和俊氏）さんのバイモーダルの考え方にすごく近いものとして、“両利きの経営”があります。組織には“知の深化”の部分と“知の探索”の部分があります。深化の部分とは、同じようなタスクを持っている人たちや、同じようなキャリアを歩んできてスペシャリティを持っている人たちが集まって、どんどん深めていく。

例えば、車のエンジン開発をする時はエンジン部門の人間が集まって作り、タイヤの開発ならタイヤ部門の人間が一生懸命タイヤを作る。いいタイヤといいエンジンが生まれるのは、タクス型ダイバーシティが低いケースです。

逆に、知の探索という新しいイノベーティブなところをやっている時は、同じことが得意な人たちばかりではなく、バラエティに富んだタクス型ダイバーシティの高いチームを作ってやっていくと、イノベーションが生まれることがありました。

当時のミクシィにもイノベーションが生まれづらい構造があったので、深化に寄っている部分を探索に寄せていき、イノベーションを戻そうと試みました。そうすれば、その競争環境が変化しても戦うことができるだろうと思いました。

組織の構造を変えたり、イノベーションを生み出せるように、組織を転換していかなければならない。当時はロックフリーな開発など、ロックフリーなことをできるようにしたいと考えていましたが、決裁ルートが果てしなく長ければ遅くなってしまう。

それを、早く決断や行動ができるように増やそうしていたんです。この時、システムの組織戦略のチェックリストを作っていましたが、これがのちに「DX Criteria」として公開され、CTO協会に寄贈するようになっていきます。この元ネタの元ネタは、この時にいろいろ考えていました。

退社後に執筆した『エンジニアリング組織論への招待』

会社自体は持ち直しましたが、小学校以上に長くいたなと思い、退職して次のことを考えるようになります。当時、会社を辞めたら海外留学にでも行く人が多かったんですが、「あまり意識を高いままにすると大変だ、沖縄にでも行ってゆっくり過ごそう」と、高まった意識を下げるため、沖縄で1、2ヶ月サバティカルに過ごそうと思って行きました。

じっくり本でも読もうと思いましたが、海が青すぎて遊んでしまって、気づいたらどんどん沖縄の事情を調べて、国際通りの坪単価を調べて、ハーバーに余っているヨットを「Uber」のように貸し借りできるシステムを作れないかと考えて、パートナーを探したりしました。

「仕事っぽいことをしている」ことに気づいて、これは戻んなきゃと思い、1年ほどいろいろなスタートアップの支援をして、レクターという会社を創業しました。技術と経営、組織とアーキテクチャの間には、解決できていないさまざまな問題がある。システム開発と組織を取り巻く問題の、メカニズムを解き明かしたいと思ったんです。

そこでいろいろな事例を見ていく中で、『エンジニアリング組織論への招待』という本を書きました。自分で言うのもなんですが、けっこうおもしろく書けたと思っているので、ぜひ読んでほしいです。

前文を紹介すると、「エンジニアを取り巻く環境にはさまざまな問題があって、いつまでも堂々巡りの議論をしてしまう。上司と部下のコミュニケーションはなぜ失敗するのか。イケてるはずのアジャイルやリーンがなんでうまくいかないのか。なぜプロジェクトは炎上し、スケジュールどおり終わらないのか。なぜ技術的負債が問題になるのか、その正体はなんなのか。経営者とエンジニアの認識はなぜ食い違うのか。

これらの根源は、“わからない”ことに対する不安で、未来や他人の考えていることはわかりません。ですから、問題なのはちょっとしたきっかけから作られた“構造”であって、誰かが悪いわけではないのです」。

この“わからないもの”に向き合って、その不安を競争力に変えていくことが、エンジニアリングにとって重要な思考です。その考え方を持てば、“不確実性に向き合う”というたった1つの原則から、エンジニアリングを取り巻くソリューションとして長らく語られてきた諸問題を、統一的に語れるのではないかと考えて書きました。ぜひ読んでみてください。

この本はたくさんの反響があり、技術書やビジネス書の大賞を受賞し、いろいろなCTOの方からもフィードバックをもらいました。たくさんの人から共感と応援の声をもらったことで、ビジネスと技術をつなぐ橋渡しができるのではないかと思いました。

「DX Criteria」の一部公開と、DXの発信

そういった活動がうまくいく中で、2013年くらいからレクターの仲間たちと、草の根的に続けてきたCTOのコミュニティを一般社団法人にできないか、こういうものが社会にも、もう少し必要になるのではないかと考えるようになりました。これらのコミュニティをパブリックなものにするとともに、レクターの中である種のコンサルティングパッケージとして使っていたDX Criteriaの一部を、誰でも使えるようにして公開しました。

Digital Transformationという言葉がものすごく流行っていましたが、僕の中ではもう1つDeveloper Experienceがすごく重要で、効率よく開発して創造的にする開発者体験を、どうすれば組織としてサポートできるのかを考える。

企業をデジタル化することが目的ではなく、よりよいサービスを生み出したり、よりよい価値を社会に届けていくためにDXがある。そのベースの部分を忘れてはいけない。

しかし、世間で語られているDXは、そこが少しずれている気がする、開発者を置き去りにしているところがあると思ったので、この2つのDXは両輪なんだということを届けたいと思い、「DX Criteria」とともに発信したところ、さまざまな交流の機会が訪れました。経団連や経産省のほか、そろそろ発足しそうなデジタル庁に、我々の意見を伝えるタイミングを得ることができました。

（次回につづく）