今月のひとこと
先号　　　次号

 優しいのはダメ 

オンライン編集長　深谷　靖純　[プロフィール]　：5月号
　今年のゴールデンウィークは、10連休だという方もかなり多いそうです。円安の影響にもめげず海外に出かける方で空港が賑わい、「未だ間に合うお出かけスポット」といった番組が連休スタート後も続いています。一方で、こうしたまとまった休みを「リスキリングやリカレントの絶好の機会」、「趣味や副業に時間を割ける」と考える人も増えています。かつて、「日本人は休みの使い方が下手」を常套句とする休日評論家（?）諸氏がマスコミに大勢出ていましたが、最近見かけなくなったような気がします。様々な休日の過ごし方があって、十把一絡げに「日本人は」と言いづらくなってきたせいでしょうか。

　プロジェクトの成功を評価するモノサシというと、直ぐに思い浮かべるのがQCD（Q：品質（Quality）、C：コスト（Cost）、D：スケジュール（Delivery））です。システムモデルプロジェクトの場合はこのQCDの指標による評価で腹落ちします。しかしながら、スキームモデルやサービスモデルのプロジェクトでは、このモノサシはどうにもしっくりとこないなと思ってきました。スキームモデルでは、人数が少ないので、期間が2倍3倍になってもプログラム全体のコストから見れば誤差のうちです。もともと何をやるかを決めるプロジェクトですから、いつまでにできるかを見通せるはずもなくスケジュール変更に大きな抵抗もありません。サービスモデルの場合も予見していなかった事象をどこまで取り込むかを予め計画することは至難です。
　先日、長くSEをやっていたという方から、超上流で安直な決定をしたシステムは開発プロジェクトがQCDをクリアしていても評判がよくなかったというお話を伺いました。この評判というものは定量化しづらいためか記録には残らず、担当したプロマネの評価に影響しないのだそうです。QCDをクリアしたプロマネを切るわけにはいかないので、安直な決定を推奨するプロマネばかりになって、プロマネの質が低下してしまったとその元SEはぼやいていました。若い人たちがそんなプロマネを見て、自分もプロマネになろうとは思わないとまで嘆いていました。
　安直な決定とはどんな決定かと尋ねると、ある業務処理システムを更改することになった時のことを話してくれました。最初のリリースから年数が経って、業務の追加・変更に伴いシステムが複雑化してきたことが、更改検討のきっかけでした。システムの改変に携わってきた中堅SEをリーダとして更改要否及び新機能を検討することになりました。その中堅SEは、該当システムの改変をとおしてユーザからの信頼も厚く誰もが適任だと思いました。ユーザを交えた検討はスムーズに進み、その中堅SEをプロマネとして更改プロジェクトが立ち上がり計画どおり完了しました。更改されたシステムは、業務別サブシステムの階層化・顧客データベースの一元管理等により各種計数の早期還元を可能にするなどの改良が組み込まれ、ユーザからも使い勝手が良くなったといわれました。
　しかしながら、更改システムの寿命は短かったのです。
　「今回のシステム更改では、入力画面のデザインに統一感を持たせ、見やすくするとともに、処理能力を上げて時間短縮を図ります。しかしながら、システム更改に伴う戸惑いが発生しないために、従来と同様のやり方で仕事を進められるよう心掛けます。」システム更改に関するユーザ部門との打ち合わせの席で、そのプロマネはこのように説明しました。仕事のやり方を変えないという優しい言葉にシステム更改に対する厳しい注文はありませんでした。また、この時出席したユーザ部門はバックオフィスの人たちだけでした。実は、この頃から既にその業務処理システムを取り巻く環境は大きく変わり始めており、仕事のやり方を変えなければいけない状況であったことをユーザもプロマネも認識できていなかったのです。
　その業務処理システムでは、営業等のフロントが起こした伝票をバックオフィスが受け取り、システム入力用に入力票を作成して入力する手順となっており、新システムでも大きな流れは変えませんでした。同時期に同業他社では、フロントとバックの垣根を取り払う流れ（フロントが直接入力）を取込み始めており、バックとフロントの間の業務調整等に時間がかかり開発プロジェクトがとん挫しているという話が聞こえてきました。そのプロマネは、入力方法の変更に耳をふさぎ、とん挫の話で自分の進め方に自信を持ったようです。さらに、顧客が直接入力（インターネット取引）することを始めたという話も聞こえてきましたが、普及には時間がかかると勝手に判断しました。
　業界内で、バックオフィスの人員削減あるいはバックオフィスそのものの廃止といった事例が増えてくるのにたいした年月はかかりませんでした。
　賢明な読者諸兄には、既にお分かりだと思います。このプロマネは、メンテナンス時と同じようにユーザを「業務処理システムの使用者」として対応していたのです。「業務の担い手」としてシステム更改だけではなく業務の見直しについても検討するという姿勢で臨めば、厳しい議論を交えることになったかもしれませんが、短命システムを開発してしまうリスクは少なかったのではないでしょうか。
以上
ページトップに戻る