先進的な取り組みを続ける現場に訪問し、
【インタビューされた人】
小野和俊（おのかずとし）
（株）小野和俊
規模の違う企業での取り組み
- ──小野さんは現在、
アプレッソの代表取締役とセゾン情報システムズのCTOという立場でお仕事をされています。それぞれの組織について教えていただけないでしょうか。 小野：アプレッソは16年前に創業し、
現在では開発メンバーが30人弱くらいの規模です。会社全体で60人程度ですので、 およそ半分がエンジニアですね。事業としては自社製品が中心です。一方セゾン情報システムズはもともとSIがメインですが、 パッケージ製品やクラウドサービスも提供しています。アプレッソの人間としてセゾン情報システムズと一緒に仕事をしていく中で、 事業的なシナジーが強くあるということで3年前に資本業務提携し、 今にいたっています。私自身の時間の使い方としては、 セゾン情報システムズが8割くらいです。セゾン情報システムズの事業はもともとSIがメインですが、 そこも変えていこうということで、 やることがたくさんあります。
アジャイルへの引力とウォーターフォールへの引力
小野：アプレッソではチーム開発をガチガチにやっていて、
100％スクラムで進めています。スクラムマスターが何人かいて、 教科書どおりのやり方でスクラムにしっかり準拠した開発フローですね。でも、 始めから教科書どおりだったわけではありません。アプレッソで開発を始めた2000年ごろは 「アジャイルソフトウェア開発宣言」 が出たばかりの時期で、 まだアジャイルという言葉は普及していませんでした。そんな 「教科書」 ができる前の時期からペアプログラミングやリファクタリングなどに力を入れていたのは、 自然にそういうやり方になっていたからです。 たとえば大学の研究室で何かを作るときも同じだと思うのですが、
何も考えずに作ると 「ちょっとここを見てもらいたいんだけど」 「ここを一緒に作らない？」 といったやりとりが生まれる、 ウォーターフォールというよりはアジャイル寄りな開発になりますよね。 - ──そうですね。しっかり計画するというよりは進めていく中で修正しますね。
小野：おそらく、
それが自然な開発だと思うんです。ガチッと計画を作るよりもやりながら修正するし、 1人で全部抱え込むよりも何人かで分担する。一時的に役割分担を決めるかもしれませんが、 進みが良かったり悪かったり、 やり始めてみたら途中で難易度が高いのことがわかったりといったこともあるじゃないですか。そこを柔軟に変えていくのは自然なことなんですよね。そういう経緯でしたから、 「教科書どおりにやらなくていいんじゃないの」 みたいな甘えも少しありました。 でも、
若い人たちが中心となって、 「一度教科書どおりに、 1つの例外もなくプラクティスを守ってみよう」 「かっちりやることにきっと意味があるから試してみよう」 という話になって教科書どおりにやってみたところ、 「すごくいいね」 ということになったんです。結果、 スクラムマスターになる研修を受けて資格を取った人も出て、 今はかっちりしたスクラムで開発しています。スクラムをやっている人と話すと 「エンタープライズだろうがWebだろうが、 1週間で回せないと何かがおかしいぞ」 という話になったので、 ウォーターフォールへの引力を感じながらも、 きちっと1週間で回して、 アジャイルでやることにしています。 - ──自然とアジャイル開発をし、
その次にかっちりスクラムを取り入れたと。 小野：はい。その一方で、
セゾン情報システムズはずっとウォーターフォールだったんです。エンタープライズだとバグが出たときにクリティカルだったり、 お客様に半年くらい前から作るものを約束していたりとか、 どうしてもウォーターフォールの重力に引き寄せられがちになるんですよ。
バイモーダルは前輪と後輪
- ──
「アジャイルかウォーターフォールか」 に近い話として、 最近ブログに 「バイモーダル戦略」 という考え方を書かれていましたよね。その中で小野さんは、 「モード1は失敗が許されない領域に適した安定性重視のソフトウェアを開発するモードである。モード2はスピード重視で、 時代の変化にいち早く対応する必要のあるソフトウェアを開発するモードである」 「それぞれの強みがありながらも文化的対立が起きやすい両者を共存させるには、 双方に敬意を払いつつ、 間を取り持ち調整を行う存在が必要だ。この存在にも名前がついており、 守護者 （ガーディアン） と呼ばれている」 と説明されています。小野さんは経験上両方を見てこられていることもあり、 この 「ガーディアン」 のような役割を担われているんでしょうか。 小野：はい、
セゾン情報システムズでは僕がその役割を担っています。チームあたりの規模の大小や会社全体の事業フェーズなど、 いろんな要素によって組織は変わってきます。たとえばアプレッソは、 どちらかというとモード2が主体です。モード1は品質保証やテストを行う部分に限られていて、 モード1とモード2の対立はあまりないんですよね。一方セゾン情報システムズは自然にやるとモード1になるんです。 よく言われる話ですが、
0から1のフェーズ、 1から10のフェーズ、 10から100のフェーズで必要とされるものが違うんですね。0から1のときは世の中に新しいものを生み出すわけですから、 まずヒットするものを作らない限りは体制を整理するどころではありません。そのため、 完全にモード2です。ベンチャーで新しくプロダクトを作るときに、 モダンな開発手法を採用して、 椅子や机がすごく充実していて、 それなのに作ったものが全然世の中に受け入れられなかった……となっても無意味というわけです。 - ──最初は立ち上がるかどうかがすべてですね。
小野：だから0から1のフェーズではとにかく当たるものを見いだすことにフォーカスすべきで、
もしかしたらペアプログラミングやコードレビューもいらないかもしれない。しかし次の1から10のフェーズでは、 「何本かサービスが実際に売れ始めて、 事業が立ち上がり始めたけど、 品質にちょっと課題があるよね」 といって品質保証チームを作ったりなど、 不足点を埋めていくのが必要になります。さらに次の10から100のフェーズ、 つまり、 事業が1本のプロダクトあたり百億円規模になったり、 従業員が千人規模くらいになってくると、 今度は属人性を排除すべきという話になります。そうすると、 0から1のときのように何もかも試しにやってみるという自由自在の動き方よりも、 「この人がいなくなったら千人の組織ぜんぶが終わる」 ということが起きないようにすること、 すなわち属人性を排除して誰でも回せるようなシステムやフローを作るようになっていきます。どんどんモード1に近付いていくわけです。 - ──そういう意味では、
アプレッソとセゾン情報システムズではフェーズが違いますよね。 小野：アプレッソは1から10のフェーズは超えていて10から100のフェーズに入ったくらいだと思うんですが、
セゾン情報は10から100の後半のほうにいます。 「属人性を排除してシステム化する」 「ルール化して誰がやってもできるようにする」 という、 組織としてある意味完成した状態です。完成度は高いけれど、 変化に弱かったり、 誰でもできる仕事では中にいる人が楽しみづらいといった話があります。だからもう1回0から1のフェーズに戻さなきゃいけない。そこでバイモーダル戦略なんですよね。 - ──フェーズの違う組織を組み合わせるということですね。
小野：
「今の時代、 こんなんじゃだめだ」 と昔のやり方を頭ごなしに否定しても絶対ダメですから、 今やっている人たちのおかげで事業が成り立っていることへのリスペクトをきちんと表すのは重要です。そのうえで、 時代が変わったから自分たちも変わっていかないといけない。そこでモード2寄りな組織も組み合わせるんです。 ただ、
この2つのグループというのは、 そのままではどうしても 「お前が悪い」 とお互い言い合うようなことになってしまいがちです。モード1の人たちから見ると、 モード2の人って 「チャラチャラしてる」 「いつも遊んでる」 「ネットサーフィンばっかりしているじゃないか」 と言われてしまう。逆にモード2の人たちからは、 モード1の人って 「ひたすら言われたことだけやっている」 「上司からの命令は絶対」 みたいに見えるわけですよ。そこで、 最近はこの2つのモードを 「自転車の前輪と後輪」 だと言っているんです。自転車にはタイヤが2つあって、 1つだけだと一輪車になっちゃいますよね。モード2とかベンチャーって、 一輪車的だと思うんです。 - ──おもしろいたとえですね。
小野：一輪車だと機動性は高いし方向修正も早い、
パッパッと首を振り続けるようなところがある。でも、 馬力ってことになると自転車、 しかも後輪のほうが強い。後輪は単体では方針転換できなくて、 前輪が指し示した方向にまっすぐ進むだけ。でも漕ぐ力は後輪が強いじゃないですか。後輪の馬力ってやはり貴重なものだし、 前輪の方針転換できる機動性や柔軟性も重要なので、 前輪と後輪どっちが偉いとか、 どっちがダメだとかそういうことじゃないんです。後輪が前輪のことを 「あいつらいつも首振ってフラフラしやがって」 と批判するとか、 前輪が後輪に対して 「あいつらはまっすぐにしか進めない」 と罵倒するとか、 そんなことをする必要はないわけです。 ある程度の規模になると、
どうしてもモード1的なものが必要になる。そこで属人性を排除してシステム化するわけですが、 単にシステム化するだけだと硬直化してしまします。そうなると、 そのシステムを壊さなければならないときに中から気付けなくなるんです。そこで前輪であるモード2が必要なんですね。ただ、 モード2とモード1はほっとくと喧嘩し始めるからお互いをリスペクトすることを表明しながら相手を取り持つ必要があって、 それがガーディアンの役割なんです。セゾン情報システムズにはそれまでモード2がなかったんですが、 変化のために作り、 自分がそこを取り持っています。
理論より実践、体験
- ──セゾン情報システムズさんでモード2を作られたということですが、
どう作られたんですか？ 小野：たとえば、
SIの会社の人にはCI （Continuous Integration、 継続的インテグレーション） を知らないという人も多いんですよ。ほかにも、 ソースコードのバージョン管理やコードレビュー、 テスト自動化もしていなかったりする。SIにおけるソフトウェアのライフサイクルは基本的に 「納品するまで」 で終わりますから、 Webサービスのようにメンテナンスし続ける製品とは違うんです。そうなると、 たとえばテスト自動化において考えるべきとされる、 「自動化のための工数」 と 「自動化によって得られる工数削減」 を慎重に比べる必要がある。1回テストに通って納品して終わりだったら自動テストをしないほうが効率が良い場合はたしかにあるわけです。 そういった開発スタイルをとっている人たちに対して、
急に 「全員GitHubでコードレビューをしましょう」 という話を出しても受け容れられづらいので、 まずはそうしたものの良さを理解してもらうために、 実際に体験してもらっています。モダンな開発に詳しいメンバーがSI的なやり方をしていたチームに入って開発するんです。 「その人の工数はそのチームには持たせず、 会社のコストとして持ちます」 「このコストはお客様への見積りにも入れなくてもいいので、 新しいやり方を体験してみてください」 という形です。そうやってテスト自動化やソースコードのバージョン管理を体験すると、 やはり 「いいな」 となって離れられなくなるんです。良い意味でハッとする体験をすると、 「言われたからやった」 ではなく 「体験して良いと思った」 となる。そうなれば、 「じゃあやろうよ」 と自然な感じで変えていけるんです。そうやってファンを増やして自然にチームとして変わっていく。それが周りのチームやプロジェクトにも伝わって、 自然に増えていく。 - ──とても良い変え方ですね。いきなり
「やり方をこう変えましょう」 とトップダウンで変えるときっと反発が起きますよね。 小野：もちろんトップダウンでやるべきこともあるのでしょうが、
開発のやり方については難しいですね。 「経営者は経営のプロとしてやってくれればいい。でも、 開発については自分たちがプロなんだから、 経営者がああ言っているけれど現場では違うやり方をしてしまおう」 なんてことが起き得る。だから、 トップダウンではなくファンになってもらって自然に変わっていくのがよいと思っています。最近セゾン情報システムズでSlackを導入したときもそうだったんですが、 上が言ったから使うのではなくて、 「楽しいから入ってごらんよ」 という感じで広めていたら、 利用は必須だと言っていないのに一気に利用する人数が増えたんです。
アイデアを試すサイクルを回せるのが良いチーム
- ──最後に、
小野さんが考える良いチームとはどういうチームかをお聞きしたいです。 小野：良いチームに共通していることがあるとすれば、
個人が言ったものを何でも採用するわけではなく、 カジュアルに試すことができて、 それを採用するかどうかもカジュアルに判断できて、 捨てるなら捨てられる……そういうことができている、 ということだと思います。たとえばKPT （Keep, Problem, Try） という手法はそれをシステム的な形で再現したものと言えると思いますが、 そういうサイクルを回せていける組織は強いんじゃないでしょうか。
本誌最新号をチェック！
WEB+DB PRESS Vol.130
2022年8月24日発売
B5判／
定価1,628円
ISBN978-4-297-13000-8
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！ - 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう - 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、 NFT