2015年9月25日金曜日

ECMサミット2015、パネルディスカッションやります

eドキュメントJAPAN 2015 ― 53rd 文書情報マネジメントショウ

Imgres

ECMサミット自体は年2回の恒例行事、なのですが、eドキュメントJAPANの枠でやるのは年に1度だけです。

今年は例の規制緩和があることもあり、各社展示ブースやセミナーも気合いがはいっているのではないかと思います。

ECMサミットもECM委員会なりに力の入った構成のつもりです。

パネルディスカッション、やります

ECMサミットは、競合しているトップベンダが一堂に会して同一フォーマットで講演を行うという特徴をもったイベントですが、基本的には各社に一定の時間枠を担当していただいて、連続して講演を聴くというスタイルになっています。この形式に対しては毎度アンケートでは、もっと統一感を出して横串で比較し特徴を見いだせるような形にして欲しいというコメントを多々頂いておりました。

過去には質問形式で議事パネルディスカッションのようなことも行い、高評価だったこともあるのですが、やはり中々登壇者の負担が大きく、毎回の実施にまでは至っていません。

ということで、今回は(主観的には結構頑張っての)パネルディスカッション形式になります。

(すべてのECM活用事例に当てはまるわけではありませんが、)ECMはプラットフォームとして捉えた方が見通しが良い、というのは近年かなり整理されてきた論点だと思います。そこについて各社なりの視点で語っていただくことをメインのトピックと考えています。

インフォメーションハブですとか、ケースマネジメント、デジタルイノベーションなど、比較的新しい言い回し、用語、の真意についてもなるべく分かりやすく語って頂けるように工夫をしていきたいと思います。

10月1日という日程的にはかなり厳しい条件もあるのですが、是非ご来場頂ければと思います。

(文責 Ishii Akinori IT-Coordinator)

2015年9月24日木曜日

コンサルティングって何? という質問と、論理的思考力とやらの話

 aegifは外資系コンサルティングファーム出身の若者(当時)を中心として作った会社なので、それ以外に稼ぎ方を知らないという意味でもコンサルティングファームだったわけですが、今ではソフトウェアベンダとしての顔も持つようになってきていますので、改めて私が考えるコンサルティングサービスについてまとめてみたいと思います。
 あくまで個人的な意見です。仕事仲間にはまったく別のことを考えている人もいますし、自分達の仕事のすべてを以下の要素で説明できるわけではありません。最近この説明しきれない部分についても考え始めたことがあるので、後日機会があればそれもご紹介したいと思います。(そんなことばかり書いている気もする)
 今回ここにまとめる内容は、新卒2ヶ月目くらいの時に自分なりに整理した内容がほとんどなので、その程度の薄っぺらさだと思って頂けると幸いです。でもまだ自分の子供たち(小学校3年と1年)にうまく説明できるところまでシンプルにもなっていないのですが・・・

意識は高くなくとも

ざっくりとコンサルタント、それも外資系出身、と言われた時、どのような人物像が想像されるでしょうか? 英語が喋れて、切れ者で、メンタルが強くて、ハードワーカーで、向上心に溢れている、なんてところでしょうか。いわゆる意識高い系という言葉に付随する揶揄のニュアンスや、押しが強くて近づき難い感じとか、抜け目なさそうなところとか、拝金主義的なイメージもあるかもしれません。あとは、頭が良いアピールがうざいとか。
 概ね正しい気もするのですが、(他の多くの職業と同じく)全部が全部そのイメージ通りでもなく、実際には色々な人がいます。例えば私の場合は、英語はIT絡みならなんとか、切れ者に見えるかどうかはともかく、メンタルは弱いし、ハードには働けないし、知識欲はあっても向上心は半端です。意識はさほど高くないと言えるでしょう。(頭が良いアピールには余念が無い方だと思いますが)
 そんな私であっても、十数年も続けていればコンサルティングサービスに対する一家言と言いますか、地味は地味なりに職業倫理みたいなものを抱えていてもおかしくはありません。ということで、今日はそういう話。

よくある説明

私が新卒の頃も、コンサルティングには個人の知識や経験を売るグレイヘアードのコンサルティングとファームに所属してチームによる組織力で問題解決を図るコンサルティングがある、だとか、戦略系・会計系・人事系などのファームの色やサービス領域による分類などはよく語られていました。ITに絡むところだと、多重下請け構造のトップに「プログラマ」「システムエンジニア」の上に君臨するポジションとして「コンサルタント」と書かれていたりもします。
 ITに絡むところと、絡まないところでは、「コンサルタント」の定義や位置づけは変わるのでしょうか?
 プログラマはプログラムを書き、システムエンジニアは仕様書を書きます。「コンサルタント」は? 要件定義書? RFP?
 「プログラマ」と「システムエンジニア」は(下請け構造があるにせよ)顧客からみると商流上同じ会社の下に入っていることが多いのに対し、コンサルタントはそうでない場合がままある(というかその方が多い?)ので、それが違いだという説明もあります。
何故そうなるのか。企業のとるアクションを意思決定から遂行に川の様に流れるものとして見た場合、上流の方があいまいでリスクが高い領域であると考えられます。そこで、そこを担当するコンサルタントがより顧客に寄り添ったポジションにいたり、リスクを見込んで高単価であったりというようなことも考えられそうです。また、あいまいさが大きくなればなるほど、ITに絡まないコンサルティングで求められているとの共通点が色々と見えてくるということもあります。
 以上のことから、私は個人的にも「エンジニア(システムエンジニアおよびプログラマ)は最終成果物として動くものを納品するという責任の取り方がある。コンサルタントの仕事にはそれがない」という話をよくしています。

では何を売っているのか

リスクがある領域で勝負しているから単価が高い。というのは、コンサルティングの仕事の性質をある程度反映した説明であると思います。ただこれは、その仕事、働き方を選択する人間の側からの説明であって、顧客が高いお金を払う理由にはなりません。
 果たして我々はどんな価値を提供しているのか。意識高くないコンサルタントとしては、卓越した問題解決能力みたいなことはあまり言いたくありません。恥ずかしいので。では、何を売りとしているのか。私は、第一にお客様のプロジェクトの成功確率を上げる(リスクを低減する)ことだと考えています。
 どのような企業にも通常業務と呼ばれる仕事、収益を上げるための活動があります。ルーチンワークと言っても良いかもしれません。そして、基本的にその作業量はその組織に所属するメンバー全員の稼働の限界に近いところで回っていることがほとんどです。そのため、例えば法律が変わったとか、新しい事業を始めたいが社内に適切な経験をもった人材がいないとか、競合会社の新戦略に対抗する施策を打ちたいとか、っていうことを考えたときに、落ち着いてそれら問題に対応できるだけの人的な余裕がないわけです。(その種のピーク時にあわせた雇用をしてしまうと、通常時に収益性が落ち込むことになります)
 そこで、それらの本来の業務ではない仕事をプロジェクトとして、期限付きの仕事として定義し実行します。このプロジェクトのチームに参画し、その成功確率を上げることがコンサルタントの主要な価値である、というのが私の主張です。

注)もちろんそれだけがコンサルタントの価値であるわけではありません。知識・経験に十分な市場価値があり、それを展開していく形で活躍されている方もたくさんいらっしゃいますし、問題解決力に特化して「考えること」の価値をマネタイズできているプレイヤーもいます。

プロジェクトの成功確率と論理的思考力

通常論理的思考力というのは、問題解決力あたりと関連付けて語られることが多い「能力」だと思います。しかし、実際にはブレイクスルーを起こすために求められる思考であるとか、イノベーションに繋がる発想だとかというものは、それほど純粋に論理的なものではないように思います。(論理と感性のバランスが必要、というような話は右脳左脳と結びつけてあちこちで語られています。右脳左脳の論に非常に強い抵抗を感じることもあり、ここでは詳細は割愛します)
 思いついたことを、他の人にも理解できるように形にしていく過程においてはもちろん論理的な思考が必要とされるでしょうが、突破力のあるアイディアを引き出すまでの過程は必ずしも論理的であるとはいえないでしょう。(そもそも論理的である必要がありません)
 ではなぜ、世の中ではコンサルタントには論理的な思考力が必要とされているのでしょうか?
 論理的な思考とは、同じ前提条件を並べられれば同じ結論を導ける、ということを保証するものだと、私は考えます。プロジェクトワークは、多くの不慣れな、あるいは、不完全な意思決定の積み上げによって行われます。作業を進めていく中で新たな事実が判明し、それまでの作業が無駄になる、ということも珍しくはありません。(それをミニマイズするための仕事の進め方を方法論という形でまとめ、活用することも大事ですが、ゼロにはなりません)
 いわゆる「手戻り」の発生です。その時その時の影響範囲にもよりますが、手戻りが発生したからといって、毎回その時点まですべての作業を巻き戻していては到底スケジュール通りに成果を上げることはできませし、何より、手戻りの発生はメンバーに混乱をもたらします。誰の責任でこの手戻りが発生したのか、という犯人探し(個人的には、そういうのは犯人探しではなくて、魔女裁判の類だと思いますが)が始まってチームが瓦解しかねません。
 だからこそ、各意思決定の時点で、どういう前提条件が見えているのかを把握し、その上で選んだ結論であるということを意識し、記録に残すことが重要になります。後で手戻りが発生するというのは、その前提条件に間違いや不足があったからであり、そこが変化したら結論がどう変わるべきかもクリアに見通せるようになります。こまめにセーブをすると被害が大きくなりづらい、ということですね。
 この、細かい意思決定の積み上げ時の前提条件の確認・把握と、その記録というのは、あまり華々しい前向きの仕事ではありません。インタビュー時に会議の勢いを削ぐかもしれないような細かい質問をし、確認を求め、議事録などの文書に残し、関係者の意識から漏れないように注意を払う、というような地味な作業によって成り立ちます。こうしたセーフティネット的な作業をどれだけ、勢いを殺さずに実施できるか、必要十分なレベルをキープできるか、というのはプロジェクト慣れと同時に、前提条件と結論の論理的な関係を見失わない能力がダイレクトに求められる領域なわけです。
 だからこそ、コンサルタントには論理的思考力が求められる。これが、意識の低いコンサルタントが論理的思考力を馬鹿にできない理由です。

 本当はソースコード管理と継続的インテグレーションみたいな話と結び付けたいところなんですが、ちょっと話が散らかってしまったので、続きはまた今度。(本当にこんなことばかり書いている)

Consulting

(文責 石井昭紀)

2015年9月11日金曜日

EFSSという用語がどこまで浸透しているかは別として

CMSWiREにEnterprise File Sharing: Good Intentions, Bad Executionという記事が載っていました。直訳すると「エンタープライズファイル共有。意図は良いが、実行は悪い」というタイトルになるでしょうか。

EFSSって?

Enterprise File Sync & Shareの略です。エンタープライズ ファイル共有と同期。我々文書管理を専門とする人間にとってはここ数年頻繁に目にするようになったキーワードですが、一般にはそこまで普及していないのではないかと思います。
要するに業務で使えるDropboxみたいなツール全般のことなんですが、例によってくどく説明したいと思います。
まず、本題に入る前に「エンタープライズ」という用語について確認したいと思います。もともとはざっくりと大企業向けと解釈しておけば間違いのない言い回しでしたが、実際にはいくつかのニュアンスが混在したものになってきていると思います。
  • 規模が大きい(データ量や処理能力など機械的な意味で)
  • 高い可用性が求められる
  • 業務用である
  • IT部門によってコントロールされる
「高価格」であるとか、日本的SIerの飯の種であるとか、スーツ族の世界であるとかっていう表現も可能かもしれません。
今回の議論とは直接関係ありませんが、もう一つ、ERPやECMの世界では重要な視点があります。
  • 中央集権的に全社統一で利用される
もちろんここにあげたものはお互いに結びついているコンセプトですが、最後の観点については、Enterprise-wide(全社スコープ)での導入か、Department(部門単位)での導入か、というのが対比で語られる、というのが特徴的であると思います。
話をEFSSに戻します。これは最近できた言葉なので、そこでいうEnterpriseも最近強調されている語感を意識して捉えるべきです。つまり、ここでいうEnterpriseの対義語はDepartmentではなくConsumerであるということになります。

Enterprise vs Consumer

数年前から日本ではSIerのキャリアパスへの不安感やWeb上のサービスを行ってるベンチャーの急成長もあって、Webネイティブな技術を牽引しているエンジニアとSIerの多重下請け構造に属しているエンジニアの間の断絶が度々問題になってきました。Web系、という言い方は業務系のシステムも世代はともかくとして同じようなWeb関連の技術を利用することが多くなってきているため、あまり通りが良くないということもあり、横文字を多用する文化圏ではConsumerizationなんていう言い回しも盛んに使われていました。
それまでは、業務向けに開発され磨かれてきた技術が徐々にコモデティ化する中で一般消費者向けにも利用できるようになるというダウンサイジング的な技術の伝播が基本だったのに対し、一般消費者向けに開発された技術の方が業務向けで使われている技術よりも先行しだしている、という状況を説明する用語でした。
Dropboxなどもその典型になります。今ではEnterprise向けのサービスも展開されていますが、基本的には個人利用をベースとして構築され成長してきたサービスです。
冒頭でリンクを貼った記事では、企業のためのEFSSと、現状利用されているファイル共有サービス(Dropbox、OneDrive、Googleドライブなど)を比較するため、後者をCFSS、 Consumer-level File Sync & Shareと位置づけています。EnterpriseとConsumerを対比させているわけですね。
面白いのは、「電子メールにファイルを添付して共有」などの技術的にはさらに古い世代のものも彼ら(?)にとって「あるべき姿」であるEFSSとの対比の意味でCFSSに含まれている、という点ですね。
このBlogでも米国のカンファレンスでDropbox問題という言い回しが一般化していた、というようなエピソードをご紹介させて頂いたことがありましたが、単に黒船が来て場当たり的に反応しているのではなく(多分に見栄が含まれていると思いますが)「もっと大きな視野で解決すべき課題を捉え、それが解決できるソリューションとそうでないものを峻別しているのである」という姿勢には敬意を払いたいと思います。

なぜEFSSが必要なのか

なんとなく想像がついてしまうこと以上の視点はとくにないのですが、(いくら日本が立ち後れていると言われていても)企業内の情報はどんどんディジタル化しています。ディジタル化するということは、余程気を付けない限り、利便性やコストメリットと共に以下の特性を抱え込むということでもあります。
  • すごい勢いで増える
  • 簡単にコピーされる
  • 簡単に消せる
要するに散らかりやすく、漏れやすいということです。これはクラウドだからとかモバイルだからとかいう以前の問題です。(もちろんそういう要素が加速する面もありますが)
従来であればECMリポジトリが、この問題に対する一つの解だったわけです。しかし、ディジタル化の波は取り扱うデータの範囲をどんどん広げていますし、社外とのディジタルデータでのやり取りも増える一方であるため、社内に抱え込んだリポジトリだけでは追いつかなくなってきている。そこにさらにDropboxのようなCFSSがシャドーIT(会社のコントロール下にないIT技術利用)的に利用されはじめてしまっているわけです。
同期ツールの利便性は高く、使い勝手の悪い仕組みの利用を強制させるのは困難です。そのため、使い勝手として同等な、しかし安全な仕組みを企業側から改めて提供していく必要がある、というのがEFSSが必要とされる理由になります。

宣伝!!

弊社では、一定の安全性が担保されている社内ECMリポジトリに対して自動同期アクセスをかけることができるデスクトップツールCmisSyncを開発しています。オープンソースモデルで開発を進めており、単純に同期をするだけであれば無償でお使い頂けます。管理機能を高めたBusiness版もご用意しています。そもそも社内にECMリポジトリなんか持っていないよ、という場合は、シンプルなECMリポジトリであるNemakiwareもご提供していますし、そろそろ10年近い付き合いになるAlfrescoの導入支援やCommunity版への独自サポートプログラムなどもあります。お気軽にお声がけください。
Imgres (文責 Ishii Akinori IT-Coordinator)

2015年9月7日月曜日

浜名湖フォーラムに行ってきました

コンサルティングファーム時代の先輩からChromebookを譲って頂いたので、今日はMarsEditではなくBloggerの標準UIで投稿してみようかと思います。

IT経営会議 浜名湖フォーラム2015 に行ってきました。これで3回目の出席になります。

ECMもEIPもBPMも、一般にはアプリケーションとして扱われているにもかかわらず、特定の業務だけをスコープにIT投資を考える場合にはなかなかメリットが訴求できない基盤/プラットフォーム/ミドルウェア的な技術です。これらの技術がもたらす利点を以下に投資企画策定時に理解し取り込んでもらうか、という検討をしている中でIT投資マネジメントを研究されている方々の取り組みを知り、ほぼ飛び入りに近い形でカリアックにお邪魔したのがきっかけでした。(IT資産価値研究会にもそこからのご縁で参加させて頂くことになりました)

自分の発表について

さて、今年は色々と忙しく、昨年以上に発表の準備に時間をかけることができませんでした。昨年はシステムダイナミクスを使って、疎結合により柔軟性を担保した仕組みの方がモノリシックな仕組みよりも、たとえ初期費用で上回っていても中長期的にはメリットが出る、というお話をさせて頂きました。(厳密には、メリットが出る時の条件を検討する枠組みだけ作った感じでしたけど)

今年はその延長で、クラウドとオンプレミスを比較し従量制と定額制の組み合わせの最適値をさぐるようなお話を考えていたのですが、思った以上に要素の数が大きく、なぜそれを考えたいのか、という説明だけして撤退、というありさまでした。

ここでも簡単に説明させて頂くと、

  • クラウドとオンプレミスは課金モデル以外にも違いが大きすぎて、現在一般に行われているTCOの比較は誠実な検討とは言えないのではないか
  • クラウドによりスモールスタートを「スタート」しやすくなったが、適用ユーザを広げるとリニアにコストアップになるので結局「スケール」しづらくなってはいないか
というようなことを考えています。

イージフではこれまで一貫してロックインされないことを重視し、オープンソース製品の紹介を進めて来ました。私はその経緯もあって、柔軟性とは「将来における選択肢の幅を狭めないこと」であると考えています。今年の発表ではそのあたりのバイアスをうまく整理しきれず、研究会のリーダーである向さんから、クラウドの柔軟性と言われれば聞き手はスケーラビリティのことだと思うよね、という至極順当なご指摘を頂きました。まったくその通りなので、忘れずに反映しないと・・・

(あと発表内容が難解すぎるので飲み会で語ったIngressとモチベーションの話の方をテーマにしてくれれば良かった、というお言葉を数度頂きました)

他の方の発表について

今年も多岐に渡る発表がありました。どこまでこうした場でご紹介していいのかわからないので簡単にキーワードとそれらについての雑感だけ、メモとして残しておきたいと思います。
  • デザイン思考 ……アイディアの出し方そのものをサービスのネタにすることの難しさや面白さについて、具体的なシーンを元にしたお話を多数聞けたのが有意義だった。
  • IoT  ……CPS(サイバーフィジカルシステム)という表現から迫ったほうが穏当? EDIの置き換え文脈もここに含まれるというのが面白かった。FAXの代替は電子メールではなくECモジュールかも、など
  • 地域支援  ……コアとなる中堅・中小企業の支援。新しく白書もでた小規模企業の支援。国などからの制度設計の視点ではROIを意識せざるを得ないが、現場は「個」の特徴に注目せざるを得ないし、成功事例はその個性を意識したところにしかない
他には、栗山先生の一連の研究にあるプロジェクト成功可否に大きな影響を与える要素としての「経営者」というお話が、改めて非常に示唆に富んだものだと思いました。IT資産価値研究会も単なる財務的な評価ではなく、意思決定に資するようなより実質的な評価を模索しているわけですが、そこには客観的な確からしさが担保される指標だけでは不十分である、という葛藤が常にあるように思います。プロジェクトの成功要因として「経営者のコミットメント」を挙げるのは、お手軽だし正しい。しかし、ワイルドカード過ぎて空虚な話になり勝ちなわけで、そこを掘り下げていくというお仕事の過程をお聞きして、どこか似たような葛藤を抱えておられるような印象を受けました。いわゆるアートとサイエンスの狭間にはありがちな話なのかもしれませんが、なんとか次の締め切りまでには自分の方も何か形にしたいものだと思います。

文責 Ishii Akinori IT-Coordinator