「さくっと構築」で顧客環境を「見える化」
"愛ある"レビューでレビュー文化を根付かせる
原理原則を言っていても進まない。これまでの改善を行ったとしても収入が増える訳でもない。理想ではなく現実的な解決策を考えたときは石田氏は「エバンジェリズム」の重要性を説く。つまり、「こうすべき」との意思を見せつつ、賛同者を募り、組織を動かしていくほかない。
ドリーム・アーツではこの活動の第一歩として、ユーザー側のコードの「見える化」を図った。大規模で、多数のオンプレミスやバージョン、カスタマイズ、データ連携が行われており、導入パートナー会社も多い、そうしたお客様ごとの再現環境さえあれば、ということで即自インスタンス化を目指して開発されたのが「さくっと構築」である。
システムのインシデントを「SmartDB」で登録・管理し、担当はSlackでbotにコマンドを打つとユーザーのさまざまなバージョンを即自にインスタンス化し、お客様ごとの環境がすぐにできる。カスタマイズやアドオンがあればGitHubから取ってきてテストし、修正すればよい。それを次の回にアーカイブ化して残しておくというわけだ。
これをドリーム・アーツでは、サポートチームが連絡を受けて窓口で再現し、早期解決によって顧客の満足を得ていると言う。
「さくっと構築」のお客様窓口フロー（講演資料35ページより抜粋）
そしてもう一つ、石田氏は「レビュー文化を組織に根付かせること」を挙げる。いわゆるPMなどに出てくる方法論については、すでにドリーム・アーツでも導入している。何度もレビューを行ってはいるものの、なかなかうまくいかない。その理由は、感想や意見、批判、非難などに終始して、いわゆる具体的なレビューにならないことだという。
「ベテランほど『オレの経験ではこれは失敗する』などと議論をレガシー化していく傾向にあり、コードに対しても具体的な指摘ではなく、『もう一度勉強してこい』『これではよくない』などの批判・非難に終始する。レビューがちゃんと意味をなすには、コードに対する明確な批評が必要」と石田氏は語る。
なお、このレガシーコードを引き起こすのは、「ドキュメントなし」「コードが悪い」「設計が悪い」「この言語は古い」など、事実を述べたつもりが非難になってしまうことだ。結果として人の感情に作用し、炎上してしまう。厳しい環境下で人間がやったことだけにバグがあるのは当然。「バグを憎んで人を憎まず」というスタンスが重要というわけだ。
重要なのは「ソフトスキルを生む環境」
未来のためにレガシーコード問題の解決を！
石田氏は「バグだらけの人間関係によるシステムをきちんと動かせるよう、組織をリファクタリングしていこうと。そのための仕組みをデザインし、コーディングし、仕掛けた」と、レビュー文化を組織に根付かせるための方策を紹介した。
それぞれの施策はとてもささいな、しかし人間的なものだ。例えば、問い合わせ対応のインシデント管理の画面で、中国の会ったこともない相手とのやりとりが多く、殺伐としていたところに、顔写真を掲載することで劇的な効果が現れたと言う。つまり、写真の人とコミュニケーションする意識を持つことで、聞き方が丁寧になったり、より多くの情報を提供しようとしたりといった行動が増えたというわけだ。
また、感情を表す「絵文字」の導入や用語の統一、エンジニア組織がやっていることを伝える「社内報」の配布など、不要な感情のすれ違いやぶつかり合いを避けるような施策も導入した。つまり、「レガシーコードを克服する」ためには、ソースコードの発掘やバージョンコントロールといったノウハウもさることながら、「ソフトスキルを生む環境」を作ることが重要なのだという。
ドリーム・アーツのレガシーコード対応状況（講演資料50ページより抜粋）
上の図は、この仕組みを導入した後の「障害申告（赤）」と「手持ちの改善課題（青）」である。合計最大70近くあった手持ち課題も現在は14となり、徐々に収束していく気配が見て取れる。
こうしたことから、少しずつ時間的な余裕が増え、エンタープライズのシステムを作る際にも、WebサービスのようなUI/UXのビジュアライズなどを行い、より分かりやすい作りやすい方法へとシフトしているという。
「エンタープライズにも優れたUI/UXを持たせることは、今後さらに重要になっていく。そこにリソースと時間を割いていくためには、やはりレガシーコード問題の解決が必要だ。ぜひ、既存のセオリーに加え、コミュニケーションなどのソフトスキルを活用してほしい」
そう石田氏は語り、レガシーコード問題の解決を勧めて、セッションのまとめとした。
