「察する文化」がシステム開発と相性が悪いという現実

Tweet

皆さんこんにちは。
GXソリューショングループの板橋です。
前回は、「システム開発プロジェクトのゴールは、安定した運用の状態に設定したほうがいいですよ」という話をしました。
今回は、システム開発失敗の大きな原因とその背景について少し掘り下げて考え、私のグループで実践している対策を少し紹介したいと思います。
※今回も文字成分多めになっちゃいました（ﾃﾍ

他業種との比較

大きなコストをかけて実施されるシステム開発ですが、建築や製造など他産業と比べて不確実性が多く、システム開発特有の状況があります。 特有の状況とは何か比較してみましょう。

1. システム（プログラム）は無形な物であること
   他の産業で造られるものは有形なので細かい部分まで目で見て、触れることで確認可能です。
   システムは無形であり、実際に使ってみないと細部まで確認できません。
2. システムは後から修正可能であること
   工場で作ったものや建築構造物は、完成後に構造的な修正はできません。
   システムは、プログラムの書き換えと再リリースにより修正可能で、顧客が何度でも修正要求を出せます。
3. 設計の具体性
   工場で製造されるものや建築構造物は、環境に合わせた具体的な計測数値を考慮して設計されます。
   システムは「使いやすさ」「見た目のインパクト」「速さ」など抽象的な基準で設計されます。

このように、システムは無形物であること、修正が容易であること、設計の基準が抽象的であることが他産業との大きな違いです。 この比較を見ると、システム開発というものは絶妙なバランスの上に成立していることが分かると思います。

要件定義について

システム開発では、顧客の要望するシステムがどの様なものかをまとめた「要件定義書」という文書を作成するのが一般的です。 顧客の担当者とエンジニアがミーティングを重ねて、開発しようとしているシステムがどの様な物かをつらつらと書き記したもので、記載内容は双方合意が必要になる非常に重要な文書です。 この文書がプロジェクトの成否の大部分を握ると同時に、トラブル要因の大きな割合を占めています。
つまり、この段階で失敗やトラブルに発展しそうな要因を徹底的に潰しておくことが大事なのです。
※要件定義がどのようなものかは本題ではないので他に譲りますね。

問題の本質

システムの開発プロジェクトでは、プログラムを書くことに目が向いてしまいますが、実はそれ以上に文書作成が多いのです。 要件定義書、議事録、外部設計書、内部設計書、テスト項目、バグ票、、、など、何をどれだけ作成するかはプロジェクトによって異なりますが文書作成は多々あります。 この文書は「記録」ではなく、未来の自分や他者等の読者への「伝言」になるものです。 文脈（コンテキスト・背景）を共有していない人が読んでも同じ認識にどれだけ近づけられるか？
そこがシステム開発の成否を分ける一つの要因でもあります。 ここでの読者とは、顧客かもしれないし、エンジニアかもしれません。 また、移動や退職によって当時の担当者以外のエンジニアが読むことだってあるでしょう。 つまり、誰が読んでも理解でき、齟齬なく当時の担当者と同じ認識を持つことができるかどうか、、、ということが本質なのです。

日本特有の文化が影響している？

突き詰めて考えると、私の中ではこのような結論に至ってしまいました（苦笑
日本特有の文化として「察する・空気を読む」文化があります。
これは、あえて明文化しなくても「常識」として重要な要素を無意識のうちに要求事項や仕様に織り込んでしまう危険性があります。このような「暗黙の認識」は読み手によって解釈や認識の程度が異なるため、それが後の工程で認識の齟齬として表面化するのです。
文書ではこの「暗黙の認識」を言語化・明文化する事が非常に重要で、脳内にあるイメージや認識を言語化するスキルが必要になります。

それとは別に、普段、私たちが使用している日本語にも危険な要素があります。
私たちは普段から日本語を使用してコミュニケーションしていますが、主語や述語を省略してもある程度、文脈から意味が通じてしまいます。
家族や友人、同僚などとの日常会話を思い出してみてください。

• • 「それやっておいて」
  • 「いい感じにお願い」
  • 「早めにやっておいてね」

皆さんもよく使いますよね？
日常生活では思いやりや気遣いとしてとても良い文化ですが、システム開発との相性は抜群に悪い側面があります。
皆さんの現場でも『それっぽくやっといて』みたいな会話しますよね？

プログラムの特性について

システム開発のプロジェクトで開発するのは、システムの細かい動きを司るプログラム群です。 それらをたくさん組み合わせて、大きな一つのシステムを作り上げます。
そんなプログラムの特徴として、「書いてあることしか実行されない」という特徴があります。
つまり、顧客が業務で利用するシステムでは、業務上起き得る全ての状況を網羅してプログラムしないと、「〇〇〇した時に動かない」とか「△△△した時の計算が合わない」などの不具合に繋がります。
その時、これらの内容が要件定義（もしくは設計）に盛り込まれているか？ということが起きるわけです。

顧客とエンジニアの意思疎通の大事さ

要件定義や設計段階では、顧客担当者と会話を重ねることが多いわけですが、顧客担当者とエンジニアではシステム化の対象業務に関する知識量が異なります。
会話の相手は対象業務のプロですので、「あえて言わなくても分かるよね？」といった「暗黙の了解」が含まれている可能性があり、エンジニア側は常にそこに意識を研ぎ澄ませながら挑む必要があるのです。 また、一般的な業界知識だけではなく、顧客企業の文化的な理由により顧客企業特有の留意事項が少なからずあったりしますので、そういった点には注意を払う必要があります。
顧客担当者からの説明を受ける場面がありますが、全ての状況・全ての条件を網羅して詳細に説明してもらえることは極めて稀です。（ほぼないと言ってもいい）
一方、プログラムは「書いてあることしか実行しない」ので、顧客の担当者とすべての状況・条件について確認しておかないと、要件定義（もしくは設計）から漏れてしまいます。 こういった漏れをレビューでフォローアップできれば、開発プロジェクトの負担も小さくて済みますが、設計工程で潰すことができなかった場合は、漏れが含まれる仕様でプログラムの実装が行われ、テスト工程へ流出します。 設計書をベースに各種テスト工程が進みますので、この漏れが発見されるのは最終の顧客受け入れテストで発見されるという最悪の事態に繋がることもあります。
この場合の修正にかかるコスト・スケジュールは、設計段階で対処する場合に比べて数十倍に増幅（※）されます。
※ウォーターフォール/アジャイルなど採用している開発手法により程度は異なります。

【設計フェーズレビューで発覚した場合】

【受入テストでの発覚した場合】

上記のように、1件の仕様の漏れが数週間に及ぶスケジュールの遅延に繋がり、プロジェクトとしての致命傷になりかねない状況に陥ります。 そのような状況が積もり積もって、追加コストやスケジュールに関する顧客との交渉、交渉の決裂などを経て開発プロジェクトの失敗に至るのです。
※プロジェクト失敗後、どの様になるかはインターネット上に色んな記事がありますので、気になる方は検索してみてください。

それを防ぐために実践していること

私たちのグループでは、このような破壊的な状況にならない様に、以下のように対策を実践していますのでそれをご紹介したいと思います。

1. 記載する文章を極限まで解体する
   開発プロジェクトで作成される要件定義書（顧客の要求事項）や設計書・テスト項目に至るまで、長い文章での記載を禁止としました。
   文節単位(意味が通じる文の最小単位)に分解し、1文節1仕様とすることで、認識の齟齬が入り込む余地を排除し、顧客に対しても気づきを与えるきっかけとなるようにしました。
   これがどういうことか、ECサイトの仕様を例に具体例を出します         

   例文）
   購入金額に応じて1%のポイントを付与する。ポイント利用時は1ポイント1円として値引きに利用できるものとする。

   要件定義書に記載する要求事項として以下の様な記載になります。
   1.購入者にはポイントを付与する
   2.付与するポイント率は、購入する商品合計額の1%とする
   3.決済時にポイントの計算を行う　　　（暗黙の仕様の可能性大・顧客へ確認が必要）
   4.ポイントの計算に送料は算入しない　（暗黙の仕様の可能性大・顧客へ確認が必要）
   5.計算で出た端数は四捨五入とする　　（暗黙の仕様の可能性大・顧客へ確認が必要）
   6.付与されたポイントは、次回以降の購入で値引きに利用できる

2. 曖昧な表現の禁止（一部）
   1.～「など」
   2.「不適切」
   3.「十分な」～
   4.「データ」
   5.「例外的」
   上記の表現は、設計者や実装者に解釈をゆだねるものです。
   つまり、担当者により解釈に幅があり具体性に欠ける表現です。
   「どの様な」入力がエラーなのか、「どの様な状況」が例外なのか、誰が見ても同じ認識が持てるように具体的な記述を行います。

※私たちのグループでは、上記の仕様記述に加え、要件定義からバグ票に至るまでのトレーサビリティに繋がっています。
これについては別な狙いがありますので、またの機会に説明したいと思います。

ただし、ドキュメントの全文を文節に分解するのではなく、認識の齟齬を排除する必要のある箇所のみとし、必要に応じて図表を使用しながら、セクションの冒頭では 文章による概要の説明を加えています。そうしないと、読みにくい文章になりますからね。
やっぱり可読性も大事にしないと、読みにくくて読まれない文書になってしまっては本末転倒ですから、このあたりの加減は非常に重要な点で試行錯誤しています。

最後に

システム開発が失敗しない様に、世の中には要件定義のコツや一般論について述べた記事はたくさんあります。
ですが、システム開発が抱えている問題やリスクの本質について記載している記事は意外と少ないなと思ったので、私の私見ですが書いてみました。
原因をしっかり分析し、それを次につなげていくのは、より良いものを作るための第一歩です。
今回は、私たちのグループで行っている取り組みの一部を紹介しましたが、皆さんの問題解決の一助になれば幸いです。

私たちと一緒にモノづくりをしていく仲間を募集しています。 弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。

• Wantedly
• 募集要項（当社HP）