2008.05.09（Fri）
「闘うマネジャー：業務のプロ＝発注者が仕様を書く、は無謀か」という記事を読んで
ITmedia エンタープライズの「闘うマネジャー：業務のプロ＝発注者が仕様を書く、は無謀か」を読んだ。
読んでみてイチイチ頷くことばかりだったのでエントリーを起すことにした。
筆者は元SEで、長崎県庁に入った際にユーザ企業つまりは発注側として「仕様を書く」点に焦点を当てている。
システム開発というものは、一般的にユーザ企業の方が当然業務に精通している。受注側のシステム開発会社はユーザ企業の業務に精通しているケースは少ない。数度の打ち合わせを経て仕様の確認、要件定義を行なう。
この要件定義、仕様が曖昧なまま開発に入ってしまい、結果的にシステムが動かない・意図した動作、処理と違うということに陥ることがままある。
コミュニケーション不足が原因だと指摘したり、テスト不足だという理由付けをしたりするが果たして本当にそうだろうか？
以下は記事からの抜粋だが、この状況はユーザ企業の立場では良くあることではないだろうか？
そして結果的にこうなるケースが非常に多い。
そこで筆者は自らが仕様を固める、詳細な設計書を書くことにする。元SEだからこそできる芸当だが、一定の有用性があるだろう。
極めつけは以下だ。開発会社、またはユーザ企業として関わった経験がある者ならば胸に突き刺さる言葉ではないだろうか？
さて、自分の場合は「ユーザ側が仕様書を書く」ということが胸に突き刺さった訳ではない。反対に今まで僕がやってきたことを、他の人、しかも元SEのような豊富なプロジェクト経験がある人が同じことを考えていたことが嬉しかった。
僕はSEでも何でもないが、画面設計書はよく書いた。実際の業務において何をどのように管理するのか、どのように操作すれば使い易いかという観点から画面設計書を起こた。そして一旦出来あがった画面設計書を業務担当者へレビューをする。担当者からは「ここをこうして欲しい。」「こういう処理も必要になる。」という意見が出てくる。そのレビュー結果を画面設計書に反映し、数度のレビューと修正を経て最終的な画面設計書を完成する。
画面設計が完成してしまえばシステム要件は明確になることが多い。多いというのは開発会社（ないしは開発部署）との打ち合わせにおいて、どうしても実現不可能なな場合（多くの場合において費用面で）には妥協点を探り、両者合意の元で画面設計をフィックスする。
このようにして何枚も何十枚も画面設計書を書いてきたが、自分の経験では開発に入っても仕様変更や追加機能が発生することはほとんどなくスムーズに開発完了・リリースに至ることがほとんどであった。
自分が画面設計書を書くようになったのは、ある小規模な短期間プロジェクトの経験が切欠だ。そのプロジェクトでは時間が無いということで、開発部署が設計した画面をそのまま使った。もちろん修正依頼をしたが「時間が無い」ということで、ほとんど修正は成されないままリリースとなった。その業務システムは実際の業務の使用に耐えられるものではなかった。操作が分かりにくく望む処理をしようにもどのように操作するのかが分からない。そして業務必要な処理が行えないという欠陥があった。もっとも十分なテスト・検証も行えなえず、改修もできなかったという事情もあったが。
どうしてこうなってしまったのかを考えた結果、業務に必要な画面設計は必要な機能、必要であるだろう機能を盛り込んだ画面設計書をこちら側＝ユーザ側が作ってしまえば良いと思い至った。
考えてみれば、業務に使う画面設計書はWebサイトにおけるユーザビリティと良く似ている。
Webサイトにおいては、エンドユーザが操作しやすく目的が達成しやすいようにユーザビリティを考慮する。どのような画面からどのような操作が出来るのか、また操作の結果がどうなるのかを、ビジュアル的に直感的に分かり易くするために腐心する。
そして本当にユーザビリティが考慮されているか、ユーザが望む操作を提供できているかを検証し、検証結果を再びWebサイトに反映する。
開発会社または開発部門というものは業務に精通しているケースは少ない。ユーザの立場にある者の方が業務に精通している。そして業務システムは業務を円滑に効率的に行うために開発するものだ。
画面設計をユーザ側が起こすというのは極端な例かもしれない。実際に画面設計書を書くのは相当な労力がいる。普段を仕事をしながら画面設計書を書く余裕は無いかもしれない。だが、結局そのシステムを使うことになるのは自分自身だ。将来のロスを減らすためにも画面設計書に携わる意味は決して無駄ではないと言えると思う。
読んでみてイチイチ頷くことばかりだったのでエントリーを起すことにした。
筆者は元SEで、長崎県庁に入った際にユーザ企業つまりは発注側として「仕様を書く」点に焦点を当てている。
システム開発というものは、一般的にユーザ企業の方が当然業務に精通している。受注側のシステム開発会社はユーザ企業の業務に精通しているケースは少ない。数度の打ち合わせを経て仕様の確認、要件定義を行なう。
この要件定義、仕様が曖昧なまま開発に入ってしまい、結果的にシステムが動かない・意図した動作、処理と違うということに陥ることがままある。
コミュニケーション不足が原因だと指摘したり、テスト不足だという理由付けをしたりするが果たして本当にそうだろうか？
以下は記事からの抜粋だが、この状況はユーザ企業の立場では良くあることではないだろうか？
発注者である職員は仕様も書かなければ、テストも中途半端で、障害が発生する度にSEを叱りつけるようになっている。一方、SEは業務知識もないのに設計書を書き、プログラミンングは下請けへと回すようになった。私はこの状況が怖くて仕方がない。誰もシステム全体を見渡せないばかりか、仕様も設計書もあいまいなのにシステムだけが毎日何となく動いているからだ。
そして結果的にこうなるケースが非常に多い。
仕様があいまいなまま開発に入り、結局、動かないというパターン
そこで筆者は自らが仕様を固める、詳細な設計書を書くことにする。元SEだからこそできる芸当だが、一定の有用性があるだろう。
そこでSE経験のある筆者自身が「詳細な設計書」を用意することになる。
極めつけは以下だ。開発会社、またはユーザ企業として関わった経験がある者ならば胸に突き刺さる言葉ではないだろうか？
SEはすぐシステムフローを考えようとするが、実は、そんなことはどうでもいいのだ。画面には職員が必要とする機能が実現されていなければならず、それを詰めないことには、DB設計もフロー設計も始まらないのだ。それに、やって分かったことだが、本番の画面に可能な限り近い画面で話をする方がいい。
色合いを始めボタンや入力欄の位置・幅など、可能な限り現実に近い画面をデザインした方がいい。自治体でのシステム開発では、できあがった後に、予算も無いのに、ベンダーに対し「あれを直せ!これを直せ!」とよく聞くが、最初に画面を詰めないからそんなことになるのである。画面は発注側も受注側も理解できる業務フローそのものなのだ。
さて、自分の場合は「ユーザ側が仕様書を書く」ということが胸に突き刺さった訳ではない。反対に今まで僕がやってきたことを、他の人、しかも元SEのような豊富なプロジェクト経験がある人が同じことを考えていたことが嬉しかった。
僕はSEでも何でもないが、画面設計書はよく書いた。実際の業務において何をどのように管理するのか、どのように操作すれば使い易いかという観点から画面設計書を起こた。そして一旦出来あがった画面設計書を業務担当者へレビューをする。担当者からは「ここをこうして欲しい。」「こういう処理も必要になる。」という意見が出てくる。そのレビュー結果を画面設計書に反映し、数度のレビューと修正を経て最終的な画面設計書を完成する。
画面設計が完成してしまえばシステム要件は明確になることが多い。多いというのは開発会社（ないしは開発部署）との打ち合わせにおいて、どうしても実現不可能なな場合（多くの場合において費用面で）には妥協点を探り、両者合意の元で画面設計をフィックスする。
このようにして何枚も何十枚も画面設計書を書いてきたが、自分の経験では開発に入っても仕様変更や追加機能が発生することはほとんどなくスムーズに開発完了・リリースに至ることがほとんどであった。
自分が画面設計書を書くようになったのは、ある小規模な短期間プロジェクトの経験が切欠だ。そのプロジェクトでは時間が無いということで、開発部署が設計した画面をそのまま使った。もちろん修正依頼をしたが「時間が無い」ということで、ほとんど修正は成されないままリリースとなった。その業務システムは実際の業務の使用に耐えられるものではなかった。操作が分かりにくく望む処理をしようにもどのように操作するのかが分からない。そして業務必要な処理が行えないという欠陥があった。もっとも十分なテスト・検証も行えなえず、改修もできなかったという事情もあったが。
どうしてこうなってしまったのかを考えた結果、業務に必要な画面設計は必要な機能、必要であるだろう機能を盛り込んだ画面設計書をこちら側＝ユーザ側が作ってしまえば良いと思い至った。
考えてみれば、業務に使う画面設計書はWebサイトにおけるユーザビリティと良く似ている。
Webサイトにおいては、エンドユーザが操作しやすく目的が達成しやすいようにユーザビリティを考慮する。どのような画面からどのような操作が出来るのか、また操作の結果がどうなるのかを、ビジュアル的に直感的に分かり易くするために腐心する。
そして本当にユーザビリティが考慮されているか、ユーザが望む操作を提供できているかを検証し、検証結果を再びWebサイトに反映する。
開発会社または開発部門というものは業務に精通しているケースは少ない。ユーザの立場にある者の方が業務に精通している。そして業務システムは業務を円滑に効率的に行うために開発するものだ。
画面設計をユーザ側が起こすというのは極端な例かもしれない。実際に画面設計書を書くのは相当な労力がいる。普段を仕事をしながら画面設計書を書く余裕は無いかもしれない。だが、結局そのシステムを使うことになるのは自分自身だ。将来のロスを減らすためにも画面設計書に携わる意味は決して無駄ではないと言えると思う。
- 関連記事
関連エントリー
Loading
この記事のトラックバックURL
この記事へのトラックバック
| BLOGTOP |
※コメントは承認するまで表示されません。