第68回例会報告
24歳で起業し、13年間ベンチャー企業の立ち上げと経営に携わってきた小野さんは、4年前にセゾン情報システムズとの資本業務提携を経験し、当初は文化の違いに戸惑ったそうです。しかし今ではこの違いをむしろ武器として活かし、「バイモーダル」な文化を形成し、老舗SIerの改革が実を結びつつあるそうです。
略歴
小学校3年生から趣味でプログラムを始める，当時はN88-Basic。プログラミングという一種の魔法の世界に引き込まれた。その後，XMLが登場した当時，パーサー開発などを行った。
シリコンバレーに興味を持ちサン・マイクロシステムズに入社。その後，23才でアプレッソを起業。エンジニアの楽園のような場所を作りたいという想いからだ。
世界に通用する日本のプロダクトを開発
アメリカでは日本のプロダクトは存在しない。逆に日本では海外製のソフトウェアばかりである。特にエンタープライズの領域で世界に通用するソフトウェアを作りたいと思った。
そこで，日本においてソフトウェア開発を行った。そこで日本企業独特の文化に直面した。それは会議体の運営方法であったり，書類のスタンプラリー，調整・根回し，事なかれ主義などなど。
しかし，日本のプロダクトの品質はいい。Hulftなどはほとんどバグの無い堅牢なプロダクトだ。これは日本の組織としての力といっていい。この組織としての馬力が日本にはある。クリエイティブではないかもしれないが，日本の強みといえるだろう。
SIの問題
SIには様々な問題がある。特に技術力の空洞化が問題だ。プログラミングの経験がある人間が多くいて，一部を下請けにお願いしプロジェクト管理を行えればいい。しかし，そのうち新卒社員がプログラミング経験なしでプロジェクト管理だけの仕事につくようになる。こうして技術の空洞化がおきる。
また，SI会社で新規事業を立ち上げることが難しいと感じる。提案しても成功の可能性や世間の評判などを気にするばかりだ。新規事業なのだから成功するかどうかはわからない。成功するとしても，それまでにキャッシュは出て行く。それに耐えられない保守的なマインドがある。SIをやっていれば定期的にお金が入ってくる。その安寧が思考を保守的にしている。
SI開発には問題も多く，今後続けていけるかどうかわからない。これは共通的に認識されている。つまり泥舟に乗っているという自覚はあるのだ。だが，そこから降りられない。降りるより泥舟に乗っているほうが当面は安全であるという思考が働いてしまう。
技術的負債
内製化できず技術が空洞化していくと，技術的負債を抱える事となる。技術的負債とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す比喩である。
SIとして納品できればいい，動作すればいいという姿勢であれば，その資産は負債と化す。
これはSI業界の“あるある”だが，様々な案件をこなすSI企業は，個々のプロジェクトの知識を横展開するというナレッジマネージメント手法が語られる。しかし，中身がゴミだとゴミを撒き散らすことになる。ただでさえ金利の高い汚いコードを横展開しては膨大な負債を抱えることになるのだ。
ソフトウェア開発と料理
この両者は似ている。では問おう。料理を作った経験のないシェフが作ったレシピを，美味しいと思うだろうか？もちろんありえない。このような非常識がソフトウェア開発では横行している。
それは，詳細設計まで丁寧にドキュメントを書き上げ，あとはコードをタイピングするだけという設計〜開発のスタイルに原因がある。ソフトウェアの開発は料理と通ずる。都度味見し状態を確認し仕上げる。プログラムも，書き，直しを繰り返す，設計をも変えていくというスタイルが正しい。
日本だけが前述のような開発スタイルになっている。それは多重下請構造が原因だろう。
もちろん，過去には高い技術力を有しなくてもなんとかなった時代があった。その当時はソフトウェアに対する要求がシンプルで業務さえわかっていれば簡単にソフトウェアを作れた時代であった。しかし，2005年くらいからだろうか，Web系の企業やクラウドなどが登場してきた。この頃から高い技術力は必須となった。
そもそも，プログラミングは下級職種的スキルではない。それにより何十倍，何百倍の差が出る高度な技能である。
BPと協力するとしても内製力があり技術的負債を背負わずに開発しなければならない。このような現状を憂い，理想の形を実現してみようと思った。
技術力向上の施策としてモダン開発推進チームを発足
技術力の指標を資格だけに求めることは難しい。資格そのものは，最低限の力の保証にしかならないからだ。また，開発の手法というものは様々であり，技術力というものは簡単に測定できないものである。
そこで，先端技術を把握し，それを担うテクノベーションセンターを2016年10月に新設した。これを「モダン開発推進チーム」と名付けた。このチームは各プロジェクトに入って様々な支援を行う。そして，それにかかるコストは，各プロジェクトには反映させずモダン開発推進チームが持つ方式とした。
SIには性悪説的な側面がある。これに違和感を感じる。性悪説的な立場を取ると問題が起こった時に遡及することには役立つが，問題を起こさなくするような工夫のほうが必要だろう。つまり，問題を起こさない良い方法を見つけ出し，それを多くのプロジェクトに広げていきたい。
例えば，デイリーコミット，自動テストなどの技術が普及すれば，工程の後期で問題が発覚し大きな手戻りとなることも少なくなる。
このような方法，技術を知らないエンジニアもいる。しかし，良さが実感できたエンジニアはインフルエンサーとなって，その方式を広めてくれるようになった。技術は体験することが大事である。体験すると良さがわかり顧客に対する言葉にも力がこもり，CIなどの導入も承認されやすい。
モダン開発推進チームの支援は，従来型のレビューなどではない。そもそも，上からのレビュー文化は良くない。悩み困ったことを解決してくれる支援が望ましい。具体的には，アーキテクチャやフレームワークなどの設計支援，CI・CDなどの開発支援，デザインパターン・コードレビューなどの実装支援などがある。特に，美しいコードを書くことの意義も体験させてみないとわからないものだ。これらが感動体験を生む。逆に言えば，感動体験がないと変えようと言う気にはならないのだろう。
ソースコードの管理などもST直前に一斉コミットしていたのを，デイリーコミットに帰ることで，作業の定量化，チーム全体での共有が可能になる。これがリズムを生む。
コミュニケーションも，メール・電話からSlackに変更した。総じて，問題の早期発見が可能になった。これは，定例会議などでは発見できないものだったりする。モダン開発が根付くともはや従来の方式には戻れない。
PMジェダイ評議会
PMというものも必ずしも資格ではない。何の基準もなくてもいいので，各事業部から「こいつは凄い！」という人物を選出してもらった。合計7名のジェダイが選出された。
進行中のプロジェクトのなかで問題のあるものにジェダイを派遣することで，すぐに問題が明確になった。また，ジェダイというネーミングの面白さも重要なファクターだ。
SoR（System of Record）とSoE（System of Engagement）
SoRは記録のシステムであり，企業活動で発生する事実を記録するものだ。具体的には受発注や売上などの伝票をベースにした基幹業務システムである。対してSoEは絆を生み出す，つまり顧客との関係を強化するシステムである。もちろん，この2つは方法論が異なる。これは，バイモーダルにつながる。従来型のSoRに対する方法はバーモーダルのモード-1。SoEはモード-2ということになる。
バイモーダル
バイモーダルとは「2つの流儀」ということである。モード-1と2がある。
モード-1は従来的であり，安定重視。開発手法はウォーターフォール的であり，予測可能な業務についてのモードであるといえる。
対してモード-2は，ヴェンチャー的であり，アジャイル手法をとり速度を重視する。
モード-1はROIを重視するが，モード-2はそうではない。先の見えない挑戦だからだ。だから，モード-2では1000社にアプローチして，999社が失敗しても1社から10,000倍となればいいという考えとなる。
また，モード-1と2は武士と忍者に例えられることもある。そして，日本の歴史ある企業はほとんどモード-1であるといえるだろう。
さらに，このバイモーダルをよく表している表現がある。それは「コンパスoverマップ」というものだ。旅をする時にマップがあるとありがたい。但し，マップ作成には多大なコストがかかる。書いているうちに変化する。だから，マップは書かずにコンパスでの方向を頼りに旅をする方法，これがモード-2だ。もちろん，モード-2ではコンパスの向きを慎重に見極めることが重要となる。
そして，これは重要な確認であるがモード-1と2は，どちらが正しいというものではなく，両方備える必要があるということだ。
モード-1はウォーターフォール的であるが，プロジェクトをやりきる馬力がある。モード-1と2を自転車の両輪に例えることが出来るだろう。馬力を生むのは後輪でありこれがモード-1だ。そして方向を指示し変えるモード-2が前輪ということになる。
Hulftの進化
Hulftは古いプロダクトでありメインフレームやUNIX中心の連系というイメージがある。しかし，縮小しているというわけではなく成長そしている。これは，自分の弱みである領域を逆に取りに行くというポートフォリオ戦略が中心になる。Hulftが殺されると思われる領域は何か？それはおそらくクラウドであるだろう。そこで，実際のクラウド運用について調査を行った。すると，実際にクラウド事業でも苦しんでいるところはたくさんあった。具体的には，クラウドとオンプレミスの連携部分などだ。その「ペインポイント」にHulftを適用させる戦略をとることでプロダクトは再浮上することができた。
テクノベーションセンターとラストマン
先端技術の研究及び，モダン開発推進を中心にテクノベーションセンターを設立した。もちろん，技術に対して手を動かすことが中心の組織だ。
ここでは，「ラストマン」の育成を心がけている。ラストマンとは，ある領域で自分が最も詳しいと自信が持てる人物像だ。そのグループ・企業の中で，この領域に最も精通している。あなたの後には誰もいないという意味である。
人間が最も成長する瞬間は誰かに頼られるときだ。そこでラストマンに辿り着く。人間は頼られると更に学習をする。これが技術獲得の力学となる。
風通しの良い文化を作る
コミュニケーションツールとしてSlackを導入した。これは世界のトップ企業の80％以上が使っているアプリケーションだ。電子メールにはないフレンドのような感覚で会話ができる。特に広場のような場所につぶやくことで，まさかの人からのメッセージが来たり，協力が得られたりするのだ。
また，「HRTの原則」というものも導入した。これはGoogleのGeekたちから発信されたものだ。Googleでは様々なプロジェクトが動いている。中には権威のある人や天才と呼ばれる人たちが集まったプロジェクトもある。これらプロジェクトは成功したものも失敗したものもある。そこで，どういうチームが成功していたかをGoogleは調査した。それは必ずしもドリームチームということではなかった。より成功していたのはHRTがあるチームであった。
HRTとは，Humility：謙虚さ，Respect：尊敬，Trust：信頼のあるチームであった。これは和であり日本的な文化性であるといえるだろう。それをGoogleが実践していたということだ。
人は交流が深まれば失礼な言葉も言うようになる。そこで「HRT！」と発言することで和が生まれた。
Practice Over Theory
今のテクノロジーは触る，体験することでわかる。理論よりも実践である。そして，AI時代の今だからこそ，このことが言える。
事例としてBitcoinの体験会を行った。それまでメインフレームエンジニアなどはBitcoin，Block Chainなどの言葉は知っていても自分には関係の無いことだと認識していた。そこで，Bitcoin体験させるためにスマートフォンで実際に取引をさせてみた，すると皆から歓声があがり興味を持ってくれた。更には取締役に対しても実践し同様の反応を得ることができた。
まとめ
・技術力とPM力の問題
内製化の重要性を啓蒙した／モダン開発推進チーム／PMジェダイ制度などで改革を行った。
・文化の問題
バイモーダル戦略／Slackの導入／HRT原則
・事業の問題
Practice Over Theory／Compasses Over Maps
全てに通じることだが，このような問題の解決は敬意を払ってことにあたることが重要であった。モード-1はダメと思っていては変わらない。モード-1の力を認識し敬意を払ったからこそ，このような改革を実現することができた。
質疑応答
・改革の取り組み，その具体的な内容，ステップは？
改革を行うのだから痛みは伴う。しかし，会社が戦々恐々となったわけではない。それは文化や既存のやり方を一切否定しなかったからだ。人を否定して改革を全面に押し出すことはうまくいかない。
ではどうするか？それは成果で説得をすることだ。成果を見せて体験させることが重要である。それを次々と行っていった結果に改革がある。
・チャットツールとしてのSlackの普及方法について
このようなツールを導入すると，遊んでいるように見られるという問題が生じる。やはり導入には成功体験が先立つ。そのために，社内の懇親イベント参加者の中から希望者にSlackのアカウントを付与した。社内の懇親イベントに参加しようという人は，風通しを良くしようという思いがある人だ。この人達を先行させると自然に成功体験が生まれ導入が加速した。
