「受託開発の極意」という、岡島幸男さんの本を読みました。私はたまたま図書館で見かけたのですが、200ページに届かない文量で、ページ数こそ少ないものの、ノウハウがギュッと凝縮されている本です。
極意は言い過ぎだと思いますが、ページ数も控え目で、サクッと読める良い本でした。
・・・というわけで、個人的な備忘録に加えて、自分の意見も織り交ぜつつ、受託開発について書いていきます。
目次
- 目次
- なぜ受託開発は嫌われるのか？
- 顧客が納得するための見積もり
- 要件定義
- 設計・実装・テスト
- 進捗は細かくブレークダウンする
- プロジェクトの成功を掴むためには、まずは自分から変わろう
- さいごに
- 補足
なぜ受託開発は嫌われるのか？
本書では、以下のような理由が挙げられています。
- やらされている感
- 顧客に振り回されている感
- 自分の仕事が何の役に立っているのかわからない感
これらの原因は、受託開発が「受け身」という側面を持っていることが問題です。受託開発だから、下請けだから、お客様の言うことだから。こういった受け身の姿勢が、受託開発の失敗や、モチベーションの低下を招くのです。
受託開発を楽しむには
まず、受け身の姿勢を変える必要があります。人に振り回されて失敗するくらいであれば、こちらから攻めるのです。
- 積極的に顧客からヒアリングをして、要件を引き出す
- 顧客がITの専門知識に詳しいことは稀なので、要件定義を上手くサポートする
- プロジェクトに積極的に関わることで、顧客からの信頼や満足を勝ち取る
顧客は受注者と発注者の関係ではなく、一緒にサービスを作り上げていくためのパートナーなのです。サービスを中心に物事を考えれば、開発しているプロジェクトに対しても愛着が湧いてきませんか？
受託開発では、既に顧客がいるというメリットを活かして、顧客を振り回すくらいの勢いで行きましょう。
なぜお客様に関心が持てないのか？
受託開発において、メンバーがやらされている感を抱くの理由の一つに、お客様の顔が見えないということが挙げられます。会議の議事録や、送られてきた仕様だけを見ても、そこに人はいないのです。
一番の解決方法は、やはりフェイス・トゥ・フェイスです。議事録役として、顧客との会議にメンバーを参加させる。もしくは、○○機能の開発担当として同席させる。手段は何でも構いません。
とにかく、使っている相手の顔が見えることが重要です。そうすることによって、どうしてもシステム目線で見がちなエンジニアに、顧客目線という視点が生まれてきます。
本来、システムを使うのは顧客なわけですから、顧客目線で見つめる事は当然なわけですが。受託開発だと、これがなかなか難しいのです。
顧客が納得するための見積もり
見積もりにおいて、以下のようなことが重要点として挙げられます。
- 見積もるための十分な情報を引き出す(もらえる)こと
- 見積もりの根拠に納得感を与えること
- ただ見積もるだけでなく、工数を抑えたり、価格を抑えるためのプラスアルファの提案(代替え案)が提示できること
見積もるための情報を引き出す
見積もりの正確性を高めるためのコツは、何と言っても情報量です。シャーロック・ホームズは、作中において「情報量が足りない間は推理しない」のような旨を語っていたと記憶していますが、私もそう思います。
そのためには、お客様からヒアリングをし、システムで実現したいことの要件を固めていきます。これの繰り返しです。
見積もりに向けたヒアリングのゴールは、例えば一般的なWebシステムであれば、必要な画面や帳票といった「モノ」を集めていくことです。見積もりには、対象物となるモノが必要です。
モノが出揃えば、後は画面毎に機能を検討しながら、見積もりへと進むことができます。
見積もりの根拠を高める
見積もりの根拠を高めるコツは、数値で計算できることです。なんとなくで弾き出した数値ではいけません。ユースケースポイント法、ファンクションポイント法、タスク分解法・・・といった方法論が、本書では列挙されています。
一定の方針に沿って算出された見積もりであれば、そこに自然と根拠が生まれます。
また、過去のプロジェクト実績があれば、大いに活用しましょう。見積もりの妥当性を検討する場合、やはり過去の実績は大きな基準となります。
要件定義
本書に、以下の興味深い一文が書いてありました。大きな要因は「要件の分析不足」と「ヒアリング不足」です。
要件は変わったのではなく、間違って定義されてしまっていることが多いのです
プログラマの仕事は問題解決である
開発者は、ただプログラミングの能力が高いだけでは不十分です。ここでは、お客様と一緒に(お客様視点で)物事を考えながら、整理していく問題解決能力が重要になってきます。
Ruby開発者で有名なMatz氏も、同様のことを述べているわけですから、意識しておいて損はありません。
プログラマの仕事は問題解決
要件の変更は、後の工程になるほど影響が大きくなります。問題に気づくタイミングは、早ければ早いほど良いです。
目に見えない要件にも気をつける
システムの要件は、画面や帳票のような、何も目に見えるものだけとは限りません。
- 信頼性要件: 復旧に要する時間や、システムの稼働率、など
- 効率性要件: 3秒以内に応答は返す必要がある、などの性能面
- 使用性要件: デザインの決まり事や方針、ガイドライン、など
- 保守性要件: ソフトウェアの今後の変更や、修正のしやすさ、など
- 移植性要件: 他のOSでも動作する必要がある、など
私は初めて知りましたが、これらの品質要件は「JIS X0129・ISO/IEC 926」として、国際規格にまとめられているらしいです。
設計・実装・テスト
変更に強い設計を重視する
設計とは、定義された要件を満たすための実現手段を検討し、品質を作り込む作業です。
ここで、重要なことは、後の変更に強い設計(=保守性が高い)にすることです。なぜ変更に強いことが重要かといいますと、簡単に言ってしまえば、後々の修正や仕様変更に強くなるからです。
例えば、モジュール同士が疎結合になっている設計であれば、他の変更が他に影響する、いわゆるデグレのような問題は少なくなります。
テストコードを活用した実装
変更に強くなるためには、変更によって生じるバグ(デグレ)を、早期に検知できる仕組みづくりが必要になります。そこで登場するのが、「テスト駆動」や「テストコード」といった考え方です。
本書には、ほとんどの問題は単体テストで発見できると書いてあります。個々のモジュールの段階で、潰せるバグは潰しておきましょう。
テスト計画による品質の画一化
テストを実施するにしても、統一した基準がなければ、メンバーによって品質はバラバラになってしまいます。品質を保証するためには、予め「どういうポイントで、どこま細かくテストするのか」を策定しておきましょう。
出来れば、テスト基準はお客様とも合意しておくことが望ましいです。
ドキュメントは運用のためにある
ドキュメントはメンテナンスされないとはよく言いますが、ドキュメントは何のためにあるかって、納品するためではなく、運用するためにあるのです。
たとえ、ドキュメントが納品物ではなかったとしても、運用フェーズにおいてドキュメントがあるとないでは、大きく変わってきます。何せ、人は読んだ本の内容を、1週間後には90%も忘れてしまうような生き物なのです。
ソースコードのコメントでも良いので、とにかくドキュメントは積極的に残しましょう。また、適切にメンテナンスされるドキュメントを維持するための、仕組みづくりも重要になってきます。
進捗は細かくブレークダウンする
進捗管理は、全体進捗のような大枠ではなく、細かいタスクレベルで管理するようにしましょう。
私見では、最近はタスクは長くても1日以内に終わるように細分化するといった取り組みが、流行っているように見受けられます。細かくすればするほど、進捗は正確性を増していくのです。
タスクの粒度が大きいと「このタスク、進捗がずっと90%だけど？」といった事態が発生します。あるあるです。私も経験があります。
プロジェクトの成功を掴むためには、まずは自分から変わろう
多くの人が、自分は変わりたいと思っています。特に、IT業界は優れたエンジニアが際立って目立つような世界です。「私もああなりたい」と思うことは、往々にしてあります。
KIML(Know,Imagine,Move,Love)サイクル
これは著者が考案した用語だと思うのですが、KIMLが興味深かったので紹介します。
- Know: 今の自分を知る
- Imagine: 変わったあとの姿を思い描く
- Move: 行動する
- Love: 変われた自分を好きになる
私なりに要約するならば、まずは現状を分析し、改善後の理想形を思い描きます。次に現状と理想のギャップを埋めるために行動します。行動した自分は、素直に褒めてあげましょう。
これは、確か7つの習慣にも書いてあったと記憶していますが、人はすぐには変わりません。まずは、自分から変わるしかないのです。自分が変われば、それに影響を受けた周りにも変化が生まれてきます。
仲間を増やそう
プログラミングは、結局は個々の作業にまで落とし込まれることが多いです。プログラマーが孤独を感じやすい理由はそこにあるのですが、何も一人で全てを頑張る必要はありません。
開発を楽しむには、仲間を作りましょう。社内で勉強会を開催しても良いですし、試しにペアプログラミングをやってみるのも面白いです。
さいごに
本書を読んだ感想として、受託開発を成功に導くコツは「顧客やメンバーをはじめとして、プロジェクトに関わる人たちを、如何に巻き込むかが重要である」と感じました。
こうやって考えてみると、受託開発も自社開発も、求められる素養はそこまで変わりないのです。もちろん、ビジネス上のメリットで言えば、受託開発では自社開発と違って、入金額の見通しが立ちやすいなどの違いがあります。
かのアジャイルサムライに「アジャイルな顧客」という一文がありますが、本書が求めていることは、それと似ています。主体的に顧客(や元請け)が関わってくれるような関係を築き上げることこそ、受託開発の極意なのではないでしょうか？
補足
本記事に書いてある内容には、私見が大いに含まれています。そのため、興味を持たれた方は、ぜひとも原著を読まれることをオススメします。
少ないページ数ではありますが、ノウハウが凝縮された良書です。
