なぜシステム開発の規約・標準化がしっかりしている開発会社はおすすめなのか

規約や標準に則ったプログラミングでシステムを開発する

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

システム開発のほとんどは集団作業です。
SEやプログラマやプロジェクトマネージャーなどの多くのスタッフが1つのプロジェクトの完成へ向けて分担して作業をこなし、各作業は要所で全体の整合性の観点からテストされます。
ごく小規模のシステムの改変をフリーランスに発注する場合などを別にすれば、システム構築は大勢のスタッフが関わりますので、開発陣の間にきちんとした共通のコミュニケーション基盤が必要になります。

このコミュニケーション基盤の例が、システム開発の現場における「規約」になります。
「規約」とは狭い意味では、プログラマがソースコードを書くときのルールを指します。
プログラムのソースコードというものは、人間の喋る言葉と同じで、意味は伝わってもその表現の仕方はプログラマによって変わってくるのが普通です。
たった1人でプログラミング作業が完了する場合には、最低限あとから他人が見て分かるような書き方になっていればよいとも言えますが、集団で作業をする場合には話し言葉が違っていればコミュニケーションが取れないのと同じで、となりに座っているプログラマのソースコードが読めない、という場合もあり得ます。
こうなってくると、開発の生産性に重大な影響が出るのは、容易に想像がつきます。

また、「規約」とは、こうした狭義の内容だけでなく、開発プロジェクト全体のルール作りを指すこともあります。

開発プロジェクトでは、発注側と開発会社側がプロジェクトの開始から終了まで良好なコミュニケーションを維持し、必要な情報共有を行い、必要な変更点を無理なく吸収していくことが大切です。
発注者側と開発会社が互いに考えを主張するだけではプロジェクトが途中で空中分解してしまう危険性もあります。

発注者側と開発会社側との共同作業を円滑に行うためには、共通のプロジェクト推進のためのルール、枠組み=標準化が必要となってきます。

この記事では開発現場での「規約」、さらに発注者側にも関係の深い広義の規約である「標準化」を確立していくポイントについてお伝えします。

規約・標準化の志向を持たないプロジェクトは危険

規約や標準を意識してプロジェクトを進める

「標準化」について正しいイメージを持つためには、標準化されていないプロジェクトとは何かを考えるのが分かりやすいでしょう。
標準化されていないプロジェクトとは、「属人化されているプロジェクト」です。

プログラマは自他ともに認めるすごい実力の持ち主ながら、そのエンジニアが書いたソースコードは他のエンジニアが見てもすぐには何が実現されているのか分からない、というケースがありますが、これはソースコードが「属人化」されている典型的な例です。

開発の素人から見ると、プログラマの生産性が高く、一度書いたらほとんどバグも生じないという場合、仮に「属人化」されていても、その天才プログラマの開発スタイルを認めてあげてもよいのではないか? と思ってしまいがちですが、これは非常に危険です。

プログラマが病気になったりすると、プロジェクトの進行が止まってしまいます。
またこのプログラマが会社を辞めたなどの理由でプロジェクトが終わったあとに連絡が取れなくなってしまうと、その後の不具合の対応もできませんし、バージョンアップしようにももとのソースコードが解読しきれないのでプログラムを作り直す必要も出てきます。

こうした危険性はプログラマだけでなく、プロジェクト全体を仕切るプロジェクトマネージャー(PM)についても言えます。

属人化されたノウハウでプロジェクトを動かしているPMが病気で休んだり、会社の方針と合わずに退職してしまったりすると、それを引き継げる人がなかに残っていないという状態になり、プロジェクトそのものが頓挫する危険性が非常に大きくなります。

確かにプログラミングには職人芸的な技術もありますので、そうした要素を完全否定してしまうと、かえって現場の生産性は落ちます。
しかし、属人化されている状態が普通になってしまうのは、プロジェクトの責任性という点では望ましくありません。

また優秀なPMも個人的な人間性の魅力、カリスマ性といったものがプロジェクトの成功に大きく貢献することは間違いないのですが、そのPMの能力に完全に依存してしまうと、やはり会社としての責任が果たせなくなるというケースも起こり得ます。

こうした危険性を回避するためには、多少の生産性、効率を犠牲にしたとしても「代わりの誰かが引き継げる」状態にしておくこと、つまり誰もが理解できる「規約」や「標準化」が不可欠になってきます。

フリーランスと違って、システム開発会社にプロジェクトを任せる意義は、こうした安全性、安心感、責任性にあります。
安い金額でフリーランスに仕事を頼む場合には、プロジェクトの確実な成功のために、発注側が開発プロジェクトをリードし、責任を持たねばなりません。
逆に、フリーランスが仕事をするような「属人化」されたスタイルでコーディングやプロジェクト全体を進めようとする会社には注意が必要です。

規約重視・プロジェクト標準化とは具体的にどんなことを指すか

規約やプロジェクトの標準化を重視して開発する

システム開発における規約や標準化の必要性が理解できたと思いますので、次に規約重視・プロジェクト標準化とは具体的にどんなことを指すかについて見ていきましょう。
メインはプロジェクト全体の標準化ですが、最初の規約の項目では、ソースコードの規約についての話も整理します。

「ソースコードの中身の規約については、さすがに発注者は知らなくてもよいのでは?」と考える方もいると思います。
確かに規約のテクニックについて、発注者が理解しておく必要はありません。
しかし、納品されたソースコードがどのようにして規約重視を実現しているのかについては把握しておくべきです。
納品されたソースコードは資産として、将来的に別の業者に保守、運用、バージョンアップを依頼する場合などに備え、自社で責任を持って管理しておく必要があります。
肝心のコードが実は属人化されていて、資産価値がほとんどなかったということにならないよう、ソースコードの規約についても最低限の知識は持っておきましょう。

その他の、設計書やテスト仕様書の規約について、さらに開発プロセスの標準化については、発注者が必ず知っておくべきものなので、しっかりと理解してください。

開発現場で必要な規約

開発現場での規約には、設計書やテスト仕様書などのドキュメント作成の規約と、コーディング規約があります。

コーディング規約

発注者にとってコーディング規約は、納品物のなかのソースコードとして提出される部分が属人化された書き方になっていないか、という点をチェックする役割を果たします
ただし、発注者がソースコードを直接チェックする必要はなく、下記の条件を満たしているかを開発会社に確認すればよいでしょう。

■ コーディング規約ポリシー
開発会社がどのような目的でコーディング規約を定め、どの範囲のプログラミングにコーディング規約を適用しているのかを確認します。

■ ファイル名、ファイル構成
ソースコードのメタ情報の指定方法、フォルダの構成方法などのルールがどうなっているのかを確認します。
将来再利用が容易になるように、1つのファイルに何でも書き込まず、適切に共有ライブラリを使っているかなどの全体構成も把握するようにしましょう。
オブジェクト指向で構成されたプログラムの場合には、オブジェクトの継承関係についての一覧表も提示してもらいます。

■ フォーマット/スタイル
関数名、データベースのカラム名、変数、定数、クラスの名前などに関して命名規則がどうなっているのかを確認します。
大文字で始まるもの、途中で大文字を交えるものなど、書き方のルールをチェックしてください。

なお、代表的な言語で推奨されるフォーマットに関しては、下記のURLを参照してください。

【WordPress関連】
CSS コーディング規約
HTML コーディング規約
JavaScript コーディング規約
PHP コーディング規約

【Python】
Google Python スタイルガイド

【Ruby】
Rubyコーディング規約

仕様書の規約

ドキュメントのうち「仕様書」は要求定義、要件定義を開発設計図に落とし込んだものです。
請負契約の場合には、最終的な納品物が「仕様書」に書かれた内容を満たしているかどうかで検収合格/不合格を決めますので、極めて重要なドキュメントです。

テストの規約

テストは、実際にシステムが予定通り動くかどうかをチェックする上で、発注者にとても関わりの深いものです。

プロジェクト全体の標準化の条件

ここまで、現場でのコーディングや、仕様書、テスト項目など「狭義の規約」について確認してきました。
次に広義の規約、開発プロセスの標準化について見ていきましょう。

システム開発企画の標準化

システム開発企画は、システム開発の目的や求める品質、金額、納期、担当窓口などを明らかにします。

システム開発企画は、多くの場合RFP=Request For Proposal(提案依頼書)に落とし込みますので、RFPで明らかにすべき内容=標準化されたシステム開発企画と考えてよいでしょう。

RFPで明記すべき事項
  • ■ プロジェクト全体像
    どんなことをシステム開発で実現したいのか、導入期日目標、概算予算、大まかなスケジュール案など
  • ■ 提案の要件
    具体的に何をしたいのかを箇条書きにします。
    必須な機能、運用・保守の体制案なども合わせて記載するなど、役割分担についても現状で分かる範囲で希望を伝えます。
  • ■ その他相談したいこと
    伝えた方がよいと思われる情報、判断に迷っていることなどを補足として記載します。

要件定義

要件定義とは、エンドユーザーの現状業務やシステムを分析し、業務要件とシステム化要件を定義することを指します。
標準化の非常に難しい工程ではありますが、1つの例として「ヒアリングシート」があります。
ヒアリングシートはシステム開発の「目的」を開発側が理解することために、「理由付け」をしながら、要望を具体化していくためのツールです。

*ヒアリングシートについてはこちらの記事などもぜひご参照ください。

概要設計、詳細設計、プログラム設計、プログラミング

概要設計では基本設計、UI(ユーザーインタフェース)設計から実施します。そして、概要設計で決まった機能を、プログラムレベルに分割し、それぞれのプログラムで実現する機能を定義するのが詳細設計となります。
プログラム設計では詳細設計において機能ごとに分割したプログラム1本1本の構造や処理手順を決めていきます。
その後、実際のプログラミングに入ってからは、コーディング規約に従って作業が進められます。

規約を満たした標準的な仕様書であれば、下記の項目は必ず入っているはずなので、チェックしましょう。

仕様書のチェックポイント
  • ■ 画面仕様
    各画面内での操作の動き、画面同士の関係を全体構成図・遷移図などで表現したもの
  • ■ 機能仕様
    個別の機能について、どういう目的で、何をするものなのかを明らかにしたもの
  • ■ データ構造
    データベースのテーブル構造のデータが何を指しているのか、どのような補完関係にあるのか、どのような関係があるのかなどを説明したもの
  • ■ インフラ構成
    ハードウェア構成、OS、ミドルウェアなどのアプリケーションソフト以外の構成を列挙したもの

プログラムテスト、結合テスト、システムテスト、運用テスト

作成したプログラムをテストしたり、機能を検証したりして、最終的にエンドユーザーが実務データに基づき検証する運用テストを経る工程です。

規約を満たした標準的なテストであれば、下記の項目は必ず入っているはずなので、チェックしましょう。

テストに関するチェックポイント
  • ■ テストを実施した年月日
    望ましいのは納品日からあまり離れていないことです。
  • ■ テストを実行した担当者
    あとで問題が起きた場合に誰に連絡すべきか明記されていることを確認しましょう。
  • ■ テストを実施したときのインフラ環境
    納品先と同じ状態がベストですが、開発会社と納品先の環境を完全に揃えることが難しい場合もあります。
    どんな環境でテストしたかは、本番環境での不具合の原因を探すときにも必要です。
  • ■ 実施するテストの項目ごとの内容
    納品物によってテストの内容が変わってきます。
    項目ごとに何を目的としてテストをするか、どのような結果が出れば合格と判断しているか、その根拠は何か、が明記されていることを確認しましょう。
  • ■ テストを実施するためのシステムの操作手順
    同じ操作でテストにパスできるかどうかを判別するために必要となります。
  • ■ テストの実行結果
    問題なし/ありの記載。
    問題ありの場合には、原因は何だったのか、修正済みかどうかが記載されていなければなりません。

納品物

最終的な納品物にはシステムのほかに各種ドキュメントも含まれます。
契約書に明記した納品物のすべてが揃っているか確認しましょう。

【最終納品物の標準例】
  • 提案書
  • 業務要件回答書
  • 原価見積書
  • プロジェクト計画書
  • キックオフ資料
  • システム要件定義書
  • 総合テスト仕様書
  • 外部設計書
  • 運用説明書
  • 結合テスト仕様書
  • 内部設計書
  • 操作説明書
  • 単体テスト仕様書
  • システム本体
  • プログラムソースコード
  • 単体テスト結果報告書
  • 結合テスト結果報告書
  • 総合テスト結果報告書
  • 検収書
  • 移行データ確認書
  • 本番稼働確認書

保守・運用

この工程は、納品後の障害対応やユーザーの追加要望に対応しながら、システムの保守や運用を行っていく工程です。
その他、ユーザートレーニングやサポートなどを提供する場合もあります。
納品物の内容によって、保守・運用メニューも変わってきますが、標準的なメニューは下記のようになっています。

運用・保守の標準的メニュー
  • リモートメンテナンス
  • セキュリティ対策
  • データバックアップ、レプリケーション
  • 性能監視・死活監視・各種イベントログ確認作業
  • ユーザー管理
  • トラブル対応
  • 操作に関するお問い合わせへの対応
  • オペレーション代行業務
  • ハードウェアメーカーとの連絡調整
  • ハードウェア保守
  • ネットワーク性能監視・死活監視
  • セキュリティ対策
  • 構成情報変更
  • トラブル対応
  • 操作に関するお問い合わせへの対応
  • オペレーション代行業務
  • ハードウェアメーカーとの連絡調整
  • ハードウェア保守
  • バッチ作業代行
  • データベース管理
  • プログラムメンテナンス
  • 利用者支援

規約、標準化を導入するメリットと注意点を確認しておこう

グローバル視点で通じる規約と標準化を考える

ここまで、システム開発における規約と標準化について整理してきました。
属人化の危険性を排除した規約や標準化はプロジェクトを安定させるために欠かせないことが実感できたかと思います。

しかし、過度に規約と標準化を意識すると、プロジェクトにマイナスとなることもあります。
ここでは、規約と標準化のメリットを再度確認するとともに、過度の意識がもたらすマイナス点について見ておきます。

システム開発における標準化のメリット
  • プロジェクト関係者の共通理解を促進することでプロジェクトの空中分解を避けられる
  • 同じ標準を用いて開発したときのノウハウが使える
  • 標準レベルをクリアすることで効率よく高品質なシステムを開発できる
  • 標準的な納品物は納品後の保守メンテナンスもやりやすくなる
  • サンプルやテンプレートを活用することで開発期間を短縮することができる
過度の標準化意識がもたらすマイナス点
  • 規約や標準が絶対的な規範となってしまい、プロジェクトに柔軟性がなくなる
  • 規約や標準に従っていればよいという雰囲気に支配され、創造的な提案が出てこなくなる
  • 常に規約や標準を意識することで、プロジェクトマネジメントが進捗管理一辺倒になる
  • 規約のための規約、標準化のための標準化に陥って本来のプロジェクトの目的が見失われる
  • 発注側と開発会社側で尊重すべき、規約、標準化のルールがまとまらずプロジェクトが前に進まない

属人化を防ぐという意味では、規約、標準化は大きなメリットがあるのですが、一方でプロジェクト全体の創造性や柔軟性が犠牲になるという点もあるので、過度の規約重視、標準化意識には注意しましょう。

規約・標準化がしっかりしている会社ほど仕様変更にも強い

過度の規約重視、標準化意識の弊害で、最も発注者に関わりのあることは何かと言えば、それは仕様変更をリクエストするときです。
システム開発はその最初期においては、完成品を完全にはイメージすることが難しく、途中の段階で「あ、あの機能がどうしても必要だった!」という気づきがある程度までは避けられないと言ってもよいでしょう。

ところが、過度に規約・標準化を意識したプロジェクトでは、先程挙げたようなマイナス点により、仕様の変更が言い出しづらくなってしまう…という面があります。

では、ある程度の追加仕様が避けられないのなら、いっそのこと、規約や標準化を無視した小回りの利く(?)、無理な要求にも対応してくれるシステム開発会社の方がよいのでしょうか?

もちろん、そんなことはありません。
実は「規約・標準化」をきちんと意識している会社の方が、逆に途中での仕様変更、追加リクエストにも無理なく対応してくれるものです。
なぜそうなるか、ということについては明確な理由があります。

規約・標準化重視のプロジェクトは仕様変更のコストも安く済む

規約・標準化を重視しているプロジェクトでは、まず開発関連のドキュメントをきっちりと作成しています。
したがって、どの部分にどんな仕様の変更・追加があった場合に、システム全体にどんな影響があるのかが、さほど時間をかけなくても把握することができます。

また、プログラム作成の規約でも、どこのソースコードがどんな役割を果たしているかについて、完備された設計図があり、ソースコードのなかにも、コマンドや関数にどんな動作をさせているかについてのコメントがしっかりと書き込まれています。

もし、参照すべきドキュメントがまったくなく、ソースコードも属人化されていてどのソースコードをいじったら追加仕様に対応できるかが分からない…という場合、仕様変更に対するコストは一気に跳ね上がります。

このような理由で、規約・標準化重視のプロジェクトでは、最短時間で仕様の変更に対応できるのでコストも安く済むわけです。

規約・標準化重視のプロジェクトは全体の管理変更も容易

システム開発では、プログラミングの進行管理以外にもさまざまな管理を行っています。
仕様変更があるということは、プログラミングの進行管理だけでなく、下記のようなさまざまな影響をプロジェクトに及ぼします。

プロジェクトにおける管理の種類
  • スケジュール管理
  • 進捗管理
  • 工数管理
  • 要員管理
  • 予算管理
  • バグ(不具合)の管理
  • 仕様変更の管理
  • 品質管理
  • バージョン管理

もし、規約・標準化をまったく行っていなかった場合には、これらの管理をすべて、属人化されたプロジェクトマネージャーが自分の頭のなかで行うことになり、想像するだけでも大変な作業です。

したがって、「仕様の追加をお願いしたいのですが…」というリクエストはなかなかしにくいですし、したとしても対応できるかどうか分かりません。

規約・標準化重視のプロジェクトでは各種管理もきちんとリアルタイムで行われているので、仕様の追加によって、どのように影響が出るかをすぐにシミュレーションすることができるのです。

規約、標準化をきちんとやっている会社をみつけよう

規約と標準化を会社の強みとして活用する

以上、システム開発における規約、標準化について整理してきました。
そして、規約、標準化重視のプロジェクトは、一見するとルール重視のためにプロジェクトの柔軟性や創造性が犠牲にされそうでいて、実はきちんとした規約、標準化を行っているからこそ、追加仕様などにも柔軟に対応できるのだということを確認しました。

システム開発を依頼するなら、ぜひこうした規約、標準化重視の会社を選ぶべきですが、問題は、上辺だけの規約、標準化重視で実際には創造性や柔軟性が犠牲になっている会社と、創造性や柔軟性を十分に発揮するために、本当の意味で規約や標準化を重視している会社との区別がなかなかつきにくいということです。

もちろん、実際に契約を結んでプロジェクトをスタートさせてみれば、選んだ外注先が上辺だけのパターンだったのか、本当の意味での規約、標準化重視の会社だったのかはっきりするわけですが、もし上辺だけの会社だった場合には、取り返しがつきません。

そんなときは、システム開発業界の評判に精通した「アイミツ」にぜひご相談ください。
御社の頼もしいパートナーとなってくれる本当の意味での規約、標準化重視の会社をピックアップいたします。

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

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

コンシェルジュ