ポケモンGOリリース日に感じた優れたソフトウェア開発とそうでないものの違い
ポケモンGOが日本でリリースされた2016/07/22(金)。
平日にも関わらずtwitterにはポケモンGOを楽しむ投稿で溢れていました。
【お知らせ】ポケモンGO配信のため、本日の業務は終了させていただきます pic.twitter.com/x7L49ldEZE
— 株式会社バーグハンバーグバーグ (@BHB_official) 2016年7月22日
その中に混じってこんな投稿が目に入りました。
流しのペアプロ業、今日やったことをひとりひとり報告していく slack 上の夕会で、半数近くが今日やったことにポケモンを挙げており、味わいがある。
— Takuto Wada (@t_wada) 2016年7月22日
ソフトウェアテストの第一人者である和田さんの会社では、 全体的に業務にゆとりがあった事を類推させる内容の振り返り(日報のようなもの？)を18:46に行っていたようなのです。
この時自分は近日リリースされるシステムの開発に忙しく、残業をしてひいこらタスクをこなしていたのですが、 これを見て
（´-`）.｡oO (自分の現状とは大違いだ。「配信日にポケモンを楽しめるゆとり」が優れたソフトウェア開発と、そうでないものの差なんじゃないだろうか…)
たまたま忙しくない日だったのか、また和田さんの会社でどのようにソフトウェア開発が行われているのかなど、内部事情は分かりませんが、このように痛感しました。
ポケモンを楽しめるゆとりがあった理由を帰り道ぼんやりと思案。
優秀なエンジニアが作ったシステムは改修しやすく、テストもあるのでデバッグに時間がかからない。だから技術力の高い会社ほど遊びに溢れてるんやなぁ…
— Ryota Murakami (@malloc007) 2016年7月22日
複雑なソフトウェア、つまりスパゲティコードがなぜいけないのか、自分なりに考えてみました。
レガシーコードがダメな理由
レガシーコードが引き起こすコスト
- 既存ロジック*1を理解するのに時間が掛かる。
- 既存ロジックを壊さないような改修方法を考案に時間が掛かる。
- 既存ロジックが壊れていないか確認するのに時間が掛かる。
コストが生じた結果
- 開発が進行するに従って上記コストが重くなり、リリースが遅れる。大量のバグを出す。
- ごく小規模な改修に膨大な工数が掛かってしまう。改修内容の軽さと修正コストの重さが著しく剥離している。
- 改修によって既存処理が壊れていないか確証を持てない。常に不具合のリスクを抱え、ユーザー、取引先に不利益を与えてしまう可能性が上がる。*2
- 各人のスキルアップ、新規事業、トレンドに合わせた機能追加など、事業の成長にフォーカス出来なくなり、他社に遅れを取る。
以上のように、
エンジニアの主要業務がデータと処理の流れを追う、慎重にデバッグをする、作業になってしまい生産的な活動が行われず、
最終的に企業価値の減少に繋がると考えています。
クソコードの何がいけないか > データフローを理解するのに時間が掛かる。データフローを壊さないような改修方法を考えるのに時間が掛かる。データフローが壊れていないか確認するのに時間が掛かる。
— Ryota Murakami (@malloc007) 2016年7月26日
スパゲティコードっていうのは、終始データフローを追う事に時間と神経を奪われた挙句、既存のデータフローを破壊していないかテストをがっちりやらないと改修が成功したのか分からない。結果として生産的行為に時間と神経を注げなくので悪なんだよなぁ。
— Ryota Murakami (@malloc007) 2016年7月25日
このような状態に陥ってしまうのは必ずしもスキル不足が原因ではないと感じています。
(仕様とシステムのズレを複雑な実装で吸収するというのは、優秀な人でないと難しそうです)
スキルが高い集団であっても、「良いソフトウェア」とは何なのかディスカッションし、それを形にしていく能力が無ければ、複雑なソフトウェアが出来上がってしまうと思います。
「良いソフトウェア」が明確であればそれを実装する能力は有している訳ですから、非常にもったいない話です。
技術力というよりソフトウェア開発スキルが足りないと思う今日この頃
— Ryota Murakami (@malloc007) 2016年7月27日
これまではほとんど一人、二人で規模の小さいシステムしか作って来なかったので、
様々な設計技法、チーム開発手法を「ずいぶん小難しい言葉を使うんだな。却って分かりにくいな。」と懐疑的に捉えていました。
しかし今回の件でソフトウェア開発を甘く見ていたな、と実感し、それらの手法が求められる理由が分かった気がします。
