エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン

[連載:西田 宗千佳④] イマドキのソフト開発「失敗」の元凶はチームの規模感にある

公開

 
ジャーナリスト・西田 宗千佳のデジMONO先端研
先読み(3)西田氏_100px.jpg

IT・家電ジャーナリスト
西田 宗千佳

「電気かデジタルが流れるもの全般」を守備範囲に執筆活動を続ける気鋭のフリージャーナリスト。主要日刊紙や経済誌、MONO系雑誌にあまねく寄稿し、書籍の執筆も多数。最近は電子書籍関連の著書が多い。近著は『災害時 ケータイ&ネット活用BOOK 「つながらない!」とき、どうするか?』(朝日新聞出版/税込840円)など

この記事の読者の中には、ソフトウエアエンジニアの方も多いことと思う。

そこで一つ質問がある。あなたは、どのような「規模」で仕事をしているだろうか?

From ImagineCup とりわけSI事業などでは、ソフト開発=大人数で行うものというイメージが強い

From ImagineCup

とりわけSI事業などでは、ソフト開発=大人数で行うものというイメージが強い

日本のソフトウエアエンジニアは企業に属し、ある程度の規模のチームとして仕事を行うことが少なくない。開発チーム規模は小さくとも、その上位には、営業や用件定義を行うSEなど、トータルでは相応の人員でビジネスを行うのが通例だ。

企業として、ある程度大きな案件を手掛ける場合には、それが効率的であったからだ。

だが、ソフトウエア開発を必要とされる範囲が変わりつつある現在、開発の規模に対する考え方は、そろそろ変えるべき時が来ている、と筆者は考えている。その理由の一つとなっているのは、ソフト市場の主軸が「PC用」から「タブレット/スマートフォン用」に移りつつある、という事実である。

PC用のソフトウエア開発、特に企業向けの受託開発の分野は、すでに成熟産業と言える。単体アプリケーションから企業内で利用するWebプリケーション的なものへと主軸は移行したが、ビジネスの歴史はすでに25年におよび、ある程度の形ができあがっている。

他方で、そのビジネスのやり方が、タブレット/スマートフォンの時代に即したものではない、ということも見え始めた。特に最近多いのが、こういう案件だ。

ヒットアプリの多くは「個人」か「小さなチーム」が開発している

従来は中規模以上の企業向け案件を担当していたような企業が、スマートフォンの普及にあわせ、スマートフォン上で動く、いわゆる「アプリ」の案件を受託した。ソフト開発力はそれなりにある企業で、開発規模で見ても技術面で見ても、難航する案件ではないように思えたという。

ところが、現実は違った。できあがったアプリの完成度は低く、市場からの評価も極めて低いものになり、悪評を受けた発注元は、開発元へ急ぎ再開発を依頼することになる。まともな評価ができるアプリケーションができあがったのは、予定のリリース時期からは半年を過ぎたころ。

その間の再開発に伴うコストは、開発会社側の責任、ということになり、大きなコスト負担を強いられた。結果、ビジネス全体としては赤字、ということになってしまったという。

技術力も開発経験もあるソフト開発部隊が、なぜスマートフォンアプリでは失敗したのか?

理由は「距離感」だ。

クラウドやスマートフォン向けアプリの共通点は、一つ一つのアプリの開発規模が小さい、ということだ。案件全体では大きくとも、その内実は小さなアプリケーションの集合であり、小さなチームが短いスパンで開発を繰り返した方が効率的である。

スマホアプリランキングで上位を記録するアプリには、個人作や小規模な集団が作ったものが多い。その理由とは......

ランキング上位のアプリには、個人や小規模な集団が作ったものが多い。その理由は……

スマートフォンアプリの世界で、世界的な成功を収めたもののほとんどは、個人もしくは小さなチームで開発されたものである。

例えば電子書籍ビューワー。日本国内で評価の高い『i文庫HD』も、ダイヤモンド社が使っている『dReader』(※現在は『BookPorter』に名称変更)も、開発を担当しているのは個人の技術者である。「読みやすさ」、「使いやすさ」の評価では、多数のエンジニアを投下して開発されたはずである、大企業運営による電子書籍ストア用のアプリを大きく上回っている。

それ以外の例でも、スマートフォン向けアプリのヒット作には、企業が作ったものが驚くほど少なく、個人に近い小さなチームによるビジネスが多い。

なぜそうなるのか? それは、小さなチームであるがゆえにフットワークが軽く、全体の見通しが利くからである。アプリケーション規模が小さいため、トライ&エラーに近い形で開発していっても効率が悪くならない。ユーザーにより近い形で開発ができるので、ニーズも汲み上げやすい。

分業化による「速度感」「現場感」の喪失がキャリア上のリスクに

クラウドについても似たような事情がある。

サーバ構築からシステム開発を行うのではなく、すでに存在するサーバ上で小さい規模からシステムを作り、規模に応じて改良していく、という構築スタイルを採りやすいため、ユーザーニーズからの乖離を防げる。

企業向け案件では、受託者と開発者が同一でない、という例が少なくない。簡単に言えば子受け・孫受けの構造だ。そのような構造が許容されてきた理由は、IT投資が比較的高コストであり、分業化して効率化する余地が大きかったからである。

だが、クラウドアプリケーションやスマートフォン向けアプリの世界では、分業化に伴う「速度感」、「現場感」の喪失が、大きなリスクとなり得る。そもそも企業向け案件でのトラブルの多くは、開発を依頼した側の要望と開発側の事情のすり合わせがうまくいかず、できあがったシステムへの満足度が上がらない、といった点にある。

もちろん、大企業向けの大規模SI案件のように、既存のやり方が向いているものもまだまだ残ってはいる。そもそも、スマートフォン向けアプリケーションやクラウドのビジネスは、注目度の割にビジネス規模が小さく、大規模なソフト開発企業にとっては旨味が薄い、という事情もあるだろう。

だが逆に言えば、発想力とスピード感を持つソフトウエア技術者にとって、「自分が属する組織の規模」は必ずしも問題とはならなくなっている、ということでもある。チームの規模に応じた開発案件・ビジネスをうまく見つけ、きちんと回していくことさえできれば、個人レベルでも大きな成功を収めるのは難しいことでなくなりつつあるのだ。

海外のプラットフォーム系企業―アップルやアマゾン、セールスフォース・ドットコムといった企業―の人たちと話をすると、必ずと言っていいほど同じ話題が出てくる。

「アメリカでは、個人や中小デベロッパーが、新しいビジネスの種を探して開発者会議に積極的に参加してくる。だが日本では『業務命令でやってきたサラリーマンエンジニア』が多く、積極性が見られない」

もしあなたが腕に覚えのあるソフトウエア技術者であるなら、「小さなチームで戦う」可能性もある、ということを思い出す、良い機会だ。

撮影/芳地博之(人物のみ)