｢バグがあってもサービスが面白ければ人は離れない｣提言の失敗【連載:TAIMEI】
2015/07/30公開
小俣泰明（TAIMEI）@taimeidrive
NTTコミュニケーションズなどの大手ITベンダーでシステム運用やネットワーク構築の技術を磨いた後、面白法人カヤックでディレクターを担当。その後、2009年4月に上場企業の取締役に就任。2012年8月にトライフォートを共同設立、代表取締役Co-Founder/CTOに就任。スマートフォンアプリ・ソーシャル領域に特化した開発・運営を展開している
タイメイです。連載第2回目も開いていただきあざーす！！
さて、2015年も上半期が終わりました。今、僕は時代の変化を強く感じています。今回は自分の提言の失敗について書きたいと思います。ITにおける重要な提言は約3年程度で変わってくるという話ですね。
僕は数年前、開発における重要なポイントとして、バグがあっても「サービスが面白ければ人は離れない」という考え方を提唱していました。
ベンチャーが大手と戦うには何よりスピード勝負。当時、他の技術責任者やCTOの方も「バグは文化」だったり「バグは個性」といった、バグを否定しない風潮が多くあったかと思っています。が、今はこの考察が通用しない時代になっていることを痛感してます。
特に3Dなど高性能なスマートフォンを要求する開発において、非常に重要なポイントになっています。
機種依存問題！
今の時代、アプリサービスをリリースした時に｢君のスマホは性能悪いから動かない。残念！｣では済まされません。無料アプリの場合でも、「無料で遊べること」を確実に保証しないといけない時代となったのです。
つまり「あなたのスマホは性能悪いから新しいスマホ買ってください」ということを伝えるようなメッセージになり得るアプリは、無料アプリだろうと｢価値のあるモノ｣とは言えないのです。それって、数万円もする費用をユーザーに要求している状態と同じこと。
つまり開発者はメモリ管理、メモリ解放をしっかりやるなどの対策を考慮しなくてはならないということですね。
具体例をいくつか挙げると、
■Unityのシーン切り替えは1枚間を挟むなどのテクニックが必要。また、開放してるつもりでも開放されていない状況なども存在する
■プレハブやテクスチャを変数に保持していた場合、シーンが破棄されてもその参照が残ってしまう場合がある（staticなマネジャークラスに保持していた場合など）
■OnDestroy()内に明示的にnullを挿入すれば参照がなくなる。これらの確認方法としてprofilerで確認し前のシーンが残っていないかをチェックするなどがある
こうした(機種依存対策)によって、“製作者”はさらなるスキルアップを要求される時代になりました。あえてここで技術者ではなく“製作者”としたのには、技術者レベルでは解決できない仕様に踏み込む問題があるためですね。
例えば、Android4.0以降、iPhone4S以降は基本対応できなくちゃいけない（非対応機種は目標全機種利用割合7％以下に抑えたい）。でもそれって、エンターテイメントとしての表現をかなり制限させてしまいます。それでもユーザーが求めているものは、快適に動作するアプリケーションです。これを無視しては、成り立たない。
さらに開発者に求められるスキルとして、運用後の状況を想定した開発ができるかというところまで意識を広げる必要があります。運用後、頻繁に変更が想定される部位の開発であれば、そこは丁寧に他の人が対応することを前提としたソースにするべきで。
マニュアル通りだけじゃダメってこと
ただし、開発にはコーディングルールとか規約統一とかあるけど、僕自身はそれが答えじゃないと思っています。これって例えばレストランのマニュアルと同じ。ユーザー側で見た時にマニュアルだけの対応って、すぐ飽きちゃいませんか？
例えば先日、会社近くのお店でランチを食べたのですが、そこのお店は店内がすごく広い空間だったんです。
from PortoBay Hotels & Resorts
マニュアルだけだとなんだか、つまらないと感じてしまう
そこで僕の目にとまったのは、お客さんが出て行くたびに入り口までスタッフが送りに行っている姿でした。僕はびっくりして、思わずお店のスタッフに聞いてみたんです。
「毎回、階段降りて出口まで見送るって、すっごく親切にみんなやってますけど、これってマニュアルがあるんですか？もしくはオーナーや店長の方針？」と。
すると、スタッフの方は「これ自主的にやってるんです。マニュアルとかも特にありません」と答えたんですね。僕は非常にクリエイティブな考え方を持った集団だと感じました。考えてみれば、スタバもマニュアルづくりとかしない代表の会社でしたよね。
これを開発現場に置き換えてみると、技術においても、コーディングルールや規約ってしばりの中で開発することで、クリエイティブな開発ができなくなることにつながると思っています。ひいてはクリエイティブな技術者精神を奪われていく。それに気付かずに、だんだんとそれに染まっていく。
経営者で、よく｢そういう言われたことだけをしっかりやってくれる人間をたくさん作れば良い｣という人がいます。が、それじゃスケールはしないと僕は思っています（ビジネスモデルによるので一概には言えないところもありますが）。
バグをなくすため＝ルール化することは本末転倒
つまり、バグの元を止めるような活動ではなく、重要なのは
【1】質の高いバグ発見体制
【2】運用後の改変部位へフォローがされたコーディング
だと僕は考えます。
まず、【1】が重要なのは、残念ながら今のバグはコーディングレイヤーでどうこうなる部分というより、バージョン依存の問題やインフラレイヤーとの連携など外的要因が多いためです。
from PROSylvain Kalache
クリエイティブな技術者を目指そう！
インフラからサーバサイド、ネイティブ、各プラットフォーム基準まですべてを見れるエンジニアがいないとそこは難しい。
CTOならそれくらいは、すべて把握するのは当然。情報力も重要なので、【1】の体制を担当する人間は、CTOレベルに近い能力を要求されると思います。
次に、【2】は運用がないサービスは成り立たない時代なので、永遠に同じ開発者が同じ部位を開発し続けるという状況はなくなっています。そこでどれだけソースの中にエラーハンドリングなどを今後の改変を想定して用意できるかなどが重要になる。ポイントは部位によるってところですね。
僕はこうした点を意識できるクリエイティブな技術者が増えていくことが重要だと考えます。そうすることで、日本のソフトウエア産業が強くなっていくのだと考えます。
変革の時期に大切な考え方
技術者のレベルやそのサービスの状況に応じて、開発の中での対応方針は変わります。そこで大切なこととして、僕が思っていることは2つ。
まず、技術初心者は他の人のソースを参考にするのは当然のこと、次に数％の個性のコーディングを意識してほしいということ。ここが成長につながる重要なマインドなんです。
そして、スキルの高いエンジニアは運用フェーズの想定を考えて、スケジュール感を自分でコントロールすること。
あくまで運用後、こんな管理ツールが必要じゃないか？ってところではなく、そういう管理がしやすいDB設計やクラス設計にしておくことや、データが1000万行になった時でも問題ないことを想定した構成を組んでおく。管理ツールとかマニュアルづくりに近いような活動は、2の次、3の次！
クリエイティブ性を失わずにどうバグと付き合い、向き合っていくのか。今、スマホ時代においても重要な変革の時期を迎えています。
■関連の外部リンク