2014-03-06（木）第30回IT勉強宴会in新大阪 【 ソフトを他人に作らせる日本、自分で作る米国】を語ろう。案内はこちら
著者の谷島さんとは偶然Facebookでつながっていました。昨年秋に本を出されたので大阪に来られる時に勉強会に来て欲しいとお願いしていたところ、急遽実現しました。当日東京に戻られるという事でしたので、新大阪の住友電工情報システム様の会議室を貸していただきました。大変面白い会になりました。本当にありがとうございました。
25名ほど集まって頂きました。
6人が10分ずつコメントし谷島さんのコメントと質疑応答。結果21:00ぎりぎりに終わりタクシーで新大阪駅に。無事21:20の最終の新幹線に乗られたとお電話を頂きました。そのころ有志11名は近くの居酒屋さんで焼酎の一升瓶を開けていました。くつろぎ庵という居酒屋、安くて美味しくてお酒の種類も豊富でまた来たいと思います。後で聞くと住友電工情報システムのメンバも常連だとか。閉店で追い出されたあと新地に繰り出した人も・・・(笑)
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0601_sano.pdf
２．SRA阪井誠(@sakaba37)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0602_sakai.pdf
３．fusion_place 杉本啓(@sugimoto_kei)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0603_sugimoto.pdf
４．某ユーザ企業 情シス屋さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0604_jyosysya.pdf
５．あきぴー(@akipii)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0605_akipi.pdf
今は、研究員という立場になっています。記者は35歳までと言われていました。実際に気力体力が最高潮なのはその辺りまでだと実感します。過去の経験の蓄積はありますから改めて取材しなくても書ける事も多いのですが、それが正しい記者の姿とは思っていません。
1985年に日経コンピュータの記者になり、コンピュータによる業務システムを取材しました。代表作と言われているのが「動かないコンピュータ」シリーズです。取材先から叱られたり、こんな事を書くと業界に良くないなどと言われながらも続けました。
取材をする中で、コンピュータを知らない経営者にも、ほんのいくつかを知って欲しいと思うようになりました。そこで、2002年から日経ビジネスオンライン（当時は日経ビジネスエクスプレス）に連載を始めました。今も続いているそのコラムを中心にまとめ直したのが本書です。
途中、グランドデザインのところで、福田恆存（つねあり）の話を書きました。30年ほど前若いころから大変好きな評論家ですので一度書きたいと思っていました。
28年間日本のIT企業にいて、外資系に転職して２年です。外資系に入って驚いた事がこの本の中に散見されました。特に気付くのは、外資系では新しいやり方が出てくる時には必ずプロセスが同時に示される事です。本書(P.58)に日本企業が新製品を作ったから意見を欲しいと言われた外資系日本法人の社長が単純な4つの事を尋ねると答えられなかったというエピソードが出てきます。
「どういう顧客セグメントに売りますか？」「売るためのシナリオは？」「シナリオ通り行っている事をどういう指標で確認しますか？」「上手くいかなかったときのバックアッププランは？」
もちろん個々の営業マンがアレンジしますが、外資系企業では基本プロセスは上から指示されます。セールスフォースというツールもそういうプロセスがある事を前提としていますので、日本企業に提案する時はプロセスを作る所からお話することにしています。
日本では会社内部のシステムの話を他社と話する事が出来ません。そのために会社の中に入っていると他社がどうやっているのかを知る機会が極端に制限されています。コンサル会社やソフト会社はその情報格差で上手く立ち回って商売をしています。この勉強宴会のような【場】をNDAを結んだ会員制にするなどすればお役に立てるのではないかと考えています。
（２）SRA阪井誠(@sakaba37)さんの感想
http://sakaba.cocolog-nifty.com/sakaba/2014/03/post-1cef.html
IT技術者の人数に関して、米国は7割が一般企業にいて、日本は7割がIT企業にいると言う記述があります(P.12)。米国の情報システム部門の人数は日本の10倍とも書かれています(p.13)。それを時系列に整理して考えてみました。
そもそもソフトウエアエンジニアリングには、米国国防省（DoD)系と航空宇宙局（NASA)系の流れがあります。軍事も宇宙開発も予算が減ってきたので一般企業に流れたという側面があるでしょう。また、2000年前後にはインドをはじめとするオフショア開発が盛んになりました。米国のIT企業にオフショアを入れるとこの数字が正しいのでしょうか。
日本のソフトウエアは米国と較べて5～10年遅れていると言われていますが、実際は日本の方法論をマネされている事も多いです。ただ、アメリカは標準化とアピールが上手いです。米国のCMM（能力成熟度モデル）に対抗してヨーロッパはSPICE（プロセスモデル）を標準化しました。そのためCMMI（能力成熟度モデル統合）になった時にSPICEの要素を入れて単純な段階でなくなりました。それを参考に強みを生かし独自性を出す事も必要だと思います。
これからは、科学、工学、技術の統合の時代になると思います。
（３）fusion_place 杉本啓(@sugimoto_kei)さんの感想
コンピュータ以前の時代では、「仕事の仕組み」は仕事をする人が作ってきました。ところがコンピュータを前提とした仕組みは難しすぎるため、仕事をする人と仕組みを作る人が分離しました。そうするとお互いにぎくしゃくするようになりました。
・仕事をする人：自分の仕事の道具に対するオーナーシップを失っている。
思った通りに出来ていない
・IT専門家： 自分の作品に対するオーナーシップを失っている。
「仕事をする人」が言った通りに作っただけ
ITを情報の情報の整理・管理・利用に 関する技術(m-IT)と電子的情報処理及び通信に 関する技術（e-IT）に分離させてはどうでしょうか。そしてe-ITには単なるプログラミングだけでなく、EXCELのようなツールを整備します。例えば、業務領域に特化したドメイン特化プラットフォーム（DSP)が整備されると内製化も楽になります。例えば計数管理業務についてはfusion_placeというDSPを使えば問題領域だけに特化した構築が出来ます。
「仕事のプロ」、「仕組みづくりのプロ」、「道具作りのプロ」の役割を明確にすることで協働作業が可能になると考えています。
（４）住友電工情報システム 谷本收さんの感想
住友電気工業という会社は、そもそも何でも自分で作る会社です。生産管理システムも自作しています。電線・光ファイバー・アンテナや工具素材など多種多様なものを作っていますのでそれぞれに異なるシステムが必要です。そのために基本的な仕掛けに関して共通部品を作り、その上で構築しました。それが楽々フレームワークです。
谷島さんは当社の事をご存じですので、内製企業の話になった時に当社も書いて下さるかと期待したのですが、書かれてなくて残念に思いました。
2007年に住友電装を子会社化しました。そこは自動車のワイヤーハーネスを作っている企業です。この業界は早くからグローバル化しているとともに、技術革新が速いため次々に新しいシステムが必要になります。手作りする時間を節約するために多少高くついても外から買っています。
今も、新しい言葉が次々に現れますが、どう解釈するかの判断が難しいことがあります。日経さんには方向づけにも期待したいと思います。
（５）某企業 情シス屋さんの感想
ユーザ企業の情報システム部の部長です。この本は「どちらが良いと言ってるわけではない」とは言われながらも「何故内製出来ないのだ」と叱られているのだと思って読みました。私の部には、手作りをするための部も設けています。私が若いころに最初から最後まで一人でやらせてもらった経験が今の自分を作っているのだと思います。そのため若い人たちには全行程を一人でやってもらうようにしています。
ソフト会社の方は、システム構築というと設計から開発だと考えると思いますが、実際にはそれらはほんの小さな部分です。企画から立案し、利害調整を行ったりデータ移行やマスタセットなど雑多な作業が数多くあります。ドラマはそういう所にこそあります。
ところが若い人の多くは、リスクを恐れるためなのか自分で作るよりも外部から調達しようとする傾向があります。「内製でやりたい」という”情シス屋”を増やしたいと思っています。そのためにどう動機づけすればよいのかを試行錯誤しています。
（６）あきぴー(@akipii)さんの感想
http://forza.cocolog-nifty.com/blog/2014/03/30itit-c132.html
日本のユーザ企業内のIT分野の問題（課題）として3点を強く考えています。まず、「ロールが多すぎる」事。最終決定者が誰なのか曖昧で、会議で議論しても意見がまとまりません。次に「開発プロセスがIT化されていない」事。重要なプロセスはEXCELで管理している事が実態です。最後に「ERPが陳腐化しやすい」事。5年経つと必ずリプレース作業が発生して手間がかかります。
設計手法は色々ありますが、最も重要なのは現在のシステムからリバースエンジニアリングする作業じゃないかと思います。その時にはUMLは役に立たないので、DOAが有用ではないかと考えています。
・一番の違いはConceptual Skill（概念化能力）の違いかなと思います。米国は抽象的な話でも延々と議論します。日本人は何故何故のように、下に向かって深堀することは得意ですが、上に向かって複雑な事象を概念化する事は弱いと思います。
・そのスキルが強いのは一神教だからかも知れません。
・プロセスを明確にするというのは、労働者の流動性の問題だと思います。「Bさんがいなくなればどうするの？」という危機感は日本より米国の方が強いです。
・IT技術者の日米比較は他の方からも日経がちゃんと調査して欲しいと言われています。
・コンピュータの発明は戦争の弾道計算です。それ以降もコンピュータの進化は軍事的なものが中心ですから厳しさが違うのかも知れません。
・杉本さんの話は原稿が書けるほどだと感じました。
・Conceptualといっても一番重要なツールは言葉です。超高速開発という言葉も、何をメリットとするのかが明確でなければ意味がありません。
・昔、イノベーターと言われている7名に「あなたはどうして成功出来たのでしょう？」と聞いていくという企画をしました。すると全員が「若いころ全行程を経験させてもらった」と異口同音に仰るので原稿をどう書くか困った事があります。企画して設計して製造して販売ルートを探して値決めして販売してという全行程を経験するとビジネス全体の感が働くようになるのかも知れません。
・インテグリティという言葉は、ドラッガーの翻訳者の上田さんは「真摯さ」と訳されましたが、データのインテグリティという言葉もあるように一貫性・完全性というニュアンスもあります。日本語にすると騎士道とか武士道が近いのかも知れません。
・日本は20年もすれば間違いなく人口が減少します。ITスキル以前に人数が足りなくなります。そのため企業はIT技術者を雇うことになるだろうと考えています。
情シス屋さんのお話は特に面白く感じました。私がこの勉強宴会を続けているのも若いSEさんが、情シス屋になるきっかけになって欲しいという気持ちがあります。ただ、ユーザ企業は明文化されていない（出来ない）守秘義務の壁を感じている方が多いため気軽に参加されないのが残念です。この情シス屋さんが匿名希望なのもその表れでしょう。昔ベストセラーになった、バカの壁なのだと思いますが、大企業になればなるほど厳しくなっているのも事実です。
守秘義務の問題だけでなく、自社のシステムが恥ずかしいと思っている企業も多いです。ご自分の会社のシステム内容を話せば、どの企業も似たような悩みがあることがわかるでしょうし、恐らく内製化へのきっかけにしやすいと思います。でも日本では当面難しいでしょう。
以上
著者の谷島さんとは偶然Facebookでつながっていました。昨年秋に本を出されたので大阪に来られる時に勉強会に来て欲しいとお願いしていたところ、急遽実現しました。当日東京に戻られるという事でしたので、新大阪の住友電工情報システム様の会議室を貸していただきました。大変面白い会になりました。本当にありがとうございました。
25名ほど集まって頂きました。
6人が10分ずつコメントし谷島さんのコメントと質疑応答。結果21:00ぎりぎりに終わりタクシーで新大阪駅に。無事21:20の最終の新幹線に乗られたとお電話を頂きました。そのころ有志11名は近くの居酒屋さんで焼酎の一升瓶を開けていました。くつろぎ庵という居酒屋、安くて美味しくてお酒の種類も豊富でまた来たいと思います。後で聞くと住友電工情報システムのメンバも常連だとか。閉店で追い出されたあと新地に繰り出した人も・・・(笑)
＜今回の勉強宴会資料＞
１．佐野(@hatsanhat)の感想http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0601_sano.pdf
２．SRA阪井誠(@sakaba37)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0602_sakai.pdf
３．fusion_place 杉本啓(@sugimoto_kei)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0603_sugimoto.pdf
４．某ユーザ企業 情シス屋さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0604_jyosysya.pdf
５．あきぴー(@akipii)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0605_akipi.pdf
＜出版の目的と背景＞
日経ＢＰ 谷島宣之さん今は、研究員という立場になっています。記者は35歳までと言われていました。実際に気力体力が最高潮なのはその辺りまでだと実感します。過去の経験の蓄積はありますから改めて取材しなくても書ける事も多いのですが、それが正しい記者の姿とは思っていません。
1985年に日経コンピュータの記者になり、コンピュータによる業務システムを取材しました。代表作と言われているのが「動かないコンピュータ」シリーズです。取材先から叱られたり、こんな事を書くと業界に良くないなどと言われながらも続けました。
取材をする中で、コンピュータを知らない経営者にも、ほんのいくつかを知って欲しいと思うようになりました。そこで、2002年から日経ビジネスオンライン（当時は日経ビジネスエクスプレス）に連載を始めました。今も続いているそのコラムを中心にまとめ直したのが本書です。
途中、グランドデザインのところで、福田恆存（つねあり）の話を書きました。30年ほど前若いころから大変好きな評論家ですので一度書きたいと思っていました。
＜本の感想や想い＞
（１）セールスフォース 佐野初夫の感想28年間日本のIT企業にいて、外資系に転職して２年です。外資系に入って驚いた事がこの本の中に散見されました。特に気付くのは、外資系では新しいやり方が出てくる時には必ずプロセスが同時に示される事です。本書(P.58)に日本企業が新製品を作ったから意見を欲しいと言われた外資系日本法人の社長が単純な4つの事を尋ねると答えられなかったというエピソードが出てきます。
「どういう顧客セグメントに売りますか？」「売るためのシナリオは？」「シナリオ通り行っている事をどういう指標で確認しますか？」「上手くいかなかったときのバックアッププランは？」
もちろん個々の営業マンがアレンジしますが、外資系企業では基本プロセスは上から指示されます。セールスフォースというツールもそういうプロセスがある事を前提としていますので、日本企業に提案する時はプロセスを作る所からお話することにしています。
日本では会社内部のシステムの話を他社と話する事が出来ません。そのために会社の中に入っていると他社がどうやっているのかを知る機会が極端に制限されています。コンサル会社やソフト会社はその情報格差で上手く立ち回って商売をしています。この勉強宴会のような【場】をNDAを結んだ会員制にするなどすればお役に立てるのではないかと考えています。
（２）SRA阪井誠(@sakaba37)さんの感想
http://sakaba.cocolog-nifty.com/sakaba/2014/03/post-1cef.html
IT技術者の人数に関して、米国は7割が一般企業にいて、日本は7割がIT企業にいると言う記述があります(P.12)。米国の情報システム部門の人数は日本の10倍とも書かれています(p.13)。それを時系列に整理して考えてみました。
そもそもソフトウエアエンジニアリングには、米国国防省（DoD)系と航空宇宙局（NASA)系の流れがあります。軍事も宇宙開発も予算が減ってきたので一般企業に流れたという側面があるでしょう。また、2000年前後にはインドをはじめとするオフショア開発が盛んになりました。米国のIT企業にオフショアを入れるとこの数字が正しいのでしょうか。
日本のソフトウエアは米国と較べて5～10年遅れていると言われていますが、実際は日本の方法論をマネされている事も多いです。ただ、アメリカは標準化とアピールが上手いです。米国のCMM（能力成熟度モデル）に対抗してヨーロッパはSPICE（プロセスモデル）を標準化しました。そのためCMMI（能力成熟度モデル統合）になった時にSPICEの要素を入れて単純な段階でなくなりました。それを参考に強みを生かし独自性を出す事も必要だと思います。
これからは、科学、工学、技術の統合の時代になると思います。
（３）fusion_place 杉本啓(@sugimoto_kei)さんの感想
コンピュータ以前の時代では、「仕事の仕組み」は仕事をする人が作ってきました。ところがコンピュータを前提とした仕組みは難しすぎるため、仕事をする人と仕組みを作る人が分離しました。そうするとお互いにぎくしゃくするようになりました。
・仕事をする人：自分の仕事の道具に対するオーナーシップを失っている。
思った通りに出来ていない
・IT専門家： 自分の作品に対するオーナーシップを失っている。
「仕事をする人」が言った通りに作っただけ
ITを情報の情報の整理・管理・利用に 関する技術(m-IT)と電子的情報処理及び通信に 関する技術（e-IT）に分離させてはどうでしょうか。そしてe-ITには単なるプログラミングだけでなく、EXCELのようなツールを整備します。例えば、業務領域に特化したドメイン特化プラットフォーム（DSP)が整備されると内製化も楽になります。例えば計数管理業務についてはfusion_placeというDSPを使えば問題領域だけに特化した構築が出来ます。
「仕事のプロ」、「仕組みづくりのプロ」、「道具作りのプロ」の役割を明確にすることで協働作業が可能になると考えています。
（４）住友電工情報システム 谷本收さんの感想
住友電気工業という会社は、そもそも何でも自分で作る会社です。生産管理システムも自作しています。電線・光ファイバー・アンテナや工具素材など多種多様なものを作っていますのでそれぞれに異なるシステムが必要です。そのために基本的な仕掛けに関して共通部品を作り、その上で構築しました。それが楽々フレームワークです。
谷島さんは当社の事をご存じですので、内製企業の話になった時に当社も書いて下さるかと期待したのですが、書かれてなくて残念に思いました。
2007年に住友電装を子会社化しました。そこは自動車のワイヤーハーネスを作っている企業です。この業界は早くからグローバル化しているとともに、技術革新が速いため次々に新しいシステムが必要になります。手作りする時間を節約するために多少高くついても外から買っています。
今も、新しい言葉が次々に現れますが、どう解釈するかの判断が難しいことがあります。日経さんには方向づけにも期待したいと思います。
（５）某企業 情シス屋さんの感想
ユーザ企業の情報システム部の部長です。この本は「どちらが良いと言ってるわけではない」とは言われながらも「何故内製出来ないのだ」と叱られているのだと思って読みました。私の部には、手作りをするための部も設けています。私が若いころに最初から最後まで一人でやらせてもらった経験が今の自分を作っているのだと思います。そのため若い人たちには全行程を一人でやってもらうようにしています。
ソフト会社の方は、システム構築というと設計から開発だと考えると思いますが、実際にはそれらはほんの小さな部分です。企画から立案し、利害調整を行ったりデータ移行やマスタセットなど雑多な作業が数多くあります。ドラマはそういう所にこそあります。
ところが若い人の多くは、リスクを恐れるためなのか自分で作るよりも外部から調達しようとする傾向があります。「内製でやりたい」という”情シス屋”を増やしたいと思っています。そのためにどう動機づけすればよいのかを試行錯誤しています。
（６）あきぴー(@akipii)さんの感想
http://forza.cocolog-nifty.com/blog/2014/03/30itit-c132.html
日本のユーザ企業内のIT分野の問題（課題）として3点を強く考えています。まず、「ロールが多すぎる」事。最終決定者が誰なのか曖昧で、会議で議論しても意見がまとまりません。次に「開発プロセスがIT化されていない」事。重要なプロセスはEXCELで管理している事が実態です。最後に「ERPが陳腐化しやすい」事。5年経つと必ずリプレース作業が発生して手間がかかります。
設計手法は色々ありますが、最も重要なのは現在のシステムからリバースエンジニアリングする作業じゃないかと思います。その時にはUMLは役に立たないので、DOAが有用ではないかと考えています。
＜感想に関するコメントと質疑応答＞
・テーマは日本と米国の違いです。どちらが良いという事ではありません。決定的な違いはありますが、良い部分があるなら普通に学べば良いだけです。・一番の違いはConceptual Skill（概念化能力）の違いかなと思います。米国は抽象的な話でも延々と議論します。日本人は何故何故のように、下に向かって深堀することは得意ですが、上に向かって複雑な事象を概念化する事は弱いと思います。
・そのスキルが強いのは一神教だからかも知れません。
・プロセスを明確にするというのは、労働者の流動性の問題だと思います。「Bさんがいなくなればどうするの？」という危機感は日本より米国の方が強いです。
・IT技術者の日米比較は他の方からも日経がちゃんと調査して欲しいと言われています。
・コンピュータの発明は戦争の弾道計算です。それ以降もコンピュータの進化は軍事的なものが中心ですから厳しさが違うのかも知れません。
・杉本さんの話は原稿が書けるほどだと感じました。
・Conceptualといっても一番重要なツールは言葉です。超高速開発という言葉も、何をメリットとするのかが明確でなければ意味がありません。
・昔、イノベーターと言われている7名に「あなたはどうして成功出来たのでしょう？」と聞いていくという企画をしました。すると全員が「若いころ全行程を経験させてもらった」と異口同音に仰るので原稿をどう書くか困った事があります。企画して設計して製造して販売ルートを探して値決めして販売してという全行程を経験するとビジネス全体の感が働くようになるのかも知れません。
・インテグリティという言葉は、ドラッガーの翻訳者の上田さんは「真摯さ」と訳されましたが、データのインテグリティという言葉もあるように一貫性・完全性というニュアンスもあります。日本語にすると騎士道とか武士道が近いのかも知れません。
・日本は20年もすれば間違いなく人口が減少します。ITスキル以前に人数が足りなくなります。そのため企業はIT技術者を雇うことになるだろうと考えています。
＜所感＞
多少無茶な企画かとも思いましたが、発表者は皆さん知り合いですので何の心配もしませんでした。想像以上に面白い会になりました。約3時間でしたが、倍の時間があっても良かったほどでした。谷島さんには初めてお会いしました。遠慮がちに訥々と語られる口調に味があって楽しかったです。情シス屋さんのお話は特に面白く感じました。私がこの勉強宴会を続けているのも若いSEさんが、情シス屋になるきっかけになって欲しいという気持ちがあります。ただ、ユーザ企業は明文化されていない（出来ない）守秘義務の壁を感じている方が多いため気軽に参加されないのが残念です。この情シス屋さんが匿名希望なのもその表れでしょう。昔ベストセラーになった、バカの壁なのだと思いますが、大企業になればなるほど厳しくなっているのも事実です。
守秘義務の問題だけでなく、自社のシステムが恥ずかしいと思っている企業も多いです。ご自分の会社のシステム内容を話せば、どの企業も似たような悩みがあることがわかるでしょうし、恐らく内製化へのきっかけにしやすいと思います。でも日本では当面難しいでしょう。
以上