「最悪のソフトウェアはマネージメントの問題」、よいソフトウェアを作る方法を政府のソフト開発を行う技術者が語る

by Austin Distel

「ひどいソフトウェアが生まれる場合、問題は特定のエンジニアリングではく、マネージメントにあることが多い」と語る、Googleのプロダクトマネージャーを経てシンガポールの公安部門向け技術開発を行うLi Hongyiさんが、「よりよいソフトウェアはどうやって構築するのか？」をつづっています。

How to Build Good Software
https://www.csc.gov.sg/articles/how-to-build-good-software

Hongyiさんは、ひどいソフトウェア開発の問題点を一文で「プロジェクトオーナーが解決すべき問題を明確にすることなく解決策としてのソフトウェア構築をスタートさせ、関係者からの長い要望リストを、フルスクラッチで開発を行おうとする外部の開発チームに委託すること」とまとめています。

一方で優れたソフトウェア開発は、まず解決したい問題を明確にすることから始まります。問題を明確にすることで考えられる解決策をテストし、適切なアプローチを行うことが可能になるためです。そして、現代では多数のオープンソースコミュニティが存在することから、フルスクラッチでソフトウェアを作ろうとするのではなく、既存のコードをうまく利用することが大切になります。というのも、エンジニアたちの時間が既存技術の再構築に取られていては、技術の進歩を遂げることができないため。日常的なエンジニアリングをできるだけ自動化し、再利用に適したシステムを識別して、必要に合わせてそれをカスタマイズすることが大切だとHongyiさんは述べています。

by Pankaj Patel

またソフトウェアを左右するのはそのリソースの量ではなく、むしろ「使いやすさ」です。多くの場合、機能が多いシステムは嫌われ、人気ランキングの上位にはシンプルさが高く評価されるアプリが並ぶ傾向があります。新しい機能をどんどん追加していくとユーザーを混乱させるために、AppleのiTunesも最終的に音楽・ポッドキャスト・テレビ番組という3つに分割されました。

プロジェクトの複雑さが増すと、エンジニアリングの進行自体が止まってしまいます。アプリのコードベースが多いほど、新しい機能が構築されるたびに多数のバグが生じることに。これは「技術的負債」と呼ばれ、大規模なITシステムが抱える大きな課題となっています。このようなシステムには、何年もの間、修正されていない問題があることも少なくありません。

そして、ソフトウェアは一見するとシンプルに見えても、そこに至るまでには多数のアイデアとプロトタイプが存在することが大半です。Appleでは最終的な製品が公開されるまでに、数十のプロトタイプを経ています。最終決定が下されるまでにはいくつもの意志決定があり、「なぜ特定のソリューションが選ばれるのか」という決定を下すための複雑な知識が必要になります。

by Shahadat Shemul

ソフトウェア開発にとって重要なのは、このような「知識」の蓄積です。あるソフトウェアのコードを別の開発チームが引き継ぐと、ソフトウェアの質が目に見えて落ち出すことがよくありますが、これはソフトウェアになじみのない開発チームが問題に対して間に合わせの修正を繰り返すため。間に合わせの追加コードが新たなバグを生み出し、ユーザーインターフェースが混乱し、最終的にはシステム全体が複雑になってしまうのだとのこと。これが、コアソフトウェアの開発を外部に委託することが難しい理由です。

上記の内容をふまえて、Hongyiさんが唱える「優れたソフトウェア開発の3つの原則」は以下の通り。

◆1：できるだけシンプルに始める

by Bench Accounting

よいソフトウェアを作るのに大切なことは、まず、最もシンプルな解決策から始めるということ。FacebookやWeChatといった多機能アプリも、最初は特定の機能に絞って始まり、人気が増すとともに徐々に機能を増やしていきました。ソフトウェアプロジェクトは「規模が小さすぎてつぶれる」ということはなく、「規模が大きすぎてつぶれる」ことがほとんどです。

また、利害関係者から多数の要望リストが送られてくることがありますが、これには「絶対に必要な機能か」「付加価値の高いものであるか」など、優先順位をつけるべきとのこと。機能の優先順位を上げたい人は、必然的に他の機能の優先順位を下げる事を考慮することになるので、話し合いも進めやすくなるとHongyiさんは述べています。

◆2：問題を探し出すこと

by Hans-Peter Gauster

論文を書く時に草稿が必要なように、いいソフトウェアを作るにはまず、「ベースとなる悪いソフトウェア」を作る必要があります。そして、そこから、問題の根源を正しく理解することが必要。例えば、政府主導の駐車券アプリである「Parking.sg」のプロジェクトが始まった当初、開発チームは解決すべき課題を「警察官が紙の駐車券をわずらわしく感じていること」だと考えていましたが、実際に現場の人々と話すと、そのような問題は存在しないことが判明しました。1つの対話によってその後数カ月の無駄な労力が節約され、「ドライバーを支援するプロジェクト」に集中することができたとのこと。

その後チームは、Parking.sgプロジェクトの「ドライバーは駐車券を扱う時に不満を感じる」という点の根源には、「政府のウェブサイトで情報を見つけるのが難しい」という問題があることを突き止めました。この問題点を明確化できたことで、問題に対する解決策の実行可能性をテストし、実際の製品の構築が可能になったそうです。

また、フィードバックを何度繰り返しても、実際の製品にはテスト中には発生しなかった問題が生まれることがあります。全体の0.1％しか発生しない問題はテスト中に顕在化しませんが、100万人のユーザーがいれば1000人がその問題に遭遇するためです。比較的軽微な修正を必要とする迅速なフィードバックグループと、より広範な問題を時間と費用をかけて解決するフィードバックグループの両方を使って問題解決にのぞむことが推奨されています。「ソフトウェアの構築で重要なのは失敗を回避することではなく、できるだけ迅速に、戦略的に失敗することです」とHongyiさんは述べています。

◆3：できる限り最高のエンジニアを採用する

by Max Duzij Follow Message

Google、Facebook、Amazon、Netflixといった企業は有能なエンジニアを募集するための激しい競争を繰り広げており、新卒者でさえ高い給与を得ることがあります。Facebookのマーク・ザッカーバーグCEOやAppleの元CEOであるスティーブ・ジョブズは「最高のエンジニアは平均的なエンジニアの少なくとも10倍の生産性がある」と述べていますが、これはコードを書く速さが10倍だという意味ではなく、優れた意志決定により作業を10倍節約できるという意味。

優れたエンジニアは再利用できるソフトウェアをしっかりと把握し、フルスクラッチで構築する必要がある部分を最小限に抑えることができます。また、日常的なタスクを自動化し、他のエンジニアが理解しやすいシステムを構築することが可能です。これによって周囲の人間が迅速かつ確実に作業を行うことができるようになるので、時間的な余裕が生まれ、エンジニアたちが創造的な問題解決に集中することができるようになります。

優秀なエンジニアの小規模チームは、生産性において、平均的なエンジニアの大規模チームをしのぎます。完成したソフトウェアのバグやセキュリティ問題は少なく、システムは簡潔で一貫性があり、理解されやすいものになるとのことです。