ユーザー主体開発が、最初からうまくいくわけがない:情報マネージャとSEのための「今週の1冊」(50)
業務課題は千差万別。真に有効なシステムを簡単・手軽になど作れるわけがない。ユーザー自身がそれなりの覚悟と情熱をもって「どう使うか」を考えることが必要だ。
開発・改良の切り札 システム内製を極める
激変する市場環境に追従するために、ビジネスの展開スピードは年々増している。一方で、必要なとき、迅速に利用できるクラウドサービスが浸透しつつあるほか、アプライアンスやパッケージ製品なども充実し、企業にとってはITを利用しやすい環境がますます整いつつある。
だが同時に、そうした環境は企業に主体性を求めるものでもある。いくらサービス・製品を利用しやすいとはいえ、それらを「どう使うか」というイメージがなければ、手軽に使えるだけにコストを無駄に垂れ流すことにもなりかねないためだ。ましてや、自社の業務はSaaSやパッケージだけで対応できるわけではない。独自開発が必要な場合もある以上、長年叫ばれ続けてきた「経営とITの融合」が、これまで以上に不可欠となっているのである。
本書「システム内製を極める」はまさしくこうした状況を見据えた作品である。そもそも情報を「利用する側が主体的にシステムに関与するのは当然」のこと。だが現状を見渡せば、「使いにくいシステムを我慢していたり、直そうにもIT企業の都合を聞かなければならないなど、情報システムを使いこなすどころか」「使われてしまっている組織が少なくない」。本書はそうした状況を基に、オープン化のトレンド以降、続いている“丸投げ体質”がいかにデメリットを招くものか、そしてユーザー(利用者、利用部門、情報システム部門、利用企業)が開発に主体的にかかわることで、いかにビジネスに好影響を与えるものか、改めて指摘するのである。
とはいえ、本書は決して上から目線で語る理想論などではない。「できるものならやっている」「内製に挑戦したくてもそもそも人がいない」といった“現実”を基点に、実際にユーザー主体開発に取り組んだ多数の企業事例を通じて、これから取り組む人たちと同じ視線の高さで、その実践を促しているのである。
特に印象的なのは、ユーザー主体開発のキモは、ITの専門知識を駆使することではなく、「業務を整理し、業務の改善を図り、それを支える情報システムの仕様を決める」業務設計を考えることにある、という当然の事実をあらためて確認させてくれる点だ。逆に業務設計さえ自力でできれば、仮に開発を外部に委託したとしても主体性は担保できることを強く訴えるのである。
第一章に配された宮崎県 宮田眼科病院のシステム開発事例は、まさしくそうした考え方を象徴するものだ。簡単に紹介すると、“日本屈指の眼科”として年間十数万人が訪れる同院では、患者の待ち時間が長いという問題の解決を狙い、手作業で行っていた予約受付業務のシステム化を決めた。だが組織が縦割りであり、組織間連携も「必ずしも良くなかった」ため、「予約システムだけを作っても待ち時間は短縮できない」と判断。導入効果を最大化できるよう、業務フローの見直しから始めた。その結果、約10カ月で「総合予約システムM-Magic」が稼働。患者の来院が平準化され、患者の平均在院時間が減少したほか、再診希望患者が大幅に増加したのだという。
だが、この話のポイントはそうした「結果」よりも、むしろ成功に至るまでの「過程」にある。プロジェクトは院内に「業務改革IT委員会」を設け、ITコンサルタントの助力を基に進めたのだが、もちろん委員会の中心メンバーは看護士や検査員。「現場のことはよく知っているが、ITにはまったく詳しく」なく、「画面のスクロールを知らない人もいた」という。このような状況で全てがスムーズになど運ぶわけがない。
それでも業務知識を駆使して効率的なフローを考え、それを基に粘り強くシステム仕様を考案し、いつしかBPRという言葉が口癖のようになったころ、「業務手順を一つなくせば、画面操作の回数を減らせる」といった意見も積極的に出せるまでになったのである。導入の成果は、決してシステムの機能のお陰などではない。それを考え、業務の中に有効に位置づけた、関係者全員の努力と好奇心と使命感の賜物なのである。各事例とも課題や中身は異なるが、この基本的なスタンスは全事例に共通している。
一般に、雑誌やWebなどで紹介される成功事例は「課題」と「結果」だけであり、その「経緯」は省かれているケースが多い。だがシステム開発において、「結果」と同じくらい大切なのは、「何を、どう進めたか」という「経緯」であるし、多くの関係者が最も知りたがっているのも、実は「結果」そのものよりも、「関係者にどんな苦労があり、具体的にどう乗り越えたのか」という“等身大の体験談”なのではないだろうか。その点、本書は「ユーザー主体開発」という理想論、キレイごとではなく、ある意味、泥臭いとも言えるその真の中身を事例を通じて具体的に紹介してくれるのである。
「ユーザー主体開発」と聞くと反射的に拒否感を抱いてしまうような人ほど、この“物語群”をぜひ味わってみてほしい。業務部門の人なら開発に対する見方が変わるかもしれないし、ベンダやSIer、情報システム部門の人なら、システム関連の仕事に携わり始めたころの志を思い出すかもしれない。
- 人はなぜ不正を働くのか?
- なぜIKEAは世界中で支持されるのか
- 今こそ「メディア」を考える
- 部下を信じ、尊敬する
- ご機嫌取りになれ
- “暗い未来”に漫然と向かわないために
- 1つの行動が社会を変革する
- あなたには確固たる「ミッション」があるか?
- 「会社に行きたくない」人ほど会社に依存している
- 失敗の2大パターンは“精神論とお役所仕事”
- コミュニケーションは、ツールではなく人が行うもの
- 社員が疲弊している会社は、経営層とITに問題あり
- ロジカルシンキングで成果が出ない訳
- 手段ばかりを求めていると、結果は出せない
- 「技術へのこだわり」という日本企業の根深い病
- 日本軍とまったく同じ、日本企業の“敗戦理由”
- “技術だけ”では、開発プロジェクトは失敗する
- 断捨離で、業務とシステムはもっと快適になる
- 仕事でモメたくない人のための教科書
- その油断と慢心が“炎上”を招く
- 本当は怖いフェイスブック
- 組織も自分もダメにする「自分大好き」という病
- 災害対策、コスト削減、システム改善は全て同じ問題
- あなたなら、自社システムをどう攻撃する?
- “想定外”から1年、見て見ぬふりはしていませんか?
- ナイトライダーも示唆する人とシステムのあるべき関係
- アップルが成功し、ソニーが失敗した理由
- 貴社のビジネス、ITシステムに“マインド”はあるか?
- 何のために働くのか? その回答はシンプルそのものだ
- 事故を起こす企業の特徴は、「責任者が不明」
- スマホ導入は、セキュリティポリシー設定がキモ
- 失敗は、「簡単なこと」「当たり前のこと」で起こる
- ITがどれほど進展しても、経営の基本は変わらない
- コピペやお絵かきが得意な人は“中毒”の疑いあり
- 情報は、人間関係があって初めて有効に活用できる
- “顧客”や“ユーザー”との関係作りを見直そう
- システム導入・浸透のポイントは“楽しさ”にあり
- “当たり前”を覆すチャンスはまだまだ埋まっている
- ソーシャルメディア・リテラシが収益を左右する
- 技術者はアーティストであり、製造業者ではない
- 分析するのは「ツール」ではなく「人」である
- ブランドは、消耗品である
- 当然のことを当然にこなすための指南書
- リスクを知っていてこそ、スマホは使いこなせる
- 個人でも企業でも、“ナンパ野郎”はウザいだけ
- 「見える化」だけでは、ビジネスは進まない
- 2ちゃん、ニコ動、外務省。次の標的は貴社のサイト!?
- あなたの会社は「突然死」の危機にさらされている
- BCPは、業務部門と情シスが連携して初めて成功する
- 仕事や人生、そして復興にも、秘策はない
Copyright © ITmedia, Inc. All Rights Reserved.