絶えず灯り続けるアジャイルのこころ
お久しぶりです、KAKKAです。
ex-MIXI Advent Calendar 2023の最終日の記事として書かせていただきます。
今回は特に僕のアジャイルキャリアについて特に振り返って考える機会があったので、アジャイルキャリアについてフォーカスを当てて書きたいと思います。エンジニアも2足の草鞋でやっていましたが、この記事では技術的なお話はごっそり省略していてます。
もう会って話すこともできないし、文章で書いても届かない人向けに、それでも文章として残しておきたい感謝の気持ちを合わせてここに記したいと思います。
アジャイルキャリアスタートと最初のコーチとの出会い
僕のアジャイルのキャリアのスタートは新卒で入った会社である株式会社ミクシィ（現MIXI）からスタートしました。
このブログの過去記事でも書きましたが、2012年頃に全社的にアジャイル変革が行われました。その頃は日本でもまだアジャイル経験者は豊富ではなく、社内でも人材は非常に限られていました。よって現場のほぼすべてのチームは自習によるスクラムを始めざるを得ませんでした。
僕は当時から非常にプロダクト志向なエンジニアでして、自分一人の頑張りよりもチームのパフォーマンス向上のほうが重要であると思い、その中核を担うスクラムマスターの役割を積極的に担うように動いていました。もちろんこのタイミングで初めてスクラムマスターの役割を担うため、右も左もわかりませんでしたが、社内で一人だけ高原さん（仮名）という認定スクラムマスターのライセンスを保有し、様々なスクラムチームの支援を行っていた方がいました。僕もそのコーチにサポートしていただいていたうちの一人ですが、比較的僕のチームに重点を置いて、時間をかけてサポートしてくださっていました。様々なアドバイスが参考になったのはもちろん、僕自身の良い変化をしっかり観察してくださっており、スクラムマスターとして「良くなってきた」とフィードバックいただけたことは、とても嬉しかったとともに、自分に自信を持てた一言でもありました。
僕はこの頃はアジャイルリーダーとしてのキャリアは全く想像もしていませんでしたが、振り替えるとここでの経験や高原さんのサポート・評価が今の僕を作った原点と言っても過言ではありません。
この頃高原さんから受け取ったアジャイルのこころは、僕のこころにも確実に灯り、後に大きな炎へと成長することになります。
スクラムマスターの経験が予想外に生きた2社目
リクルートの内製での新規プロダクト開発に興味を持って、エンジニアとして転職をしました。この頃、リクルートでは事業の内製化に非常に力を入れており、同時にアジャイルの導入もこれから始まるという段階でした。案の定、前職のミクシィで見てきたように、チームにはスクラムが導入されるものの、経験者があまりいないという状況にまた遭遇しました。そしてこのチームでスタートアッププロジェクトの結果を出すにはしっかりとスクラムを再導入する必要があると感じ、少しでも経験値のある僕自身が抜擢され、スクラムマスターを担うようになりました。
幸いにも、認定スクラムマスター研修を受講でき、Certified ScrumMaster®のライセンスを取得したり、日本でも数少ない外部のアジャイルコーチにサポートしていただけたりと会社からの支援も重なり、とてもいいスクラムチームになりました。スクラムマスターとしてチーム全体からも非常に信頼していただいたのも印象的です。隣のチームのコーチを担当することもありました。また、外部のアジャイルコーチはこのチームは本当に良いチームだとフィードバックをいただけたのも良い経験で、「これが良いスクラムチームなのだ」と認識できたことで、理想のスクラムチームのモデルを頭に入れることができました。
ずっと後に気づきましたが、なぜこのチームが良いチームになったのかは、十中八九、アジャイルなマインドセットを持った人たちが集まったスタートアップチームだから（クレイグラーマンの法則）、というのが答えだと思います。
非常に好きな環境だったのですが、わずか一年で去ることになりました。本当はもっとここで働きたかったのですが、スタートアップの本場シリコンバレーの、アーリーステージのスタートアップであるDrivemode, Inc.という会社にご縁があったためです。
シリコンバレーのスタートアップDrivemode, Inc.
Drivemodeには7年も在籍しており、ここでの学びを語りだすととても長くなってしまいます。このブログにもDrivemodeに関する記事はいくつか書いていますのでかなりシンプルに書きたいと思います。
入社時は社員2名、ファウンダー4名という本当に初期フェーズのスタートアップでした。会社全体が1チームで常に動いてました。スクラムマスターという役割はとても好きだったのですが、エンジニアと兼務するとどうしても時間的制約があったため、次こそはエンジニアに集中できるぞ、しかもメンバーはすごい人達ばかりだと、非常にワクワクしながら入社したのを覚えています。
スクラムの知識経験はあったのでそれを活かすバリューストリームの改善は入社直後からやったのですが、本当にそれくらいしかやっておらず、あとは会社全員が一丸となってプロダクト開発を必死にやっていたら勝手にアジャイルになっていたというのが非常に印象的でした。
シリーズAあたりから組織の成長痛を感じるようになりましたが、僕自身のアジャイルの知見をアップデートし、組織課題を提起することで変革のきっかけが作れました。そうこうしている間に2019年にホンダにEXITすることになります。
当時はこういった僕の課題提起の行動がメンバーから非常に煙たがられていたと思いますが、こういうキャラクターだったからこそ、ホンダのDX推進のリードを任していただけたのだと思います。
シリコンバレースタートアップから大企業のDX変革
この頃からアジャイル変革を大胆に行うようになりました（アジャイル変革はDX変革のうちの一部分です）。このころから何チームものアジャイルコーチ業務も本格的に行いましたし、丸3日のオリジナルアジャイル・スクラム研修もスタートし、何度も何度も開催しました。研修は単なる座学ではなく、習熟度を上げるようにとても工夫しており、一度に受講できる生徒は10名程度に絞らざるを得ませんでしたが、この時点でも研修受講者やサポート対象者は100名を軽く超えていました。
これらの活動は少なくとも「うまくいっていない」という感覚はなく、DX変革のスコープで見ても確実に前進していることが自分でも感じられました。何と言っても変革対象組織の方々からとても信用をしていただける実感が日々大きくなっていったのです。
DX変革は一般的にとてもむずかしいもので、その成功の定義も曖昧ですが、成功率は10%程度だという情報もあります。そんな中でたった一人で数百名の組織のDX変革の結果を残せているのはとてもやりがいを感じられましたし、社内でも評価され、僕を信用してくれた人たちがついてきてくれ、組織としてDXを変革を行う流れにもできました。
しかしながら申し訳ないことに転職をすることになりました。
MIXIへの再入社と高原さんとの再開、モダンな組織へのアジャイル再導入
MIXI創業者である笠原さんから声をかけていただき、MIXIに再入社することになり、みてねのエンジニアリング組織のマネジメントに現在も従事しています。
MIXIは10年ほど離れていましたが、10年前に在籍していた懐かしのメンバーもいらっしゃり、ワクワクと自分を受け入れてくれるかの不安が混ざったような気持ちでしたが、入社後はその不安は一瞬で消え去りました。
また、僕のアジャイルキャリアのスタートを作ってくれた高原さんも同じ組織にいました。「スクラムもいいけどやっぱり稼がなきゃいけないと思ってエンジニアのフォーカスしている」ということでエンジニア職として活躍されていました。
みてねは非常にDeveloper Experienceの高い組織だなと感じてはいましたが、アジャイルに関してはなんかしら良い変革ができる余地がありそうだとも感じていました。入社後に真っ先に取り組んだ変革アクションはやはりアジャイル変革でした。構造を整える、研修を行う、コーチングサポートを行うという大手製造業でも行っていたことは、みてねでも通用するどころか、そこを丁寧にやることがDeveloper Experienceにクリティカルに効果が現れると確信しました。
組織に受け入れられ、灯り続けるアジャイルのこころ
高原さんは「今はエンジニア」と割り切っていましたが、僕が社内でアジャイル系のイベントを行うときには高原さんも積極的にサポートくださったりもしました。やはりアジャイルのマインドは絶えず灯っているのだなと僕は非常に嬉しく思いました。
そして徐々に高原さんがエンジニアから再びアジャイルコーチの役割に興味を持たれるようになってきました。リソース調整は必要だったものの、10年前に僕にアジャイルを伝承していただいた師匠とまた一緒にアジャイル変革できるのかと僕はワクワクしていました。
僕が入社してからスタートしたアジャイル変革は持続的に良い影響をもたらしていると実感しています（僕自身はきっかけを与えたのみで、すごいのは組織なのですが）。
丸3日のアジャイル・スクラム研修を何度も受講したいと申し出る人がいること。
サポートしていた1スクラムマスターがめきめきと成長し、自信に満ち溢れた振る舞いをするようになっていったこと。またそれに従って周りのチームメンバーの信用が一回り大きくなっていったこと。
みてねの組織Valueを改変し、Be Agileを含められたこと。
チームメンバーにとってもスクラムの再導入が非常に好感触であること。
みてねのスクラム開発で私が感じたこと - mitene / FamilyAlbum Team
スクラムの本格導入による開発プロセスの変化＠みてねプロダクト開発部 MERCHチーム - mitene / FamilyAlbum Team
これまでチームで悩んでいた人が、今めちゃくちゃいいチームだと笑顔で話していること。
研修などの活動がみてねの組織を超えて、全社に広がっていってること。
この経過を見ると、アジャイルという価値観は少なくとも衰退の気配を感じさせません。僕が理想モデルとして頭の中にある良いチームに近づいていっていると感じています。そしてそれはきっと高原さんも納得するものになってきていると思います。
経営判断としてもちろん常にアジャイルファーストであることはないのですが、それでも現在のところ価値がなくなる未来は見えていません。
しかしながら、高原さんがアジャイルコーチの業務に興味を持たれ、僕がまた一緒にアジャイル変革できるというワクワクは、叶わず今に至ります。
意外にも、一緒にアジャイル変革に携わることができなくてすごく惜しい、という気持ちはそれほどありません。なぜなら高原さん目指したいと思っていただろう状態に向かって僕らは着実に前進しているし、それを実現できるリーダーたちもいるからです。そしてこれらの変革のきっかけが僕だったとしたら、そのスタート地点を作ったのは高原さんなのですから。
10年前、高原さんから受け取ったアジャイルの灯火は、僕にも灯り、今では多くの人々にも灯り始めています。
少なくともみてねでは、この灯火が日々強くなってきています。
それが「世界中の家族のこころのインフラ」を実現するのにとても貢献してくれると思います。
あなたのその存在に感謝したいと思います。本当にありがとうございました。
スクラムにおける現実的最適手段の選択 - INVEST編
スクラムは、理解は容易、習得は困難
スクラムは、理解は容易ですが、習得は困難です。基礎を学び、ルールや推奨方法を理解した後でも、実際のプロダクト開発では理想通りに進まないことが多々あります。しかし、プロジェクトを前に進めることは非常に重要です。スクラムの理想を追求しすぎてプロジェクトが進まなくなると、スクラム自体がアジャイル変革を阻害する要因になる可能性があります。そのため、常に理想を目指しつつも、現実的な最適手段を選択し、その手段が心地よく感じられるようにすることが重要です。今回は、私がさまざまなチームを見てきた中で感じた「現実的最適手段」について考えてみたいと思います。
プロダクトバックログアイテムをINVESTにしたい
INVESTはスクラムのルールからは外れるものの、理想的なプロダクトバックログアイテムの形であることは言うまでもありません。しかし、クロスファンクショナルチームであっても、固定されたスプリント期間内で潜在的にリリース可能なプロダクトインクリメントを生み出すことは困難です。プロダクトバックログアイテムをさらに細分化することが難しくなったり、解決策が見つからなかったりすることもあります。この課題はどの組織でもよく遭遇するものです。
INVESTにならないとどうなるのか？
INVESTを満たさないプロダクトバックログアイテムには以下の問題が生じます。
スプリント期間内に完了しないプロダクトバックログアイテムが常態化する
この状態では、ベロシティの計測が機能せず、経験主義的な見積もりや生産性の可視化が困難になります。スプリントプランニングが困難になり、開発者の作業量が把握できなくなります。極端に忙しくなる場合もあり、スクラムチームとしてのサポートや生産性改善活動、品質の向上などに十分な時間を割けなくなり、レトロスペクティブの機能も低下してしまいます。さらに、アイテムの完了時期が分からないため、プロダクトオーナーは中長期的なプロダクト戦略を立てることも困難になります。
考えられる原因
スクラムチームの開発者がクロスファンクショナルになりきれていない
バックエンドエンジニア、フロントエンドエンジニア、ハードウェアエンジニア、UXデザイナー、UIデザイナー、QAエンジニア、ディレクター、アナリスト、研究者、カスタマーサポート、セキュリティエンジニアなどの専門家が開発者としてスクラムチームに入ったら、クロスファンクショナルチームになりフロー効率が上がるというのは、この時点では妄想にすぎません。それぞれの専門的タスクには量の違いがあり、常に毎スプリント人的リソースのコントロールも難しいし、それぞれの専門的タスク量のコントロールもできないからです。開発者それぞれが専門性の幅を広げ、ボトルネックになりそうな専門領域のタスクをこなせる人を増やしていくことが重要になります。
QAのタスクはQAエンジニアが、コーディングをするのはソフトウェアエンジニアが、データ分析はアナリストが、などと暗黙的に役割が決まっていて、そこから買われないのであればとフロー効率は改善せず、結果的にベロシティが上がらず、プロダクトバックログアイテムがスプリント期間内に終わらないということにつながります。
現実的最適手段とは？
上記の問題は一時的には解決が難しいものが多いです。短期的な解決策が見つからない場合には、現実的な最適手段を選択することが重要です。私の経験から、以下の優先順位で目指すのが良いと考えています。
INVESTに優先順位をつける
繰り返しますが、INVESTが良質なプロダクトバックログアイテムを表現するための条件としては理想的なものであるという考えは変わりません。しかしながら、これを意識するあまり、上記のような致命的な問題につながるケースがよくあります。これらをなるべく避けながら、理想状態を目指すためにスクラムを組み続けることも非常に重要です。現実的最適手段を選択することにより、スクラムチームそのものをインクリメンタルに改善していくのが良いと考えます。
個人的な考えとして下記の優先順位で目指し続けるのが良いと考えています。
- Small
- Estimable
- Negotiable
- Testable
- Valuable
- Independent
Small（小さい、最適なサイズ）
小さいとはいえ、小さすぎることも非常に危険です。小さすぎることで、上記のような「プロダクトバックログアイテムがタスクリストになってしまい、スクラムチーム全員がプロダクトバックログアイテムの内容を知らないどころか興味を持てない」という問題が新たに発生します。
では最適なサイズとはどういうことか。下記のプロセスでできたプロダクトバックログアイテムであると考えます。
- まずはValuable, Independent, Testableを満たした状態のプロダクトバックログアイテムを作る
- サイズが大きすぎてEstimableではない、Estimableではあるが1スプリントで到底終わらない場合、ValuableとIndependentを妥協し、Estimableで1スプリントで終わらられる程度までアイテムを分割する
こうすることで現実的に分割可能になるはずです。繰り返しますが、あまり分割しすぎると上記のような「プロダクトバックログアイテムがタスクリストになってしまい、スクラムチーム全員がプロダクトバックログアイテムの内容を知らないどころか興味を持てない」という問題が新たに発生しますので、上記プロセスでやることが重要です。
それで、INVEST状態ではないと自覚し、それがどうすれば改善できるかを真剣に考え、レトロスペクティブなどの場で話合いましょう。この漸進的なマインドセットは決して忘れてはいけません。
このINVESTの優先順位における妥協が、現実的最適手段となるパターンをよく見かけます。これを選択することによって、
- 1スプリントで完成させることができます
- これにより、「経験主義的な見積もりと生産性の可視化」が可能になります
- これにより、POが中期的なプロダクト戦略を考えやすくなります。また、スプリントプランニング第一に相当するWhatを決める際に最適な選択をできるようになります。そして、スプリントプランニング第二に相当するHowを決める際に、より具体的に時間軸の概念を含めて考えることができます。
みてねのエンジニアリング組織マネジメントをやり始めました
あれから
前回は退職ブログ「2015年から働いていたDrivemodeというシリコンバレースタートアップ(2019年にホンダグループ入り)を、先週に最終出社として退職をしてきました。」を書かせていただきました。あれから長らく有給消化期間となり、今月の12月15日までDrivemode社員でしたが、実際11月ごろから先行して働かせてもらっており、12月16日付けで無事正社員として入社いたしました。タイトルの通り、家族アルバムサービス「みてね」のエンジニアリング組織マネジメントをやります。
家族アルバム「みてね」サービスについて
すでに1500万ユーザーを突破し、日本国内ではママやパパの半数となる47.1％の方が利用しているという、結構とんでもないサービスになってきています。そして意外と知らない人もいるかもしれませんが、これMIXI社の事業なのです。僕は新卒でMIXI社にエンジニアで入社しましたので、約10年ぶりにMIXI社への出戻りとなります。
toyokeizai.net
きっかけ -笠原さんとの再開、組織を知る-
このみてねの事業責任者（PO）はMIXI社のファウンダーでもあり、考えるプロダクトは必ずヒットさせるということで天才と呼ばれている笠原健治さんです。幸い、10年前のおかしな若造であった（過去形？）僕のことを笠原さんは覚えててくださり、今年のある日突然「ランチに行きましょう！」とお誘い頂いたのがことの始まりでした。そしてランチの際に、今の僕のポジションの前任のエンジニアリング組織全体のマネジメントを行っている方も同席され、実質的に「採用のカジュアル面談」となったことをきっかけに興味を持ち、そのままトントン拍子で話が進み、入社させていただくことが決まりました。
少し、個人的に心を動かされたお話を書いていきます。
興味が湧いたポイント1: 組織規模
個人的にこの「みてね」は、初期開発メンバーがほぼ全員知り合いではあったので、リリース前の開発中から知っていましたが、その頃の「数名のスタートアップ」というイメージが強かったですが、なんと今の組織規模は50 -60名程度となっているということを上記ランチでお話したときに知り、驚いたことを覚えています。
僕のこれまでの経験で、数名〜30名程度の規模の組織はいろんな状態を見てきているし、更に数百名以上との組織も見てきましたし、それぞれの難しいところや面白いところも把握してきたつもりです。そんな中で思っていたこと、次にマネジメントという立場で一番興味がある組織規模はだいたい50〜100名かなぁという気持ちでした。
これはぼくの純粋な感覚ですが、組織マネジメント難易度が上がる人数規模のしきい値があるきがしています。
1. まずは1チームの限界が来る10名超え
2. 組織からアウトプットされることすべてを一人の人間が把握する限界が来る50名超え
3. その後はなだらかに難易度があがり、複数事業や部門のサイロ化が起こる、1000人超え
1と3は見てきましたので、2あたりの経験が必要だなとしみじみと感じていました。
興味が湧いたポイント2: 良い組織
シリコンバレーのスタートアップやホンダのDXなどで様々な活動をしてきましたが、組織マネジメントの観点で「これをやるべきだ！」と感じてきて、僕自身も実行してきたことや、これから実行しようとしていることが"マクロな視点で"大体できている良い組織でした。前任の方が本当に頑張ってきたんだなぁと非常にありがたい気持ちです。
え、じゃあこれから何をよくしていくのか？という疑問が湧いてくるかもしれません。今回の転職はそれを"探し求める"ということが目的の一つなのです。
自分が働く上で意識している大事なこととして、「今が非常に良くても完璧ではないのだから、今より良い状態を目指すのだ」というのがあります。これは組織やマネジメントに限らず、ソフトウェアでもUXでもUIもデータ分析でも何にでも共通して言えることだと思います。
ここではどこまで進化しても"完璧を目指し続ける"ことで、エンジニアリング組織の到達点を探索していきたいと思っています。
おそらく世の中的にはまだまだレガシー企業のDXという社会的課題は長年取り組まれることでしょうし、仮に僕自身がまたそれを携わるとしても、目指すべき到達点がアップデートできた状態で取り組みたいという思いがあります。
また、マクロな視点で出来てると思いきや、細部までちゃんとできていなかった、みたいなパターンはどの組織でもあることだと思います（DX変革でもここが本当にキーポイントでした）ので、マクロな視点を持ちつつも、解像度をできる限りあげて課題解決を推進していきたいと思います。
興味が湧いたポイント3: 笠原さんと日々一緒に働くという点
繰り返しますが、このみてねの事業責任者（PO）はMIXI社のファウンダーでもあり、考えるプロダクトは必ずヒットさせるということで天才と呼ばれている笠原健治さんです。一般的にもスタートアップや起業・事業の成功というものは成功確率が非常に低いというのはお察しの通りですが、こんな笠原さんと毎日働く機会は、宝くじを当てるよりもレアだと思います。取締役ではありますが、本当に日々、みてねのプロダクト開発に携わっています。
興味が湧いたポイント4: 事業が素晴らしい
世の中には様々なサービスやプロダクトがありますが、こんなにも事業自体が社会的意義のあるものもレアだと思っています（完全に個人の好みの問題かと思います）。
みてねのミッション「世界中の家族の"こころのインフラ"をつくる」
とても懐かしさを感じました。僕が新卒でMIXI社に入ったときはSNS mixiの全盛期でした。そのSNS mixiのプロダクトミッションが「世界中の人々のコミュニケーションのインフラ」（だったはず）。当時の僕はこれにとても賛同し、仕事に没頭していました。みてねのミッションもまた、その熱さを思い出させてくれるものです。
こころのインフラというものはかなり幅広くて、例えば家族で子供の写真を共有しコメントし合うことで和やかな気持ちになるとかそういうものだけではなく、こころのインフラには「安心」という要素も含み得るものです。子供の危険な状態を察知する（みまもりGPS）、危険な状態になったときに助けてくれる機能（コールドクター）があるなど、この生存のに関する危機を未然に防ぐという”安心”も提供しており、昨今の猛暑での保育園バス置き去り事故などにひどくショックを受けていた僕としては、こういったミッションを持つことは本当に世のためになりつつも、家族のミライを守ることにもつながるのだなぁと感じています。
「みてね」を支える組織について
ここまで個人的なお話ばかり述べさせていただきましたが、僕自身の責務を果たすためにもみてねの組織についても紹介しておきます。
より良いものにどんどんアップデート予定ですが、みてねの採用サイトはこちら。
team.mitene.us
事業成長の真っ只中、会社からの期待にも答えなければなりません。より一層組織を強化すべく、しっかりと採用枠を確保しに行っています。まだ未確定な枠もあり、ちょっと先走ってますが、すでにJob Descriptionまで公開させていただいてます。この枠に限らずとも、ぜひカジュアル面談からでもお話させてください！
docs.google.com
【家族アルバム みてね】CXエンジニアリングエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】シニアスクラムマスター - MIXI GROUP RECRUIT
【家族アルバム みてね】QAエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】Engineering Manager - MIXI GROUP RECRUIT
【家族アルバム みてね】バックエンドエンジニア（プロダクト開発） - MIXI GROUP RECRUIT
【家族アルバム みてね】iOSエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】Androidエンジニア - MIXI GROUP RECRUIT
【家族アルバム みてね】 Rails エンジニア（Data Engineering グループ） - MIXI GROUP RECRUIT
退職しました: シリコンバレースタートアップからホンダのDX
2015年から働いていたDrivemodeというシリコンバレースタートアップ(2019年にホンダグループ入り)を、先週に最終出社として退職をしてきました。
そもそも後述するホンダのDXは、とてもうまく進んでいましたし、仲間も増えましたし、これからもっとやっていくぞという気持ち満々だったのですが、とても無視できない良縁があり、Drivemodeを退職することとなりました。
体が2つあるならば・・・と思っているところです。
Drivemodeジョイン(2015/02)〜Exit(2019/09)まで シリコンバレーのスタートアップエンジニア
ひたすらエンジニアやっていました。画像はメインのAppリポジトリのものです。
「シリコンバレーのスタートアップ」を存分に楽しみました。いくら働いても燃え尽きることなく、ずっと走り続けられました。ピッチコンテストや技術カンファレンスに登壇したり、雑誌やネット記事に載ったり。
全員ロックスターのように圧倒的当事者意識を持ち、職能の幅を超えて全員で一丸となって同じものを目指す日々でした。
Exit後(2019/09)〜現在(2022/10)まで ホンダのDX推進リード
ホンダがDrivemodeを買収するという理由、これにはホンダ自身にシリコンバレーのソフトウェアベンチャーのカルチャーを取り込むという、当然誰もが思いつくであろう目的がありました。自分もエンジニアでありつつも、アジャイルリーダーとしての自覚はありましたし、Drivemode社内でも様々な変革をしてきました。この熱量を、今度はホンダの変革に使いたいと思い始めました。
これまでのエンジニア、スクラムマスター、アジャイルコーチなどのキャリアを元に、CEOからそういったチャンスをもらったことが、正式なスタートです。
それがホンダのDX推進リードです。
ホンダのDX変革
僕の言うDXとは単なる業務効率化のためのデジタイゼーションとか、ソフトウェア・プロダクトそのものではなく、それを持続的に支えるエンジニアリング組織をつくるということ（≒Developer eXperience）です。
結局どういう状態から、どんなことをして、どういう成果をあげられたのか。書きたい気持ちは強いですし、書き出せば山のように書くことが出てくるのですが、ホンダは皆さんご存知の超有名企業であり、機密管理も厳しく行われていますので、かなり抽象度を上げ、比喩表現を使って表現してみます。
DX変革を、広大な荒れ地を整備して、今風なまちづくりをするようなプロジェクトに例えるならば、その広大な荒れ地の雑草は取り払い、地盤改良を行い、心地よく住める一軒家を建てるところまではできました。
ここに至るまでフルコミットで2年かかりました。最初は、よそ者の一人がなんかバズワードのDXやるぞとか言ってる人が絡んできたぞとかそんなことを思われていたかもしれませんが、一つ一つ口先だけではない成果を上げるたびに組織全体からの信頼度が増してきたことを強く感じられました。僕と一緒に走ってきていただいた方々には本当に感謝しています（そんな中で先に離脱してしまい本当に惜しい気持ちになっています）。
DX Criteriaの活用
DX Criteriaには本当にお世話になりました。DX推進に着手する前から目をつけていて、これはホンダのDX推進に使えるぞと継続的にウォッチしてきました。今となってはDX Criteriaプロジェクトに参加し、自らDX Criteriaを育てることに取り組ませていただいてます。DX Criteriaについてはこちらから。
dxcriteria.cto-a.org
DX人材が幅広い専門スキルが必要な理由
DXの難しさを強く感じました。そこに人と金がないのであれば、いざとなれば、最初から最後まで、また抽象から具体まですべて自分がやるしかない。特にDX変革を第一線で引っ張るリーダーにはこの幅広い実務スキルが必要でした。
人と金がないからできないと言ってると、それを解決するだけで何年かかるかわかりません。内製開発を推進する理由と同じく、自分が圧倒的スキルを身に着けて自分で全部やるのが結局早くて質が良いのです。
DX人材とはこういう人です pic.twitter.com/qEJryB8deA
— 中西裕太郎｜TENTIAL CEO (@yu_isbznd4) 2021年3月15日
この画像の中心部はDX変革リーダーの必要なスキルセット。広く浅くではなく、そこに人と金がないのであれば、広く深く習得している必要があります。
実際これだけではなく、ソフトスキル（上記ツイート画像のビジネススキルの領域かな）がすごく重要だということもわかりました。力のあるアジャイルコーチが、まずは現場の信頼獲得に全力投球するのと同じく、現場との関わり方ももちろんのこと、部門長やエグゼクティブが日々どういうことを考えているか、どういうことを不安に思っているか、どういうサポートを求めているか、どういったアウトプットをすれば信頼を獲得できるかを、”極めて少ない情報を元に”、的確に捉えて接することも最も重要なことの一つでした。
今のホンダとDrivemode
ホンダはグローバルで20万人を超える組織なので、もちろん僕の把握していない組織範囲はありますが、その一部には確かに、高いレベルアジャイル開発を実践し、お互いに尊敬しあい、日々モダンなクラウドサービスでコミュニケーションを取り合い、情報をまとめ、システムはモダンで、バッチリデザイン思考であり、データドリブンなプロダクト開発を行い、そしてなんと言ってもみんなそれぞれが優秀（超有名企業人材ですし）な組織が存在します。
みなさんがイメージするような、「社内に敵となる人や上司、部門長、役員がいて、説得できない」みたいな状態では決してなく、彼らのうちの重要組織は攻めのマインドセットを持っているのは確かです。みんな一丸となって、「同じ敵」を倒そうと頑張っているのが実情です。
僕はDrivemodeを去り、ホンダのDX変革から離れますが、Drivemodeではすでに僕のやってきたDX変革プロジェクトを組織化しており、強力な人材を採用し、未来を託しています。彼らなら引き続き良い成果を挙げられること間違いなし。しかもDrivemodeのCEOは本当に強い人です。こんなに頼れるボスはいない。
理念
DX推進を行う中で、心が折れそうになったときや、人に物を伝えるとき、組織を引っ張るときの強力なメッセージとして僕が使っていたものを一部書いてみます。もちろん中には他の人の言葉をパクったものもありますが、こういうビッグなワードは本当に役に立ちました。
「メッセージは投げなきゃ伝わらない。」
「DXはCEOとCTOの総力戦」
「情報をオープンに共有しよう。デフォルトオープン。」
「文化は組織構造に従う」
「アジャイルになることを諦めたら、その時点であなた方はアジャイルではない。」
「アジャイルになることを目指し続けるのであれば、成約を一時的に破るのも悪くはない。」
「自律的組織に必要な条件とは、0.1秒以内に現状を把握できること、ゴールが明確であること。」
「勇敢であろう。あなたのボスや偉い人が簡単に諦めていることでも、本当に無理かどうかを確かめもしないで諦めるのはやめよう。」
「人生はそう長くない。今日寝て、明日起きたらもう5年経ってますよ。」
「プロセスをどうしても作りたいなら、プロセス自体をプロダクトと考え、継続的にそのプロセスをエンジニアリングせよ。」
「チャンスの扉はいつも開いているわけではない。」
「プロダクト開発をしなくても、アジャイルソフトウェア開発者宣言を守り、スクラムの3本柱を考えよう。」
「Over Planning, Over Analysisをやめ、Over Communicationを活用しよう。」
「家族やあなた自身を犠牲にして仕事をするのはやめよう。」
今後について
まだ12月までDrivemode社での有給消化期間となるため、後日書きたいと思います。
Digital Transformation(DX)をやろう。
お久しぶりです、DrivemodeのKAKKA(@KAKKA_Blog)です。
CTOA Advent Calendar10日目のバトンを受け取りましたので書かせていただきます。
ソフトウェアエンジニアとしてシリコンバレースタートアップやメガベンチャー、日系大企業など多様な組織で働き、その中でもっとエンジニアリングを効果的にしようと色んな仕事に手を出していたらもはやコードを書く機会がほとんどなくなってきました。そのシリコンバレースタートアップが某自動車メーカーにExitした流れで、現在はDXをリードするお仕事が多くなってきてます。
今回はDXってなに？なんでやるの？どうやるの？みたいな超レッドオーシャン的な記事を改めて自分用に書いてみようと思いました。よって本記事は筆者自身がDXに真剣に向き合うにあたって、過去の知識や経験をもとに日々考えていることを整理しながらアウトプットしているため、リファレンス元を明確にした科学的事実や新しい発見などについてを述べているものではないですし、ちょっと散らかった話になっているかもしれないということを予めご了承ください。
DXの目的：なぜDXするのか
シンプルにいうと、今後のビジネスにおける競争力を上げることだと思います。それは単に、社内の守りのIT部と戦って業務改善ソフトウェアの導入をすることでもないし、AIやソフトウェアによって仕事の自動化を進めて経費削減することでもありません。しかしそれらが効果なしというのも間違いだとも思います。中にはそれだけでDXをやり終えることだってありますが、世の中でこんなにもDXが行われているのは、ビジネスを成功させるために把握しなければならない市場ニーズがあまりにも不確実で変化が速いからです。そしてこれに適応するためには、企業に何かしらの変化を加えて、企業を何かしらの状態にすることで適応していかなければなりません。
何かしらの状態とは
すごくシンプルな言い方をすると、組織のAgilityが圧倒的に高まった状態であると考えています。つまり組織のAgilityを圧倒的に高める事によって、不確実で変化の激しい今後のビジネスにおいて高い競争力で利益を上げていく、という論理ができます。
Agilityとは何か
次に組織のAgilityとはなにか、単に直訳した場合「速さ」ですが、それは人間の個人の能力を限界突破してAGIポイント振りまくるみたいなことではありません。常人のAGIのパラメータで、組織のボトルネックを徹底的に排除し、そして最大限仕事を効果的・効率的にし、常人の素早さが最大限生かされる状態のことをAgilityが高いと考えています。なぜなら個人のAgilityや強力な専門能力は組織のボトルネックによって簡単に無意味なものにされてしまうからです。個人の成長も大切ですが、もっと大切なのはその土台であると考えています。これは軍事やビジネスで考慮されるランチェスター戦略における、質✕量＝強さという考えではうまくいかないのだということを意味しています。事実、ドイツの電撃戦や1980年代のホンダヤマハ戦争、昨今のテクノロジー企業の急成長など、戦争やビジネスでもランチェスター戦略における弱者が、Agilityによって勝利するということが確認されてきました。このことから、高い給料を払って優秀なデジタル人材をたくさん採用し、定着させることやテレビCMをバンバン流して宣伝することは時には強力だと認識しつつも、その土台がなければ全く意味がないということも言えます。
よって組織のAgilityが圧倒的に高まった状態に持っていくために手を加えなければならないことは、結局ビジネス戦略、組織構造、マネジメント、人事、採用、カルチャー、プロセス、システム、ツール、セキュリティポリシーなど途方も無いくらい広範囲になってしまいます。
DX後の組織ビジョン
DXしたらどんな組織になるのか？Agility高い状態ってつまりどんな感じなのか？という質問にうまく答えられなかった経験があります。「データによるとDXに成功したら、そうじゃない会社に比べて利益がこれくらい増えます」とか全然答えとしても違うし、「アジャイルな感じで仮説検証回してます」とか「自律的な意思決定ができていてかつ同じもの目指している状態」とかも、正しいとはいえ実際見たことがない人にとってはイメージしづらいだろうと思います。なので組織の設計はどうなっており、その中にいる人達の価値観や行動パターンはどんな感じなのか、認識合わせをどうすればよいかを考えてみます。
MissionとVisionを認識合わせる
その組織の存在意義の確認です。存在意義がない組織なんて存在しませんし、組織を定義した人によるなんらかの意図があるはずなので、明確にします。ちなみにここでいうVisionは現時点の組織において定義されているVisionであり、現時点の組織において定義されているMissionを達成したときの顧客を取り巻く世界の状態のほうを表しています。DXしたあとどんなかんじになるの？という話とは少し違います。
この時点で、目指しているものが確かに方向性が違うことを感じ、DXを行う必要性が感じられなかったら、そのDXプロジェクトは失敗することだろうと思います。ここを確認し、少なくとも不確実で変化の早い市場ニーズに対して競争力を上げていくような方向性であることを確認しなければなりません。それから下記のように解像度を上げていきます。
組織図を書いてみる
デジタル業界にいる人達にとってはとても自然で書くまでもないことかと思うかもしれませんが、やはり世界は広く、様々な組織図があるものです。なので実際に組織図とポジション、責任権限とKPIなどを書いてみるとかなりイメージが合わせやすくなります。先にソリューション的なものを見せるアプローチも違和感があるかもしれませんが、その構造になるセオリーの説明は一旦すっ飛ばして、絵をチラ見せすることでビジョンの解像度が高まるはずです。
Valueを詳細に言語化してみる
絵に加えて言葉でも補足してみます。私自身も様々なチームに在籍し、作り、運用し、外から見てもきましたが、その中でも、主観的にも客観的にも良いチームを作れたときがありました。それらに共通することはなんだったのかを書き出し、少しずつアップデートして言語化したものを下記に書いてみます。私の場合、現時点ではこれを良い組織文化の価値観のゴールとして設定することは、十分に難易度が高く、どれも理想的で目指し続けられるものだと考えています。しかし中身にも書いてますが、これも完璧なものではありません。
Agile
不確実で変化の激しい市場ニーズに適応するために、アジャイルになろう。
プロダクトバリュファースト
社内の事情よりも、プロダクトの価値が最も大切だ。価値があるかどうか、正解はユーザーしか教えてくれない。
動くものを早く作ろう
内部的進捗や価値のわからないコンポーネントに時間を費やすのではなく、ユーザーに提供可能な動くものを優先して作ろう。
ルールやガイドラインを効果的に使おう
形骸化したルールも邪魔だが、無法地帯も効果的ではない。適切にメンテナンスされたルールやガイドラインで効果的に働こう。
一緒に働こう
同じ空間で働き、コミュニケーションをとり、お互いを尊敬しあってチームのパフォーマンスを最大化しよう。
Scientific
ポジションや役割にとらわれずに、客観的事実や数字とともに話そう.
客観的事実や数字を重視しよう
いろんなアイデアやコメントフィードバックも十分に価値があると理解しながら、客観的事実や数字をより重視しよう。
実験と評価をしよう
小さく速く試して、結果を得よう。プロダクトに関してだけではなく、組織やマネジメントに対しても同様だ。
再現可能な改善行おう
サイエンティフィックに働いていたら、それが再現可能な知見となり、組織が継続的に成長していくはずだ。
Transparent
透明性を徹底的に上げることで、みんながセルフマネジメントし、リーダーシップを発揮できるようになる。
正直になろう
自分にとって不都合なことでもオープンに共有しよう。それはみんなにとっての知見となり、長期的にプラスになるはずだ。
情報を整理しよう
一見して理解しやすい内容のほうが、結果的に伝わりやすいはずだ。
意識的に情報をオープンにしよう
どの情報がどの人に必要かなんて毎度正確に分かるはずがない。誰かを伝達者とするのではなく、みんなが同時に同じ情報にアクセスできるようにしよう
傾聴しよう
リアクションする前に最後まで聞いて理解しよう
一対多コミュニケーション
チームを重視しよう。私とあなたの会話内容もまた情報だ。
Free and Responsible
与えられた役割にとらわれず、何事も行い、そして責任も持とう。
お互いに徹底的にフェアな関係になろう
ポジションや役割にとらわれず肯定、否定、質問、反対しよう。それと同時に人の意見も傾聴しよう。
自分で意思決定し、セルフマネジメントしよう
自律的な意思決定とセルマネジメントによって組織のAgilityが上がるはずだ。それができない場合、ボトルネックを探そう。
我々はみんなロックスターだ
我々はあなたが殻を破って、大きなことを変えようとすることを応援する。
Progressive
組織は現実的ではないほど高いビジョンに向かって、継続的に進化していこうとする姿勢が必要だ。我々は今、完璧ではないのだ。
ゴールはいつも遠い
我々がいくらすごいことをして、自分たちが素晴らしいと思っても、ゴールはいつも到達できないほどに遠い。だから歩み続けないといけない。このドキュメントもまた完璧ではないことはわかっている。
いろんなことに興味を持とう
それがあなたの強みだ。組織に多様性をもたせてくれる。
失敗を認め、そこから学ぼう
成功したと断言するのはまだ早い。未来は学びのほうを欲している。
どうやってAgilityを圧倒的に上げるのか
目指すべきところが見えて、そこを目指す理由も明確になったところで、Howについて考えていきます。
ソフトウェアの活用
銀の弾丸とまでは言いませんが、Agility強化のためのあまりにも強力な要素であるから、ソフトウェアファーストという言葉も世間に馴染んできました。ソフトウェアの活用はビジネスと組織のAgilityを圧倒的に上げてくれます。ソフトウェアの特徴である少人数で大多数に素早く影響を与えることができるScalabilityと、正解を見つけるための要素がリアルタイムに目に見えて観測できるObservablilityにより、顧客との接点にソフトウェアを絡めることで、真実を、素早く知り、価値を、素早く、大多数に届けることができるようになります。しかしソフトウェア開発は複雑で、専門性の高いスキルが必要なので、専門家にやってもらう他はありません。
デジタル人材の採用・内製か、外注か
ソフトウェア開発ではもはやみなさんがよくご存知のAgileという言葉があります。ここでのAgileな組織の意味はAgile Manifesto及びその原則が組織に定着している状態であるとすると、上記までのAgilityとは少しニュアンスというか意味を成すスコープが違いますが、まぁそれでもAgileであるということはAgilityにかなり強いインパクトを与えるし、かなり重要だと考えています。一方でかなり厳密なアジャイルプロジェクトは内製開発でも外注でも可能ではあります。しかし内製開発のほうが圧倒的に有利であることは間違い無いと思います。組織に所属している／していないのその差だけで、カルチャーも変わってきますし、そんなハンディキャップのなかでAgile Manifesto及びその原則を忠実に守るのは難しいかと思います。制約条件があるから守らない（守れない）だと、うまく行かなくなります。
またAgileな組織文化に加えて、データやシステム、デザイン領域における高度な専門性を育て、組織に定着させるという点においても、外のそういった機能に頼るよりも、それらを直接組織に持っておくということのほうがどう考えても有利です。
デジタル人材の採用と定着・ポジティブな退職
というわけでデジタル人材を採用し、Agileなソフトウェア内製開発を行い、不確実で変化の早い市場ニーズに価値を届けるプロダクトを開発するんだという方向で事が進みます。ここで採用してもすぐにネガティブな理由により退職される場合、完全に土台作りに失敗しているといっても過言ではありません。ここをどのように解決するかを考えるととんでもないボリュームになりそうなのですっ飛ばしますが、要はデジタル人材が定着してくれるような土台作りが必要となってきます。その結果、デジタル人材が定着してくれ、退職するにしてもポジティブな退職であればそれは会社にとってもポジティブな結果になることが多いはずです。この土台作りが組織文化などに強く関連しています。
組織文化
組織文化という言葉がビッグワードであるものの、そのAgilityに対する重要性は非常に高く、基礎となると言われています。オランダの社会心理学者であるホフステードで代表されるように、玉ねぎ型モデルでしばしば表される文化ですが、一番コアな部分の価値観は変えられないものである一方その外側にある儀式、英雄、シンボルなどは理解し、変えていくことができるとされています。だからこそ、ここを野放しにしては組織文化が崩れてしまうといっても過言ではありません。
アジャイルやスクラムの文脈でもここは明確にして話されることが多い印象です。
ちょうど中心部分はAgile Manifestoに定義される価値・原則に当たりますし、スクラムにおいてもスクラムガイドで明確に定義されています。そして重要なのはプロセス・プラクティスなどはその上に乗っかるものということです。プロセスやプラクティスからは文化のコアを変えられないということです。例えばアジャイルなプラクティスを導入したところで、組織文化がまるっとアジャイルになるわけではないというと多くの方が経験してるのではないでしょうか。組織のコアな部分を定義する必要があります。それぞれの人に根付いたのコアの価値観は変えられない一方で、他者の価値観を理解し、周辺の儀式、英雄、シンボルをアダプトさせるためです。
よく用いられているのがMission、Vision、Valueであり、これが組織がどんな状態なのか（目指しているのか）を言語化してるのかなと感じています。Culture Deckのように、Value部分に相当する文章が詳細にかかれていればなお文化の可視化ができます。
組織文化の変え方
組織文化を変えるなんてそんな大きな話、不可能のように感じます。少なくとも一技術者がやることではないのではないか、という気持ちにもなってしまいます。システム思考家のジョンセドンも「組織の文化を変えようとする事は愚かな試みです。なぜなら、そのような試みは常に失敗するからです。」と明言しています。しかしAgile界の巨匠であるクレイグラーマンは、ラーマンの法則において「文化は組織構造に従う」という言っており、またジョンセドンも上述に続き「人々のふるまい（文化）は体制により作られるからです。もしあなたが体制を変えれば人々のふるまいは変わるでしょう。」と続けています。文化を変えるためには組織構造を変えることが唯一にして必須の条件となることがわかります。
実際にこのラーマンの法則を目で見てきましたし実行もしてきました。過去に記事も書いてます（Drivemodeでも、他のリーダーたちの多大な協力のおかげもあり、順調にプロダクト（フィーチャー）組織が定着してきました）。
kakkablog.hatenadiary.jp
プロセス・ルール・ガイドライン
組織文化の基礎固めを行ったら、そこに載せるプロセス・ルール・ガイドラインも考えることができます。たとえここの導入が間違っていたとしても、文化のコアな部分がぶれていなければプロセスも自ずと正しい方向に導かれるようになるはずです。組織がコントロール可能であるにも関わらず、スケールの大きさや難易度からコントロールできていない制約条件により、妥協してしまっているプロセスがあれば、まだ構造や文化が未完成であると考えられます。
DX Criteria
さて、まだどうやってAgilityを圧倒的にあげるのか、というセクションが続いているわけですが、世の中にはDX Criteriaという素晴らしいものがあります。日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインで、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。しかもこれは単に一部の人の思い込みで作られたわけではなく、世界中のソフトウェア開発やデザイン思考、マネジメント理論や組織論などの名著などを参考文献とし、実際に世界の最先端で実践されている内容を集約したものになっています。そんなDX Criteriaでさえ完璧ではないと考えられており、というか時代とともに変えなくてはいけないと考えられており、アップデートする前提で作られています。
しかしながらDX Criteriaでスコア化されたものは、あくまでも表面に現れる具体的現象のことが可視化されたのであり、各項目が直接的なDXの課題とは限りません。要するに、DX Criteriaのスコアを伸ばそうと思ってアクションプランを立てる際、多数の項目の根本となる課題が深層に根付いてることがあります。故にそれをまず取り除かなくてはなりません。
この記事でここまで考えてきたビジネス戦略、組織構造、マネジメント、人事、採用、カルチャー、プロセスなどの土台を整えて初めてDX Criteriaを基準として改善していけるのではないかと私は考えています。ここまでの抜本的な対策を行った上で土台を整え（この時点で結果的にスコアは一定まで上がるはず）、あとは独立した各項目を具体的に実践していくことで更により良いデジタル企業へと変革していけるものかと思います。
しかしこのCriteria、デジタル企業でも達成するのは至難の技であり、目指すところとしては申し分ないくらいに理想的で遠い存在です。参考までにDXリーダー企業がスコアをオープンにされていますので載せておきます。
DX Criteria ver.201912を使ってVOYAGE GROUPとfluctを自己診断してみました。 - VOYAGE GROUP techlog
単なる流行に飛びつくのではなく、戦略的に“データ駆動経営”を進める。 | DX解体新書 メルカリ編
FinatextさんもCTOAアドベントカレンダーの昨日の記事で紹介されています。
medium.com
もちろん一つ一つがとても重たく、大変なことであることは変わりないでしょうし、だからこそ大勢の組織が長い時間かけて取り組んでいるのだと思います。
DXの成功確率は低い。その要因は？
マッキンゼー企業変革調査(McKinsey TransformationalChange Survey)によると、企業の変革全般での成功率が30%程度と言われている中、DXにおいてはその成功率は半分程度の16%にとどまっており、どう考えても成功率が低い変革なのです。確かにここまで考えて、だれがこれできるんだと思ってしまいます。
さらに、DXの障壁となっているのは、技術的なものではなく、経営者のコミットメントや理解度、企業の文化やデジタル人材の不足といった、人・組織にまつわる要因が上位である、という結果が出てます。DXがあまりにも抽象度が高く、トレンドワードを多数含む概念なので、上記の様に土台を作らずにプロセス入れたりとか、システム変えたりとか部分最適した結果変わりませんでしたとなることもパターンとしてはあるのかなと思います。
結局これだけ広範囲なことを変革する必要があるので、プロジェクト自体がCEOやCTO/CIO案件にならざるを得ません。
CEOやCTO/CIOだけで二人三脚で進められるような広範囲な知識や経験、時間があるのであれば、比較的やりやすいと思いますがそんな会社は、すでに皆さんご存知のデジタル企業なのだろうと思います。
でもやらなきゃいけない
組織のAgilityを圧倒的に高める事によって、不確実で変化の激しい今後のビジネスにおいて高い競争力で利益を上げていかないと、生き残れないですから。
プログラミングまでインクリメンタルなソフトウェア開発
はじめに
TDDやインクリメンタルな開発について学び実践する機会があったので、今一度振り返り、記事にしておこうと思う。
ソフトウェアとして目指すべき所
ソフトウェアを開発するにあたり、このソフトウェアの目指すべき方向性とは一体なんなのかふと考え直す必要があるシーンに遭遇する。よくあるパターンでは、不確実な仕様を満たすことに注力したり、技術的品質に異常にこだわったりするあまり、"Things Right"なものにならない、またはなるのが非常に遅くなるパターンだ。もちろん言わずもがなそれは大事なことではあるが、そのソフトウェアが、必要とされるときに使われなかったら、それはただのToyとなってしまう。
世の中に広く普及しているソフトウェアで必ず共通しているものが、「価値がある」ということだ。しかし価値があるだけでは、数年間に渡りメンテナンスを強いられるようなソフトウェアになることだってある。これはビジネス上非常に苦しいことである。
というわけでシンプルに考えると、ソフトウェアは「価値があり、品質が高い」というところを目指すべきである。かんたんに言うけれど、これはなかなか難しいことだ。しかし目指すべき所としては間違いない。ここに向かって走っていくべきだ。
ここでソフトウェアと言っているが、基本的にはソフトウェアに限らず、すべてのプロダクトは価値があり、品質が高いほうが良いということは間違いないだろう。しかし今回はレジリエント、スケーラブル、可観測性といった特徴を持つソフトウェアというプロダクトに対してフォーカスする。考え方そのものはソフトウェアに限らず有効に使えるものだ。
計画型プロセスと経験的プロセスによる不確実への戦い
なぜ使われないソフトウェアを作ってしまうのか。なぜ使われない機能に多大なコストをかけてしまうのか。その根本には要件定義書の不確実度にある。要件定義の精度を高めるという努力も一定効果がある一方で、要件が不確実なことがほとんどだからである。
図で示すようなシンプルな領域については今回お呼びでない。「これは絶対に人々が求めるものだ！シンプルだ！」と思い込んでいるパターンも含め、それを示すデータやサイエンスがない限りたいていcomplexであり、我々の生きる未来そのものがcomplexであり、このchaosやcomplex領域において要件定義というものは単なる仮説にすぎない。
仮説ならばそれを検証しなければならない。いつやるのか？なるべく早いほうがいい。なるべく早く仮説を検証し、ゴールへの一歩を着実に積み重ねる必要がある。これができるのが経験的プロセスだ。
仮説＝真実という前提で歩みをすすめるのが計画型プロセスと言われる。
よってcomplexやchaosといった不確実な領域と戦うためには、様々な制約条件の中でも少なくとも経験的プロセスの考え方が必要となってくる。
これはすでに世の中に広く知れ渡っている考え方であり、かなり多くの組織で意識されていることだろうと思う。
Test Driven Development(TDD)でコードレベルの経験的プロセス
ソフトウェア・プロダクトの実態は≒ソースコードと考えることができる。ソフトウェア・プロダクトに対して仮説検証を繰り返す場合、ソースコードでも予めすべてを設計することは不可能である。よってソースコードレベルでのフロー効率を意識する必要がある。
フロー効率を意識するとは、図のように一番早くプロダクト自体がShippableになる状態を目指すことである。これが冒頭で述べたインクリメンタルな開発である。高品質なソフトウェア・プロダクトを目指すのであれば、自動テストはなくてはならない存在であり、そしてフロー効率を考えるあれば、テストコードはタイムリーに書く必要がある。
テストコードをもっとタイムリーにしていくと、先に書いてしまったほうが良いのではないかとも考えられる。流動的な要件に対してそれを具現化したテストコードを書き（テストコード＝仕様）、それをパスする実装部分をプログラミングする、さらに継続的にリファクタリングもする必要がある。これはフレームワーク化されており、みなさんご存知Test Driven Development(以下TDD)だ。TDDではTest→Code→Refactoringというサイクルを10分〜15分という非常に短い時間で繰り返しながらソフトウェアを開発していく。
Refactoringで経験的プロセスの考え方を活かす
Simpleな領域においての計画型プロセスの考え方では、プログラムの設計は早期に行われる。要件が固まっていればいるほど設計の抽象度も下がり、設計に従うことが正しく機能する。一方で不確実領域に対して経験的プロセスの考え方を導入する場合、早期に設計を行うことはどうしても抽象度が高くなる。よってプログラミングという具体レベルになると矛盾や無駄などが発生することは想像できる。この場合、設計はほどほどにしてジャストインタイムな設計・リファクタリングが有効に働く。これはシンプルに、開発途中のほうがコードへの理解、テクノロジーの知識が、開発前より高まっているからである。注意するべき点は、これができるのはRefactoringやTDDができる人だけであり、それができない場合、ただ設計をてきとうにやっただけ、ということになって終わってしまう。リファクタリングやTDDは単なる知識ではなく、習得にはそれなりに時間がかかる技術であるため、ソフトウェアエンジニアにはこれらのトレーニングの機会や実務で活かせる機会があると良いと思われる。
TDDはチームでの開発にフレンドリー
TDDは、極めれば極めるほど非常に透明性の高い開発プロセスである。Test, Code, Refactorというはっきりとした工程に加え、それぞれが非常に短い時間で行うため、誰かの頭の中でなにかしらの作業が行われているという時間が少ない。明確なプログラミングプロセスがソースコードにアウトプットされている状態である。これにより、ペアプログラミング、モブプログラミングなどの共同開発プラクティスにフレンドリーである。
終わりに
ソフトウェアは価値があり、品質が高くあるべきだ。不確実な領域との戦いを強いられる現代のビジネス環境において、フロー効率を考えた、早くShippableなプロダクトを開発できるインクリメンタルな開発によって、ソースコードレベルでも経験的プロセスの考えを生かしたプログラミングフレームワークは有効である。特にTDDなどは非常に相性が良いと思われる。継続的な設計、日常的なリファクタリングを繰り返すことにより、抽象的で無駄が多い設計から脱却し、それが高品質なソフトウェアへとつながる。
こういった内容は、Odd-e社におけるスクラムデベロッパーテクニカルトレーニングなどで学ぶことができる。スクラムの知識は必須ではあるが、ここから学べることはスクラムの範疇を超えており、不確実な要件、技術領域において価値のある品質の高いソフトウェアを開発するという観点において非常に役に立つ示唆がある。実務にもすぐに活かせるTDDの実践トレーニングも含まれている。
エンジニアリングリソースを有効活用することについて考える
はじめに
「技術を財務で表現する」という素晴らしい記事を見かけました。
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
GP（総生産力）。GPってのは僕が勝手に名付けた名前で「Gross Productivity」の略にしています。要するにエンジニアチームの総生産力を表しています。
僕の視点からすると、現代のIT企業の内製エンジニアチームって凄く特殊で、バランスシートにやってくる「システム」資産を作る力のことと言っても過言でない。もう少し言葉遊びすると「作る」というより「作り続ける」力。流量のようなイメージでしょうか。
Gross Productivity（総生産力）という言葉、いいなぁと思いました。昨今のエンジニアリング組織の生産性向上はまさにここの数字をあげることかと思います。
そして「作り続ける」という言葉選びも重要です。一般的に人的なエンジニアリングリソースはコストが高いため、エンジニアやデザイナーなどがより専門性を発揮できるように、無駄を省いて専門分野にフォーカスする時間を確保するというアプローチは、リソースを有効活用するという観点から言うと自然ではあります。しかし、限られたプロジェクトスコープ内で徹底的に無駄を省くよりは、この「作り続ける」ということを意識して、時間軸踏まえて考えるほうが良いと私は考えます。「きれいな水を一定量、常に流し続ける」というイメージです。
今回はこういった専門職の人たちのモチベーションややりたいことを一旦分けて、「きれいな水を一定量、常に流し続ける」ということを考えてみます。
きれいな水を一定量、常に流し続ける
私の言う「きれいな水」というのは、価値のあるプロダクトインクリメントです。ユーザーがプロダクトに求めている価値そのものです。ときにはそれは技術的負債の返済にあたることもありますが、間接的にこれも価値のあるプロダクトインクリメントとすることができるでしょう。
そして「量」は開発スケールであり、アジャイル開発においてよく用いられるチームのVelocityを意味します。
私は今までこれを「ゴールに向かって正しい方向に一定スピードで走る車」と表現していました。今回は「きれいな水を一定量、常に流し続ける」という表現にフォーカスします。
プロダクトにおけるスタートからゴールまでの水量の合計
プロダクトの開発をスタートしてから、そのプロダクトの一生を終えるまで、常に最大限にエンジニアリングリソースを有効に使えた場合はこの図の用になると思います。
この青色部分の面積が大きければ大きいほど、プロダクトに価値を提供できたということになります。この場合面積がMAXなので最高の例となります。
厳密には、チームを増やして流量のキャパシティ自体を増やしていくこともあるので、縦軸を%ではなく、流量[ml]とかで表現したほうが直感的かもしれません。しかしここでは財務という観点から、限られたリソースを有効に活用するということを考えるため、%で考えます。
ところが実際このようにうまくは行きません。プロダクトに所属する、掛け持ちをしていないチームを想定した場合、例えばこんなふうになったりはしないでしょうか。
青色部分の面積は先の例と比較してかなり小さくなっています。これでは財務的に有効に活用しているとは言い難い状態です。当然、あらゆる組織にはそれなりの制約条件があり、なるべくしてなるという状況は多々あると思います。しかしこれは仕方ないからと見過ごせるほどの差ではありません。文字通り、何倍もの差が出てしまうことになります。解決できるところは解決したほうが良いということは間違いないでしょう。
短期プロジェクトでしか、流量を確保できないパターン
施策を短期プロジェクトでしっかり何をやるかを考え、無駄を省いてスピーディにプロダクトインクリメントをデリバリーすることは悪いことではありません。プロジェクトもうまくいき、そのプロジェクトは無事成功だったとしましょう。
しかしプロジェクトが走っているとき以外はきれいな水の流量は比較的少なくなってしまいます。繰り返しますが、プロダクトに所属する、掛け持ちをしていないチームを想定した場合の話です。もちろん、チームのレベルやプロセス、カルチャーなどに依存するといってしまえばそれまでですが、それでもプロダクトに対する視座という観点でいうと、プロジェクトを構成していた人員のスキルセットと比較すると劣ってしまうことが多々あります。
また、プロジェクトではしばしば期限を設定し、プロジェクトマネージャーはそれを守るためにいかに工夫するかというところにも労力が割かれます。
要件に優先順位をつけ、期限に間に合わないものはやらないという決断は立派な働きだと思います。ときには、「今回は技術的負債には目を瞑ろう」と判断して期限を短くすることもあるかもしれません。その努力の結果、プロジェクトは成功し、期限内に必要なものをリリースすることができました。これはプロジェクト成功と言っても良いでしょう。それではそのプロジェクトのあと、次何をやるのかをしっかりと考えなくなったとすると、Productivityはどのようになるかというと、下がります。
せっかく短縮した期限、プロジェクトは成功したのにも関わらず、中長期的な視点でプロダクトに対する価値提供は最大化できているかどうかは疑問です。
繰り返しますが、これはチームのレベルやプロセス、カルチャーなどに依存するものなのでこのセオリーが全組織に適応されるものではありません。
また、制約条件により、プロジェクトの期限を守ることがかなり重要なケースもあると思います。
回避可能な場合において、短期プロジェクトでプロダクトを作っているときに、こうならないように対策が必要であるということです。
※職能組織編成でプロジェクトのみでプロダクトを動かすし掛け持ちも当たり前のような状態はこのような想定にはなりませんが、それはそれで別の問題があります。*1*2
スクラム&プロダクトチームで流量が保てないパターン
スクラム＆プロダクトチームを考えた場合、プロダクトバックログにおいてWhat to doは常にメンテナンスされ、毎週のようにプロダクトインクリメントをデリバリーされる状態が、比較的担保されやすいと考えられます。しかしながらプロセスやフレームワークは銀の弾丸ではないというのはまさにそのとおりで、図のようにうまく行かないパターンも当然あります。
この場合のパターンは見積もりが甘く予定していたVelocityを発揮できなかったとか、技術的難易度が予想以上に高かったとかそういうものから起因する場合を除いて考えることにします。というかその場合、全員が全力で戦ったっけどだめだったということでありエンジニアリングリソースは有効に活用していたということですもんね。
クロスファンクショナルチームとプロダクトインクリメント
スクラムチームを構成する場合、クロスファンクショナルチームを構成するのが理想です。これはプロダクトインクリメントを優先度の高いものから順番にデリバリーできるようにするためというのは理由の一つですが、当然この背景には、プロダクトインクリメントをデリバリーするために必要な職能は単一のものであることはほとんどない、という事実があります。
例をあげながら説明すると、このような要件があったとします。
可視化はされていませんが、それぞれの要件について必要な職能は異なってきます。
一方で現在のチームはこのような構成であるとします。実際他にも職能が必要そうですが、簡単のため、これをクロスファンクショナルチームとしてみます。
もうおわかりかと思いますが、人と職能を紐付けてしまうことによって、それぞれの要件で必要な人、必要でない人が出てきます。
例えば「ユーザーがアプリ内でタイマー機能を使うことができる」、「ユーザーが仕事帰りに電車でおすすめのレシピをpush通知で受け取ることができる」要件に対してはアプリの開発だけで良いかもしれません。一方で、「ユーザーが電車でテキストでレシピを検索することができる」は全員フル稼働が必要かもしれません。それぞれの人の稼働状況に偏りが出てきます。
したがって、リソースを100%有効活用しているかどうか、という観点で見ると、素直にYesとは言えない状態です。
個人レベルでのクロスファンクショナル
この例では極端な話、人＝職能と考えてしまう場合に起こってしまいます。この４人のスキルセットをそれぞれ図で表してみるとこのようになります。
それぞれのスキルセットは専門分野ではレベル100と非常に高く、立派な専門性を持っていると言えます。しかしこの状態だと上記のように不安定な流量となってしまいます。Back endの負担が多いからBack endエンジニアをもっと増やそう、という解決法でも一時的に解決できるかもしれませんが、世の中はわからない上に変化しますし、要件もそれに従い変化します。よって不安定な状態は続くと考えられます。
ということで個人レベルでのクロスファンクショナルという事を考えてみます。
そんなもんレベル100マルチスタックがいいなんてわかっとるわ！って声は聞こえてきそうですが、注目していただきたいのは、一旦短期的にそれぞれレベル60程度を目指しているというところです。
レベル100とかレベル60って実際どんなもんなのか？という議論は置いておいて、ここで私が言いたいのは、業界のエキスパートにならずとも、スキルレベルはレベル60あれば、高品質で満たせる要件もまぁまぁあるということです。さらに、0->60への成長のほうが60->100への成長よりも難易度が低いと考えられます。これは世の中にある情報やスキル習得者の数、解説のしやすさから考えてもその様になるのかなと思います。
仮にこの仮設が正しくなかったとしても、重要なのは、人＝単一職能と考えないことによって生まれてくる、Productの視座向上だったり、タスクテイカー感からの脱却、そして責任感といったカルチャー的な側面で好循環が生まれて来ます。*3
以上のことから、スクラム＆プロダクトチームにおいても、個人レベルでのクロスファンクショナルにすることによって、少なくともプロダクトの価値提供能力つまり今回で言うきれいな水の流量が増え、長期的にプロダクトの価値が高まっていくと考えられます。
やっぱり大事なのはWhat to doが常に考慮されている状態を作る
常に価値のあるものを、継続的に提供するためには、常に価値のあるWhat to doを、文字通り積んでおく必要があります。単純に開発スピードを上げたいからと言ってエンジニアを採用エンジニアを採用というのは、一旦立ち止まって少し深く考えたほうが良いのではないかという場合もあるでしょう。プロダクト開発に必要なのはプロダクトマネジメントだったりプランニング、デザイン、品質管理、カスタマーサポートなど多岐にわたります。その中で例えばWhat to doがボトルネックになっているのであれば、職能としてのエンジニアを強化しても逆効果になり得ます。
What to do がボトルネックになり、管理されていない状態となっている場合、ボトムアップ的なアプローチで委託するとか、明確に権限移譲を行うとかでケアする必要があります。
そのためにはそもそもチームの存在意義と明確に定義し、ミッションや目標を定義し、それに向かって自立的に走っていける環境を作り、障害となるものは取り除いたり、オフィシャルなプロセスを設定したりするなど組織としての基礎の部分をきっちり固めてやる必要があるかと思います。
こういったことを考え出すと、より一層Gross Productivityの最適化を考える場合、エンジニアリングというのはエンジニアのアウトプットではなく、プロダクト開発組織全体のアウトプットということになり、スコープは決してエンジニアにとどまらないということになってきます。
そもそも人は変化して成長できる
ある程度確かに特定分野のエキスパートも必要ですし、この人はこれが得意といったイメージが生まれるのは良いことだと思います。
しかしながら、人＝この技術、つまり人の職能フォルダ分けから、人への職能ラベル付けへ考え方を変えることで、組織はより柔軟な動きができ、全体のGross Productivityを向上させることができます。上記の例ではソフトウェアエンジニアに関する複数のスキルセットについて述べましたが、そもそもこれもエンジニアというフォルダに入っているので、このエンジニアと言う枠組みからの脱却ももちろん考えるべきことかと思います。もしかするとデザインや品質管理、人事、プロダクトプランニング、など幅を広げられる可能性もあります。
しかもその人達が、やりたいという思いがあるならこんなに幸せなことはありません。長期的な視点を持ち、この時期はプロダクトに対するインクリメントがどうしてもできないといった状況の場合、新しい分野への学習の時間をガッツリ取るのも、長期的には将来Productivityを向上させることに有効に働きます。
おわりに
今回は、財務で表現するという話から、エンジニアリングリソースを数字的な概念として捉えて有効活用する考えを書いてみました。
振り返ってみると言ってることは非常にシンプルで、要約すると「継続して何をやるかを考えよう」と「人を単一職能の人とかんがえるのをやめよう」みたいになってしまいますね。確かにこういう文言はどこかしらで見かけるものでありますが、それだけ言ってもなかなか伝わらないと思います。私自身も、人に伝えるという経験をすればするほど、今までの抽象的な理解では不十分だったと反省する日々です。
そしてこのセオリーですが、エンジニアやデザイナーなどの専門的な人たちは決して機械ではなく、人なので、これだけでは不十分でしょう。
その前に組織ビジョンやカルチャー、そしてそれが影響を受ける組織構造、さらに基礎となる事業や会社のミッション、ビジョン、バリューなどしっかりとした土台が必要になります。
