選ぶならこの会社!システム開発の経験の差はここに出る

優秀なシステム会社の開発作業風景

更新日:2017年09月06日 | 公開日:2017年09月06日

システム開発が必要になり、外注先のシステム開発会社を選ぶときに、とりあえずインターネットで「システム開発会社」と打ち込んでみる発注者の方は多いでしょう。
しかし、検索結果を見て「この会社がよさそうだな」とスムーズに候補先を選ぶことができる人はそれほど多くないと思います。

この記事では、システム開発会社を選ぶときに注目したいポイントを、「システム開発の経験の差」に注目することで整理していきます。

システム開発の差はプログラミング領域だけではない

パソコンでシステム開発のためのプログラミングを行う

システム構築の全行程は次の通りです。

【システム構築の全工程】
  • 開発範囲を決定し、RFP(提案依頼書)をまとめる
  • 発注先候補に対してオリエンテーションを行う
  • 相見積もりを検討して候補を絞り込んで決定
  • 基本契約書締結
  • 要求定義作成
  • 要件定義作成
  • 外部設計
  • 内部設計
  • 個別契約書作成
  • テスト計画
  • プログラムコーディング開始
  • 単体テスト
  • 結合テスト
  • システムテスト
  • 受け入れテスト
  • 納品
  • 本稼働
  • 保守・メンテナンス

一般的にシステム開発と言うと、プログラマが背中を丸めてディスプレイに向かいカタカタとソースコードを打ち込んでいる、という姿を思い浮かべるのではないでしょうか。
しかし、その作業はこの中で言うと、下記の4工程だけなのです。

【狭義のシステム構築の工程】
  • 11. プログラムコーディング開始
  • 12. 単体テスト
  • 13. 結合テスト
  • 14. システムテスト

実際にシステム構築を開発会社に発注した経験のある担当者の方はお分かりだと思いますが、そうでない方は「意外とプログラミング以外の作業が多いのだな」という印象を持ったことでしょう。

では、具体的にプログラミング以外の部分も含めて、システム開発会社の差が出るポイントを解説していきます。

システム開発の差は問題解決能力に出る

システム開発外注化の最初期段階は、発注者からシステム会社へのアプローチがメインになります。
具体的には先程の流れで示した最初の4工程になります。

【問題解決能力に差が出る工程】
  • 開発範囲を決定し、RFP(提案依頼書)をまとめる
  • 発注先候補に対してオリエンテーションを行う
  • 相見積もりを検討して候補を絞り込んで決定
  • 基本契約書締結

システム開発の外注を何度も経験したことがあるという”ツワモノ”が社内にいる場合は別として、一般的にはこの4つの工程をスムーズに行うためには、開発会社の協力的な姿勢が欠かせません。

発注者側からすると以外かもしれませんが、「システム開発をお願いしたい」というだけで発注内容の詳細が決まっていない場合、システム構築会社はそれほど親切には対応してくれません。

形ばかりのRFPを用意して「詳細は未定なので、とりあえずざっくりとした提案をお願いします」というアプローチでは、概算金額だけが書かれた見積書がFAXで送られてきたり、詳細について詰めるには相談料金がかかると言われたり、ひどいときにはそのままいつまで待っても連絡がこない、などということもあります。

開発フェーズに入ったあとの技術力に定評があるシステム開発会社であっても、発注者側からの要望をきちんと受け止めて、システム開発でお客様のどんな問題を解決できるのかをしっかり提案できる会社とは限りません。

きちんと、RFPを受け止めてお客様の問題解決に積極的に関わるという態度の開発会社とそうでない会社とではその後のシステム構築のヒアリング作業に大きな差が出てきます。

システム開発の差はヒアリング力に出る

初期の工程で開発会社の経験の差が出やすいのが、発注者がシステム構築で何を実現したいのかを明らかにしていく「ヒアリング力」です。
ヒアリングとは、お客様の悩みを聞き出してそれに対する解決方法を考えるという作業なので、プログラミングとは別の種類の力が必要です。

具体的には、ヒアリング力の差は「要求定義」「要件定義」に現れます。

【ヒアリング力で差が出る工程】
  • 5. 要求定義作成
  • 6. 要件定義作成

このうち5の要求定義が、発注者が何を望んでいるのかを把握して、詳細を聞き出す能力です。
聞き出す内容は、大きく分けて次の2つに分かれます。

■ 超上流工程
会社レベルでのIT投資の目的「我が社はこれを目指すべき」の明確化

■ 上流工程
現場レベルで「ここを改善すべき」という要求の明確化

超上流工程では、現在の業務プロセスを見直したり(BPR=ビジネス・プロセス・リエンジニアリング)、ライバル企業や市場の最新動向を見据えたりしながら、将来にわたって会社の重要資産となるIT投資を大きな視点から明確化していきます。
当然会社の役員レベルの意思決定者にもヒアリングを行い、発注側企業のビジネス上の課題や問題点を共有できるいわゆるコンサルティング能力やビジネスセンスのようなものも求められます。

また上流工程では、現場レベルでの業務フローを明確化して、どのように業務システムを変えれば改善要求に効果的に応えられるかとい部分を詰めていきます。
もちろん守秘義務等はあるにせよ、その会社が過去に同業他社のシステム開発を手がけていたり、流通や物販といった業界単位で共通する課題や最新動向に通じていたりしたほうがより適切なヒアリングができるでしょう。

5の「要求定義」がヒアリングによって明らかになったあとは、それをどのようにシステムに落とし込めば解決できるのかを「要件定義」という形でまとめます。
要件の内容は、下記の2つに分けて明確化していくことが一般的です。

■ 機能要件
システム化できる要件のうち、画面操作、帳票出力、データ連携や更新といった機能面に該当する要件

■ 非機能要件
性能、品質、信頼性、拡張性、運用性、移植性、セキュリティといった機能面以外の要件

ここでも、「システム開発」という言葉に対する一般的なイメージとしては「画面操作、帳票出力、データ連携や更新」といった部分が連想されますが、実は「性能、品質、信頼性、拡張性、運用性、移植性、セキュリティ」が大きく差の出る部分です。

非機能要件をきちんと初期の「要件定義」で明確化できるかどうかで、システム納品後の運用の質がまったく変わってしまいます。

ソースコードの水準は設計段階で差が出る

要件定義まで終わると、いわゆる狭義の「システム開発」=プログラミング前後の領域に入ってきます。
この段階では、設計とテスト計画が重要ポイントとなります。

【設計とテスト計画に差が出る工程】
  • 7. 外部設計
  • 8. 内部設計

設計とは、それまでヒアリングしてきた発注者側の課題を解決する設計図を描くことです。
フリーランスエンジニアに頼むなどの場合を例外とすれば、システム開発で発注者からのヒアリングが終わったあと、いきなりプログラミングに入るということはありません。

システム開発における設計とは、例えば機能要件では、画面設計、テーブル設計、帳票設計といった形を取り、非機能要件の内容はハードウェア構成図、システム構成図といったシステム全体を構成する要素とともに設計に落とし込みます。

当たり前ですが、実際のプログラミングの品質がこの設計図の完成度を超えるということはありません。
設計図が優秀ならば水準の高いソースコードが期待できますが、設計図の完成度が低ければバグだらけの劣悪なソースコードとなる可能性が高くなります。

プログラミングの品質は設計段階で差が出る

テスト計画とは、どの水準のシステムが合格点に値するかテストする項目を列挙したものです。
案件ごとにどのようなテストをすれば合格点に達するかということをテスト計画に反映させる部分には、システム開発の実力がはっきりと出てきます。

【テスト計画で差が出る工程】
  • 10. テスト計画
  • 11. プログラムコーディング開始
  • 12. 単体テスト
  • 13. 結合テスト
  • 14. システムテスト
  • 15. 受け入れテスト
  • 16. 納品
  • 17. 本稼働
  • 18. 保守・メンテナンス

ときどきシステム開発の外注ノウハウを解説した記事などで、その会社の開発体制に信頼が置けるかどうかを見極めるため「どんな人がプログラミングをするのか、技術者と顔合わせをしておきましょう」というような記述を見かけますが、あまり意味がありません。
顔を見てもプログラミングの実力など分からないからです。
それよりも、プログラミングしたあとにどんなテストを行うのか、そのテスト計画を見せてもらえば、システム開発会社の実力ははっきりと分かります。

もちろん、テスト計画書を作らないという開発会社は外注先候補としては論外なのですが、そうしたシステム会社も一定数存在しますので、注意しましょう。

【しっかりしたテスト計画の例】
  • ■ プログラム構文チェック
    ソースコードを解析し、コーディング規約違反、潜在バグを検出します。
  • ■ 機能テスト
    画面設計書で定義した仕様を満たしているかを1画面ごとに確認したり、バッチ設計書で定義した仕様を満たしているかを1バッチごとに確認したりします。
  • ■ フォーマットテスト
    帳票やインタフェースファイルが設計通りのレイアウトで出力されることを確認します。
    ブラウザの違いによるデザイン崩れやJavaScriptエンジンの動作不良をチェックします。
  • ■ セキュリティテスト
    定められた権限の人しかリソースにアクセスできないことをテストし、定番のセキュリティ障害に対応できているかなどをチェックします。
  • ■ モバイル実機テスト
    モバイルの実機において、ベンダーやバージョンの違いによる動作不良をチェックします。
  • ■ シナリオテスト
    納品後に想定されるユーザの操作シナリオに沿って動作検証します。
  • ■ 運用テスト
    運用が実用に耐え得るものかを検証します。
  • ■ 障害テスト
    障害発生時の対応が設計通り動作するかを検証します。
  • ■ 性能テスト
    各種ターンアラウンドタイム(システムに処理の要求を送ってから、結果が出て終了するまでの時間)が規定値以下であることを確認します。
  • ■ 移行テスト
    本番稼働環境への移行プログラムの動作検証を実施します。
  • ■ 業務シナリオテスト
    納品後の他システムとの連携も含んだ全体の業務フローが設計したとおりに回せるかを検証します。

以上、伝統的な開発モデルにおけるシステム開発会社の経験の差が出やすいポイントについてお伝えしました。
次は徐々に普及し始めている「アジャイル型開発」でシステム開発会社の経験の差が出やすいポイントについてお伝えします。

アジャイル開発の実力の差はここに出る

アジャイル開発でシステムを構築する

先程のシステム開発の例は、工程の1~18まで滝が一気に流れ落ちるように開発が進んでいくウォーターフォール型開発のものでした。
最近のシステム開発では、ウォーターフォール型開発のように最初に仕様をガチガチに決めてしまわずに、小さな開発単位ごとに納品を繰り返しながら、発注者と開発者で構成された共同チームで、次に何を開発するのが適切かを決定していくアジャイル型開発が普及してきています。

アジャイル型開発では、開発の工程自体もシンプルです。

【アジャイル型開発の工程】
  • 発注側と開発側からキーマンを含めた人選で共同開発チームを作ります。
  • 共同開発チームにて、開発範囲全体をいくつもの短い範囲に区分します。
  • 発注側の希望を優先させながら、可能な限り柔軟に業務プロセスの優先度を考慮し、どの区分から着手するかを決定します(期間は2週間が目安)。
  • 2週間という期間内に、その区分での要求の決定、実装、テスト、修正、完成までを行います。
    テストには発注者も加わって、開発陣へ必要なフィードバックをします。
  • 完成した機能を評価し、次に着手する優先すべき区分を決めます。

アジャイル開発についての詳しい説明は、こちらの記事などをご参照ください。

アジャイル型開発の最大のポイントはウォーターフォール型開発に比べて圧倒的に自由度が高いことにあります。
ところが、この自由度の高さをシステム開発会社がきちんと理解しているとは限りません。

「アジャイルなのだから、システム開発の目的の明確化や計画性よりも、市場の動向だよね」という言葉そのものは間違っているとまでは言えませんが、もし「アジャイルなのだから目的の明確化や計画性はいらないよね」ということになってしまうと、完全に間違いです。

アジャイル型開発対応を謳っているシステム開発会社の実力の差は、こうした自由度だけにフォーカスしてしまっているか、それとも本質的な部分を正しく理解しているのかに出てきます。

アジャイル型開発の理解度の正しさに経験の差が出る

アジャイル型開発の本質的な部分を押さえていないと、どのような誤解が生じてしまうのか、具体的に見ていきましょう。

アジャイル開発は開発計画を立てない ⇒ 誤解です

アジャイル型開発では、「計画に従うよりも変化に対応する」という有名な言葉があります。
この言葉が独り歩きして、アジャイル型開発には開発計画そのものが存在しない、もしくは計画を立てなくてよいという誤解があります。
実際には、先程の工程5の「完成できた機能を評価し、次に着手する優先すべき区分を決める」という時点で新たな計画が設定され、小さなゴールへ向けて計画を進めていきます。

計画そのものを1回ごとに評価し直すので、ウォーターフォール型開発が一度決めた計画に向かい最後までやり通すのに比べて、「計画」は常に更新され、むしろ重視されているということを経験豊富な開発会社は知っています。

途中の仕様変更は完全自由である ⇒ 誤解です

アジャイル型開発では、「完成した機能を評価し、次に着手する優先すべき区分」を決めます。
その後、新たな開発が始まれば、「2週間という期間内に、そのプロセスでの要求の決定、実装、テスト、修正、完成まで」を行います。
この2週間という過程のために決定されたプロセスは厳密に行われます。
つまりこの2週間のうちに、再度の計画変更は基本的にはありません。

もし、優先順位を決めて着手している開発区分よりも重要度の高い区分が見つかっても、それはいったん着手している区分を完成させてから、再度その重要性を評価するというプロセスを踏みます。
アジャイル型開発の経験豊富な開発業者は、無制限な変更に歯止めをかけることの重要性をよく知っています。

アジャイル開発にはドキュメントがいらない ⇒ 誤解です

確かにアジャイル開発では「包括的なドキュメントよりも動くソフトウェア」という言葉があります。
しかし、この言葉は、「動かないソフトウェアよりも最初に決定された仕様書」とも言うべき、伝統的な開発モデルでのドキュメント偏重にくぎを刺していると解釈すべきです。
開発に必要なドキュメントはできるだけ簡単にして作成の負荷を減らし、疑問が生じたときには真っ先にドキュメントに向かうのではなく、開発チーム内で議論をしつつ「動くソフトウェア」の開発に注力する、というのがアジャイル型開発の正しい姿です。

とは言え、プロジェクトを円滑に、間違いなく実行していくための最低限のドキュメントは必要です。

どのようなドキュメントが必要になるかは、開発プロジェクトごとに違いますので一概に「これが必要」というガイドラインはありません。
しかし、アジャイル型開発においても、最低限の規約、標準化は必要です。
そうでないと、徐々に開発チームとして機能しなくなり、チームとは名ばかりの属人化したプロジェクトに陥ってしまうでしょう。
アジャイル型開発の経験豊富な開発会社は、こうした危険性を熟知しています。

アジャイル開発はリーダー不要 ⇒ 誤解です

「最良の構想、要求事項、設計は自己組織的チームから出現する」というアジャイル原則の有名な言葉がありますが、確かに特定のリーダーがいなくてもチームが自己組織的に機能するのは理想状態だと言えるでしょう。

アジャイル型開発は、共同チームがこうした自己組織的にプロジェクトを推進していける状態を理想としてはいますが、必須だとしているわけではありません。
現実的には技術的な水準や経験の度合いやリーダーシップなどで他のメンバーを引っ張っていく存在が求められるケースも多々あります。

ウォーターフォール型開発のように、進行管理をきっちりと行うことがプロジェクト成功の第一条件となっている場合には、プロジェクトマネージャーの存在の大事さを誰もが認識しています。
しかしアジャイル型開発においても、メンバーに認められたリーダーがプロジェクトをまとめていくことで、より品質の高い納品物ができ上がることに変わりはありません。
経験豊富な開発会社はそのことをよく知っています。

システム開発の経験の差を軸に開発会社を探すために

信頼できるシステム開発会社を見つける

さて、いかがだったでしょうか。
システム開発会社を依頼する場合には、やはり経験豊富な会社を選ぶべきだということがお分かりいただけたと思います。
経験豊富な開発会社に外注を頼んだ場合には、まずプロジェクト進行の安定感、安心感が違うでしょう。

また、良いシステム構築の指標とされるQCD(「Quality(品質)」「Cost(費用)」「Delivery(引き渡し)」)を高水準で達成できるかどうかにも、開発会社の経験の差が大きく関わってきます。

システム開発会社を自力で探そうとした場合には、こうした経験の差といった目に見えない部分をどうやって見抜いていくかがポイントとなります。
しかしこうした違いをホームページや会社のカタログなどの公式情報から読み取るのはむずかしいと言わざるを得ません。

そういった場合には、ぜひシステム開発業界の情報に精通した「アイミツ」にご相談いただければと思います。
表面的な部分に出てこない業者の経験や実際の評判などをもとに、貴社に最適のシステム開発会社をピックアップいたします。

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
5万社以上が利用している無料の相談サービスです。

コンシェルジュ