ラベル aegif の投稿を表示しています。 すべての投稿を表示
ラベル aegif の投稿を表示しています。 すべての投稿を表示

2013年11月4日月曜日

そして、自社セミナもやります

イベント情報 | お知らせ | aegif: "弊社が中心となり開発を進めているOSS(CmisSync, NemakiWare)の機能や活用方法、最新情報をご紹介いたします。また、両製品に共通するトピックであるCMIS規格の概要や動向についても、これまでオープンソースECMを扱ってきた弊社視点でご紹介させていただきます。ぜひ皆様のIT投資への一助としてご活用ください。 "





前回の投稿に続きセミナ関係です。



今月19日じ弊社主催のセミナを行います。これまで取り扱ってきているLiferayやAlfrescoの新しい活用方法ですとか、自社製品CmisSyncやNemakiwareについてのご紹介をさせて頂く予定です。



前回の投稿でご紹介したCMISがどんな規格かというような話も冒頭で少しご説明させて頂く予定です。



しかし、私自身が細かく決めているわけではないのですが、こういう企画というのは本当に難しいですね。ご紹介したいお話はたくさんあるのですが、なかなか絞りきれません。



どの分野でも同じかもしれませんが、とりあえず来て頂いて休憩時間などでお話するか、ご挨拶だけさせて頂いて後日詳しい説明をしに伺うか、というところで具体的に見えてくるものがあるのが実情だと思います。とすると、極論登壇時のテーマは何でもよい、もしくは見た目にキャッチーなテーマであるほど良い、ということになりそうですが、そこまで割り切って進められる程講演テクニックに自信がもてるわけでもないですし…



(文責 Ishii Akinori IT-Coordinator)




2013年6月25日火曜日

プレゼンスについて

Alfresco社としては弊社とのパートナーシップは黒歴史と化してしまったようですね・・・



弊社もかつては日本の独立企業としてトレーニングパートナーの契約をしてプレスリリースも打っていた経緯がありますが、確かに今ではパートナーシップを解消してしまっているので、プレスリリースを書く人の立場にたって考えると色々難しい気もしますね。まあ、「数年前にトレーニングがなくて困りました」なんてことを言われてしまうと、Alfresco自体の初期バージョンリリースから弊社とのパートナーシップ締結および最初のトレーニングの実施まで1年半もかかっていないと思うので、こういうところに愚痴めいたポストもしたくもなりますけども。(リンクを貼ったプレスリリースはトレーニングパートナーの契約時点の話でお客様に対するトレーニング等はもっと以前からやっていたという経緯もあります)



しかし、結局の所は自社のプレゼンス、情報発信力が十分でなかった故の行き違いであることは、間違いないですよね。



弊社のビジネスはAlfrescoにしてもLiferayにしても、リスク過大評価気味の日本市場において優れたOSS製品を提供している企業と早期にパートナーシップを確立することに依存してきたので、それらの優れた製品の力によってマーケティング的な面で有利な仕事をさせてもらってきたという認識があります。優れた製品、OSSというコンセプトという組み合わせは、理解の深いお客様との接点を作ってくれた要素の一つでもあります。そういう意味では今後自社製品の展開などを含めると、会社としての情報発信力をより強化していかないといけないわけですが、折角なので何か毛色のかわったことをやりたいですよね。今のところ個人的に満足してる施策は、クリンゴン語のランゲージパックぐらいなものなのですが、今後もそれに近い仕掛けを考えていきたいです。



(なんとなく如何にもWebマーケティングの営業がかかってきそうなことを書いてしまいましたが、マーケティング部門は粛々とちゃんとした仕事をしていて、プレスリリースやセミナー、ショーへの出展なども定常的にはやっていて特にそこに不足を感じているわけではないです。ちゃんとしたこと、以上のことをやれたらいいですね、というお話です。)



(文責 Ishii Akinori IT-Coordinator)




2013年6月20日木曜日

BROコラムに記事が掲載されました

BROコラム|知識0でも大丈夫!OSS導入のコスト面でのメリットを解説! ―IT投資施策決定における重要な4要素からOSSを評価する 前編 |BRO



ご無沙汰しております・・・



実際には結構前に書いた記事なのですが、私が確認作業を放置したなどの行き違いがあって、最近ようやく公開されました。IT投資評価の文脈で、適切にOSSを評価してもらうためのセットアップを期したのですが、なかなかうまくまとめるのは難しいですね。



(文責 Ishii Akinori IT-Coordinater)




2013年4月26日金曜日

求める人物像など

前回の記事が、結局ハードルを上げてしまっている、というもっともなご指摘してきをいくつか頂いてしまいましたので、さっそく続編を。頑張ってハードルを下げていきたいと思います。あ、下げ始める前に、ハードルの高さという意味でのネガティヴ要素を吐き出してしまうとすると、今現在の技術要員のほとんどが東大か京大の出身です。例外はありますが、個人始めたAndroidアプリのダウンロードが50万を超えた、とかっていうフランス人です。でも、学歴は別に条件ではないので、例外っていう言い方は不適切かもしれませんね。



よし、ハードルを下げる時がきました。(繰り返しますが、別に学歴やコミュニティ活動の実績は初めから求人の条件に入っていないので、それをもってハードルというのは本来おかしいんですけどね)



求める人物像



例によって、スキルや実績の話と性格や姿勢の話があると思うんですが、まずはより具体的な直近で求めているスキルの話から。



期待するスキル



今弊社で開発中の2つの製品CMISSnycとNemakiWareのうち、すぐにも人員を増強したいのはNemakiWareの方です。これはいわゆるNoSQL系の中でもドキュメントDBといわれるCouchDBを利用する文書管理のためのソフトウェアで、本体部分はJavaで作っています。検索はSolrを使っています。UI部分はRailsで作っています。CouchDBの都合なども考えると、言語としてはJavaかJavaScriptかRubyができれば良いということになるわけですね。(ハードル下げてますよアピールが鼻につく文体になりがちで、注意が必要な気がしてきました)



ただ、この製品はOASIS標準規格であるCMISに準拠するというコンセプトがあるため、この規格についての理解が求められます。おそらく日本国内にこの規格に明るい人材なんて数える程しかいないはずなので、これは参画の時点で求めるべきスキル・知識だとは考えていません。ただ、英語でこの規格についての文書を読み、理解を深め、場合によっては規格策定の当事者たちに質問して疑問を解消する、というようなことが求められる可能性はあります。(また、上がってきてしまいました)



ということで、新メンバーの方には、実際にはCMISについての理解度の要求水準が比較的に低いRails製のUIのところから着手してもらうことになるのではないかと思います。パッケージ製品として長期にわたって展開していくので、メンテナンス性や拡張性を考えた設計や実装をしていきたいですし、オープンソース製品なのでその成果物のほとんどは衆目にさらされることになります。このあたりを引き受けられるかどうかがポイントになるのではないかと思います。その点で信頼できる人であれば、たとえば仕事でRailsを使ったことがなくても問題ないくらいだと考えています。



スキルや経験以外の話



この場では副社長権限で私の好みについてだけ書かせて頂きます。実際にはチームワークなので、他のメンバーの好みはここに書かれているものとは異なりますし、採用の条件にはなりづらいと思いますが、少なくとも候補者の方の視点から私の好みを観察できることに意味はあると思うので。



色々考えたのですが、「自分のことを頭が良いと思っている」ということに尽きる気がしています。より正確に表現すると、「文脈・分野・問題によっては他の人より自分が考えた方が良い結果に繋がる(こともある)、というステートメントを引き受けることができる」ということなんですが、言葉が増えた割には明確にはなっていないかもしれませんね。要するに考えることをすべて他人任せにされてしまうととても困る、ということです。そして、自分で考えるという選択肢を主体的にとれるのは、そういう自負がある人だけだというのが私の考えです。



念のために書いておきますが、うちのメンバーが全員自分が一番賢いと思っている鼻持ちならない秀才タイプということではないです。むしろ逆と言っても良いくらいです。あえて当てはまりそうなのは私くらいじゃないかと思います。そういう思い上がりを表に出しても良いことはないわけですからね。



くどくなりますが、うちのメンバーは見るからに優秀です。特に技術部門のリーダーは(本人はありとあらゆる隙間を見つけて否定してきますが)相対する側が圧力を感じるくらいに優秀です。そのため新しく参画する人は、自分よりも他のメンバーに判断を委ねた方が組織全体のためになる、と考えてしまう可能性が高いわけです。特に自分がまだ不慣れな状況である、ということを勘案すれば、その選択はなかなか責められるものではありません。しかし、我々の業界では、考える部分を他人に依存し続けることで楽しく仕事ができることはほとんどないと思います。個別に正しい割り切りを積み上げていくと、結果みんなが不幸になってしまう。



弊社のような環境では、優秀な仕事仲間を仮想的な競合(敵)とみなすことなく、あくまで助言者として利用し、自分で考えて仕事を進めていく必要があります。そのためには、現場感覚としてはリスキーに思えても、自分から担当範囲を広げていくしかないわけです。その時の支えになるのが、これまでに積み上げた成功体験です。自分が考えたことで良い結果を生んだという体験がない人には、なかなかそのリスクを引き受けることができないのではないかと思います。だからこそ、私は「自分のことを頭がよいと思っている」人を求めているわけです。(東大卒の人達などは立場上普段から「自分はバカですから」という発言を封じられているという意味で、この基準をクリアしやすいという構造があると思います)



なかなかうまく表現できませんでしたが、個人の好みを書き連ねるのはここまでにします。もし、今後ここを読んだ候補者の方とお話をする機会が持てたとしたら、その時個別にフォローしたいと思います。



会社の特徴



今、イノベーションの主戦場がWeb系のサービス運営会社に移ってしまい、企業向けソフトウェアの業界はその魅力を失っていると言われています。我々は、その陰りが見え始めたと言われる業界において、もっとも活気があると思われる領域(の一つ)をホームとしています。



情報システム分野、特にソフトウェアについては初期投資があまり必要ではないため、新規事業者が戦い易い領域です。つまり、混沌とした競争環境が続く戦場です。その中で長期的に生き残る為には、何らかの競争優位な性質を見極め、そこに注力するのが良い選択だと考えられます。そこで我々が選んだのが「オープンソース」です。



これまでの仕事



今「オープンソース」はある特定の文脈においては、「ソーシャル・モバイル・クラウド」などに比べて新規性(輝き?)が失われたキーワードだと見なすことができるかもしれません。しかし、それを言うのであれば我々が戦略としてここに注力することを選んだ8年前でも、別に新しさのある言葉ではありませんでした。我々は新しい分野で目立ちたくて選んだのではなく、長期的な優位性を持ち得る考えたからこの道を選んだのです。



なぜ、オープンソースが長期的な優位を生むのか。それは、このモデルが一次生産者である個々の技術者と消費者の双方にとって有利なものだからです。IT技術はインターネットによって一般のビジネスにおける情報格差を消滅させ、多くの卸売業を窮地に追い込みましたが、IT技術そのものの供給は相変わらずIT技術の知識の有無という情報格差に依存したSIビジネスによってなり立っています。特に、ユーザ企業側の技術に対するコミットが弱いとされる日本企業においてその傾向は顕著であると言えるでしょう。それでも、一次生産者と消費者がオープンソースを選好していけば徐々に企業向けのITプロジェクトがオープンソース製品ベースのものになっていくと考えられるわけです。



なぜ、一次生産者と消費者にとって有利なのか。これにはいくつか理由があります。まず、ここでいう一次生産者はITベンダではなく、そこで働く技術者を想定しています。プロプラエタリな技術は徹頭徹尾勤務先であるベンダに帰属します。その知識や経験が適用可能なプロジェクトはそのベンダの製品を取り扱ったものに限られます。そして、その製品自体の寿命はその企業の経営状態にも依存してしまいます。ビッグベンダによって買収され、親会社の製品ラインナップのなかに無理矢理押し込められる、というのは恐らく最良に近い将来像であると言えるでしょう。つまり、仕事をつまらなくする要素に事欠かない、ということです。オープンソースの場合は、もう少し状況は改善されます。貢献の事実は個人の資産ですし、部分的にであれ良いものができているなら好きなだけ他のプロジェクトへ持っていくこともできます(持っていく先も多くの場合はオープンソースであることが期待されますが)



ソースコードを公開する、という前提があるので、ある程度以上の自信があるエンジニアでなければ精神的に辛い面もあるかもしれません。しかし、それはつまり、オープンソースのものとそうでない2つの技術なり製品があった時、前者側に参加しているエンジニアの方が相対的にスキルが高いと期待できるということでもあります。私の知る限り、優秀なエンジニアと一緒に働きたいと考えない「優秀なエンジニア」は存在しません。以上の帰結として、オープンソース製品には(相対的に)優秀なエンジニアが集まる傾向にあると予想できます。少なくとも自由に選択肢が提示されれば、そうなっていくはずです。その意味で、長期的な優位、です。



消費者にとって有利、というのも、価格のことだけではありません。特定のベンダにロックインされにくく、技術自体の存続性の期待が高い、そして優秀なエンジニアに担当してもらえる可能性も高い、ということです。こちらも、IT投資のリスクをどう評価するのか、という点にかかっているので、すぐにオープンソース陣営が大勝ちするということは期待していませんでしたし、実際に移行は緩やかなものだったと思います。「感度の高い」お客様から先にオープンソースの製品を採用していくという傾向がありました。これは、8年前の時点で明確に狙っていたことではありませんが、結果としてこれまでのお客様のほぼすべてが、皆一緒に働く甲斐のある人達でした。



これからの挑戦



そして今、私たちはさらに新しいことに挑戦しはじめています。自社製品の開発です。当然、オープンソースモデルを採用しています。



今までの経験がどこまで通用するか、まだはっきりとはわかっていません。しかし、海外で成功しているオープンソースの企業向けソフトウェアの実態や、それを日本で展開することのビジネス面と技術面双方での難しさ、などについての理解・経験においてすでに我々は国内でもトップの水準にあると思われます。それは確かに一つの経営資源であり、活かさない手はありません。その一つの方法が、自社製品の開発であると考えています。



ベンチャーなので、小さい会社なので、個人の裁量が大きいという言い方はあまりしたくないのですが、そういう実態があるのもまた事実です。そのことは、単なる丸投げ体質と言われかねないものでもあるでしょう。だからこそ、どういう見込みに基づいてこれまで仕事してきたのか、これからどんなレベルで試行錯誤をしていかなければならない状況にあるのか、ということについて可能な限り明らかにしておきたいと考えました。十分な整理なく、勢いで書いてしまっているので、冗長なわりに表現しきれなかったことばかりである気もしますが、以上が今回の人材募集の背景として考えていることになります。



まとめると、「なんだか面倒くさそうな人達と一緒に、RailsやNoSQLとJavaを織り交ぜて、企業相手のソフトウェアを書く仕事」に興味がある人いませんか? って感じです。



皆様是非よろしくお願い致します。



(文責 Ishii Akinori IT-Coordinater)




2013年4月25日木曜日

改めて求人を担当するにあたって

困ったことになりました。いよいよもって人手が不足しています。受注が重なってしまい、自社開発プロジェクトに深刻な影響がではじめました。そこで、私が担当となって追加の技術要員を探すことになってしまいました。



人材の募集は常に行っているのですが、通常ですとメンバーが業務の隙間時間に面談を繰り返し行い、最後に我々取締役が最終面談、という流れであり、最近は忙しくてなかなか手が回らない状況が続いていました。特に、弊社の場合はコンサルタント要員よりも技術要員の方が実質的なハードルが高い、というやや特殊な状況がどうもあるようで、まずはそのあたりの整理から着手していく必要がありそうです。(ここでいうコンサルタント要員はビジネスコンサルティングの部門の要員という意味で、OSSのコンサルティングは弊社ではどちらかと言えば技術要員の仕事になっています)



ですが、時間がないので最初のところから私が担当することでスピードアップを図りたいと思います。一人で勝手に候補者に会って即決、というわけではなく、今まで通りの面談は実施していく予定ではありますが、時間を短縮することくらいはできるのではないか、と。



せっかくなので何故技術要員のハードルが高くなっているのか、というお話や求める人材像(?)についてもう少し。記事の性格上会社の特徴なんかも必要かもしれませんね。また、無駄に長くなりそうですね・・・



高いハードル



後で会社の特徴としても触れるかもしれませんが、経営陣の一人である私に技術者重視の会社を作りたいという気持ちが元々あること。そのくせ日和って技術畑でない人とのバランスや収益性を考えると、技術者パラダイス的な組織を用意するような器があるわけではないこと。それらの結果として他社がやりたがらない難しい仕事ばかりをやらざるを得なくなっていること。そして何より、現状のメンバーがそれが出来てしまうくらい優秀であること。



結果として、どの仕事も新しい人を割り当ててうまく行くイメージを持てない、という状況がうまれました。



これは、私の、(しかも残念な事に、世の中にはありふれている類いの)失策です。優秀なリーダーと優秀なメンバーに甘えすぎました。



難しい仕事とは



弊社の技術部門の場合は、オープンソースの企業向けソフトウェアの導入コンサルティングや技術アドバイザリ、製品サポート、トレーニング、などがそれにあたります。他社に先駆けて取り扱いを開始したため資料は仮にあったとしても全て英語ですし、複雑な問題解決には開発元の人達との英語でのコミュニケーションが必要になります。その場合、ソースコードが読めることは大前提です。



一方で顧客サイドに対してもまだまだ理解度に濃淡がある「オープンソース」に対する期待をコントロールし、ライセンス費用が無償である分時として逆に期待レベルが上がってしまっているスキルに対する要望に応えていかなければなりません。



こうして仕事の性質を並べて書いてしまうと、とても割の良い仕事には見えないかもしれません。実際、メンバーには負担をかけているところもあります。それでも、ソースコードへのアクセスがある、製造元の技術力やビジョンを直接自分で判断できる、ということのメリットは大きいはずですし、年々顧客サイドの理解も深まっています。何より、弊社のメンバーはその仕事をこなし、今回のような人手不足を生じさせてしまうほどの評価も得ています。



ですから、難しい仕事という言い方は、実は一面的すぎたわけです。



私の反省すべき点



問題なのは、この「オープンソースかつ企業向け」というマーケットの可能性を私自身が十分に信じ切れておらず、事業としてのリスクをメンバーのスキルのみで押さえ込んできてしまった、というところにあります。



このビジネスにはもっと間口を広げて(現状の技術メンバーの大部分のように元々の知り合いで、すでに「できる」ことがはっきりしている人以外にも)もっと人員を多く動員できるだけの余地が十分にあったし、今もある、ということです。



次回予告



やっぱり長くなりすぎるので、求める人材像と会社の特徴の再整理の話は次に持ち越します。上記の話はこれまでやってきたOSSのコンサルティングのビジネスを下敷きにしてしまっていますが、現在の募集はそこだけでなく、より技術志向の強い自社製品開発の部分に重点をおいています。(既存のコンサルティングの募集ももちろんやっています)



次もすぐ書きます。今日か明日には。



(文責 Ishii Akinori IT-Coordinater)




2011年11月18日金曜日

ケースマネジメントと管理会計

http://www.wdc-jp.biz/jasmin/2011_fall/sub.php?open_key=D3-4: "BPMと記録管理の連携方式の考察"


今年からJIIMAのECM委員会に参加させて頂いているんですが、最近そのメンバーの一人であるNRIワークプレイスサービスの松本さんとケースマネジメントについてのお話を色々とさせてもらっています。


松本さんはACMなどで話題になりつつあるケースマネジメントの考え方が、主に記録管理の分野で銀の弾丸扱いされているのではないか、という懸念をもたれているそうです。


確かに、ケースマネジメント的な考え方というのは、ある仕事の単位の中での業務の手順その他にバリエーションが多く柔軟な対応が求められる場合において、非常に強力な解決策となるものですが、(システム的なサポートは適宜行うとしても)、やはり事案横断の分析の可能性やフローを固めることで生まれる自動化などの発展性を犠牲にする面があると思われます。柔軟性を得たいがためだけに安直にケース単位の情報・記録管理だけをやればよい、という風潮になってしまうことは避けるべきだ、というのが松本さんの意図であると思います。柔軟性にともなうトレードオフというのはシステムの世界ではよくある話ですので、違和感のないストーリーと言えるのではないでしょうか。


さて、では何か他に対案があるのか、ということになりますが、そこで松本さんは「ユニット」による業務の分割、とその管理単位のBPMへのマッピングという手法を提唱されています。(リンク先はその発表第一弾の概要です)


詳細は私もわかっていない部分もあるので割愛しますが、ここでいうユニットとは(おそらくは野村総研で採用されている)管理会計上の最小単位ということのようです。「プロセス」は「部門」を横断しますが、その構成要素たる「ユニット」は「部門」の中に収まるように設計されていて、計数的な報告・分析はすべてこの「ユニット」単位で行うことが義務づけられている、という世界観です。組織変更の場合は「部門」間で「ユニット」を引き渡す形になるのだそうです。


ここまで割り切った「ユニット」が定義され、実際に管理会計レポートのための報告体制までできあがってる企業というのは非常に限られていると思いますが、仮にこうした体制ができているとしたら、それを前提としたBPMが従来の色々な課題を回避できうる、というのはかなりあり得そうな話だと思います。この成熟度まで行くのが難しい、といわれれば、それはもちろんそうですが、記録管理や業務プロセス管理というのは安全性の向上や業務効率の向上という具体的なメリットを生む行為であり、意思決定サポートのためとして考えられてきた管理会計制度の整備が、具体的なパフォーマンス向上につながるという絵を見せることができるのであれば、それは非常に価値が高いことだと思います。


今後とも継続的に松本さんの取り組みに注目し、できる限り一枚かませて頂こうと考えています。


(文責 Ishii Akinori IT-Coordinator)












2011年10月28日金曜日

InfoTalk、行ってきました

aegif CTO blog: InfoTalk/20111021 - 産業技術大学院大学:


前回の投稿で予告した勉強会へ行ってきました。


結論としては、妙な別題を付けてしまったプレッシャで、うまく喋れませんでした。反省です。大学院という先入観があるためか、10年前の修士論文発表会を思い出しました。思えばあれも情けない発表でした。


別題は、「コードなんて書かなければ書かないほど偉い」と思っている人とのつきあい方、というものだったのですが、これは趣味やバイトでプログラムを書いていた学生が外資系コンサルティングファームでパッケージ導入コンサルティングの仕事につくことで感じた価値観のギャップと、今現在のWeb業界のイノベーションとEnterprise市場のビジネスの連携の弱さというIT業界の問題点を絡めた話をしたい、と思ったからなんですが、うまくまとめきることができませんでした。どこかで再チャレンジしたいテーマではあります。


Technology Populismとソーシャル・モバイル・クラウドの話とか、我々が何故OSSの業務パッケージを扱ってるのか、という話を思い切って削ればよかったのかもしれませんが、そうなると本当に私が何者なのかわけがわからなくなりますし、、、


もう一つの反省点は、つきあい方、の答えをちゃんと伝えることができなかった、というところですね。事前に社内でディスカッションして、意思決定に近いところで仕事しよう、そのためには偉くなるか、フラットな構造の会社を顧客にするか、規模の小さくても付加価値ができる仕事をすれば良い、、、というような話。もう一つが、やはりオリジナルな製品・サービスで勝負しよう、別にWeb業界じゃなくてもそれはできるし国外にも市場はある、というような話。前者は偉そうな感じがして嫌ですし、後者はアジテーション色が強すぎて辛すぎました。


(文責 Ishii Akinori IT-Coordinator)



2011年10月21日金曜日

InfoTalk/20111021 - 産業技術大学院大学

InfoTalk/20111021 - 産業技術大学院大学: "「Enterprise市場から見たWebとSocial」"


今日こそはランチミーティングに参加、と思ったのですが、社長が時間をけちりたがるので社内ミーティングスペースで実施することになってしまいました。空腹のあまりおかしなことを書いてしまうかもしれません。


本日18時、産業技術大学院大学で毎月行われている勉強会イベント、InfoTalkに参加させて頂く予定になっています。Enterprise市場から見たWebとSocialという、怪しい表題です。柄にも無く砕けた感じの話をする、、、という課題を勝手に設定しています。事前に講演内容のダイジェストをお送りすることになっていたのですが、ちょうど忙しい時期でなかなか手が着けられず、締め切りぎりぎりでひねり出した格好です。徹夜に近い状況だったため、眠気のあまりおかしな副題をつけてしまいました。(もし、万が一、愉快な内容を期待して来られる方がいらしたら本当に申し訳ないです)


エンタープライズソフトウェアの世界を少し相対化した整理と、Technology Populismの話が、エンタープライズソーシャルに繋がるような話をできればいいな、と思ってはいるんですが、対象自体がまだまだ混沌としている状況なので、実際の発表はかなりとっちらかってしまうかもしれません。聞いて頂いた方のフィードバックをもらえればそれを反映したバージョンの発表資料を後日ここでも紹介したいと考えています。


(文責 Ishii Akinori IT-Coordinator)



2011年10月6日木曜日

久々の六本木ヒルズ

約1ヶ月ぶりの通勤です。


今月からイージフCTOとしての業務にフルタイムで復帰したはずだったのですが、月初から出張が入っていたためオフィスにくるのは久しぶりです。さっそくエレベータホールを間違えました。六本木ヒルズはこの手のビルでは珍しいダブルデッカー(2階建て)のエレベータなので、我々偶数階の住人はまず1階分エレスカレータで上がってからエレベータに乗らないといけないんですが、そのことをすっかり失念していました。


社長やマーケティング責任者(取締役)の加納あたりには10月1日にPwCコンサルティング同期の同窓会で会ったんですが、その時も妙な「久しぶり感」がありました。長期の仕事であれば1ヶ月顔を合わせないことなんて今までもあったような気がするんですが、やはり「クレーン屋」の世界からの復帰ということが大きいのかもしれません。


Blogの投稿も復活させていきたいと思います。金曜日には社内のBlog寄稿者があつまってランチタイムに執筆しようという動きもあります。


#MarsEditによる公開日時の指定はうまく行きませんでした。日付は入ったんですが、ステータスがDraftのままで公開されませんでした。かといってPublishedで出すとすぐに公開されてしまいそうです。


(文責 Ishii Akinori IT-Coordinator)



2011年10月2日日曜日

復帰

ご無沙汰しております。aegif CTOの石井です。


さぼっている間に、一緒にお仕事をさせて頂いた中国人ブリッジSEの方に「Blogを読んでます」といわれてプレッシャを感じました。こんなところまでチェックしているとは、意識の高いエンジニアの方のバイタリティには恐れ入ります。


復帰直後に私事で申し訳ないんですが、1ヶ月程までに父が亡くなりまして9月いっぱいはaegif CTOとしての仕事を完全にお休みさせて頂いておりました。家業が「(ホイスト式)クレーンの製造・販売・メンテナンス」というマニアック(?)な町工場を営んでいるため、父から弟への事業承継のサポートをしていました。時間も予算も限られていたので会社案内の焼き直しや簡易的なCRMの導入など、本当にささやかな成果しかなかったんですが、その中で会社案内を受け取って頂いた方が見るかもしれないWebサイトの構築、というタスクがありました。


GoogleサイトというGoogle Appsの中にあるおそらくはWiki的な情報共有サイトを構築するための仕組みを使って、会社の公開サイトを作ってみました。Googleサービスに対するログインや利用規約へのリンクが強制的に表示されるなど、基本的には会社のメインサイトに使うものではないような気もしますが、簡易さとGoogle Appsとの親和性を買って今回はこういう形にしてみました。30分程度で完成して大したものだと思っていたんですが、実際には画像(会社ロゴも!)が自動的に画像ファイルそのもののリンクになっているのを放置した形だったり、ページ名がURL構成文字のつもりで設定したwwwのままだったり、と形ができた後にも色々と細かくいじるべきところがあったらしく、色々な人からコメントを頂いて2日くらいはあちこちを書き直していました。


また、Googleのサービスを使って独自ドメインをマップした如何にもな会社サイトをつくれば、特にSEO的なことをしなくても良いかな、と思っていましたが、私の実家のような零細工場でも最近はマピオンなどの電話帳サービス上でページが割り振られてしまっているため、最初は会社名で検索してもまったく結果ページに表示されませんでした。(このエントリも半分以上公私混同といいますか、実家のサイトの被リンク数を押し上げるための施策であったりもします)


これまでの私の認識ではGoogleサイトは「帯に短くタスキに長い、あまり使い道がなく人気もない」サービスだったのですが、UIの使い勝手は良いですし、独自ドメインのマッピングも無料でした。前述した強制的に挿入されるリンクのフッタさえ気にならなければ、なかなか応用が利くしくみなのかもしれません。Webサイト構築をブラウザで簡単にやりたいという目的ならJimdoの方が高機能ですし、特定組織内の情報共有に関してはWikiもしくは専門のコラボレーションツールを使うべきだとは思いますが、



  • (画像が多いなど)自由書式に近い表現方法を採用したい

  • 独自ドメインの配下におきたい

  • 扱うユーザがGoogle Appsに参加している

  • RSSなどで整理された更新情報を受け取らせたい相手がいるわけではない

  • ページ毎にアクセス権を設定したい(あるいは後でしたくなるかもしれない)


などの条件下であれば、かなり適合度が高くなるということのようです。存続してくれることを願います(ここ5年のITの環境を考えると、結構切実な願いですよね)。


(文責 Ishii Akinori IT-Coordinator)



2011年4月18日月曜日

Tech Populism

ソーシャルコンテンツマネジメントのところでも触れましたが、近頃、Tech PopulismとかTechnology Populismと呼ばれる傾向について考えさせられる機会が増えているように思います。(Populismでは通りが悪いのか単にDemocraticという語を用いるケースも多いようですが)


テックポピュリズム、技術ポピュリズムという訳が良いのか、あるいはもう少し意訳的な試みをすべきなのか悩ましいところですが、要するに個人生活においてGoogleやfacebookに慣れているエンドユーザが、既存の企業システムの使い勝手の悪さを許容できなくなってきている、というお話です。


私個人は恐らく就職活動にはがきを使わなくなった最初の世代にあたると思います。採用担当者との連絡はもっぱら電子メールで、面接の際にもそういうったことが話題に上ることがありました。大学に入学した時にはWindows95の発売の直前で、つまり普通のPCにはTCP/IPスタックが搭載されていなかった時代(Windows95がでてもまだオプションでしたね)ですから、6年間の間にインターネットが完全に社会インフラとして定着したということを実感したものです。


当時、会社のPCおよびネットワークの環境に対して「自宅環境に比べて貧弱すぎる」という不満を持っていた人は極めて少数派であったと思います。(もしかすると私自身はそこに含まれていたかもしれませんが)。ブラウザやメーラはほぼ同じものを使い、ハードウェアはどちらかと言えば会社のものの方が高性能、専用の高価なソフトウェアもインストールされているかもしれない、という状況でした。


その後、その前提が大きく崩れていきます。1つにはセキュリティポリシの適用があります。会社側が設定する方針にしたがってセキュリティ対策を実行すると、PCの性能は落ちますし、USB外部記憶装置が使えないなど、利便性も損なわれます。パスワードの強制変更にストレスを感じることもあるでしょう。


もう1つが、GoogleをはじめとするWeb上の生産性向上ツールの普及です。GMailはデスクトップのメーラと比べても遜色しない使い勝手と、遙かに高いレベルの可用性や検索などの利便性を備えた上で「無料」です。一方で会社で新システムとして導入されるWebアプリケーションは、使い勝手の面でのGoogleレベルというわけにはいきませんし、ブラウザのアップデートに追随できないということも珍しくありません。セキュリティ等々のリスクがあることは頭では理解できるとしても、わざわざお金をかけて無料のものよりも使いづらいものを作って強制し、生産性が落ちていく状況を飲み込むのは結構なストレスであると思われます。


こうした不満による反動は、クラウドブームに乗じたセキュリティについての考え方の見直しとあいまって、Google AppsやSalesforce.comの採用という形で徐々に目に見えるようになっているのではないでしょうか。技術の成長スピードは速く、その多くが海外からやってきていることを考えると、後ろ向きなセキュリティ評価に手間取っているうちにどんどん外から置いて行かれることになってしまいそうです。とはいえ、セキュリティを完全に無視してよいわけがありませんので、何らかの評価手法を打ち立てる必要があるように思います。弊社でも既存のお客様のシステム投資案評価の支援などを通してこのあたりの課題の整理を進めて行くつもりです。



(文責 Ishii Akinori IT-Coordinator)



2011年4月12日火曜日

怠慢のつけ

 またしてもBlogの更新をさぼってしまっておりましたが、今回はその間にあまりにも沢山のできごとがありました。


 まず、途中まで書き上げていた記事に、弊社の5周年というものがあります。2月22日が創業記念日でした。今年の2月22日にaegifは創業からまる5年を経たことになります。創業メンバーとしてはそれなりに感慨深いものがあったような気もしますが、特にこれというイベントも行いませんでしたし、ノベルティグッズみたいなものを作ったりもしませんでした。


 実はその直前に求人についての考え方の記事を連投していたこととも関係あるのですが、今年に入ってからは特にビジネスも調子を取り戻しつつあり、このところ小休止状態になってしまっていた規模の拡大に向けて動きだそうとしていました。それも含めて皆忙しくしていたということもあるかもしれません。(つい過去形で記述してしまいましたが、人員の募集への積極的な姿勢自体は今も変わっていません)。10周年を祝う機会があればその時はもう少し派手にやっても良いのかなとは思いますが、案外10周年も同じようにあっさりと過ぎ去ってしまうような気もします。思うに、たとえば創業○周年パーティ! というイベントをやるとして、自分で自分を祝うということ自体が実はピンと来ていないところがあります。これが他の人のことであれば、純粋におめでたいことであり、無理に理由をつけでも祝い事をすべきタイミングだと思えるのですが、自分たちのこととなるとちょっと冷めるというか気後れをする部分もあり、行動が鈍ります。そうこうするうちに半年や1年なんてあっというまに過ぎ去ってしまうので・・・


#このあたりの感情的な動きについてはあくまえ私個人のものですし、うちの社長はむしろ派手好きで自分大好きなので、5周年をスルーしてしまったのは本当にたまたま忙しかったから、だと思います。ただ、派手好きな社長がいたとしてもちゃんと前もって計画をしないとこの種のイベントはすぐに過ぎ去ってしまうということは改めてよくわかりました。


 そして、3月に入って震災がありました。まだこの問題は総括して振り返るような段階にないと思いますが、ほぼ東京圏でのみ完結するビジネスを行っている(お客様はもう少し広い範囲にいらっしゃいますが)弊社にとって、直接のダメージはほぼなかったと言えます。防災の責任者としての私の怠慢から非常時の行動指針の周知徹底などはまったくできていませんでしたが、オフィスに勤務しているメンバーが率先して電子メールでの安否確認を行ってくれたこともあり、大きな混乱もありませんでした。六本木ヒルズは揺れ自体は長時間続いたようですが、エレベータの運行も比較的早い段階で復旧しましたし、電気も自力で発電して東京電力側へ供給しているほどだそうですからまったく途切れることがありませんでした。私は外出中だったのですが、結局徒歩でオフィスに戻り朝まで交通機関の復旧を待つことにしました。


 直接の被害を受けていない会社として、メンバー個人と連動する形での寄付を行うことにしましたが、他の形で寄与できることがないという点には忸怩たるものがあります。Goolgeと自社を比較してもはじまりませんが、Google社では安否確認のサービスを緊急で立ち上げたりGoogle Appsの当該地域での利用を無償化したりという施策を打たれています。自社の強みや日頃生み出している付加価値の部分をそのまま提供することで、その時自らが背負い込むコスト以上の便益を提供できているわけです。これは、素直に羨ましいと思います。我々は起業によって大きな行動の自由を手に入れていますし、幸いにして優秀なメンバーにも恵まれています。もちろん、資金力にはきつい制約がありますが、それでも自分はそれらのアドバンテージを十分に活かしていないのではないかと思えてなりません。大きな課題です。


 もちろんビジネス自体は継続しています。3月の後半にはAlfrescoのキックオフミーティングに参加して来ました。多くの人に日本の状況について温かい言葉をかけて頂きました。刺激になった点も多々あります。去年に限ったことではありませんが、彼らのビジネスは急速に成長しています。特に今後は国内でのパートナーシップ展開に力を入れていきたいという気持ちを強くしました。我々だけの限られたリソースでは、とてもついて行けない規模になってきています。欧州、北米に比べて国内のAlfrescoの導入実績は極めて少数ですし、今後はBRICsにも抜かれかねない状況です。これはほぼ、日本企業がECMを必要とした場合に、他国にくらべて高コストで身動きのとりづらいプロプライエタリ製品かスケールが期待できない小規模向け製品しか利用できていないということを意味しています。そして、その責任のうちの幾分かは我々にあります。今年は、これまで以上に積極的な情報発信と、パートナー候補となるSIerさんへの支援に力を入れていきたいと思います。


(文責 Ishii Akinori IT-Coordinator)




2011年1月21日金曜日

コンサルティングという仕事

求人の局面で意味をなしそうなことを連投する、という企画の続きです。


まずは、どんな仕事をしているのか、というお話から。コンサルティング、という言葉は意味が広すぎるので、弊社のサービス内容としての「コンサルティング 」の中身についてご紹介したいと思います。


Webサイトの会社紹介のページにも簡単に触れていますが、私を始めaegifの初期メンバの過半が外資系コンサルティングファームの出身者です。その全員が、部門こそ違っていますが新卒時に総合系ですとか、かつては会計系と言われたファームに入社しました。そのため、実はコンサルティング以外の仕事の経験がほとんどなかったりします。


この時点で、まず1つの分岐があります。世の中一般でコンサルタントといった場合、個人として卓越した知見を持ち、ある種伝道師のようにその知見を求めるクライアントに助言を行う、というスタイルをイメージされるケースがあります。以前はグレイヘアードなんて表現を目にしましたが、最近そういう言い回しはあまり聞かなくなりましたね。我々は新卒時にいきなりコンサルティングファームの門を叩き、コンサルタントになっているので、そういうタイプの仕事をしているわけではありません。新社会人に対して、助言だけで価値を生み顧客の役に立つということ求めるのは無理があります。我々がおこなってきた仕事は、もう少し「システマチック」なものです。


我々が新人だった10年間頃、会計系のコンサルティングファームはSAP R/3などのERPの導入に力を入れていて、私自身もそのトレーニングを受け、大規模な導入プロジェクトにアサインされました。(そこで、たまたま巡り会ったECMパッケージとの縁が今のAlfrescoのビジネスにつながっているのですが、今回の話の筋とは離れてしまうのでここでは触れないでおきます。)


こういったシステム導入のお手伝い、特にパッケージソフトウェアの導入というのは非常に「システマチック」な性質を持つ仕事です。もちろん、情報システムにかかわるから「システマチック」と表現しているわけではありません。プロジェクト(独自性があって、反復を前提としない、期限が切られたアクティビティ)として、様々な意志決定を行い、システムの設計と定着化を目指すにあたって、1つ1つの意志決定の積み上げをいわば積み木のように慎重に積み上げいく必要があります。関与するステークホルダが多い大規模システムの場合は積み上げるべき検討事項の数や依存関係が膨大になり、かなり「きっちりと」積み上げていかないとすぐにあちこちにほころびが生じてしまいます。そこで、プロジェクトの現場で、各検討事項を「きっちりと」捌いて積み上げていく、というお作法になれた人員が求められます。きっちりと定められた手順、要求された品質で、作業成果を積み上げていく、という実態を「システマチック」と表現しました。また、こうした要求に応えられる人たちのことを(ERP)コンサルタント、と呼んでいると思います。



  1. プロジェクトワークの全体像を把握でき、その中での自分の役割を認識できる。


  2. そのパッケージを有効に活用し無用な追加開発をさけることのできる標準機能やカスタマイズ負荷についての知識を持っている。


  3. 抜けもれなく前提条件をおさえ、フェアな意志決定ができるだけの情報を整理し、その仮定を適切に記録して振り返りに対応できる体制を構築維持できる 。(プロジェクトの緊張感をささえる土台となれる、プロジェクトを牽引できる、という言い方をする場合もあります)


などのスキルが求められます。 2.だけがパッケージなどの技術に特化した知識の要件で、実際にはそれ以外の要件は「プロジェクトワークの専門家」であるということにつきます。パッケージの知識については担当領域さえ絞り込めれば比較的短期間に学習することができますし、何より、各技術・知識領域の専門家達が学習のための教材を用意しているケースもたくさんあります。そのため、プロジェクト実行担当者として頼りになるかどうか、が仕事をできるかどうかの判断基準になっています。


もちろん、aegifのコンサルタントにも、こうした実行力を求めています。


(おそらく)つづく、


(文責 Ishii Akinori IT-Coordinator)




2011年1月19日水曜日

求人(?)

景気の波、ということでしょうか、おかげさまでこのところ「人が足りない」という贅沢な悩みを抱えています。時折、弊社のWebサイトから直接応募をしてくださる奇特な方もいらっしゃるので、そういう方の参考になるような情報にも触れておきたいと思います。実際、こちらのBlogまでリサーチして頂けるかというとちょっと難しい気もします。仕事で調べている紹介会社の方のほうが、あるいは沢山読んでくださっているかと思いますが、今のところ具体的な候補者なしでのコンタクトは一律お断りしてると思います。(すみません、直接の担当ではないので間違ったことを書いているかもしれません)


今現在(2011年1月)、Webサイト上では”ビジネスコンサルタント”と”会計コンサルタント”の2つの職種について記載しています。今、特に不足しているのは前者のビジネスコンサルタントですが、もちろんOSS領域の技術者の方で弊社に関心を持って頂ける方がいらっしゃればお気軽にコンタクトをとって頂きたいと思っています。(上に牽制的な書き方をしてしまっていますが、人材紹介のコンサルタントの方々には大変お世話になっていますし、今後もともに成長していきたいと考えています。ただ、直接求職者の方からコンタクトを頂いたケースの方がコストがかかりませんし、ベンチャーなのでなんとなくそのことで気分が盛り上がる面もあります。その意味で、うちに限らずベンチャーへの求職者には直接応募を強くお勧めします)


ところで、ビジネスコンサルタント、というタイトルは漠然としすぎている、という批判もありえるのではないかと思います。これは本当に悩ましい問題です。例えば、Webサイトの【求める経験・資格】の欄にも「コンサルティング会社での業務コンサルティング経験」とだけ記載されています。一方で、【歓迎する資格】にはいわゆる外資系のコンサルティングファームではさほど一般的であるとは思えない、中小企業診断士やITコーディネータが列挙されています。これでは弊社がどういう人材を求めているのかよくわからない、という方もいらっしゃるかもしれません。


そこで、小さい会社ではありますが実際にはいろいろなタイプの人間がいろいろな仕事をしているので、本当は私の意見だけに会社を代表させるわけにはいかない部分もありますが、今後数回にわけて、私が考えるコンサルティング仕事の具体的な中身や求めている人材像なんかについて書いていきたいと思います。また、求職者の方からよく質問される、起業した理由ですとか今後の事業戦略なんかについても、まとめられる範囲で書き散らしていくつもりでいます。


(文責 Ishii Akinori IT-Coordinator)




2011年1月15日土曜日

Blogの名称変更

少し前にプロフィールの文言をいじったんですが、今度はBlogのタイトルをaegif Blogからaegif CTO Blogに変えてみました。


公式Blogとしての性格が強い体裁になっていることによる書きにくさを感じる面もあったので、今後は客観的な単なる海外記事の紹介だけでなく、もう少し個人の意見を反映したようなものも書いて行ければ、と考えています。


とはいえタイトル画像の差し替えをする時間的な余裕がないので、見かけ上はほぼ何の変化もない状態になっています。折を見てタイトル画像やデザインも少し手を入れたいと思います。


(文責 Ishii Akinori IT-Coordinator)




2011年1月7日金曜日

ご無沙汰している間に

更新をさぼっていた2ヶ月間を振り返ってみると、やはりオフィスの移転が最も大きなイベントであったように思います。同じビルの中を28階から34階へ移動しただけ、なんですが、やはり引っ越しというのは大変なものです。


#インターンの受け入れも大きなイベントだった、ということにここまで書いて思い至りましたが、今回は割愛してしまいましょう。


苦節5年弱、我々はついに専用の会議スペースを手に入れました。憧れの「天井まで届く壁で覆われた」会議室です。これまでは上の方が空隙になっているサーバルーム(通称社長室)と簡易的な間仕切りで囲われた会議スペースしかありませんでしたが、今回は完全独立型の会議室の設置に成功しました。独立型過ぎて一度廊下にでて結構な距離を歩く必要がありますが、そこはご愛敬ということにしたいと思います。部屋を暗くしても誰にも迷惑がかからないため、プロジェクタも導入しました。音漏れなどをあまり気にすることなく会議に集中できます。せせこましい話で恐縮ですが、久々に会社が前に進んでいる感じ、を実感したような気がしました。(実際にはもっと意味のある変化が色々あったはずですが、やはり単純なものの方がインパクトは大きいということでしょうか)


こういう場合、オフィスの写真を掲載すべきなんだと思いますが、手元に適切なデータがないので、また今度、気がついたら対応したいと思います。



��文責 Ishii Akinori IT-Coordinator)



2011年1月6日木曜日

あけましておめでとうございます

またも、しばらく放置してしまっておりましたが、新年にあわせて再開したいと思います。


昨年末の弊社オフィスでのパーティでお声がけ頂いた皆様、今度こそ長続きするように頑張りますので暖かく見守ってください。


aegifも6期目に入りました。設立が2月22日なので、丸5周年というのはもう少しだけ先になりますが、やはりそれなりに感慨深いものがあります。最近は少し会社や自分の仕事の領域に対する慣れが悪い方向に作用してしまうことが多くなってきたように思う面もありますので、今年は意識してベンチャーらしい仕事をしていきたいと思います。


今後ともよろしくお願いいたします。


(文責 Ishii Akinori IT-Coordinator)




2010年9月28日火曜日

社員旅行2010

またも、間がかなり空いてしまいました。


忙しくなると、どうしても目前の作業ばかりが気になってしまい、長期的な視座に基づいた行動をとるのが難しくなります。Blogへの投稿が果たして、「長期的な視座」に適うものなのかどうかは難しいところかもしれませんが。


ところで、やや唐突ですが、先週末は最近ようやく「恒例」と言っても良さそうな段階に入ったと言えそうな、イージフの社員旅行でした。基本的に宿と夕飯、翌日の朝食くらいまでを押さえてあって後は現地集合現地解散、という流れです。今回は、水上高原でした。私は子連れ参加なので、ほとんど何のアクティビティにも参加していないのですが、ゴルフをやったりパラグライダーをやったりと他のメンバーはかなり活動的な週末を過ごしたようです。


若手が集まったベンチャーで、伝統的日本企業で行われていたと言われる社員旅行を再発明、、、という程の実績や野心的で派手な取り組みがあるわけではありませんが、毎回旅行準備を担当してくれているメンバは色々と頑張ってくれています。いつまで続けられるものかわかりませんが、どうせなら長く続けたいと思います。


通常ですとここで集合写真か、旅行中のハプニング映像かなにかのマルチメディア的なものを貼り付けるところですが、色気のないBlogをモットーにやっておりますので、割愛します。


(文責 Ishii Akinori IT-Coordinator)




2010年8月13日金曜日

IFRS of the day: 「現場で使えるIFRS導入の実務」好評いただいています


[From IFRS of the day: 「現場で使えるIFRS導入の実務」好評いただいています]

またしばらく放置してしまってましたが、Blogの更新を再開したいと思います。


先月末に本が出ました。同僚の野口との共著(と言っても、ほとんどすべて彼女の成果なんですが)で、日本実業出版社から「現場で使えるIFRS導入の実務」という書名で出ています。


私自身は普段は情報技術の話ばかりをしていますが、うちの会社は社長も公認会計士ですし、会計コンサルティングの会社でもあるわけです。IFRSは会計分野から派生してITの領域でも無視できない影響を及ぼすだろうと言われています。ちょうどここ数年のJSOXの動きと重ねて見ている人が多いのではないかと思います。


我々も内部統制のコンサルティングという形で本当に多くのお客様のお手伝いをさせて頂きました。その中で、「本当に内部統制のために外部コンサルを雇う必要があるのか(あったのか)」、という問いに対して、常に答えを返せるようでなければならない、と考えて来ました。直接内部統制に関する作業に携わっていない意志決定者や協力部門の責任者の方々に対して十分な説明責任を果たすことができなければ、プロジェクト作業そのものが阻害されてしまう、という実務的なレベルでの必要性もありますし、コンサルティングというサービスの根幹に関わる問題意識でもあると感じています。ここで大切なことは、仕事の全体像、その必要性、難易度などをなるべく納得しやすく伝えることで、「社内人材でできることの限界」についての同意を得ることであったと考えています。


IFRSについても同様で、まずはどのような作業を行う必要があるのか。それぞれの作業にはどういう難しさ(多くの人の同意を得なければいけない、とか、高度な専門知識を要する、とか)が含まれているのか、ということをなるべく具体的にイメージして頂きたいと思います。今回の書籍では、外部のコンサルタントを利用するかどうかはともかくとして、「プロジェクト」としての流れを現時点で可能な限りタスクのレベルまで掘り下げて記述することで、社内人材でその作業を実施できるのかできないのかを判断する材料として使ってもらうことを狙ったつもりです。(それだけが狙いというわけではありませんが)


IFRSに絡む可能性がある方は是非お手にとって頂ければと思います。


(文責 Ishii Akinori IT-Coordinator)




2010年2月27日土曜日

日本IBMとIBCSが4月に統合 - ニュース:ITpro


[From 日本IBMとIBCSが4月に統合 - ニュース:ITpro]

弊社の創立メンバ4人のうち実に3人の出身ファームであるIBMビジネスコンサルティングサービスがついに日本IBMと統合することになったそうです。


プライスウォーターハウスクーパースコンサルタントという名前の時代に就職活動をし、入社の日にPwCコンサルティングになると聞かされ、監査法人との独立性確保のためにMONDAYに社名変更するというアナウンスに目を疑い、いよいよとなったところで急遽IBMによる買収のニュースを聞く、という一連の流れを思い出します。


ファームの規模が全く違うとはいえ、ここ数年のコンサルティング業界の再編の動きがどういう結果を生むことになるのか、まだまだ先行きは不透明です。アウトソーシングビジネスの比重を高める、成果報酬型プロジェクトを実施する、などのビジネスモデルの転換についてのニュースも一段落したように思います。不景気の間にファームの統廃合が進み、業界全体の構成メンバが多少スリム化された後、結局同じようなビジネススキームが続いていくという見通しを語る方もいらっしゃいます。我々は比較的若いファームだと思うので、いわゆる従来からあるコンサルティングサービスの世界でもまだチャレンジするべき事がいくらでも残っているような気がしていますが、やはり仕事柄どのような意味であれ「同じことを繰り返していく」という方針には抵抗があります。


少しずつでもリスクをとって、自覚的に新しいことにチャレンジしていきたいと思います。


(Ishii Akinori IT−Coordinator)