SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2016福岡】レポート (AD)

実録レガシーコード克服秘話、必要なのは「ソフトスキルを生む環境」【デブサミ2016福岡レポート】

  • X ポスト
  • このエントリーをはてなブックマークに追加

 苦労して作ってきたプロダクトのコード資産が、レガシーとなり新たな価値創造の足かせになる――。エンタープライズのLTS(Long Term Support)を担うエンジニアなら誰もが抱えがちな悩みといえるだろう。株式会社ドリーム・アーツでも大企業向けパッケージ・ソフトウェアの開発現場において同様の状況に陥り、試行錯誤しながら打開してきたと言う。その経緯と得られた知見について、同社取締役 CTOの石田健亮氏が紹介した。

  • X ポスト
  • このエントリーをはてなブックマークに追加
株式会社ドリーム・アーツ 取締役CTO 石田健亮氏
株式会社ドリーム・アーツ 取締役CTO 石田健亮氏

過去のプロダクツのコードが
次世代の付加価値創造の足かせに

 2016年のIPA(情報処理推進機構)IT人材白書では、75%のIT技術者が事業会社の情報システム部門、SIベンダー、ソフトハウスといった受託開発に携わっていると言う。そうした多くのエンジニアが、レガシーとなったコード資産の管理・対応を担っていることが伺える。

 一方、株式会社ドリーム・アーツもまた石田氏が担当してきた多店舗運営を支援するコミュニケーションツール「Shopらん」をはじめ、大企業向けのプロダクトを提供しており、1996年よりVer.1が提供開始となった企業グループウェア「INSUITE Enterprise」など、延々とメンテナンスを行ってきた製品がコミュニケーションや業務の基盤を支えていることも多い。石田氏もまた、自由にプロダクツを開発していた立場から、「INSUITE Enterprise」の改訂・メンテナンスに携わることになり、その中でさまざまな問題に取り組むこととなったと言う。

 そうした中で、石田氏がエンタープライズに携わるエンジニア100人に問題についてヒアリングしたところによると、第3位はブラウザが古い、第2位がUIを変えにくい、そして第1位は保守が困難となった。

 まず、第3位の「ブラウザが古い」について実際に調査すると、エンタープライズで使われているブラウザはいまだIE8が約3割を占め、Firefox、Chrome、IEのさまざまなバージョンが続き、その上5%がいまだIE6を使っているということが分かった。

 さらに第2位の「UIを変えにくい」については、石田氏が「登録する」ボタンの位置が1pxずれたことで「社内マニュアルの変更がある」とクレームになったことを紹介。それだけ、UIはセンシティブで変えられない存在であることを強調した。

 そして、第1位の「保守が困難」については、オンプレミスであり、大規模で複数のバージョン、カスタマイズ、データ連携なども多々行われており、さらには導入パートナー会社も多いという、がんじがらめの状態であることが多いと言う。これが生じるのは、LTS(Long Term Support)が求められるから。いわゆる「レガシーコード」が発生してしまっているというわけだ。

 「レガシーコード」とは、ドキュメントもなければテストコードもない、そもそも"クソコード"であることが多く、設計もひどければ、使われている技術も古いという状態だ。しかし、そうはいってもそれが現実であり、なんとかしなれば何も変わらない。次の世代に、"ちゃんとした状態で"手渡すためには、どうしたらいいのか。

伏魔殿と化したエンタープライズの裏側
運用の原理原則も現場では無効

 石田氏はまずレガシーコード発生の背景について、「プロダクツ側ではなく、システム構築側に起きやすい」と分析する。つまり、よくあるSIer案件では、要件定義からカットオーバー、保守という時間軸の中で、価値はカットオーバー直後が最も高くなだらかに下がっていく。しかし、実際には要件定義で理想を描きつつも、なかなか進まずに納期だけが迫ってくるため、結局"やっつけ"で仕事をせざるを得なくなり、カットオーバーには要件が満たせず、ずるずると作業をやらざるを得ない……という状況に陥りがちだ。

 「会社からは予算オーバーするなと言われ、その間システム価値はどんどん目減りする。エンタープライズというとスマートな印象があるが、その実内部はドロドロのめちゃくちゃ。さらに何か連携先のシステムが変わるということで修正要望が上がり、調べてみると伏魔殿的で、よく分からず適当に修正し、再びトラブルが起き、調べてもよく分からず……というデススパイラルに陥ることになる」

 石田氏はレガシーコードが生じる背景をそのように説明し、「これに若者を巻き込むのは心苦しい。レガシーコードをこのままにしていても闇は深まるばかり。なんとかきれいにして渡すべきではないだろうか」と語った。

 「レガシーコードに光を」と、解決先を考えたときに、その方法として一般に言われているのが、ソースコードを発掘・管理し、バージョンコントロール下におくこと。そしてビルドやスクリプトを動かせる環境を用意し、テストケースでガードして、リファクタリングしながら少しずつ改善していくという方法だ。

 詳細は『レガシーコード改善ガイド』(翔泳社)や『リーダブルコード』(オライリージャパン)などの手引書に委ねるとして、石田氏は「それ以外の部分の知見も重要であり、今回はそこを紹介したい」と語る。

 実際、ドリーム・アーツでは、ジョエル・スポルスキが2000年に出した、ソフトウェアの開発チームのレベルを判定する「ジョエルテスト」をクリアしており、ソースコードも共有サーバーから、CVSなどを経て2016年からGitHubに切り替えられている。自動ユニットテストやテストカバレッジ計測、外部からSeleniumのテストも行い、ジョエルテストにもあった静かな環境を整えている。つまり、組織としては"ちゃんとしている"わけだ。ジョエルテストもほぼクリアしており、過去の仕様書の一部を整理するのみだと言う。

 しかし、エンタープライズの開発では、そこまでしても"伏魔殿"になりがち。その理由について、石田氏は「ソースコードの発掘などもろもろを作業しようとしても、『動いているものに触れないこと』が大前提となる」と語る。日本の美徳である整理整頓ができていない状況ながら、いわゆる原理原則では実際の現場には通用しない。それでは、どうしたらいいのか。

「さくっと構築」で顧客環境を「見える化」
"愛ある"レビューでレビュー文化を根付かせる

 原理原則を言っていても進まない。これまでの改善を行ったとしても収入が増える訳でもない。理想ではなく現実的な解決策を考えたときは石田氏は「エバンジェリズム」の重要性を説く。つまり、「こうすべき」との意思を見せつつ、賛同者を募り、組織を動かしていくほかない。

 ドリーム・アーツではこの活動の第一歩として、ユーザー側のコードの「見える化」を図った。大規模で、多数のオンプレミスやバージョン、カスタマイズ、データ連携が行われており、導入パートナー会社も多い、そうしたお客様ごとの再現環境さえあれば、ということで即自インスタンス化を目指して開発されたのが「さくっと構築」である。

 システムのインシデントを「SmartDB」で登録・管理し、担当はSlackでbotにコマンドを打つとユーザーのさまざまなバージョンを即自にインスタンス化し、お客様ごとの環境がすぐにできる。カスタマイズやアドオンがあればGitHubから取ってきてテストし、修正すればよい。それを次の回にアーカイブ化して残しておくというわけだ。

 これをドリーム・アーツでは、サポートチームが連絡を受けて窓口で再現し、早期解決によって顧客の満足を得ていると言う。

「さくっと構築」のお客様窓口フロー(講演資料35ページより抜粋)

「さくっと構築」のお客様窓口フロー(講演資料35ページより抜粋)

 そしてもう一つ、石田氏は「レビュー文化を組織に根付かせること」を挙げる。いわゆるPMなどに出てくる方法論については、すでにドリーム・アーツでも導入している。何度もレビューを行ってはいるものの、なかなかうまくいかない。その理由は、感想や意見、批判、非難などに終始して、いわゆる具体的なレビューにならないことだという。

 「ベテランほど『オレの経験ではこれは失敗する』などと議論をレガシー化していく傾向にあり、コードに対しても具体的な指摘ではなく、『もう一度勉強してこい』『これではよくない』などの批判・非難に終始する。レビューがちゃんと意味をなすには、コードに対する明確な批評が必要」と石田氏は語る。

 なお、このレガシーコードを引き起こすのは、「ドキュメントなし」「コードが悪い」「設計が悪い」「この言語は古い」など、事実を述べたつもりが非難になってしまうことだ。結果として人の感情に作用し、炎上してしまう。厳しい環境下で人間がやったことだけにバグがあるのは当然。「バグを憎んで人を憎まず」というスタンスが重要というわけだ。

重要なのは「ソフトスキルを生む環境」
未来のためにレガシーコード問題の解決を!

 石田氏は「バグだらけの人間関係によるシステムをきちんと動かせるよう、組織をリファクタリングしていこうと。そのための仕組みをデザインし、コーディングし、仕掛けた」と、レビュー文化を組織に根付かせるための方策を紹介した。

 それぞれの施策はとてもささいな、しかし人間的なものだ。例えば、問い合わせ対応のインシデント管理の画面で、中国の会ったこともない相手とのやりとりが多く、殺伐としていたところに、顔写真を掲載することで劇的な効果が現れたと言う。つまり、写真の人とコミュニケーションする意識を持つことで、聞き方が丁寧になったり、より多くの情報を提供しようとしたりといった行動が増えたというわけだ。

 また、感情を表す「絵文字」の導入や用語の統一、エンジニア組織がやっていることを伝える「社内報」の配布など、不要な感情のすれ違いやぶつかり合いを避けるような施策も導入した。つまり、「レガシーコードを克服する」ためには、ソースコードの発掘やバージョンコントロールといったノウハウもさることながら、「ソフトスキルを生む環境」を作ることが重要なのだという。

ドリーム・アーツのレガシーコード対応状況(講演資料50ページより抜粋)

ドリーム・アーツのレガシーコード対応状況(講演資料50ページより抜粋)

 上の図は、この仕組みを導入した後の「障害申告(赤)」と「手持ちの改善課題(青)」である。合計最大70近くあった手持ち課題も現在は14となり、徐々に収束していく気配が見て取れる。

 こうしたことから、少しずつ時間的な余裕が増え、エンタープライズのシステムを作る際にも、WebサービスのようなUI/UXのビジュアライズなどを行い、より分かりやすい作りやすい方法へとシフトしているという。

 「エンタープライズにも優れたUI/UXを持たせることは、今後さらに重要になっていく。そこにリソースと時間を割いていくためには、やはりレガシーコード問題の解決が必要だ。ぜひ、既存のセオリーに加え、コミュニケーションなどのソフトスキルを活用してほしい」

 そう石田氏は語り、レガシーコード問題の解決を勧めて、セッションのまとめとした。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9755 2016/11/02 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング