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