ソフトウェア開発って難しい
はじめまして。開発チームのマネージャーのkatoです。
突然ですが、ソフトウェア開発って、趣味でやるにはとても楽しいものですが、お仕事となると本当に「難しい」ですよね。見積もり通りに進まない、納期に間に合わない、バグがなくならない、途中で仕様が変わってやり直し、できたものが期待と違う、予算内に収まらない、最悪の場合メンバーが健康を害してしまう、、などなど、様々な問題が発生してなかなか「思い通りにならない」のです。そして、プロジェクトの規模が大きくなればなるほどこれらの問題はより顕著になります。開発を頼む側や担う側、何らかの形でソフト開発に関わったことのある方は、多かれ少なかれ必ずこれらの問題に直面されたことがあるのではないかと思います。
では、ソフトウェア開発ではなぜこのように多くの問題が発生するのでしょうか？そしてそれはどうすれば解決できるのでしょうか？もちろん、答えはそんなに簡単ではありません。顧客と作り手のコミュニケーション、設計手法、開発ツール、工程管理、チームビルディング、個人のスキル、など、様々な観点から、基本となる原理原則を理解した上で、現状の問題の発見と、プロジェクトの特性に応じた適切な改善策を積み重ねていく必要があるのです。
ソフトウェア開発というのは、例えるならば、「目に見えない巨大な生き物」を育てていく活動だと思います。期待通りに成長させるためには、見えない姿をできるだけ見えるようにした上で、その育て方を広い視点で考えることが必要です。「いやぁ、大変だなぁ。。」と感じられるかもしれませんが、逆にそれが面白いところなのかもしれませんね。
ジョエル・オン・ソフトウェア (Joel on Software)
当然世の中には、これらの問題に取り組むための方法論を考えている人や企業は沢山いらっしゃいます。ここでは、私がこの業界で働き始めた頃に出会った書籍を一冊ご紹介したいと思います。雲をつかむような仕事で途方にくれていた当時、「原理原則を理解する」上で深く腹落ちしたことが今でも印象に残っている一冊です。
『Joel on Software』
副題は、「ソフトウェア開発者、設計者、マネージャ、それに幸か不幸か何らかの形で彼らと働く羽目になった人々が関心を抱くであろう、ソフトウェア、並びに往々にしてソフトウェアに関連する諸所の問題について」
副題が非常に分かりやすいですね（笑）。これは、かの有名なMicrosoft Excelなど多くのソフトウェア製品開発に関わられたJoel Spolsky氏が、「ソフトウェア開発で本当に大切なことは何か」について書き綴られたブログを書籍化したものです。（当然ブログでも読むことが可能です。）
2000年～2004年頃の記事が中心なので、内容的にはやや古い（というよりは、今は当たり前になっている）ものも含まれますが、今読んでも充分に通用する「ソフトウェア開発に関する原理原則」がよくまとめられているので、現在でも一読の価値はあるのではないかと思います。
（続編で、”More Joel on Software”も刊行されています）
ジョエル・テスト
著書の序盤に、「ジョエル・テスト」という記事があります。原理原則はさておき、12の質問にYes/Noで答えることで、ソフトウェア開発チームのレベルをチェックできるチェックリストです。裏を返せば、原理原則を踏まえた上でのプラクティス集ということになりますね。Joel氏曰く、11ポイント以上が許容範囲、10ポイント以下だったら深刻な問題を抱えている、現実には多くの開発組織は2～3ポイント、とのこと。
＜ジョエル・テスト＞
1. ソース管理システム（構成管理ツール）を使っているか？
2. １オペレーションでビルドを行えるか？
3. デイリービルドを行っているか？
4. バグデータベースを持っているか？
5. 新しいコードを書くまえにバグを修正しているか？
6. 更新されているスケジュールがあるか？
7. 仕様書はあるか？
8. プログラマは静かな環境で作業しているか？
9. 手に入る一番良い開発ツールを使っているか？
10. テスト担当者はいるか？
11. プログラマの採用面接でコードを書かせているか？
12. 「ユーザビリティテスト」を行っているか？
いかがですか？あなたのプロジェクトは何ポイントでしょうか？2017年現在では、もはや「常識」となっているものも多いので、2～3ポイントということは無いと思いますが（と、信じたい…）、自信を持って11ポイント以上というところはまだまだ少ないのではないでしょうか。会社の制約やプロジェクト固有の事情で、完全にYESとするのは難しい項目もあると思いますが、各項目での背景にある原理原則をしっかり理解し、できる範囲で少しずつでもチームのレベルアップを図っていきたいものですね。
ストラテジーレター
著書の中には、ソフトウェア・ビジネスで成功を目指す上での、戦略面での原理原則をまとめた記事も含まれています。ここでは詳しくは書きませんが、プラットフォーム展開に於けるネットワーク効果やロックイン、後方互換性の問題、オープンソースの経済学など、興味のある方には面白い内容ではないかと思います。
私達の取り組み
ここまで著書の紹介を中心に色々と書いてきましたが、最後に、私達がお客様から依頼頂いたソフトウェア開発を行う上で、この難しい問題にどのように取り組んでいるかについて、簡単にご紹介したいと思います。まず、ジョエル・テストにあるような、定石的なことはできる限り導入した上で（もちろん全部は難しいですが…）、自分達なりに工夫しているポイントとして、次の３つのことを特に意識しています。
①お客様とのコミュニケーション
冒頭に述べた通り、ソフトウェア開発に於ける悲劇の一つに、「できたものがお客様の期待と異なる」ということがあります。これが発生する理由として、「お客様自身、はじめは欲しいものが明確になっていない」といったことも意外と多いものです。よって私たちは、お客様の要望のヒアリング→開発（試作）を進めてレビュー→フィードバックを貰って次の開発へ、というサイクルを細かく回す、所謂「アジャイル型」の開発スタイルをできるだけ取り込むようにしています。そして、そのコミュニケーションを円滑に行うために、各種情報（進捗など）の見える化のためのクラウドサービスや、迅速な情報伝達を実現するチャットツールなども積極的に導入し、お客様と二人三脚で開発を行える関係の構築を目指しています。
②こまめな改善
様々な方法論があると書きましたが、正解はありません。プロジェクトによって前提や条件はまちまちなので、どのやり方が適切かも異なりますし、必ず様々な問題が発生します。大切なのは、それらの問題を分析・改善を根気強く繰り返し、「自分たちだけの最適なやり方」を作り上げていくことです。よって私たちは、出来る限りお客様も巻き込みご協力頂きながら、このPDCAサイクルをこまめに回しながらプロジェクトを進めるようにしています。
③開発者のこだわり
ソフトウェアを最終的に作り出すのは開発者です。よって、プロジェクトの内容に合った、優れたスキルを持つ開発者に参画頂くこと、そして、開発者にやりがいをもって仕事をして貰うことが、プロジェクト成功には非常に重要だと考えています。ジョエル・テスト11. をそのまま実践するのは難しい部分もありますが、メンバー選びには様々な工夫をしています。また、8. 9. については可能な限り実現しつつ、新しい技術や手法を積極的に取り込み、開発者としての成長を感じられるようなプロジェクトの実現を目指しています。
おわりに
今回は、抽象的な話が多くなりましたが、私達がソフトウェア開発に取り組む上での考え方が、何となくでもお伝えできれば幸いです。今後は、個別のテーマについて具体的な事例なども取り混ぜながらご紹介していければと思います。