このすみノート

Webエンジニアが技術や趣味を書くブログです。

受託開発のメリットを活かせ!失敗しないプロジェクト運営のコツを受託開発の極意で学

「受託開発の極意」という、岡島幸男さんの本を読みました。私はたまたま図書館で見かけたのですが、200ページに届かない文量で、ページ数こそ少ないものの、ノウハウがギュッと凝縮されている本です。

極意は言い過ぎだと思いますが、ページ数も控え目で、サクッと読める良い本でした。

・・・というわけで、個人的な備忘録に加えて、自分の意見も織り交ぜつつ、受託開発について書いていきます。

目次

なぜ受託開発は嫌われるのか?

本書では、以下のような理由が挙げられています。

  • やらされている感
  • 顧客に振り回されている感
  • 自分の仕事が何の役に立っているのかわからない感

これらの原因は、受託開発が「受け身」という側面を持っていることが問題です。受託開発だから、下請けだから、お客様の言うことだから。こういった受け身の姿勢が、受託開発の失敗や、モチベーションの低下を招くのです。

受託開発を楽しむには

まず、受け身の姿勢を変える必要があります。人に振り回されて失敗するくらいであれば、こちらから攻めるのです。

  • 積極的に顧客からヒアリングをして、要件を引き出す
  • 顧客がITの専門知識に詳しいことは稀なので、要件定義を上手くサポートする
  • プロジェクトに積極的に関わることで、顧客からの信頼や満足を勝ち取る

顧客は受注者と発注者の関係ではなく、一緒にサービスを作り上げていくためのパートナーなのです。サービスを中心に物事を考えれば、開発しているプロジェクトに対しても愛着が湧いてきませんか?

受託開発では、既に顧客がいるというメリットを活かして、顧客を振り回すくらいの勢いで行きましょう。

なぜお客様に関心が持てないのか?

受託開発において、メンバーがやらされている感を抱くの理由の一つに、お客様の顔が見えないということが挙げられます。会議の議事録や、送られてきた仕様だけを見ても、そこに人はいないのです。

一番の解決方法は、やはりフェイス・トゥ・フェイスです。議事録役として、顧客との会議にメンバーを参加させる。もしくは、○○機能の開発担当として同席させる。手段は何でも構いません。

とにかく、使っている相手の顔が見えることが重要です。そうすることによって、どうしてもシステム目線で見がちなエンジニアに、顧客目線という視点が生まれてきます。

本来、システムを使うのは顧客なわけですから、顧客目線で見つめる事は当然なわけですが。受託開発だと、これがなかなか難しいのです。

f:id:konosumi:20180731030432j:plain

顧客が納得するための見積もり

見積もりにおいて、以下のようなことが重要点として挙げられます。

  • 見積もるための十分な情報を引き出す(もらえる)こと
  • 見積もりの根拠に納得感を与えること
  • ただ見積もるだけでなく、工数を抑えたり、価格を抑えるためのプラスアルファの提案(代替え案)が提示できること

見積もるための情報を引き出す

見積もりの正確性を高めるためのコツは、何と言っても情報量です。シャーロック・ホームズは、作中において「情報量が足りない間は推理しない」のような旨を語っていたと記憶していますが、私もそう思います。

そのためには、お客様からヒアリングをし、システムで実現したいことの要件を固めていきます。これの繰り返しです。

見積もりに向けたヒアリングのゴールは、例えば一般的なWebシステムであれば、必要な画面や帳票といった「モノ」を集めていくことです。見積もりには、対象物となるモノが必要です。

モノが出揃えば、後は画面毎に機能を検討しながら、見積もりへと進むことができます。

見積もりの根拠を高める

見積もりの根拠を高めるコツは、数値で計算できることです。なんとなくで弾き出した数値ではいけません。ユースケースポイント法、ファンクションポイント法、タスク分解法・・・といった方法論が、本書では列挙されています。

一定の方針に沿って算出された見積もりであれば、そこに自然と根拠が生まれます。

また、過去のプロジェクト実績があれば、大いに活用しましょう。見積もりの妥当性を検討する場合、やはり過去の実績は大きな基準となります。

要件定義

本書に、以下の興味深い一文が書いてありました。大きな要因は「要件の分析不足」と「ヒアリング不足」です。

要件は変わったのではなく、間違って定義されてしまっていることが多いのです

プログラマの仕事は問題解決である

開発者は、ただプログラミングの能力が高いだけでは不十分です。ここでは、お客様と一緒に(お客様視点で)物事を考えながら、整理していく問題解決能力が重要になってきます。

Ruby開発者で有名なMatz氏も、同様のことを述べているわけですから、意識しておいて損はありません。

プログラマの仕事は問題解決

引用:Matz氏講演会「学生エンジニアの生存戦略」 - Qiita

要件の変更は、後の工程になるほど影響が大きくなります。問題に気づくタイミングは、早ければ早いほど良いです。

目に見えない要件にも気をつける

システムの要件は、画面や帳票のような、何も目に見えるものだけとは限りません。

  • 信頼性要件: 復旧に要する時間や、システムの稼働率、など
  • 効率性要件: 3秒以内に応答は返す必要がある、などの性能面
  • 使用性要件: デザインの決まり事や方針、ガイドライン、など
  • 保守性要件: ソフトウェアの今後の変更や、修正のしやすさ、など
  • 移植性要件: 他のOSでも動作する必要がある、など

私は初めて知りましたが、これらの品質要件は「JIS X0129・ISO/IEC 926」として、国際規格にまとめられているらしいです。

f:id:konosumi:20180731031445j:plain

設計・実装・テスト

変更に強い設計を重視する

設計とは、定義された要件を満たすための実現手段を検討し、品質を作り込む作業です。

ここで、重要なことは、後の変更に強い設計(=保守性が高い)にすることです。なぜ変更に強いことが重要かといいますと、簡単に言ってしまえば、後々の修正や仕様変更に強くなるからです。

例えば、モジュール同士が疎結合になっている設計であれば、他の変更が他に影響する、いわゆるデグレのような問題は少なくなります。

テストコードを活用した実装

変更に強くなるためには、変更によって生じるバグ(デグレ)を、早期に検知できる仕組みづくりが必要になります。そこで登場するのが、「テスト駆動」や「テストコード」といった考え方です。

本書には、ほとんどの問題は単体テストで発見できると書いてあります。個々のモジュールの段階で、潰せるバグは潰しておきましょう。

テスト計画による品質の画一化

テストを実施するにしても、統一した基準がなければ、メンバーによって品質はバラバラになってしまいます。品質を保証するためには、予め「どういうポイントで、どこま細かくテストするのか」を策定しておきましょう。

出来れば、テスト基準はお客様とも合意しておくことが望ましいです。

ドキュメントは運用のためにある

ドキュメントはメンテナンスされないとはよく言いますが、ドキュメントは何のためにあるかって、納品するためではなく、運用するためにあるのです。

たとえ、ドキュメントが納品物ではなかったとしても、運用フェーズにおいてドキュメントがあるとないでは、大きく変わってきます。何せ、人は読んだ本の内容を、1週間後には90%も忘れてしまうような生き物なのです。

ソースコードのコメントでも良いので、とにかくドキュメントは積極的に残しましょう。また、適切にメンテナンスされるドキュメントを維持するための、仕組みづくりも重要になってきます。

進捗は細かくブレークダウンする

進捗管理は、全体進捗のような大枠ではなく、細かいタスクレベルで管理するようにしましょう。

私見では、最近はタスクは長くても1日以内に終わるように細分化するといった取り組みが、流行っているように見受けられます。細かくすればするほど、進捗は正確性を増していくのです。

タスクの粒度が大きいと「このタスク、進捗がずっと90%だけど?」といった事態が発生します。あるあるです。私も経験があります。

プロジェクトの成功を掴むためには、まずは自分から変わろう

多くの人が、自分は変わりたいと思っています。特に、IT業界は優れたエンジニアが際立って目立つような世界です。「私もああなりたい」と思うことは、往々にしてあります。

KIML(Know,Imagine,Move,Love)サイクル

これは著者が考案した用語だと思うのですが、KIMLが興味深かったので紹介します。

  • Know: 今の自分を知る
  • Imagine: 変わったあとの姿を思い描く
  • Move: 行動する
  • Love: 変われた自分を好きになる

私なりに要約するならば、まずは現状を分析し、改善後の理想形を思い描きます。次に現状と理想のギャップを埋めるために行動します。行動した自分は、素直に褒めてあげましょう。

これは、確か7つの習慣にも書いてあったと記憶していますが、人はすぐには変わりません。まずは、自分から変わるしかないのです。自分が変われば、それに影響を受けた周りにも変化が生まれてきます。

仲間を増やそう

プログラミングは、結局は個々の作業にまで落とし込まれることが多いです。プログラマーが孤独を感じやすい理由はそこにあるのですが、何も一人で全てを頑張る必要はありません。

開発を楽しむには、仲間を作りましょう。社内で勉強会を開催しても良いですし、試しにペアプログラミングをやってみるのも面白いです。

さいごに

本書を読んだ感想として、受託開発を成功に導くコツは「顧客やメンバーをはじめとして、プロジェクトに関わる人たちを、如何に巻き込むかが重要である」と感じました。

こうやって考えてみると、受託開発も自社開発も、求められる素養はそこまで変わりないのです。もちろん、ビジネス上のメリットで言えば、受託開発では自社開発と違って、入金額の見通しが立ちやすいなどの違いがあります。

かのアジャイルサムライに「アジャイルな顧客」という一文がありますが、本書が求めていることは、それと似ています。主体的に顧客(や元請け)が関わってくれるような関係を築き上げることこそ、受託開発の極意なのではないでしょうか?

補足

本記事に書いてある内容には、私見が大いに含まれています。そのため、興味を持たれた方は、ぜひとも原著を読まれることをオススメします。

少ないページ数ではありますが、ノウハウが凝縮された良書です。