Best effort JavaScript

All essay implicitly 個人的には.

ポケモンGOリリース日に感じた優れたソフトウェア開発とそうでないものの違い

ポケモンGOが日本でリリースされた2016/07/22(金)。
平日にも関わらずtwitterにはポケモンGOを楽しむ投稿で溢れていました。

その中に混じってこんな投稿が目に入りました。

ソフトウェアテストの第一人者である和田さんの会社では、 全体的に業務にゆとりがあった事を類推させる内容の振り返り(日報のようなもの?)を18:46に行っていたようなのです。

この時自分は近日リリースされるシステムの開発に忙しく、残業をしてひいこらタスクをこなしていたのですが、 これを見て

(´-`).。oO (自分の現状とは大違いだ。「配信日にポケモンを楽しめるゆとり」が優れたソフトウェア開発と、そうでないものの差なんじゃないだろうか…)

たまたま忙しくない日だったのか、また和田さんの会社でどのようにソフトウェア開発が行われているのかなど、内部事情は分かりませんが、このように痛感しました。

ポケモンを楽しめるゆとりがあった理由を帰り道ぼんやりと思案。

複雑なソフトウェア、つまりスパゲティコードがなぜいけないのか、自分なりに考えてみました。

レガシーコードがダメな理由

レガシーコードが引き起こすコスト

  • 既存ロジック*1を理解するのに時間が掛かる。
  • 既存ロジックを壊さないような改修方法を考案に時間が掛かる。
  • 既存ロジックが壊れていないか確認するのに時間が掛かる。

コストが生じた結果

  • 開発が進行するに従って上記コストが重くなり、リリースが遅れる。大量のバグを出す。
  • ごく小規模な改修に膨大な工数が掛かってしまう。改修内容の軽さと修正コストの重さが著しく剥離している。
  • 改修によって既存処理が壊れていないか確証を持てない。常に不具合のリスクを抱え、ユーザー、取引先に不利益を与えてしまう可能性が上がる。*2
  • 各人のスキルアップ、新規事業、トレンドに合わせた機能追加など、事業の成長にフォーカス出来なくなり、他社に遅れを取る。

以上のように、
エンジニアの主要業務がデータと処理の流れを追う、慎重にデバッグをする、作業になってしまい生産的な活動が行われず、
最終的に企業価値の減少に繋がると考えています。

このような状態に陥ってしまうのは必ずしもスキル不足が原因ではないと感じています。
(仕様とシステムのズレを複雑な実装で吸収するというのは、優秀な人でないと難しそうです)

スキルが高い集団であっても、「良いソフトウェア」とは何なのかディスカッションし、それを形にしていく能力が無ければ、複雑なソフトウェアが出来上がってしまうと思います。
「良いソフトウェア」が明確であればそれを実装する能力は有している訳ですから、非常にもったいない話です。

これまではほとんど一人、二人で規模の小さいシステムしか作って来なかったので、
様々な設計技法、チーム開発手法を「ずいぶん小難しい言葉を使うんだな。却って分かりにくいな。」と懐疑的に捉えていました。
しかし今回の件でソフトウェア開発を甘く見ていたな、と実感し、それらの手法が求められる理由が分かった気がします。

*1:既存ロジック = データフロー(配列整形など) + 制御処理

*2:このようなソフトウェア開発が行われてしまう組織では、主要処理が網羅されたE2Eテストが用意されている事は考えにくい。テストするには大量の人員を動員するほかない。