SS2010 WG5 ユーザ視点 プロシーディングス

1.エンド・ユーザ自らのソフトウェア開発
利用者が自ら自分たちの望むソフトウェアを作ること、これが望ましいのはいうまでも無い。ソフトウェアは価値を生み出さなければいけない、と口々にいわれるが、利用者自らがデザインしたソフトウェアが動けば、価値に直結するだろう。なぜならそれは、業務を遂行するためのコンピューティングで、目的を達成すれば、価値を生んだといえるからだ｡
そして、安価に、簡単に、利用者が望むソフトウェアを作ることができる環境が整ってきた。これが、エンド・ユーザコンピューティングを後押しすることも間違いない。
特に、昨今の Cloud、PaaS などのサービス志向のアプローチは、難解なリレーショナル・データベースなどを使わずとも、データをストアすることができ、部品も整ってきている。
そもそも、重厚長大なソフトウェアは、かえって変化に弱く鈍重な存在であるので、Cloudのような軽いサービス志向が、エンド・ユーザの直接的な利用に向いているといえる。
しかし、過去にこの EUC は、不良債権ソフトウェアとなる、という問題を生んできた。これは、Access や Notes で利用者が作った業務ソフトウェアで、多くは個人のスキルに依存して成立していた。しかし、その作成者が不在になると、メンテナンスができず、情報システム部がフォローするということになった。これを不良債権ソフトウェアと呼んでいるが、この問題をどう解決するかが課題である。
このような、不良債権ソフトウェア化という問題を解決するアイデアとして、現在の IT 部門の人間が、利用部門に赴く、というものもある。
これは、「シャドウ IT」などと呼ばれ、実際に運用されてきた事例もある。
また､利用者中心のコンピューティングを目指すための課題として、不良債権化を上げたが、それだけではなく、もちろん利用者のスキルをいかに向上させるか、という点も大きい。
そのために、IT スキルのある情報システム部員を、利用部門に異動させ、EUC を実現するということだ。
このモデルを適用した場合、企業の情報システム部門は、その存在意義が変わることになる。情報システム部門は、無くなるというわけではないが、インフラの提供やマスター・データの管理などが中核の仕事となり、少数精鋭な部隊になるだろう。
社会も情報システムも複雑になるなか、世の中は分業化せざるを得ない環境にある。しかし、この IT 部門の人間が利用部門に行く、または IT 人材を現場に分散させるというモデ

1

ルは、分業化とは逆の、横断的なアプローチであるといえるだろう。
また、このようなエンド・ユーザ自らのコンピューティングに、Unix の Shell を使うのはどうか、という話題になった。Shell はファイルをストリーミング変換するのに適している
し、動作が軽快で、習得も現在の重厚長大な言語に比べたら、容易であろう。
また、Windows 上で動作する Cygwin であれば、Excel 等のファイルを操作することもできると思われるので、可能性は高い。
現在では、Shell のエンド・ユーザでの利用を前提に作られた、フレームワークや開発環境が無いが、これらが整備されれば現実味を帯びるだろう。

2.ユーザ企業の IT 部門のあり方
1）分業化・官僚主義の問題
ユーザ企業の IT 部門も、社会やシステムの複雑さに応じて分業化が進められている。そのため官僚的な体質になりつつあることは問題だ。
ある部門が問題を抱えていて、その解決に頭を悩ましているような場合に、隣の部門に答えがあることがしばしばある。視野を広げて、横断的に思考することが重要な鍵となる。
また、分業化が進むと、横を見ることができないだけでなく、俯瞰して物事を見ることもできなくなる傾向がある。そして、虫の目での議論に終始しているようだ。
しかし、IT はその性質上、分業化しないと事が運べないわけではない。IT こそセル生産方式のように、全工程をまかなうエンジニアを育成すべきだろう。
社内のコミュニケーションについても、SNS 等を利用して活性化することも、官僚主義的になった組織には役に立つかもしれない。SNS を社内風土変革に使うのなら、まず個人の言葉を出させるところからスタートする必要がある。そして、そこからナレッジを生み出す動力になれば、なおいい。
2）ある意味ルーズな考え方
先に、システムが不良債権化してしまうという問題を書いた。なぜ不良債権化するかという原因は、そのシステムの作りにあるともいえる。しかし、もう 1 つ何故やめてしまえないのか？という点も考える必要がある。
一度作ったシステム、一度動いてしまったフローに、イナーシャが強いことが問題だ。作

2

って使ってみたが、そろそろ止めようという発想が出てこなくてはならない。これも前述の官僚主義的な側面かも知れない。
このような、ある意味ルーズな態度は、妙味であることも多い。
システム開発において、その業務や構造は複雑で、工数は大いにかかるが、企業の中で大きな事業でなければ、作らない、という選択肢を持つことも大事だろう。手作業で人間がやればいい、という判断だ。
企業のワークフローは複雑だ。一つのパターンに決めて、申請〜決済などを作ることはできない。その案件により、だれの判断が必要であるか大きく異なる。このようなアドホッ
クな要件を定型のワークフローにのせると、かえって情報システムが企業の足を引っ張ることになる。そのくらいなら、人間系でなんとかし、最終結果や必要な証跡だけシステムに入力することで良いだろう。
しかも、企業の組織体系は頻繁に変化する。M&A や海外進出などの環境変化も激しい。そのような中で、流れを限定的にするソフトウェアは、有害であるともいえる。
かえってルーズなほうが良い。
もう１点、今回の SS2010 で気づきがあったのは、日本のソフトウェアの品質の良さ、という話だ。日本はもの作りにこだわりがあるので、どんな情報システムにでも高い品質を求める傾向にあるらしい。欧米のソフトウェア品質と比べて、コンマ１つ２つの精度の違いがある、という話もあった。
しかし、品質を高めるということはコストがかかるということだ。企業の中にはミッション・クリティカルなコアシステム以外にも様々な情報システムが存在する。そのような周辺の情報システムに過剰な品質を持たせてコストをかけることはナンセンスであろう。
このあたりも、ある意味ルーズなほうが良いのかも知れない。
さて、このような「ある意味ルーズな考え方」という話題が、何故 SS2010 WG5 ユーザ視点で出てきたのか。それは、このような、“止めてしまおう”、“作らないでおこう”、“少々品質悪くてもいいのでは”という思想は、SI ベンダーからは出にくいからだ。
当然、SI ベンダーは、システムを使ってもらって、良い品質のものを作って、なんぼ、のビジネスモデルである。しかしユーザ企業はそうではない。自社にとって最善であることを基準に考える。
このようなマインドのズレが存在するのが事実なら、やはりユーザ企業の IT 部門は自立しなければならない。
そして、もう 1 つ付記しておく必要があるのは、ユーザ企業が、上述のような「ある意味ルーズな考え方」をコンサルなどから提案を受けた場合に、もちろんそのコンサルティングの価値を認める必要がある、ということだ。

33）人員の育成
どこの企業でも人員の育成は重要課題である。さらに景気が低迷する日本にとって、最も優先して取り組むべき課題は、教育であろう。
優秀なエンジニアの条件は何か？それは、「自ら進んで学習すること」だ。これに尽きるといってもいい。
そのために必要なことは何か？それは、刺激を得ることだ。刺激を得るためには、社外に出て優秀なエンジニアや識者と接触することだ。
そうすると、その優秀なエンジニアを自分とのギャップを認識するだろう。または憧れを感じることもあるだろう。この一種のフラストレーションが、「自ら進んで学習する」という動力源になる。
このように、社外に出て人に会うということは、自分の世界が拡大することになる。そして、人と人とは自然に引き合う。これがコンピュータの世界ではコミュニティ発生のメカニズムになっている。
しかし昨今、このように社外に出て積極的に人と交わろうというメンテリティが不足していると感じる。メンテリティだけならいざ知らず、企業までもが、このような社外とのコミュニティに消極的な傾向にある。社外で学んでくることは、（夜の部の情報交換も含めて）きわめて有用であるにも関わらず、少しばかりのお金がかかることや、会社の営業日に席を空けることに対して否定的なのだ。
昔に比べて仕事がつまらない、という話はよく聞く。これは全国的な現象で特に都会で顕著ではないか。これは、自分の世界が経験とともに拡大していくということを実感できないからかも知れない。求められていることは、お金を稼ぐこと、コストを下げること、効率を上げることなどばかりだ。だから目標、夢、希望がなくなってきている気がする。
人を育てることは、決してコストではない。投資であるのだ。投資という気持ちで社外での活動をさせることを推進する風土が大事だろう。
4）ユーザ企業においての人員の評価
ユーザ企業の IT 部門は、どうあるべきか？ということを､この SS で議論をしてきた。その答えの 1 つは、プログラミングやモデリングを、ユーザ企業の IT 部門で行うというものだ。
プログラミングとモデリングは、かなりの部分で同じものである。そして、その中のモデルというものは、ユーザ企業でしかできない、という点に依拠している。

4

クラスやエンティティというものを切り出して、関係を記述することはベンダーにはできない。ベンダーにやってもらうには、逐一自社の業務や環境を説明する必要もあり、膨大なコストがかかる。
このような議論があるなか、企業の中の IT 部門の評価制度に問題があるといえそうだ。
ユーザ企業の情報システム部門で UML やデータモデルを正確に書くことができる人材は、まだ少ないが、この技術を評価する基盤が無い、つまり上司が評価しようにもその知識が無い場合が多い、ということだ。
このように、企業の IT 部門の中では、専門的な技術に関して評価システムが遅れているといえる。結果事務方が出世するという構造もあるようだ。なぜなら事務的な仕事は、その意味がわかりやすく評価がしやすいからだ。ソフトウェア・エンジニアリングを実践する、情報システム部の技術者を、評価できる部門長は少ないだろう。
これは、実は、情報システム部門の自立に対して最も大きな問題なのかも知れない。
この点に関して、アメリカでははっきりしたモデルがあるようだ。日本のように歳を取ったらマネージャではなく、マネージャは最初からマネージャとしての職が確立している。
テクニカルエンジニアもしかりで、そのスキルを評価するシステムもあるようだ。
今の日本に最も必要なのは教育であることは前述した。そこにお金をかけるだけではなく、評価システムや、社外コミュニティへの積極的な参加を推進する風土が、先に無ければいけない。
そして、その評価システムは、定量的でなくても良い。定量化、数値化は人間を窮屈にする。それでは良いアイデアの出る組織にはならないだろう。
5）無用の用人材の育成や評価について、より大きな視点で、人を窮屈にしない形が望ましいということを書いた。そして、企業が拝金主義的傾向にある中で、社会はもっと余裕がなければならないだろう。
このような議論の中、老荘の「無用の用」について議論をした。
世の中、価値を生む出すことに必死である。そして日本からイノベーションを起こしたいと願ってもいる。しかし、今の世の中余裕がないことも事実である。
世の中には無用であっても、必要なものは多いということを認識して、心に余裕を持つことが大事だ。
イノベーションを起こすような、プロダクトやビジネスモデルを創出したいと、どの経営者も思っているだろう。しかし、一朝一夕には難しい。そのためには失敗も必要である。
失敗を多く積み重ねてこそ、イノベーションは生まれるといってもよい。

5

問題は、失敗を認めないような組織風土だ。
このような近視眼的な思考に陥っていないか、現在の経営者は自分の足元を見直してみてはどうか？自分の立っている地面だけが有用な存在ではない。
無用の用は、投資でもコストでもない。それは心の余裕である。
3.クラウド時代におけるユーザ企業のありかた
クラウド・コンピューティングは、高度で難しい技術の上に成り立っている。例えば、ハード・ディスクの共有化であったり、スピードを安定させる方式であったり、バグを修正することが難しい、であったりする。
しかし、それを克服して利用に耐える基盤になったことは、人類の英知だろう。
このようなクラウド環境の中で、ユーザ企業としては何が変わるのだろうか？
まずは、企業の中の IT 部門でしかできない仕事に専念できるということがあげられる。それは、前述のように、ソフトウェア・エンジニアリングに立脚したモデリングやプログラミングだ。
逆に言えば、ハードウェアやミドルウェア、ネットワークなどはプロのベンダーにお任せをしたいところだ。
しかし、現状ではそうも行かず、ユーザ企業の IT 部門も、ある程度のハードや OS などの知識を要求される。
それは、特にハードやソフトのリプレース時に発生する。このようなリプレース時に、今まで、そのシステムに特に不満は無かったのだが、バージョンがあがるために、様々な手当をしなければならなくなるのだ。
数年利用したサーバをリプレースするような場合、当然 OS は古くなっているので、最新のバージョンを検討する。そうすると、別のミドルウェアが動作しないので、手当が必要になる。このような項目を逐一検討して、ハードウェア・ソフトウェアの見積が FIX する。
その後、機器を発注して納品されるのだが、検討開始から２〜３ヶ月かかることもある。
さて、このような作業は本来、ユーザ企業の IT 部門としては、あまりかかわりたくない。
できれば、プロに任せたい。しかし発注者であるので、ハードや OS の仕様を決めないと先に進めないのだから、やるしかない。
これらの、（我々から見たら）煩雑な作業がクラウド・コンピューティングで解決されるかも知れない。期待がかかるところだ。
また、サーバの見積〜発注〜納品に２〜３ヶ月かかるようなモデルでは、実はコンシューマ向けのサイトの運用はできない。なぜなら、一般のインターネットビジネスは、話題になると爆発的なアクセス数になることがあるからだ。数日で何倍ものアクセスになったなどという事例は沢山ある。このようなスケーラビリティに対応できるのは、クラウドでし6かありえない。
この技術革新は、ハードウェアの物理的な存在場所という意味を無くす。しかし、日本では、どこにあるか分からないサーバを使うことに抵抗があるようだ。実際日本では都会にデータセンターが建設される事例も多い。
このあたりのマインドも変える必要があるだろう。
次に、クラウドによる開発環境、いわゆる PaaS 利用について考える。
エンド・ユーザが自ら、自分たちの仕事をデザインし、コンピューティングすることの有用性について、冒頭で記述したが、これを、クラウド上のサービスの組み合わせで実現することができれば、と考えている。
現在の PaaS ビジネスは、エンド・ユーザコンピューティングに相性が良いと思われる。しかし、現在は、SI ベンダーや情報システム部門が、開発・構築をする前提でサービスが提供されている感がある。
視点を変えて、エンド・ユーザがコンピューティングする環境として、PaaS をデザインしてはどうか？

7