ミラクルorリピータブル？
前回は「サービス工学」のほんの“触り”の部分について、お話しさせていただきました。
今回から、「サービス工学」の研究テーマとして、奇跡のプロジェクトを分析して得られた結果と知見について、お話をさせていただこうと思います。
システム開発すべてに当てはまるものではありませんし、もしかしたら「当たり前じゃん！」という話なのかもしれません。しかしながら、この中の一部でも、システム開発で苦労している皆さまの参考になれば幸いですし、「やっぱりそうか！」と思っていただければ満足です。
■システム開発での課題
1．顧客企業の目的価値と、開発会社の目的価値は異なる
不幸というか当たり前というか、顧客企業がシステムに求める目的価値と、開発会社がシステムに求める目的価値にはギャップがあります。顧客企業にとってシステムは「手段」であり、システムを使って経営課題を解決することが目的です。逆に、開発会社にとってシステムは「成果」であり、仕様書どおりのシステムを、短納期かつ高品質、低予算で作り上げて導入することが目的となります。双方の目的は、システム課題を解決する局面で交わりますが、そのほかでは双方が無関心になりがちです（正確には、専門外と思い口出ししない）。そのため、本来ならば経営、業務、システムは一体のはずですが、連続性が失われて矛盾が生じることがあります。
参考図1：システム開発ではなく、「ITを活用した業務改革（経営課題解決）」が目的
参考図2：顧客と開発会社とのギャップ
2．顧客企業の中でも、立場によって課題が異なる
顧客企業の中でも、立場や役割によって課題が異なります。経営層は業務改革による効果（コストの削減や品質の向上）を課題としますが、ミドルマネージャはチェックや確認処理など業務運営における課題を気にします。現場は、日々の入力の簡素化や画面の操作性、レスポンスなどを問題視し、加えて他部門や、顧客の顧客、取引先業者などが関係してくると、さらにややこしくなります。
3．顧客のITに対する知識不足。開発会社の業務に対する知識不足
システムの仕様書は業務とシステムが融合して初めて出来上がります。顧客はシステムが分からない。開発会社は業務が分からない。その様な中で、顧客が仕様書を書く、もしくは開発会社が作成した仕様書を承認する、という所からシステム開発は始まるのですが、実のところ適当に分からないまま承認されていたり、仕様書と言いつつ実は詳細設計書だったり、というのが実態だったりします。
参考図3：仕様書はまっとうか？
また、双方の知識の不足は、言葉の違いにもつながります。それぞれ業界の方言で話すとコミュニケーションにもギャップが出てきてしまいます。
4．難燃性、不燃性、可燃性
多くのユーザーがいれば、さまざまな性質の人たちがいます。すぐに乗っかってイケイケな人もいれば、文句ばかりたれて何もしない人もいます。数的に多いのは様子見タイプですが、往々にして打ち合わせの場は不燃性の声の大きな方に引きずられてしまいます。
5．段階的詳細化
システムが一番難しいところかもしれません。多くの場合において、段階が進むにつれて問題が細かく、かつ数が多くなってきます。画面に対する要求、個別業務、テストパターンなど。だんだん全体像が見えなくなってしまうのです。
6．ローカルな業務運用ルール
基本的に、どこの支店でもやっていることは同じはずなのですが、業務運用ルールは異なります。同じことを違うやり方でやっているのです。システムが、個別ルールにすべて対応しようとすると、とんでもないことになってしまいます。
■奇跡のプロジェクトが成功したわけ
1．IT構想段階でのブレインストーミングで、方向性をコミットした
IT構想段階で、経営層、中間管理職、現場（業務、他部門単位）にて、「現状の課題、問題点」「将来のあるべき姿」というテーマにてブレインストーミングを行いました。この結果をまとめ、トップを交えた顧客企業全員の前でプレゼンすることにより、方向性をコミットしました。ここでポイントは、下記になります。
- AsIs-ToBeを明確にすることにより、ぶれない軸を立てた
- ブレインストーミングにて多くの人の意見を聞くことにより、参画意識を高めた
- プレゼン時は、トップも参加してもらって、トップ承認の既成事実を作った
- 将来を示すことにより、個別のバラバラな課題を1つにすることがでた。個別への不満はなくなった
2．仕様書作成は全員参加
方向性を決めた段階で、具体的なシステム仕様書の作成になりますが、これは設計事務所も含め顧客企業のIT担当と開発会社SEも参画した共同作業としました。業務が分からない、システムが分からないという知識不足問題はここで解消します。システムと画面を融合した、画面業務フローなる概念もここで生まれました。
3．調整者、翻訳者の設置
開発期間中は、顧客内、開発会社間の調整は設計事務所の役割です。加えて、顧客、開発会社間での翻訳も設計事務所の役割でした。コミュニケーションの不足はこの機能で解消しました。
4．短期で開発、そして改造
ウン十億のシステムですが、実質の開発期間はスケジュール上、開発は半年、試験は3カ月という、とても短期間でした。とにかく短期で開発し、ユーザーに使ってもらいながらの障害対応、改善、機能追加の連続。言いかえるならば、段階的詳細化の最終段階については、実際にシステムを利用するユーザーと共に開発や試験を行ったということでしょうか。
5．定着化に向けた努力
運用開始後は、とにかくシステム定着化に向けたさまざまな努力を惜しみませんでした。アメとムチの使いわけで、「使わない言いわけ」を徹底的に排除し、不燃性を燃焼させました。
- 一般ユーザー教育
- システムの改善
- 外部コンサルタントからの評価
- インフラの充実（当初予定にはなかったが、PCのリプレイスを早め高スペックにしたり、管理職向けに大画面を導入したりした）
- 活用事例情報交換会の実施
- エキスパート特別教育
- 利用度調査と課長評価への反映（IT利用度を課長評価の1つにした）
- 現場改善活動の導入など
6．1つ上の視点からの課題解決
システムの開発をやっていると、どうしても業務に合わせることが難しく、コスト高になってしまう機能があります。そういった場合は、1つ上でシステムを業務に合わせるのではなく、業務をシステムに合わせる方法をとりました。ローカル業務運用ルールは、そうやって改めてゆきました。
■結局、設計事務所の役割はなんだったか（サービス工学的に）
ここまで、システム開発の課題と奇跡プロジェクトの成功要因を例示してきました。最後に設計事務所の役割が何だったか、ということをサービス工学的にお話しさせていただきたいと思います。
参考図4：設計事務所サービス
今回のプロジェクトを、図の様にモデル化しました。設計事務所は顧客に、IT化構想や開発管理、サポートデスクなど「顧客IT化支援サービス」を、開発会社や運用会社にシステム設計や運用設計などの「開発、運用支援サービス」を提供しています。そして開発会社や運用会社は、顧客に「システム開発やメンテナンス、運用サービス」を提供しております。
ここで重要なことは、設計事務所は顧客にサービスを提供しつつ、顧客のニーズ（Needs）をとらえている、もしくは掘り起こしている、ということです。そしてそのニーズを要求（Requirements）として整理し、システムの必要スペック（Specification）として、開発会社や運用会社に提供しているのです。これは従来の顧客―開発会社という一方通行的なモデルと違い、設計事務所がポンプの役割を担い、ニーズとシステムを循環させる仕組みがシステマティックに実現できており、これが顧客満足度の高いIT化を実現できた理由だ、という結論に達したのです。
■最後に
話が長くなってきましたので、今回はここまでにしたいと思います。次回、解説編として、今回の話を少しフォローしてみたいと思います。