曖昧は障害、曖昧は損害、曖昧は怠慢

2018年9月8日土曜日

システム開発 道徳常識

t f B! P L


人間社会での会話ではある程度「曖昧」な表現が許される。
聞き手である人間には状況判断と推測能力があって曖昧な言葉の意味を推測し、不足している説明から「他に必要な物は何か」を状況から推測することができる。
だから不完全な会話が成り立つ。

人間相手なら、
「今晩はカレーにするから足りない材料買ってきて」
と言えば一々何を買ってくるかを指示しなくても、勝手に冷蔵庫の中の食材を確認し不足している食材をスーパーで買ってくるだろう。
気が利く者なら野菜に包丁を入れ「後は煮るだけ」の状態にして冷蔵庫に入れておくかも知れない。

コンピュータ相手では一から十まで全ての作業に指示を出さなければならない。
「カレーの材料を用意する」
という要件を満たす為に、
「具体的に何をどれだけ(量)買ってくるか」
「どこの店で買うか」
「何時行くか、何時までに用意するか」
「移動手段はどうするのか」
「予算はいくらか」
「買い物袋は使用するのか、レジ袋を使用するのか」
etc...
など細かい指示を一々与えなければならない。
(実際に食材を用意できるような知能ロボットが実用化したらもっと要領よく判断すらかも知れないが、この例えは「情報システム開発」をイメージしてもらう為に書いている)

さらに前提が成り立たないときどうするか「異常処理」を予め指示しておかなければならない。
「ジャガイモ3個、人参2本、タマネギ3個買ってくる」と指示する場合、
「ジャガイモ3個が無かった場合」「人参2本が無かった場合」「タマネギ3個が無かった場合」にそれぞれどうするか指示しなければならない。
また、同様に「スーパーが休みの場合」「工事などで道路封鎖されていた場合」「予算が不足した場合」「レジ袋を指定されたときにスーパーにレジ袋が無かった場合」なども全て指示しなければならない。
間違った指示を出せば間違ったまま実行する。

業務システム開発を情技師(ITエンジニア)に依頼するときも、業務については同様に全てな業務論理を説明しなければならない。
少しでも説明に漏れが有ったらシステムは作れないので漏れについては情技師は非常に細かいところまで聞いてくるはずだ。その内容は非情技(非ITエンジニア)の常識から考えて信じられないほど細い所まで確認してくる。
「そんな細かいこと現場の担当者に聞かなきゃわかんないよ」「そんなのだいたいの雰囲気でどうにかならないの」と非情技の人は思うだろう。
しかしコンピュータには一切の「曖昧」が通用しない。全ての命令は0と1の値で表すのである。曖昧さの入り込む余地はないのだ。

曖昧な要件を出してはいけない

要件については細かい部分までよく考える必要がある。
非情技が情技師に業務や依頼内容を説明するときは一度文章に書いてみることをお勧めする。
文章にまとめる過程で矛盾や漏れに気づくからである。頭の中だけで考えているだけては中々、矛盾や漏れには気づかないモノだ。
年を取るほど慢心から文章に書くことをサボるようになる。気を付けて欲しい。

纏まった要求の内容は情技師のレビューを受けて欲しい。必ずどこか間違っている。情技師が対話しながら修正してくれるだろう。
ここで怠惰な人は「だったら最初から文書など書かずに情技師に相談した方が良いじゃん」と考えて要件を纏める作業をサボろうとする。
しかし依頼や要件は依頼書の頭の中にしか無いのでそれを発掘できるのは依頼者だけである。情技師にそれを丸投げにするのは、情技師が依頼者の頭の中の状態をカウンセリングによって分析する行為であり、フロイトの精神分析宛らのとんでもなく効率の悪い仕事の進め方てある。
依頼者は自分の依頼内容ぐらいは責任を持って自分で纏めて欲しい。

曖昧なことについて考えるのにコストか掛かる

要件や業務の説明に曖昧な部分かあると情技師はその部分を推測しなければならない。
非情技の人には分からないと思うが、曖昧でよく分からない部分を明らかにするにはコストが掛かる。情技師でもこの事が分かっていない人は多い。
曖昧な部分を明らかにする為には他の明確な部分から出現パターンなどを抽出して仮の値を当てはめてみて正常な結果になるかどうかを確かめたりする。それをシステムを作る前に情技師の頭の中で行うのだ。
関連要素の数が増えると組み合わせの数が急速に増え仮の値による推測回数が膨大な量になってしまう。
つまり要件が曖昧で有れば曖昧で有るほど無駄に金と時間が掛かるということだ。
曖昧な部分は依頼者がハッキリさせるのが一番コストが掛からないのだ。
だから情技師と対話をしろと言っている。

業務要件を纏めるにあたって以下のことに注意すると良い。

全ての文に「主語」を付けて考えてみる。

これをやると日本語の文章としては不自然な文章になると思う。日本語は主語を省略して使うのが一般的だから。
しかし、主語を省略すると言葉の定義や範囲が曖昧になり論理的で明確な要件が書けなくなる。だから文書として格好悪くなっても無理矢理主語を付けて書いて欲しい。

範囲を明確にする

依頼する内容の適用範囲を明確にする。
期間、対応部署、客層、SKUなど対象製品要素、部品資材などのどの範囲が対象範囲に含まれるのか最初から意識して要件を書いて欲しい。

例外処理(異常処理)を書く

全ての業務手順には例外処理が存在する。
先のカレーの材料を用意する話で言えば「ジャガイモ3個が無かった場合」どうするか考えなければならない。たとえば「3個無ければ有るだけ買い、不足分だけカボチャのスライスを買う」「他のスーパーへ行く」などのように代替手順を明らかにする必要がある。

モノの総数を明らかにする

業務側で、あらゆるモノの総数を数えて明らかにしておく必要がある。
人数、商品個数、種類の数、顧客総数、属性の総数、支部や部署の数など全て。
数はそれほど正確である必要は無い。「顧客数はだいたい18000人ぐらい」「商品点数は5000ぐらい」「部署は30ぐらいです」
このぐらいの精度で良い。
なぜ総数か必要なのかと言えば「データ件数によってシステムの作り方が全然違う」からだ。技術的な話はしないがデータを他システムへ送るとき10件程度のデータなら文字列一つでも送れてしまう。
2万件ならWebサービス一回のレス(返事)で送信できる。Webサービスというのは例えると普通のWebページを1ページ表示する処理が「一回のレス」になる。
30万件のデータを送る場合はXMLやCSVファイルに出力して特殊なソフトでファイル転送しなければならない。
データ件数によって作り方が違うのだ。
要件に件数の情報が無いと確認を求められる。

要件を出すときは対話する

要件を情技師に出すときは一方的に要件を投げないで情技師と対話してください。
非同期通信ならチャットのように何度か言葉のキャッチボールをしてください。
専門分野が違うので対話はスムーズには行きません。社内SEなら別ですが。
「そういうモノだ」と割り切ってください。

曖昧さは怠慢である

曖昧で有ることによりどれだけ無駄なコストた時間が嵩み、システム開発の失敗リスクが増大するか説明してきた。
曖昧さを生む大本は非情技の依頼者なので、無駄なコストと時間を無くしたいのなら、依頼者(発注元)が注意に払えば無くせるということだ。
だから非情技の方こそ曖昧さを排除する努力をすべきなのだ。
「私はITは素人だから、それは君がやってくれ」などと大威張りで我が儘を言ってないで無駄をなくす努力をすべきだ、あんたの仕事だろう。

皆で幸せになろう!

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ