第8回 やってはいけない、「製造工程」の丸投げキーワードでわかるシステム開発の流れ(2/3 ページ)

» 2008年03月18日 12時00分 公開
[高田淳志,株式会社オープントーン]

発注担当者の引き受ける「仕事」

1. 画面単位/機能単位など細かい粒度でのレビュー

若井さん 「それでは、3/11は商品検索部分のレビュー、3/21は購入部分のレビューということで、関係者の皆さんへ参加手配をお願いできますか?」

青木室長 「みんな忙しいからなぁ。おおむね全体が完成したタイミングで一気に実施してくれないか?」

若井さん 「そうですか。まとめて実施することは可能ですが、いろいろな機能が複雑に組み合わさっているため、変更があった時の手戻り幅が大きくなります。その点を承諾いただけますか?」

青木室長 「構わないよ。設計段階でレビューを済ませているし、大きな変更は発生しないだろう」

若井さん 「分かりました。では、4月末ごろで全体的なレビューにしましょう」

という風にスケジュールされた次回レビュー会議。

  そしていよいよ4月末のレビュー会議の日を迎えました。果たしてすんなり進むでしょうか?

若井さん 「……という流れで、インターネット・ショップで購入されたお客さまの情報や購入内容を確認することができます」

赤井君 「皆さん、どうでしょうか? 各担当部門ごとに現場の業務フローを思い浮かべてもらって、何か気付く点はありませんか?」

発送担当 「同じお客さまからの複数の注文を後から1つの注文にまとめる機能を見たいのですが」

若井さん 「はい、分かりました。……(操作説明)……のような操作で実現することができます」

経理担当 「ちょっと待ってください。配送作業をまとめる場合であっても、決済は注文ごとに完了している場合もあります。その時に、単に注文情報までまとまってしまっては後で入金データとの照合がやりにくくなります。そのような場合はどのように注文情報をまとめるのですか?」

青木室長 「赤井君、仕様書はどうなっているのかね?」

赤井君 「えーと、仕様書では……、今のようなケースに関して特別な記述はないですね。そもそも、そのような場合を想定していたかどうか……」

経理担当 「これじゃ、経理担当者の手間が増えます。そういうまとめ作業はやらないようにしましょう。システム上で管理せずに、手作業で箱をまとめてしまえばいいのではないですか?」

発送担当 「ダメなんだよ。商品だけでなく、パッケージなどの梱包材も在庫管理していて、在庫がある個数を下回ると資材課へ発注依頼がされるようになっているんだ。資材課で、実際の在庫数を確認して、それから発注するようにしてもらえるかい?」

資材課 「それは可能ですが……。だったら、在庫管理については、新しいシステムを利用せずにこれまで同様、管理台帳で確認するようにしますよ」

青木室長 「……(じゃ、在庫管理機能なんて要らなかったじゃないか)」

 少し問題が発生したようですね。

 実際、こうした問題が起きる頻度は割と高いように思います。設計書という書類の上だけでは実際の使用感を得にくいために細部にわたったレビューを行えないこと、また、書類上のレビューといったタイミングでは「ユーザーのレビュー本気度」が高まっていないという点などが原因として挙げられます。

 そこで、「見落としはあるもの」「変更は発生するもの」という前提に立ち、それにいかに早く気付くようにするかという点の工夫が重要になってきます。例えば、前の例では、注文情報をまとめる機能だけでレビューを実施し、その時点ですぐに問題点に気付いていれば、影響範囲をより狭めて対応することが可能だったことでしょう。

 レビュー粒度を小さくするということはレビューの回数は増えます。しかし、発注担当者と開発担当者とのコミュニケーションの機会が増えますし、レビュー自体も内容を絞って綿密に行えるというメリットもあります。

ALT 図2 レビュー粒度を小さくするとよいことがある

ここまでのキーワード

【レビュー】 一般的に使用する「レビュー」の意味と大差はないと思うが、システム開発の場合は、どちらかというと「確認」という意味で使用されることが多い。「設計書のレビュー」=「設計書の確認」といったニュアンスか。その進め方や内容などにより、幾つかの分類がされているので、2つほど紹介してみることにする。

 

(1) ウォークスルー

 

  システム全体を一通り眺めてみる形でのレビュー。“walk through”の和訳を調べてみると「リハーサル」(三省堂:EXCEED英和辞典)とあるように、実際の業務フローや仕様書に沿って、最初から最後まで一通り内容を確認する。あくまで「練習」ではなくて「リハーサル」なのだから、途中で疑問点が出ても解決策の議論までせず、リハーサルが一通り完了後あるいは時間的な制約により別の機会に行うことが多いように思う。

 

(2) インスペクション

 

  ホテル業界では、客室の清掃具合や設備・備品の状況などを総合的にチェックすることをこのように表現することがあるようだ。システム開発においては、次のような作業内容によるものをいう。

 

  • モデレータと呼ばれる進行役が、あらかじめチェックポイントを明確にして参加者に向けて資料配布と事前確認を依頼する
  • 参加者は、事前に配布された情報に基づき、自分としての判断や問題点の把握を行っておく
  • ミーティング時は、各自が持ち寄った判断や課題・問題等について議論し、決定を図る(業界内部でも聞くことの少ない用語だから、認知度としては「ウォークスルー」よりマイナーかもしれない)


2. 関係部門間での仕様の迅速な調整・決定

 ある程度までは開発担当者側で何とかできるが、それ以上は発注担当者側に委ねるしかないのがこうした「決定」作業です。前のやりとりの例でも、発送担当者・経理担当者・資材担当者の3業務の担当者がそれぞれの要求を展開しています。官公庁のような明確な縦割り組織でなくても、このような場面は発生します。

 私はこうして各担当業務ごとで意見の相違が発生し、それがレビューなどの場で衝突することは歓迎すべきことだと思っています。お互い、最優先と考える内容が異なるわけですし、確認もそこそこに新システムを導入した結果、従来より作業効率が落ちたり、実施不可能な業務が発生するようではいけないのですから。しかし、開発担当者側で頑張れるのはここまでです。

 現時点でどの業務部門からの要望を優先すべきか、もしくは実現プライオリティの高低をどう判断するかは、各発注企業の情報システム戦略や方針にかかわってくる場合もありますから、「一般にこうです」というお話が難しいところです。

 そのような時に、発注担当者側関係者を集めて最終的な解決策まで導く……こうした面を迅速に解決する体制作りを普段から心掛けておくことが大切です。製造工程では、設計工程の時よりも多くの人数で製造作業(プログラミング、テスト等)に臨んでいることが多いため、たった1日の「待った」でも、20人で作業していれば一気に約1カ月分の作業成果を失うことにつながります(実際にはこう極端にはならないような備えをするものですが)。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ