老舗ソフトウェア企業は文化的負債をどう解消するか　プロセス・コミュニケーション・要件管理における改善事例

セッションの内容

高橋裕之氏（以下、高橋）：「文化的負債との戦い」ということで、「老舗ソフトウェア開発会社でアジャイル変革を仕掛けた8年間」について発表します。よろしくお願いします。

本日お伝えすることとして、我々は老舗ソフトウェアとしての歴史がそこそこあるのですが、そこで溜まっていた文化的負債の利息を解消すべく、ソフトウェアプロセス改善というアプローチを取ってきました。

とはいっても、CMMIやPMBOK、SAFeなどの大きな何かを導入した苦労の話ではなくて、現場で起きている一つひとつの問題に向き合いながら、プロセスで解決しようというアプローチを取ってきた話をしていきたいと思います。

“文化的負債”とはなにか

はじめに、“文化的負債”という言葉をもしかしたら聞いたことがない方がいるかと思います。文化的負債というのは、「採用や雇用などの決定、コミュニティの基準、あとは組織の階層構造、会社の文化が最終的に生み出しているもの」と、オライリージャパンの『Effective DevOps』という本に書いてあります。

技術的負債と同様で、これはいつか返済しなければいけないし、負債を放っておくと、どんどん負の利息が溜まっていき、大変なことになるという定義になっています。

今日はその文化的負債について、DevOpsの生々しいストーリーを話していきたいと思っています。

先ほどの本に「コラボレーション、アフィニティ、ツール、スケーリングという4本柱でDevOpsの文化を調整する」という考え方が書かれています。この中でも、コラボレーションは複数人で対話をしたり、チームでうまく成果を出していくプロセスを作っていくためのものです。

アフィニティというのは、チーム間の関係を構築して目標の違いを乗り越えていくというような、学習するプロセスの話です。“プロセス”と書かれているこの2つのところに関しても着目して我々はやっています。

登壇者の自己紹介

あらためて軽く自己紹介ですが、私は高橋裕之と言います。ウイングアーク１ｓｔで、QA部門の部門長をやっています。

内藤靖子氏（以下、内藤）：内藤靖子と言います。同じくSPQI部、ソフトウェアプロセス＆インプルーブメント部というところの中にSPIグループがあり、プロセス改善を専門にやっています。そこのグループマネージャーをしていて、約5年半、この活動を高橋さん、荒川さんと一緒にやっています。よろしくお願いします。

荒川健太郎氏：荒川と言います。内藤のグループでメンバーをやっています。今の会社は入社5年目です。今日お話しする内容の8年間の中で、直近の2年に私は関わっています。今日はだいたい時系列でお話ししますが、私は後半に登場します。後半のほうのお話を聞いてください。よろしくお願いします。

高橋：では、弊社のビジネス領域を前提としてお話しします。弊社は帳票と呼ばれる分野が強い会社です。「SVF」という主力製品があり、2020年度で国内シェアが67.3パーセントの実績で持っています。ほぼ国内では一人勝ちという感じです。

（スライドを指して）右下にある写真のとおり、請求書や発送伝票などを帳票と呼びますが、これを電子的に出すような場合に、弊社のSVFがよく使われています。

あとは、紙を電子化する「SPA」というソリューションも持っています。

また、高速なデータベースとして「Dr.Sum」という製品や、Biツールとして「MotionBoard」といった製品も持っています。

（スライドを指して）弊社はこの間、無事に東証一部に上場できましたので、その際の目論見書から持ってきました。弊社の屋号がどう変わっていったかがわかります。ポイントとしては、2004年に翼システム株式会社から営業譲渡を受けています。年代が高めな方は「翼システム」と聞くと「あぁ」と言ってもらえる方が多いです。

私は2013年に入社したのですが、2014年に複数の子会社が合流して、ワンカンパニーになりました。SVF、Dr.Sum、MotionBoardという、それぞれの子会社ごとに開発していましたが、1個の会社になりました。

SVFが24周年、Dr.Sumは20周年と、息の長いプロダクトになっています。

また昨今のクラウド化の流れに合わせて、今まではオンプレが主戦場だったプロダクトも、クラウド上でサービスにしています。

今日の話のポイントとしては、プロダクトの歴史が長い、「ザ・派生開発」と呼んでもいいでしょう。複数の子会社がワンカンパニーになったので、異文化統一といった観点があります。そしてクラウドサービスの波があり、案の定と書きましたけが、「Dev vs Ops vs QA」みたいなものが起きていたり、いなかったり。いろいろあったという話が今日の主体となります。

アジェンダは14個用意しています。時間の許す限りいきたいと思うので、応援よろしくお願いします。

文化的負債Case1：カオス

Case1、「カオス」です。2013年に私が入社した時にはボスがいましたが、「この会社のプロセスは、見えるかたちでありますか？」と言ったら「あるよ」と言われてこれが渡されました。「ファッ！」となりましたね。すごいカオスだなと思っていました。

『ジュラシック・パーク』にイアン・マルコム博士という人物が出てきます。この人ははじめから「ジュラシック・パークはうまくいくはずがない」というカオス理論で失敗する話をずっと言っているのですが、僕もそんな気持ちでした。

「カオスだな。無理だろ」と。ボスは、2011年の頃から子会社に対して標準プロセス化しようとしてがんばっていたんですけど、2年経ってもぜんぜんそんな跡形もなくて、動いていませんでした。私からみると、「これはなぜやるのか」の説明不足とか、資料自体が「こうあるべき！」という強めの主張ばかりだったと思います。

私が昔、師と仰いでいた清水吉男さんの言葉を借りると、「プロセス改善というのは、そもそも何を改善したいか。個人の習慣を変えることや、組織の文化を変えること。ここがポイントだ」と。「しかも、それをきちんと継続させるような仕掛けも作らないといけない」と言っていました。個人も組織も変化に強くすることが、プロセス改善の肝である。

そういったわけで、とりあえず書き方のルールなどは置いておいて、（スライドを指して）これは私の作った当時のPowerPointですが、1枚目に会社の仕組みをとにかく書き表してみたら、いろいろな問題が起きていました。

こういった見える化をする、見える化というほどではなく絵を描いただけですが、これをやることによって、何が問題かを（把握して）はじめに着手できたんです。

例えば、回っていない要件管理というのが、すごく高いプライオリティな問題です。当時、とある掲示板ツールを使って、週に2回、2時間ずつ、1週間で4時間掲示板を見ながら、営業さんや開発者などを10人ぐらい呼んで、侃侃諤諤するようなことをやっていました。

すごく時間の無駄でした。それで「無駄を直しましょう」と言ってプランを提示したり、プロセスを「こうしたほうがいいんじゃないですか」という提案をしたら、改善が回り始めた。そんなスタートの切り方をしました。

ちょっとぼやきです。アジャイルマニフェスト、アジャイルのソフトウェア開発マニフェストに、「プロセスやツールよりも個人との対話を」という有名な一文がありますよね。共感はしている一方で、あれで失ったものがあると僕は思っていて。ここで出ているプロセスというのは、形骸化したプロセスや、考えもなしに持ってきたフレームワークのことを指していると思っています。

けっこう流行ったのもあって、アジャイルムーブメントの中で、“プロセス”という言葉を出すことに、タブー感が出ていたんじゃないかなと思っていました。

“プロセス”と言う人があまりいないと思います。みなさんが自社のエンジニアに「スクラムをしっかりとやっていますか？」と聞くところはいいのですが、「今どんなプロセスで開発をやっているの？」と聞いた時に、けっこう答えが変だと思うんですよ。

（スライドを指して）本当にあった怖い回答と下に書きましたが、「ウォーターフォールでもない、アジャイルでもない独自のプロセス」という回答を本気でされたり、「イテレーション風のプロセス」と言われたり、本当にこんな感じになっています。だから少し“プロセス”と言っていたのが残念だったかな、みたいなところもあります。

文化的負債Case2：静かすぎるオフィス

高橋：それではCase2、「静かすぎるオフィス」です。内藤さん、お願いします。

内藤：はい。発表の前に、このシートの見方を説明します。スライド上部にタイムラインが書いてあります。これは私たちが今日お話しする8年間で、星マークがついているところが、各ケースでアクションを取った時期になります。なので、シートの星マークを参考にしてもらえるといいかなと思っています。

Case2、「静かすぎるオフィス」です。私は2015年8月にウイングアーク１ｓｔに入社して、最初に思ったことはこれです。オフィスが静かすぎる。その前に2社経験していて、どちらも開発会社でしたがが、開発者は相談したり、談笑しながら仕事をしているイメージがありました。ですが、（弊社では）スーツを着て、みんな静かに自分の机に向かって黙々と作業をしていたんですね。

それが「一人ひとりスペシャリストであれ」という文化だったかなと思います。（スライドを指して）本当にこんな感じで一人ひとりの席が区切られて、ラーメン店の「一蘭」のような状態で仕事をしていました。

ただ環境が変化していって、だんだん仕事も増えていきます。そこで私たちは個の限界にぶち当たるんです。「このままでは仕事が終わらない」となります。

高橋：これは『エンジニアリング組織論への招待』という最近のとてもいい本の中から引用しているます。スペシャリストばかりを集めようとしても、組織として情報処理能力が上がるわけではないというグラフです。考えてみればわかるとおり、人が増えれば増えるほどコミュニケーションコストもどんどん増大していきますし、目標の統一化もいろいろ苦労するはずで、単純に上がっていかないという話があります。

また『THIS IS LEAN』からも引用しますが、スペシャリストに依存しようとすることは、リソース効率依存です。この本は和訳本が出ていますが、左がアリソンさんで、右がサラさんかな？　左の方が「ちょっと自分は癌かもしれない」と心配になって検査を受けるんですけど、いろいろな専門医を順番に回されて、（検査結果を聞くまで）42日間かかったという図です。

一方、右の人は1つクリニックで一気通貫に検査が2時間で済んだケースです。左がリソース効率を追求したプロセスで、右側がフロー効率を追求した病院といった話です。これの何が違うかというと、左の方は42日間も不安だったわけですよ。右の人は不安だったものの、2時間後には検査結果が聞けたという話になります。ということは、我々のビジネスも、どう考えるかが大事だと思っています。

また同じ本において、「フロー効率を生み出すためにはプロセスが大事だ」という話もあります。“ボトルネック”という有名な考え方がありますよね。そこをどうにかしなきゃいけないとなると、やはりプロセスをどうにかしないといけないと思っています。

内藤：そこで私たちは、個の限界を突破するためにスクラムを導入することを含めて、チームで協力して追加・変更に対応できる仕組みを作っていこうとしました。

実際にスクラムを導入したチームは、コミュニケーションが活性化しました。スクラムのイベントで強制的にチームの対話が生まれて、そこからどんどんよくなっていったかなと。

ただ、いきなり自己組織化するというのは難しくて、我々SPIグループは、チームの学習や改善を助けるような立場で関わり続けていきました。

すべてのプロダクトがスクラムを取り入れたわけではありません。スクラムを取り入れていないチームに対しては、ConfluenceやJIRA（Jira Software）で情報共有するような仕組み。あとはふりかえりを実施しましょうとか、かんばんやデイリーミーティングで「協力して課題解決をしていきましょう」ということを浸透させ続けて、今では文化として定着してきています。

高橋：ぼやきなんですが、スクラムマスターの振る舞いということで、有名なYouTubeがありますよね。スクラムマスターの1日を、ちょっと大げさに説明した動画です。これを、あるプロジェクトのキックオフでウケ狙いのために流しました。そうしたら、「高橋さんヒドイ！！　アレは私のことですか！」と怒られました。やはり用法・用量を守ってしっかりと使いましょうね、という感じです。

文化的負債Case3：要件の合意レベルが低い

Case3、「要件の合意レベルが低い」です。

内藤：私たちは要件の管理がなかなかできていませんでした。プロダクトマネージャーはすべて把握しています。しかし、それがシステム化されていないことによって、開発メンバーもステークホルダーも、何がどこまでできるのかわからないという状態に陥っていました。それで、ソフトウェア黎明期から繰り返されるアレが……。

高橋：そうですね。有名な「顧客が本当に必要だったもの」問題というのがちょいちょい起きると。

内藤：はい。起きました。

高橋：また清水（吉男）さんの登場ですが、「要件管理の肝は合意できることである」と。しかも要件管理を維持しようと、関係者全員が認識するのが必要です。例えば僕が営業で「開発の要件リストはどこにあるの？」と聞いたとします。そこで開発リーダーが「僕のパソコンのExcelローカルフォルダです」と言ったら、これはもう完全に関心がない状態で放置されているということですよね。

要件を合意するために、やらなければいけないポイントがあると思っています。

やはり仕様がどう出てくるかを考えると、背景があって、それをどうすれば解決できるかを考えて要求が出てきます。さらにその要求をどうすれば具体的に実現できるかとなって、初めて仕様になるという考え方がありますが、これをきちんとプロセスとして認識するのがとても大事だと思っています。

内藤：ここはプロセスをJIRAで管理できるようにしましたが、JIRAで管理したからといってプロセス自体が回るわけではありません。JIRAをどのように使うかという運用ルールだったり、回し方だったりをやって、その後、関係者みんなに説明会をすること。

システムだけを構築してもダメで、どういうコミュニケーションを取るかというところまで、すべて私たちが関わってやっていきました。その結果、5年ぐらいかけて、プロダクト横断で要望管理のプロセスが揃いつつあるというところです。まだ一部できていないところもあります。

高橋：ちなみにツールが大事だという話ではなくて、JIRAはすでに誰かが導入してあったので、せっかくあるから使ったという感じです。あとは合意が大事だという話を先ほどしましたが、スクラムのすごい点の1つに、やはり要件を合意できる仕組みが、巧みに組み込まれているところだと思います。

当然スプリントプランニングもですし、スプリントレビューでそもそもしっかりと完成しているのかをチェックするような、日々のデイリースクラムがあるところがすごい。合意できる仕組みとしては、とても有効だと感じています。

（次回に続く）