先日表題の内容で社内勉強会をやったので、そのとき話した内容をこちらにも一部記載します。
本記事は、どちらかというとSIerやコンサル会社向けです。
ここ1年ほど、ノーツからの移行案件が増えてきた感があります。
ノーツからSharePointへの移行は、ノーツのバージョンアップやリース切れのタイミングで検討されるため、数年おきに波があるのですが、今は非常に多い時期と言えます。
弊社も大型の移行案件含め、いろいろとお手伝いさせていただきましたが、
移行する際に気を付けるべきポイントが、ある程度見えてきました。
・ノーツからSharePointへの移行は”超”大変である
国内だけでも数多くの事例はあるものの、実際にはこれが現実です。
Exchangeへの移行は比較的すんなりいくものの、SharePointはとても大変です。
ちなみに、企業がノーツではなくSharePointを採用するという意思決定をするまでには、
機能的な比較やROIなどが重視されますが、
導入が決まると機能的な部分は実はあまり問題にならないと考えています。
それよりも何が大変かというと、以下の3点に集約されると考えています。
①現状のノーツ環境の調査
②エンドユーザーとの調整
③プロジェクト管理
この3点は独立した問題ではなく、すべて関連し合っています。
詳細を1つ1つ解説します。
①現状のノーツ環境の調査
移行先や実装案を検討するうえで、現行のノーツ環境の調査が必要です。
これを行ってはじめて、SharePoint標準機能でいけるのか、開発しないといけないのか、
といった切り分けができます。
ところが、ノーツの場合多いのは、
・各DBの設計書、仕様書が存在しない
・各DBを作った人がすでにいないため、誰も仕様が分からない
という2つの事態です。
これにより、現状調査は結局1つ1つ実機で動作確認をする必要があります。
これには非常に時間がかかります。
なんせ、ビジネスロジックが分かっていない状態でアプリを触っても、
何から手をつけていいか分からないからです。
中にはエンドユーザーが懇切丁寧に教えてくれるケースもありますが、
移行対象DBが多いとそんなことまでやってくれません。
逆に適当に調査すると、ノーツは隠れDBや隠れロジックが潜んでいる可能性が高いため、
非常に重要な機能要素を見逃して後で大問題になる可能性が出ます。
②エンドユーザーとの調整
移行にあたっては、エンドユーザーとコンセンサスをとっていくことが必要となります。
これは企業によってその必要性の度合いが変わってきます。
一般的に、エンドユーザー部門の意見が強い場合は、この調整は大変です。
逆に情報システム部門側の発言力が強く、イケイケ状態であると、比較的楽です。
ごくまれに、エンドユーザーもシステム部門も両方イケイケの場合があり、この場合はとても楽です。
とはいえ、大なり小なりエンドユーザーに対しては、
移行する目的や現状の要望、移行後のイメージや負担してもらうことを説明しなければいけません。
その際には以下のような点で非常に苦労します。
・ノーツの言葉とSharePointの言葉は、中国語と日本語くらい違う
・エンドユーザーはSharePointのことはまるで知らないので、理解してもらうために根気強く説明と大量のサンプル作成が必要
・現行業務に変更が生じる場合、当たり前だが拒否反応を示される
・エンドユーザー目線でいうと、SharePointは非常に融通の利かないシステムに見える
まず、ノーツとSharePointは全く違う製品である、という大前提が、エンドユーザーには通用しないことがあります。
エンドユーザーからすると利用システムがなんであれ、自分たちの業務が効率よく遂行できれば良いわけですから、これは当然の反応です。
通常の業務アプリ開発の場合は、エンドユーザーの現行業務を洗い出し、要望を吸い上げながら、
より良いシステムを一緒に作っていくことができます。
が、移行案件の場合は、1つ1つそんなことはやっていられないケースが多いため、
まずは最低限現状維持でまとめて移行する、という大雑把な選択肢になりがちです。
これはこれで仕方のないことではあるものの、実際には現状維持どころか、
大幅に機能落ちすることも少なくありません。
ノーツはExcelのマクロやAccessのアプリのように、EUCで業務密着型のアプリを作りやすくなっており、
この柔軟性にはSharePointは太刀打ちできません。
この機能差を埋める3rdパーティ製品は多々あり、こうしたもので解決できることもありますが、
製品紹介はちょっと本題からずれるので割愛します。
(また別の機会にまとめたいと思います。)
もちろん、SharePointならではのメリットは多々あるものの、
エンドユーザーからは「できないこと>できること」に見えるため、なんでこんなシステムに移行するんだ、という大変雰囲気の悪い状態になることは少なくありません。
③プロジェクト管理
個人的な経験から言うと、
ノーツからの移行プロジェクトは当初計画より、コスト増、スケジュール遅延になる可能性は非常に高いです。
これは①、②がしっかりできずに、後になって大きな問題が発覚したり、
エンドユーザーからの要望で追加開発が増えてしまったり、調整に時間をとられることに起因していることがほとんどです。
プロジェクト計画は、当初想定できる範囲で書くため、
開発が大変とか、データ移行が大変とか、そういうある程度計算できる領域よりも、
予想外の部分でのリスクが大きく影響します。
何度か移行案件をやっているプロジェクトマネージャならまだしも、
そうでない場合は非常に難しいプロジェクトになります。
また、SharePointはノーツと違い、多層アーキテクチャになっているため、
インフラからアプリまでのサブプロジェクトがパラレルで走ることもよくあります。
この進め方は悪いわけではないですが、
サブプロジェクト同士の連携を密に行わないと大きな問題を見逃す可能性が高くなります。
以上3点については、こうしたらうまくいくよ!という単純な解があるわけではありません。
が、こうした困難な移行案件でも、うまくこなしている事例はあります。
細かい要素は無数にありますが、共通して言える大きなポイントとしては、
・移行する目的、プロジェクトのゴールが明確になっている
・移行するスコープ(そもそものプロジェクトスコープ)を限定している
・情報システム部門がSharePointのことをある程度理解している(自分でサイト作ったり、サイト管理ができる)
・プロジェクトチーム内の情報共有が着実に行われている
という点かと思います。
どれも難しいですけどね(笑
2012年1月23日月曜日
2011年2月2日水曜日
ログオン画面だって悪くない
いまとあるお客様の社内ポータルの検証作業をお手伝いしているのですが、
Windows統合認証が使えるSharePointを利用するのに、わざわざログイン画面を出すというご要望。
むしろ、普通はシングルサインオンになって嬉しいというお客様が多いのに、
珍しい要望だなと思って理由を聞いてみたら、
ログイン画面は従業員に対する広告として使える、とのお答え。
言われてみればごもっともなんですが、目からうろこでした。
従業員に周知したい情報は多々あれど、全従業員が必ず目にする場所というのは多くありません。
ログイン画面はそういった意味で、その数少ない有効な広告スペースの1つなんですね。
利用者にとってみたら単にわずらわしいログイン画面でも、
実はまったく異なる別の目的に有効利用ができるという、発想の転換でした。
Windows統合認証が使えるSharePointを利用するのに、わざわざログイン画面を出すというご要望。
むしろ、普通はシングルサインオンになって嬉しいというお客様が多いのに、
珍しい要望だなと思って理由を聞いてみたら、
ログイン画面は従業員に対する広告として使える、とのお答え。
言われてみればごもっともなんですが、目からうろこでした。
従業員に周知したい情報は多々あれど、全従業員が必ず目にする場所というのは多くありません。
ログイン画面はそういった意味で、その数少ない有効な広告スペースの1つなんですね。
利用者にとってみたら単にわずらわしいログイン画面でも、
実はまったく異なる別の目的に有効利用ができるという、発想の転換でした。
2011年1月12日水曜日
新年ごあいさつ & 効率化について
遅ればせながら、あけましておめでとうございます。
すっかり更新が滞っている本ブログですが、今年は頑張って更新していこうと気持ちを新たにしております。
このところプロジェクト案件がいくつか並行していたのですが、忙しい反面いろいろな知見を得ることができました。
その1つが効率化という言葉。
効率化という言葉を、偶然にも同時期に別の立場の人から聞いて、ちょっと考える機会となりました。
一方はプロジェクトを進めているお客様からで、IT 活用の1つの重要テーマが、事務作業の効率化であるという点。
もう一方は弊社のパートナー企業、すなわち効率化のソリューションを提供するITベンダー側の営業担当者からで、最近の顧客企業では効率化という言葉は人手を介していた仕事を奪うことになるから、むしろ悪い印象に受け取られることが多い。そのため、効率化という言葉は使わないようにしている、というもの。
図式としては以下のように妙なことになっています。
顧客企業 ITベンダー
「業務効率化がIT活用のテーマ」 ⇔ 「効率化はNGワード。口にしない」
※当たり前ですが、顧客企業やITベンダーによって考え方が違うので、
すべてに当てはまるわけではなく、あくまで私の周囲の話です。
ちなみにITベンダー側の意見は今に始まったことではなく、
10年前くらいにも同じようなことを言っていた時期がありました。
業務フローの電子化がブームだったころで、やはり「俺の仕事をパソコンにとられる」的なことを仰る方々がいるので、効率化という言葉を使う時は気を付けようと。
一見食い違っているように見える両者の意見ですが、
考えてみれば原因は同じところにあって、視点が違うだけかなと。。
10年間もそうでしたが、不況期にはこうした風潮が強まると思います。
どうしても内向きのコスト削減やムダの削減に力を入れざるを得なくなるため、
全社的に効率化などが重要視されてくる。→顧客企業
その結果、企業の利益率は向上しますが、不況期であるため売上そのものが伸びるわけではありません。
さらに、効率化によって劇的に仕事が楽になってハッピーという人は多くなく、むしろ人員削減によって仕事が増えたり、自分の仕事を守ることに精いっぱい、社内の空気も悪いということになる。
そんなところにもっと効率化しましょう、という提案は持っていきづらい。→ITベンダー
じゃあ景気回復しないと効率化なんてやらないほうがいいよね、ということではなくて、
私は「効率化してどうするの?」というところを掘り下げていくべきと思います。
効率化はあくまで手段であって、目的は別のところにあります。
1つの解は、売上を増やすこと、つまり生産性の向上です。
効率化によって仕事がなくなるなんてことはありません。
むしろ、そこで空いたリソースは売上を増やすための業務にまわすべきです。
効率化はそのための手段としてとらえ、いかに人材を適材として活用するか、
そこまでを見据えた提案を、ITベンダーはしていくべきでしょう。
すっかり更新が滞っている本ブログですが、今年は頑張って更新していこうと気持ちを新たにしております。
このところプロジェクト案件がいくつか並行していたのですが、忙しい反面いろいろな知見を得ることができました。
その1つが効率化という言葉。
効率化という言葉を、偶然にも同時期に別の立場の人から聞いて、ちょっと考える機会となりました。
一方はプロジェクトを進めているお客様からで、IT 活用の1つの重要テーマが、事務作業の効率化であるという点。
もう一方は弊社のパートナー企業、すなわち効率化のソリューションを提供するITベンダー側の営業担当者からで、最近の顧客企業では効率化という言葉は人手を介していた仕事を奪うことになるから、むしろ悪い印象に受け取られることが多い。そのため、効率化という言葉は使わないようにしている、というもの。
図式としては以下のように妙なことになっています。
顧客企業 ITベンダー
「業務効率化がIT活用のテーマ」 ⇔ 「効率化はNGワード。口にしない」
※当たり前ですが、顧客企業やITベンダーによって考え方が違うので、
すべてに当てはまるわけではなく、あくまで私の周囲の話です。
ちなみにITベンダー側の意見は今に始まったことではなく、
10年前くらいにも同じようなことを言っていた時期がありました。
業務フローの電子化がブームだったころで、やはり「俺の仕事をパソコンにとられる」的なことを仰る方々がいるので、効率化という言葉を使う時は気を付けようと。
一見食い違っているように見える両者の意見ですが、
考えてみれば原因は同じところにあって、視点が違うだけかなと。。
10年間もそうでしたが、不況期にはこうした風潮が強まると思います。
どうしても内向きのコスト削減やムダの削減に力を入れざるを得なくなるため、
全社的に効率化などが重要視されてくる。→顧客企業
その結果、企業の利益率は向上しますが、不況期であるため売上そのものが伸びるわけではありません。
さらに、効率化によって劇的に仕事が楽になってハッピーという人は多くなく、むしろ人員削減によって仕事が増えたり、自分の仕事を守ることに精いっぱい、社内の空気も悪いということになる。
そんなところにもっと効率化しましょう、という提案は持っていきづらい。→ITベンダー
じゃあ景気回復しないと効率化なんてやらないほうがいいよね、ということではなくて、
私は「効率化してどうするの?」というところを掘り下げていくべきと思います。
効率化はあくまで手段であって、目的は別のところにあります。
1つの解は、売上を増やすこと、つまり生産性の向上です。
効率化によって仕事がなくなるなんてことはありません。
むしろ、そこで空いたリソースは売上を増やすための業務にまわすべきです。
効率化はそのための手段としてとらえ、いかに人材を適材として活用するか、
そこまでを見据えた提案を、ITベンダーはしていくべきでしょう。
登録:
投稿 (Atom)