まず要件定義

今回は、『システム開発者の頭の中』です。

偉そうなタイトルですが、実は技術者と言っても人間なのです。と言うお話です。

 

 

システム設計者が10人居ると10通りの考え方があります。
システム設計は意外と属人的な作業なのです。

 

お客様がご要望されているシステムを設計する場合に、まずは要件定義（何をしたいかの定義）を行います。

この段階では、中小・零細企業様の場合は大体、会社のTopの方の意向が色濃く反映されます。

 

曰く
「締日の残業時間を減らしたい」
「在庫を圧縮したい」
「紙を無くしたい」等。

 

このあたりは問題は無いのですが、ここから具体的な要件や設計に入る時に色々あります。

 

 

ご要望のその背景を知る

近頃は "情報システム部の方が前面に出てくる" と言うのはめっきり減って、ユーザー部門の方が担当者として出てこられることが多いです。

 

どうしても手探り状態でお客様の話を聞く所から始まります。

ユーザー部門の方は、「これくらいは分かっているだろう」という前提で自分の興味のあるところの話を重点的にされるので、いきなり具体的なロジック修正部分の話になったりします。

 

例えば、「今使っているこの画面のこの項目を少し桁数を増やしてほしい」というような感じです。

 

いくら経験豊富な技術者でも前提無しで具体的なロジック設計は出来ません。

ですので、私は常に「そのご要望の背景を教えて頂けますか」と聞く事にしています。

 

「何故、桁数が足らないのか」「今までは、どうやって短い桁数で行っていたのか」など、ご要望の前提に関わる質問をします。

そうしますと、「ほとんどの場合はOKなのだけれど、あるお客様の取引だけ桁数が足らない」とか、
「コード体系を変更する話が出ている」とか、システム変更の前提の情報が出てきます。

 

こういう前提のお話がきっちり聞けないと、システム設計を間違えます。

 

 

お客様へのヒアリングは
｢目的｣と｢前提｣を常に意識

一番困る（悩む）のは、Topの方の要件（ご要望）と現場の方の要件が違う場合です。

 

Topの方は、システム投資は結果を得るため（経費削減や業務改善の為）に行うわけですが、現場の方は、作業の改善が中心となります。

どうしても現場の方は「今のやり方」を是としての改良の話になります。

 

特に日本の企業の場合、「パッケージに合わせて運用を変える」というような
ドラスティックな運用変更を嫌いますので、自社の現場に合った手作り感満載の詰め込んだシステムになりがちです。

その複雑なシステムをさらに「改良」となるので、難解なパズルを解くような事になります。

 

私は常に "「目的」と「前提」からずれていないか" を気にしながらお客様のお話を聞くようにしています。

「全体図」の無い設計は、どこかで間違えると思っているからです。

 

システム屋は設計の初めの段階では、ロジックはあまり考えていません。

それよりも、システム全体の整合性やお客様の一寸した言葉の矛盾を気にしながら、お客様の頭の中にあるシステムイメージを自分の頭の中に再構築していっています。

ですので、システム屋には普通の言葉で出来るだけ頭の中にある「風景」を説明してもらえると助かるのです。

 

 

今年もあと僅かとなりました。

良いお年をお迎えください。