うんこめも

自律分散うんこ製造システムに関する考察メモ

Java Day Tokyo 2013にいってきたお話

5/14に日本オラクル主催のJava Day Tokyo 2013に参加するため秋葉原にいってきました。
Java Day Tokyo 2013


自分はまだJavaのことをなにも知らないんなあ、と感じてなかなか有益だったので簡単にそのメモを書いておきます。


キーノートではOracle本社のvice presidentが何人もきて今年9月にリリースされる予定のJava SE 8についての概要が紹介され、午後にはそれぞれのセッションで細かい話があるという流れです。

2時間のキーノートを一行でまとめると、ラムダ式を使って簡潔にコードを書こうぜ、Java Swingの後継であるJava FX8を使えばリッチなアプリケーションを簡単に書けるよ、Java Embeddedで組み込みがイケてるぜ、という感じでした。


組み込みもJava

特に、組み込みはRaspberry Piという3000円ほどの基盤を使えば驚くほど簡単にものがつくれるということで良いです。昔、LEGOのマインドストームでCっぽい謎言語で書いて動かしたときはわりと難しかったのですが、それよりもかなり簡単に書けそうな印象です。カメラやethernet端子もついていて、簡単に製品のモックアップがつくれそう。
ぱっと思いつくところでは、ストーキング用の製品かヘルスケアの監視系かでおもしろいことできそうかなと思ってます。身近だとArduinoやってる人は多そうだけれど、どっちがよいのでしょうか。日本語情報や関連製品はArduinoのほうが多いけれどCライクな言語でしか書けない?のが違う。ハッカソンぽい感じで議論してつくっていくと楽しそうです。
>みなさま
こんどやりましょう。



エスケープフロムレガシーJava

現場を支えているのは一部の優秀なエンジニアだが、このままでは空洞化するしJava EEをつかってレガシーを脱却しましょうというお話。

struts1がEOLを迎えたけれど、まだ使っているところも多いです。
Apache Struts 1 EOL Announcement

きちんとサポートされるものに移行するべきなのですが、そう簡単に移行できるはずもありません。コストがかけられなかったり、自社フレームワークに組み込まれていたりと・・・。


最新のJava EE 6 では各サードパーティフレームワークが提供していた機能を自前でもっているのでサードパーティフレームワークを使わなくてすむので綺麗に書けるし生産性高いし全部公式なので安心なのだそうです。
JSFコンポーネントベースに記述して、CDI(Context Dependency Injection)するなどなど。Java EEは機能が複雑だなと思ってるけれどよく考えるとSpringの複雑さもたいがいだし全部公式で書けるならそれがいいのかもしれません。Oracleのなかの人が言っていることをさっ引いても、JavaEEは良さそうだなと思います。

ただ、いま動いているシステムから移行するコストがあることと、難しいJava EEが分かる人材が確保できないなど課題は多そう。レガシーJavaJava EEシステムにマイグレーションする方法とか考えてみたい。


とりあえずStruts1をつかってる独自フレームワークなんとかしてほしい。よっぽど特殊かドメインが限定されているので無い限り、独自フレームワークとか独自標準化とか技術やプロセスの進化や保守コストをあまり考慮してない気がしてよくない。。


Javaでソフトウェアつくろう

この頃はできるエンジニアの方々はみな軽量言語か関数型のかっこいい言語をつかっている印象がありますが、Javaもまだまだ進化しています。みんなJava書きましょう。
Java EEも含めると仕様が肥大化している気がしないではないですが、Oracleが公式に標準化してやっていることを考えるとちょっと安心感はあります。)


資産も多いし、エンジニアも多いです(ただしry)。
まだ会社で使用するJavaをバージョンアップはできないかなという感じですがどれもおもしろそうで試してみたい。


ただ、お仕事ではSE8を使うのはまだまだ先でしょうか。*1
これを使うためのシステムと考えると順序は逆になりますが、生産性をあげて楽しく開発するためにも勉強し解きたいです。

Beginning Java EE 6 GlassFish 3で始めるエンタープライズJava (Programmer’s SELECTION)

Beginning Java EE 6 GlassFish 3で始めるエンタープライズJava (Programmer’s SELECTION)


その他

Javaでマルチスレッドもかなりすごい。並列処理を実装するならこの記事のスライドと動画は一見の価値あり。
Concurrency Utilities for EE 7 | 寺田 佳央 - Yoshio Terada



18時以降にあったJava the Nightはスタッフさんに聞いたら表彰とかコミュニティ活動とかです、とのことだったので帰ってしまったけれどタイムラインをみてるとおもしろそうだったので勿体ないことをしたかも。



以上、簡単ですが参加メモ。今回は聴くだけだったので次回は「Java EEに移行してみてわかったこと」とかやれるようになりたいです。


さらにその他の日記

会場のアキバでは平日の昼から客引きのメイドさんがたくさんいるしAKBカフェも並んでいるしなかなか文化的でした。客引きのメイドさんに絡んでいる中学生くらいに見える童顔の少年が印象に残っています。


お昼は駅のそばにある麺処MAZERU。二郎インスパイアな油そば?チーズや野菜マシのトッピングが無料ですてきですが、濃い。。
f:id:daaaaaai:20130519173005j:plain



夕食はなぜか神田の天下一品に。
たまに天一が食べたくて食べたくて仕方ないときありますよね。この日はまさにそんな日でした。
そして今日は体のためにもスープは飲まないでおこう、と思っていても気付いたら全部飲んでいるというのもお約束です。こってりとはいっても油っぽさがあまりなくて野菜な旨味が好き。
f:id:daaaaaai:20130519172948j:plain



あと会場のUDXでは同じフロアに東京アニメセンターなる施設があって「俺の妹がこんなに可愛いわけがない」展を無料でやっていたので昼休憩に寄ってみました。
f:id:daaaaaai:20130519172932j:plain

Java Day Tokyoに行ってきてすごく勉強になった、という話をFacebookにこの写真と合わせてポストしたら、普段の倍以上のいいね!がついて困惑しております。

*1:バージョンアップした場合に現行のアプリケーションが正しく動く保証がとれないため・・・。Ruby2.0ほど性能面の差がないのでそこを確認するコストのほうが大きくなる。マルチスレッドでスケールさせるなら別かもだけれど

Facebookのなりすましが5/18から増えている件についてメモ

Facebookでなりすましアカウントが量産されている感じなので、ちょっと調べてみた。
あんまり記事にまでなっているものがなさそうなので拙いけれど、ブログに書いてみます。


**


昨日、ある友人からFacebookのリクエストがきた。
けれどその友人はすでにFacebookやっている。おかしいなと思いそのアカウントを調べると、IDと表示名が異なるし、5.17の15時ごろにつくられたアカウントであることからなりすましっぽい。そしてご本人の友人に片端からリクエストを投げている。なかには承認してしまっているひともいる。


怖いなと思っていろいろ調べてみると、一昨日から類似の事例が何件もあって昨日の夜に急増しているみたい。


自分のFacebook上でも3件あった。(1件は友人で、2件は友人がシェアしてた)
気持ち悪い共通点があったので簡単にまとめてみる。

  • 登録名は漢字
  • 名前は女性だが登録している性別は男性
  • ID(URIに含まれる名前)と登録名が異なっている。
  • アイコンはディズニー系。プーさんの絵とか、ドナルドの写真とか。
  • 作成されたのは5.18の午後。
  • 本人の友だちにリクエストを送りまくっている。友だちは5.19時点で50人ほど。


本人はYamada Hanakoみたいに登録しているのに、なりすましは山田花子みたいに登録しているケースもある。
なかには、本当は華子だけれど花子みたいになっているケースもあるらしい。

また、なりすまされた本人の友だちでない人も承認しているのでなぜだろうと調べてみると、もともと同姓同名の別人が友だちにいることを発見。2名しか確認してないけれど2名とも。名前がアルファベットか漢字かで違うということについても、手動で設定したからではなくて誰か1名の名前をコピーして、Facebookの検索ででてくる同姓同名の人の友だちにリクエストを送ってるのかもしれない。


Twitterで検索して出てきた類似案件。5/17の夜から発生している様子。
これまでの人手で単発のなりすましとはちょっと違いそう。


とりあえずそういうアカウントを見つけたら、歯車マークの「報告・ブロックする」から、なりすましているということを本人とFacebook社に報告しましょう。

参考:気味が悪いです。 私の名前でFacebookをやり始めて、私の友達全員に友達申請を送... - Yahoo!知恵袋

参考:Facebookのニュースフィード表示アルゴリズムのメモ - うんこめも

3月・4月に読んだ本

先々月に書いたのに続いて読んだ本の棚卸しをする。恥ずかしいのは除いてます。
1月・2月に読んだ本 - うんこめも



まず個別に記事を書いたのが3冊。ノンフィクション2冊とビジネス書1冊。ただし小学生並の感想*1
(読書メモ)日本をもっとも知っていた男のドラマ「旅する巨人 宮本常一と渋沢敬三」 - うんこめも

(読書メモ)「NASAを築いた人と技術」 -組織の文化とプロジェクトマネジメントについて - うんこめも

(読書メモ)「ソフトウェア企業の競争戦略」 - うんこめも



その他のものについて簡単に。

ハチはなぜ大量死したのか

ただの虫だと思っていたハチ。実は蜂蜜をつくるだけでなくこいつがいなければ多くの作物は受粉できず実を結ばないために人間と密接なつながりをもっている昆虫である。
そのハチが危機に陥っている。原因はダニか、病原菌か、農薬か、ストレスか。これを追っていく前半部は探偵もののようなスリリングなおもしろさがあるけれど、後半部にこそ価値がある。自然をコントロールしてきたと思っていた人間と、コントロールできないほど複雑な社会性と生態を進化させたハチを主人公に現代社会の問題をえぐり出す傑作ノンフィクション。

ちなみに原題は「Fruitless Autumn」。これはレイチェル・カーソン沈黙の春と対比される壮大なタイトルなんだけれど、なぜ「ハチはなぜ大量死したのか」という控えめで虫好きしか手に取らなさそうなタイトルにしたんだろう。「空疎な秋」とかでも良い気がする。
科学ものとしてはサイモン・シンと並ぶくらい読ませる。けれど、終盤、すこしだけ沈黙の春ばりに煽りが入っているところもあることに注意。ゆったりハチを飼えるくらいのところで生活してみたい。

ハチはなぜ大量死したのか (文春文庫)

ハチはなぜ大量死したのか (文春文庫)



常時結合によるシステム開発効率化ガイド

CIの利点とそのプロジェクトへの導入方法。なぜかantとCruiseControl、Go。
プロジェクト管理に必須のCIの考え方をざっくり分かりやすく解説している。ただサンプルやツールの紹介が多くて薄い気も・・・。
一番難しいのは、長く稼働しているシステムに自動テストを導入することかな。。

常時結合によるシステム開発効率化ガイド

常時結合によるシステム開発効率化ガイド



たったひとつの冴えたやり方

この名著との名高い古典的SFをいまだに読んだことがなかった・・・。
中身は、地球外生命体とのファーストコンタクトで、知性の描き方が人間本位であれなのだけれど、それは仕方ない。結末はすぐに予想できるものではあるけれど、やっぱり読んでみると悲しいような、前向きなような不思議な感覚になる。
ちなみに原題は「The Starry Rift」これも作中の大事な言葉なのだけれど、これを作中で使われる台詞の「たった一つの冴えたやり方」に変えたのは翻訳者の妙だと思う。
Sniperを「山猫は眠らない」に訳すくらいいい。

参考 この邦題をつけたのは誰だあっ! 映画邦題ベスト10&ワースト10 カゲヒナタのレビュー


ちなみにこの台詞、英語では「It's the only Neat thing to do.」と書くらしい。

たったひとつの冴えたやりかた 改訳版

たったひとつの冴えたやりかた 改訳版





もうちょっと読みたい本があったけれど、某資格の勉強であまり時間がとれなかった。
以下、マンガ。

山賊ダイアリー

絵はさておき、猟師の日常をたんたんと描いている良マンガ。雰囲気や伝え方としては「僕は猟師になった」のほうがいい味がでていて好きだけれど、猟銃のことが書いてあるのはおもしろいし岡山の山や狩猟者たちの様子が楽しい。エアライフル使ってみたい。今年度は狩猟免許とってみよう。

山賊ダイアリー(1): 1 (イブニングKC)

山賊ダイアリー(1): 1 (イブニングKC)



海街dialy 吉田秋生

吉田秋生のはBL色があるとされるBANANA FISHしか読んだことがなかった。それで先入観があったけれど、良い。うまく説明できないのだけれど、親の不倫・離婚、病気など重いものをモチーフにしつつも明るさと前向きさがある。
多数の登場人物が出てくるオムニバスを、相互の感情を流れるように描いてここまでうまくつくれるのは天才、これだけ書ける人はほかに知らない。
ただ、読んでいて、凡庸な生き方・働き方・人との関わり方をしている自分の人生がすこし物足りないのではという思いがすこし出てくる。幸せなことではあるしマンガの読み過ぎだけれど。

海街diary 1 蝉時雨のやむ頃

海街diary 1 蝉時雨のやむ頃


銃夢 Last Order18巻

これは未だに購読している数少ないマンガのひとつ。ジャンルは狂気の宇宙SF格闘仏教マンガ。たぶん。
18巻では前巻までの壮大さは影を潜めて前シリーズのような個人の狂気に話が移っている。カポエラナースのケイナちゃんが可愛い(そして以下略)

銃夢 Last Order NEW EDITION(1) (KCデラックス)

銃夢 Last Order NEW EDITION(1) (KCデラックス)




アニメでは、第一印象を裏切られてスタードライバーがすごくおもしろかった。
けれどあまりうまく説明できないし感想も書けないのでまたこんど・・・



関連記事:
新社会人がGWに読むべき働くことについてのマンガ6冊 - うんこめも

*1:最近のネットではこれを(小並感)と書くらしい

(読書メモ)日本をもっとも知っていた男のドラマ「旅する巨人 宮本常一と渋沢敬三」

長くウガンダにてフィールドワークしていた美少女から薦められた「忘れられた日本人」を読んだのは3年前。つい数十年前の日本には自分が想像もできないような生活をしていた人々がいたことに衝撃を受けた。それを書いた宮本常一はどんな学者だったのだろうと気になってるところに佐野眞一による本書を発見したのが手に取るきっかけ。



宮本常一は長く在野の民俗学者として、病弱な体を押し4000日以上日本各地を歩き続け、1200軒以上の民家に宿泊している。

その希代の民俗学者である宮本と、財閥の御曹司として生まれ、本人の希望とは別に日本銀行総裁や大蔵大臣を勤めるまでになりながらも自身も民俗学者であった渋沢敬三の人生。本書は佐野眞一によるこの2人を描いていた大宅壮一ノンフィクション賞受賞作で本当にいい作品。民俗学・人類学に興味がない人でも手にとって欲しい。

旅する巨人―宮本常一と渋沢敬三 (文春文庫)

旅する巨人―宮本常一と渋沢敬三 (文春文庫)



深い知識と観察眼、そして古老たちから話を聞き出す愛嬌と情熱をもっていた宮本は、これまでの柳田民俗学とは異なる現地に根ざした独自の民俗学を切り開いてきた。学問だけでなく農業技術を各地に広め、経国済民を地で行った人。司馬遼太郎に日本で学問をしている2人のうちの1人で恐ろしい人と評されるまでになっていて多くの村、多くの人に影響を与えている。そして家の重圧を受けながらも民俗学者として成果を出し、パトロンとして宮本や多くの学者を見出し、導いた渋沢。もうこれはロマンですよ。大河ドラマ
宮本の考え方や人柄、周囲の人々との相互作用を読んでいると、この人が日本にいて急速に失われつつあった漁村や農村の情報をまとめたのは奇跡的だと思える。

小さいときに美しい思い出をたくさん作っておくことだ。それが生きる力になる。学校を出てどこかへ勤めるようになると、もうこんなに歩いたり遊んだりできなくなる。いそがしく働いてひといきいれるとき、ふっと、青い空や夕日のあった山が心にうかんでくると、それが元気を出させるもとになる(宮本常一,p58)

20代のころ、大阪泉南で教員をしていたころの言葉。



この伝記では、宮本と渋沢その人の人生のおもしろさだけでなく、その人を通して感じることの出来る激動の歴史も感じることができる。特に宮本も渋沢も絡んでいないとはいえ、大東亜共栄圏の統治手段のために重視されていた民俗学の絡みで、岩畔豪雄の陸軍中野学校や昭和通商、西北研究所それにつながっていた川喜田二郎や梅棹忠雄なども出てくるところは、燃える。

それ以外にも戦争中に村々をまわるとスパイ呼ばわりされる宮本常一。終戦時に大蔵大臣としてインフレと戦った渋沢敬三。経済発展で急速に失われる独自の文化と、その寵児、田中角栄も出てくる。


本書はおもしろいだけでなく読みやすいのでおすすめです。著者の佐野眞一は、最近は橋下徹市長のノンフィクションで叩かれていたけれど、かなりすぐれたノンフィクション作家なのでみんな読むべき。

忘れられた日本人 (岩波文庫)

忘れられた日本人 (岩波文庫)


おまけ:本文中に出てきてメモった言葉

大事なことは主流にならぬことだ。傍流でよく状況をみていくことだ。舞台で主役をつとめていると、多くのものを見逃してしまう。その見逃されたもののなかにこそ大切なものがある。それを見つけてゆくことだ。人の喜びを自分も本当に喜べるようになることだ。人がすぐれて仕事をしているとケチをつけるものも多いがそういうことはどんな場合にもつつしまなければならぬ。また人の邪魔をしてはいけない。自分がその場で必要を認められないときは黙ってしかも人の気にならないようにそこにいることだ(渋沢敬三,p88)

財界でも学界でも中心に居てはいけない。いつも少し離れたところに居るべきだ。そうしないと渦のなかに巻き込まれてしまう。そして自分を見失う(渋沢敬三,p184)

銀行屋というものは、小学校の先生みたいなものです。いい仕事をしてだんだん成長した姿を見て、うれしく思うというのが、本当の銀行屋だと思いますね。えらくなるのは生徒です。先生じゃない(渋沢敬三、p160)

名銀行家であり名伯楽でもあったらしい。


昭和二十八年離島振興法という法律が出来て、十二年になり、二十八年に七億ほどの離島予算が昭和四十年には九十億をこえるにいたったのだから、島民にとって結構なことのように思えるが、私には多くの危惧の念がある。その一つはどうも無駄遣いが多すぎるように思えるのである。田舎では貧乏なものが多少金を持つと、何はさておいても家の改築をはじめる。そして外見のよそをきそう。離島振興の実情を見ていると、それに似た現象がきわめて多い。家だけは立派になっているのが生産の方は大してのびていないといった姿である。もっと再生産のための設備投資に本気になれないものか。これではいつまでたっても島が本質的な力で本土に追いつく日はない。(宮本常一,1965年,「日本の離島」第二集あとがきより孫引き)

離島振興法は、その成立のために宮本も尽力している。これを成長まっただ中の1965年に指摘しているというのは慧眼と思う。


「就職するな。遊べ」「給料をもらうと堕落する。眠っていても金が入ってくるからだ。(宮本常一,p423)」

うーん。。

(読書メモ)「NASAを築いた人と技術」 -組織の文化とプロジェクトマネジメントについて

なぜ人はNASAに憧れるのだろう。
NASA、米国航空宇宙局は69年の月面着陸という前人未踏の偉業やアポロ13号の成功した失敗などのプロジェクトを担った科学技術の最先端の機関として絶対的なきらめきとブランドをもっている。


けっして通販番組で登場する「洗剤」だけでない。
中学生のころは、CIAとかFBIと同じように漠然とした憧れであったけれど、大学にいるころには、あれだけ巨大で高度なプロジェクトをどうやって成功させたんだろう、どんな組織なんだろう、と興味がわいてきた。


佐藤靖による「NASAを築いた人と技術」はそんな興味に応える良著。
副題の「巨大システム開発の技術文化」からもわかるようにその偉業をなしとげた技術の文化とその組織について解説している。



NASAを築いた人と技術―巨大システム開発の技術文化

NASAを築いた人と技術―巨大システム開発の技術文化



宇宙開発ミッションは人類の経験した中でももっとも技術的に高度で大規模なプロジェクトのひとつだ。政治的な制約や全世界からの注目もありプレッシャーは半端ではなかったと思う。その組織的・技術文化的な葛藤の記録として、組織におけるプロジェクト推進の事例としても参考になる。


本書で繰り返し現れる事象は、プロジェクトの規模拡大により職人的な技術コミュニティから近代的な、脱人格化された厳密なプロセスに移行する過程。そして過程で発生する衝突。
これについてプロジェクトや研究所ごとに状況も文脈も違うため一般化は難しいけれど、おおむね、以下のように進む。


1.これまでの人的な内部サークル的組織では厳密さや信頼性を欠くため大規模プロジェクトに向かない
2,そのため、上部組織からシステム工学的手法の導入と管理の圧力が高まる
3.現場が反発しつつもシステム工学的で合理的な手法をいくつか取り入れ、組織の文化と統合していく


これは現代のソフトウェア開発とも被るかもしれない。


つまり、人的・職人的な開発であったメインフレームな時代の小規模で職人的で属人的な仕事から、近代的管理手法の時代に移行する。そしてあらゆる管理とドキュメント化で厳密に進められることになったウォーターフォールなどの開発手法は硬直化していると批判を受けた。そんなときにアジャイル開発として人的なつながりを重視し柔軟な管理をもった手法が広がりつつある。


ベスト&ブライテストでテクノクラシーな組織に眩しさを感じつつ、そういったプロジェクトにて自分はどういう役割を担えるか考えていくとおもしろい。


NASAじゃないけれど、糸川教授の言葉を引用。

私企業であると国家事業であるとを問わず、プロジェクト、計画を立ててやる仕事の場合、そのリーダーには三つの性格が必要なんです。第一は、演出家でなきゃいけない。二番目は、政治家でなければいけない。三番目は、馬力がなければいけない。この三つがなければ、グループ・リーダーにも計画者にもなれない。これがなければ、ニュートンやアインシュタインのように、1人でやれる研究から一歩も出ないんです。(日本ロケット開発の父 糸川英夫教授)


以下、読書メモ。

前置き

  • 本書について
    • アポロ計画において宇宙飛行士の活躍は氷山の一角であり、その実態は厖大な技術業務であって、またそれを支える管理・契約事務等であった。
    • NASAの技術的詳細やその開発の過程を含む多角的な研究が積み重ねられているが、本書で注目するのは、その中でも技術を築き上げたNASAの技術者と技術者の社会である。
    • 技術開発のアプローチや手法、それらの背後にある技術に対する考え方にもスポットを当てる。
  • NASA本部と各研究所の関係
    • NASAは、発足と同時に軍や大学などさまざまな母体の研究所を引き継いだ。
    • NASA本部と各研究所のあいだの健全な緊張関係がすぐれた成果につながったという意見もある。
    • 各研究所はその伝統に根ざした、経験的で属人的な部分があり指揮系統が弱く合理性に欠けていた。
    • 世論と議会の監視の下、NASA本部は各研究所に、技術プロセスの管理を強化するため、システム工学を中核とする規格化された手法の導入を推進した。
    • これは研究所のローカルなコミュニティにとって脅威であったためその妥協点を探ることとなる。
  • システム工学・システム技術者について
    • 日本ではシステム技術者という言葉とソフトウェア技術者という言葉をほぼ同義に使われるが本来は別の意味を持つ。
    • システム技術者の役割は、ICBMのような巨大技術システムの開発を統合的に管理することにある。
    • システム工学は、開発過程全体を管理するため総合的な視点を持つ、その一方で、巨大技術システムを適当な大きさの構成単位に分割して取り扱うため分析的であるといえる。
  • システム工学の手法
    • コンフィギュレーション管理をはじめとするシステム工学の手法は技術プロセスの徹底した文書化を要請し、脱人格的であった。
    • これは各技術コミュニティではあまり歓迎されなかったが官僚組織であるNASA本部の、人の入れ替わりが激しい組織においては共通言語として受けが良かった。

マーシャル宇宙飛行センター。フォンブラウンのチーム

  • 一つ屋根の下の組織から、巨大組織へ
    • 陸軍ミサイル研究では、理論から実践まで幅広い分野をフォン・ブラウン率いるセンター自前でもっていた。

良いチームはみな、冷静な科学的言語では評価が難しい一定の性格をもっている。良いチームには帰属の意識、誇り、そして集団で物事を成し遂げる気持ちがある。自ら進んで取り組むという要素がそこにある。そうした良いチームは木や花のようにゆっくりと有機的に育てなければならない。(フォン・ブラウン

  • フォン・ブラウンの考え方。有機的なチーム
    • 多大な予算が絡む難しい判断をするとき、国防総省の高官は保身に走る。権威ある科学者のサインがあることで、なにかまずいことが起こっても国内でもっとも賢い人間に意見を求めていることで責任を回避できる、と考える。説明責任が自己目的化し、成功のための努力が犠牲になっているとフォン・ブラウンは批判している。
    • ロケット開発には様々な分野の専門家が必要であり、管理者は最大限の権限委譲を追求しなければならない。そして権限委譲するためには、まずチームの技術者の能力を認め、信頼しなければならない。また、良いアイデアはだいたい組織の実働部隊のレベルから出てくるものなので、効率的で途切れのない意思疎通のシステムを確立する必要がある。
  • 自前主義か、外注するか。
    • フォン・ブラウン率いるマーシャル航空宇宙センターでは、当初は自前開発(内製)主義でやっていたが、予算と業務の増大によって、外注を余儀なくされる。ここで、ボーイングなどの民間の組織に発注しながらも技術者を常駐させ協働していた。
    • ここで、一定の技術業務を組織内にとどめておかなければ、メーカーの企画書や実績を評価するものさしを失い、それはひいては納税者の不利益になる、とフォン・ブラウンは主張した。
  • マーシャルの文化。意思疎通のシステム
    • 各技術部長に対して、その専門分野に対する「自動的な」責任を持たせていた。彼らはセンター内のプロジェクトの進行状況や問題点について、会議やその他公式・非公式のルートを通じて常にフォローしておくことを期待された。これは最大限の権限追従。合理性はない。
    • 各技術部長が進捗や問題などをA4一枚にまとめ、これをフォン・ブラウンに提出、彼はこれにコメントをつけて全研究所に回覧する。また会議では発散的・徹底的に議論しこれをまとめる。
    • 組織の信頼と長年の蓄積があってこそ、言葉や数式で表現しきれない技術実践。


そこにNASAのエリートシステム工学者のシェイがやってくる。すべてを数式と言葉で説明するべきと考える彼の考えは「君が理解しているのなら、ぼくに理解させることができるはずだ」という格言に現れている。システム工学の信念に基づいて管理し分析することでプロジェクトを推進しようとする。


  • 組織はどう変わっていったか
    • ブラウンは組織を二重化した。ひとつはもと技術部門の研究開発実施本部。もうひとつの業務実施本部はプロジェクト管理をおこなう役割で、センターの人員の2割にも満たないがここでシステム工学やメーカの監督、NASA本部への報告や対応を担当した。これによりシステム工学の管理圧力から従来の技術文化の美点を守り抜くことが出来た。
  • 信頼性確保のための統計的アプローチと、人的アプローチ
    • 信頼性工学は、健全な技術的鍛錬と分析的手法との結合として考えられる。
    • 信頼性の統計的実証については全機レベルではもちろんサブシステムレベルでも非現実的だと考えていた。数字の持つ表面的な厳密さと正確さに技術者が惹かれてしまう傾向に注意を喚起。
    • 統計的確信は『技術的革新』にとってかわられなければならない。
    • 技術的革新を達成する上でのカギは、開発試験の全段階を通して発生するすべての故障の原因の厳密な特定。としていた。(ちょっと意味不明だけれど、本でも、このまま引用されていた。)
    • 信頼性を高めるための機能追加は、その機能追加によりシステムの複雑さが増すことで信頼性が低下することもあることを考えて決定する必要がある。
    • 統計的手法で実証することは不可能
    • 意図的に疑似故障状況をつくり故障パターンを潰す
    • これは人的に故障を減らす手法であるが、技術的に保守主義になりミスを恐れる文化でもある。長年かけて熟成されたチームは、個人のミスがその組織内での信頼を失ってしまうために失敗を恐れ保守的になっている

ついに高い信頼性を達成する方法について、かなり明確な考え方を持つに至った。それは一言で言えば、健全で見識のある技術のやり方と、長い間の経験に基づきあらゆる分析手法に支えられた技術判断を適用することだ。(マーシャル所長代理エバーハルト・レース)

  • マーシャルのその後
    • サターンV型の打ち上げ成功の後、目標は多角化し、ブラウンだけでは管理できず権限は散逸していった。またマーシャルは徐々に予算を削減され、人員も削減し、もはや大型ハードの開発・検査・点検できる能力は無くなったと宣言された。

アポロ宇宙船開発

  • 組織の文化
    • 出自の異なる航空分野系と弾道ミサイル系のグループがあった。
  • 航空分野系
    • 技術的問題の解決に当たって人を以下に組織するかを重視する傾向があった。
    • 「成功への主な鍵は人であり、人をいかに組織するかである」
    • 調和的で民主的なコミュニティで人間志向の技術アプローチ
  • ミサイル分野
    • 人の組織よりもむしろ技術システムの徹底的な分析を重視する傾向があった。
    • 階層的で能力主義的、技術システムの分析能力が何よりも重視される環境であった。

真の信頼性を達成するためには、問題が発生する微かな兆候を決して見逃したり無視したりせず、きちんと認識する人たちが必要だ。最後の一押しの労力を惜しまずに払う人たちが成功と失敗を分けることは本当に良くあることだ。(ギルルース)

私はシステムを信じていない。私は仕事をする能力があり意欲を持つ人たちを信じている(ロウ シェイの後任の宇宙船開発室室長でのちのNASA長官代理)

  • 文化の変遷
    • 分析的・合理的、トップダウン・階層的にすすめるシステム志向なリーダーと、信頼のおけるチームで調和的なコミュニケーションをとっていく人志向なリーダー。相互評定の文化であるが悪く言えば内部サークル的。その相克が良い緊張関係をもたらしていたが徐々に後者に取って代わられた。
    • 有能なだけでなく、信頼されていないと情報は入らない。優秀な者が簡単に取って代われるような機械的な組織ではなく有機的な組織。ただ、どちらの場合でも無能なものは簡単に排除される仕組みになっていた。
    • アポロ計画でもジェミニ計画でも、初期の段階ではトップダウンな天才技術者が引っ張っており、その後、運用上の配慮が必要になる頃には内部サークルからの調整役的なリーダーに替わっているのは興味深い

大学の研究とプロジェクトの推進(ジェット推進研究所)

  • 大学における研究の文化
    • 個人の裁量を重んじ、他のメンバの仕事に干渉することを避け、規律や画一性に縛られることを嫌う大学の文化。
    • ありきたりな仕事を軽視しリスクを顧みずに失敗や遅延をものともせず抗争の大きなプロジェクトに挑む。
    • しかし予算とスケジュールを管理するNASAにとっては許容できるものでない。
    • 未踏の技術を追い求めて失敗をいとわないために、冗長性にかけ低品質な部品を使用し試験も不足している。
    • 1960年にはマッキンゼー社からも国家プロジェクトを遂行するには不適格と評価される。
    • システム工学の導入と反発。NASA本部との対立。


人的アプローチとシステム工学の止揚により成功するまでになっていった。
技術分野に分かれていた個人主義の組織をどうやって巨大なプロジェクト推進に向くように変化していったかは読み応えがあるのでぜひ手にとって確かめて欲しい。


日本の宇宙開発

  • 東大系のISAS
    • ドキュメントもつくらないし連絡も口頭で済ませ、関係者間の責任分担も明確化しない。と現代のプロジェクトマネージャが聞いたら卒倒するような進め方。信頼のある専門家同士だからなせたワザだと思える。
    • 米国からの技術援助も避けるというか拒む、それでも衛星打ち上げに成功する
  • NASDA
    • 米国からいかに技術を学び、それを独自のものとするか。

その他気になった話

  • 社会の文化と技術プロセス
    • 契約社会では業務関係は一時的であり、技術者も互換的でなければならない。このため脱人格化された技術プロセスに利がある。
    • 一方、非契約社会においては人間関係が安定的かつ有機的であり、技術者が全体の業務の文脈を理解しつつ調和的に動くことが出来る。このため特定の人間に依存したやり方が効率を高める。
  • 技術者と技官の民主的な協働的なマッチング。
    • 実験模型を考案・設計する技術者と、それを制作する技官。工作の名手に依頼するには、技術者同士で競争しなければならないこともあり、技官側が強い立場の選ぶ側であった。また技官側も有望株をつかまえて注目されたいと思っていたので、意地の悪い仕組みではあるがお互いに優秀な者が上に昇る仕組みになっていた。
    • これは技官と技術者のあいだだけでなく、技術者でも同じ。大学を出たばかりの若手でも上層部と直接、技術上の議論をもてた。研究所を組織していたのは、組織図上の関係ではなく相互の評価であり評判。表彰などはなく、賞とはいい仕事を与えられること。誰かが良い業績を挙げると、郵趣な人なみなその人と仕事を従ったし、その人のチームでその人のアイデアについて研究したがった。

本書中では技術者のキャリアの選択や、組織人事のかけひきも垣間見えておもしろい。
特に、中央からの大きな方針変換があったときに、それを受け入れないこれまでの現場のトップが辞表を叩きつけることが多いことが気になる。日本では、閑職に追いやられることこそあっても、だいたい穏やかにことがすすむように思う。自分のキャリアよりも信念を大事にしているように感じられておもしろい(実際は違うかも知れないけれど)。こういう土壌があると組織の方向転換もスムーズにできるのかもしれない。



以上

(雑感)仕出し屋「玉子屋」と勘とデータマイニング

2013/5/6 文末に玉子屋の情報を追記

ーー

昨日の夜、帰宅してテレビをつけるとNHKでサラメシという番組をやってた。
働く人のご飯に注目するという内容の、すこし変わった視点の職業紹介といった感じでおもしろい。

これまでの放送 - NHK サラメシ


そのなかで、玉子屋というお弁当屋を紹介していたのだけれど、これに見入ってしまった。

お弁当の玉子屋


ただのお弁当屋じゃなくて会社相手に1日に6万食もつくって配達しているお弁当屋さん。
なんでもご飯を1日に1.5tも炊くらしい。


すごいのは量だけでなくて、お弁当の発注数の予測らしい。
当日配達するお昼のお弁当をその日の午前10時まで注文を受け付けている。注文を受けてから作って車を出していたら間に合わないので、ある程度見込みでつくる。そして当然ながら会社まで運ぶときには不足を出さない。


もちろん許容廃棄率に余裕があればいいのだけれど、そこはけっこう厳しくしている印象で、販売数の予測に売りがあるという触れ込みだった。


お弁当屋さんの売り上げに関係しそうな変数ってどれくらいあるんだろう?データマイニングを使ってる現場の実際って気になる。

と、わくわくして観続けると、経営戦略室室長みたいないかつい肩書きの30歳くらいの人なつこそうな兄ちゃんが、すでにフル稼働で生産している弁当工場の事務室に現れた。
そしてPCを開き、データを確認するかと思いきや、天気を確認。まずは天気からだよね。お弁当の売り上げに一番影響あるよね。


と、観ていてもPCはもう画面に映らず、その兄ちゃんは受注一覧とでもいう紙とにらめっこして、工場と電話で数字をやりとり。
そのあと、注文を受け付ける部屋にカメラは移動。


PCを前にしてヘッドセットをつけた制服姿のオペレータが並んでキーボードを叩く、なんてことはない。10人ほどのおばちゃんたちが肩がくっついてるんじゃないかというくらい狭いところでひっきりなしにかかる電話を受けながら鉛筆と電卓を高速に動かす。そして飛び交う怒号。PC?そんなものはありません。みんな紙の伝票に書き込んで、机の上に立ち上がったおばさんが集計していく。まさに戦場。

そこからの室長の兄ちゃんはそことやりとりしてこのペースだと今日はこのくらいかな、と数字を出して工場に電話で連絡する。


アナログ*1というかアナクロというか。職人技。すごい。たぶんすごく洗練されている。
仮に発注数を予測する計算式がつくられていたとしてもテレビなんかに出さないだろうけれど、そんなのなさそうなくらい勘をつかってる感じ。

テレビに映っていた伝票はすべて紙だったし、2010年代になって、1日の売上が2500万円くらいありそうな規模の会社でこのローテクさは衝撃を受けた。自分の世界が狭いのはあるけれどその100分の1の規模の企業でもExcelで管理してるのに。


ただ、時代遅れの企業だし電子化すべき。という話ではない。
こういう洗練されたローテクで日々の業務を回しているところは、IT化でコストを削減できるかちょっと自信が持てない。まず要件を聞き出すのに死ぬし、導入でも死ぬ気がする。BIとかデータマイニング、ビッグデータのお高いパッケージを使うよりはいいのかもしれない。

ただ、この職人室長の計算と、入念に調整されたデータマイニングの予測値の差は気になる・・・。
(だれか学生さんが共同研究を持ちかけて調べないかな)



玉子屋について

テレビではアナログ企業であるかのように紹介されていた玉子屋が、野村総研主催の未来創発フォーラム2006にて講演していたみたい。

支払方法や料金の回収は、お客さんに任せており不都合はないと言うが、何故か、電話注文からインターネット注文に切り替えると客数が減るのだと言う。
   電話受付は100人いるが、営業は配達人がやってくれるので営業の人間は一人もいない。
   弁当容器は総て回収して洗って再利用する。 

未来創発フォーラム2006・・・玉子屋の革新経営 - 熟年の文化徒然雑記帳


もひとつ、こんなのも見つけた。かなりおもしろい会社かもしれない。

  • 仕出し弁当業「玉子屋
  • 社是「事業に失敗するコツ」
  1. 旧来の方法が一番よいと信じていること
  2. もちはもち屋だとうぬぼれていること
  3. ひまがないといって本を読まぬこと
  4. どうにかなると考えていること
  5. 稼ぐに追いつく貧乏なしとむやみやたらと骨を折ること
  6. 良いものはだまっていても売れると安心していること
  7. 高い給料は出せないといって人を安く使うこと
  8. 支払いは延ばすほうが得だとなるべく支払わぬ工夫をすること
  9. 機械は高いといって人を使うこと
  10. お客はわがまますぎると考えること
  11. 商売人は人情は禁物だと考えること
  12. そんなことはできないと改善せぬこと
事業に失敗するコツ*仕出し弁当業「玉子屋」

本当に同じ玉子屋だろうか・・・

*1:誤用

(読書メモ)「ソフトウェア企業の競争戦略」

はじめは、魅力的なタイトルではあるけれど、この変化の早い業界で2004年に出版されたということで陳腐化しているものと思いあまり気を引かれなかった。
けれど、日本語版への序文で見つけた次の一説を目にし、これは今なお通用すると思った。

過去20年間にわたり、日本は米国に次ぐ世界二番目の規模のソフトウェアを生産し、使ってきた。しかし、多くの部外者にとってみると、日本のソフトウェア・ビジネスは常に謎めいた存在だった。テレビゲームを除くと、外国に輸出される日本のソフトウェア製品はほとんど無きに等しい。日本の法人ユーザーは、高価なカスタム・メイド(特注の)ソフトウェアを購入することになれてしまっている。日本のソフトウェア製造企業が、グローバルな製品を開発しようとしたことはほとんど無かった。彼らは国内顧客への対応に追われるあまり、英語によるインターフェイスを備えた製品を設計しないのである。日本の教育と雇用システムが、優秀なソフトウェアのプログラマーを生み出すのに必要な創造性を抑圧している、と考える欧米人も多い。


日本語版への序文より

MITスローン経営大学院教授 マイケル・クスマノによるこの本を読めば、日本のソフトウェア産業の今後についてヒントがあるかなと期待して読んでみた。いまだに通用しそうなこともあるし考えるきっかけになった。簡単に読書メモをとってみたので公開してみる。あんまり整理してないし読んでない章もあるので抜け漏れあるかもです。ご容赦を。


前提

あまりソフトウェア企業の定義は記述されていないけれど、暗黙のうちに1ライセンスいくらのパッケージソフトウェアか、それの周辺のビジネスのことを指していて、SaaSのような形態や、広告で稼ぐWebサービス、個人向けのECのような、執筆当時にあまりなかったものは念頭に置かれていない様子。著者も、2004年の時点で「これまで20年間業界をみてきて」と語っておりいまとは状況も異なることに注意。


ソフトウェア産業の特徴

ソフトウェア産業は他の産業と比べて特徴的な点があるため、経営や戦略も異なるものが必要となる。

  • コピー可能であり量産コストが安価
    • ※ソフトウェアはコピー可能な物ではあるが、企業の基幹系にかかわる箇所だと広範囲なカスタマイズと継続したサポートが必要になる。
  • 製品売上げに対するマージンが大きい
  • 製品企業の多くがいつのまにかサービス企業に変貌する
  • 製品開発プロジェクトの8割が遅れるばかりか予算超過になる
  • 生産性の高い従業員とそうでない従業員の生産性が10-20倍ほど違う
  • ロックイン

など
(いまだと追加するものはなにかあるだろうか?個人でも資本なしでも始めることもできる、とか?)


各地域のソフトウェア産業について

  • 欧州
    • ソフトウェアを科学として扱う傾向
    • SAP,ビジネスオブジェクツ、CERNとか。
    • プログラミング言語と設計原理分野で素晴らしい大学教育を実施
  • 日本
    • 基礎研究や大学研究に十分な投資をしていない
    • 富士通、日立、NEC、東芝、NTTのようなメジャーなソフトウェア企業は、OJTで教育しなければならず、開発は製品製造の課題のひとつになっている
    • ゲームや家電の組み込みなどの例外を除くと、日本の大企業は、経験則、プロセス、いくばくかの資本とマンパワーで大規模システムに取り組んでいる。
    • 標準化されたプロセスに従うカスタムまたはセミカスタムによる大量生産に向いている。
    • 類似システムを少し安く簡単に構築するには都合がいいが、世界を変えることはない。
  • 米国
    • ソフトウェア技術をソフトウェア企業設立のための手段だと思っている
    • 防衛産業などでは統制のとれたエンジニアリングとしてソフトウェア開発されている

日本企業はソフトウェアを生み出すプロセスの点では優秀。しかし製品については課題が多い。


信頼性や大まかな生産性指標では米国企業と同等か、より優れている。
標準化された開発手法、共通の訓練プログラム、厳格な品質保証手法、統計を用いたプロジェクト管理などが特徴的。
しかし、予測不可能でテンポの速いPCソフトウェアやインターネットの世界では、決まり切ったプロセスに従うより、戦略やカネを稼ぐことに注目した(一見いいかげんな)アプローチがよく適合している。(e.g. マイクロソフト


ソフトウェア企業の形態

事業成功は製品とサービス両方を同時に販売することにかかっている

ビジネスモデル

  • ソフトウェア製品企業
    • ライセンス料で稼ぐ
    • ヒット製品があれば大きな利益をあげられるが、まったく利益のでないこともある
    • ベストセラーをねらう印刷業的
  • サービス企業
    • コンサルティングや顧客向けソフトウェア開発・インテグレーション、テクニカルサポートなど
    • 労働集約的で利益率は悪くなる
    • 収入は安定する資産管理型
  • 上記のハイブリッド(サービスが8割程度)

ソフトウェアのヒットを出すと、ひとつのソフトウェアから膨大な利益を出すことが可能。
しかし、これは計画できないし、ヒットした後に、普及してしまえば、顧客はアップグレードしなくなる(office2003をいまだに使用している企業はいまだに多い)。
製品がコピーされたりコモディティ化することで急速に売上げが悪化することはよくある。
そしてより労働集約的で利益率の低いサービス事業(サポートやカスタマイズ)に移行せざるを得なくなる。
ただし、ソフトウェアのサポートやカスタマイズ、ソリューションの統合なども、結局はそのソフトウェアの売上げに遅行して連動する。これを切り離せる企業は少ない(例外はIBMやSAP)


つまり、新製品開発に力を入れている企業でも、結局は新規顧客への販売活動よりも、既存顧客へのサービス、および段階的なメンテナンスやアップグレードで収益を上げることになる。こうした企業は無意識のうちにサービスよりに転換しているため、環境変化に準備が出来ないことがある。市場の変化に対応するためには柔軟性を持った組織構造を持つ必要がある。
(どういう組織構造だと柔軟性があるのだろうか)


各形態での戦略

景気が悪いとき、または既存製品や顧客ベースが古くなってくると、市場で生き残るために、利益率の高い製品販売から利益率の低いサービスの販売へと移行せざるを得ない局面がある。


法人向けソフトウェアを販売しているソフトウェア企業の多くは、個人ユーザや特定顧客のニーズに合わせて自社の製品や戦略を適宜変更するだけの抜け目のなさをもつことが必要となる。


製品事業

製品事業では、標準化された製品を以下に多く売るかが重要。
基本的な戦略は似たような市場で経験済みの事例を規模拡大または繰り返すこと。
e.g.マイクロソフト、アドビ


開発部隊は、可能な限り多数のユーザに、まあまあ満足できる品質を保ちながら一定の期間で新製品とアップグレードを出すことに注力する。

カギは大量販売のためのマーケティング力と販売力。ほとんどのソフトウェア企業がつくっているのは補完製品だが、デファクト化を狙うことやプラットフォームリーダーを目指すことも戦略の一つになる。

コピー可能なソフトウェアを活かしてスケールが効くことがメリット

サービス事業

ソフトウェアサービス事業では主にひととかかわるものであり、顧客との関係を構築することがカギとなる。収益を生む顧客層を十分に確保し、自社の抱えるコンサルタントや開発担当者を限りなく100%に近い稼働状態にしておくことがサービス事業の目的となる。
e.g.IBM、PwC、アクセンチュア


範囲の経済がキモになる。ノウハウの共有・プロセスの標準化など組織能力が必要となる。
企業の根幹にかかわる、置き換えにくいソリューションによりロックインすることで継続的に収益をあげることも重要。


サービス企業は利益率は低くなるが、財務的には弱点であると同時に強みでもある。

ハイブリッド

これでうまくやるには、高度な技術、顧客管理力、組織能力を必要となる。両方をマスターしている企業はまれ。


技術の管理

ソフトウェア・ビジネスで技術を管理することは、特定ユーザのニーズに応じてソフトウェア製品や情報システムを設計、製作、テスト、納品、サポートし、そのライフタイムを通じてソフトウェア製品の機能を拡張する全体的なプロセスを監視することとほぼ同義である。


ソフトウェア企業の健全性を測る指標

  • 売上に占めるライセンス料の割合とその伸び率

−従業員ひとりあたりの売上高(20万ドルあれば、通常は適切な役割を適切にこなせる人材を雇うことが出来る)

もっとも簡単に従業員ひとりあたりの売上や利益を挙げる方法は、大量販売用パッケージ製品のベストセラーを開発すること。
特定顧客向けのソフト開発やサービスを主要ビジネスとするベンダーが多くの収益を得ることも可能だが、それはそれに見合う多くの人々を雇える場合に限られるだろう。規模の不経済。


ソフトウェア・パッケージを売る企業は製品がコモディティ化して、競合他社が出現するため大幅な赤字に陥ることがある。こうした状況では高価格のカスタムまたはセミカスタム製品を提供する企業のほうがそうでない企業よりも有利になる。


マーケティング

法人向けにソフトウェアがメインストリームの市場に無事到達するためには、ジェフリー・ムーアのいう「ホール・プロダクトソリューション」が必要になる。信頼性・使いやすさ・マニュアル・サポートが含まれる。利益も大きいがコストも大きい。企業は長期的なサポートのためにお金を払うことに抵抗は少ない。



特定のドメインに限られる垂直型展開と、そうでない水平型展開。マスかニッチかという選択もある
水平型は、市場が大きく魅惑的であるが、狙うには莫大な投資とスキルの獲得が必要となる。水平型で成功するにはまず垂直型で足がかりをつかむことが必要だろう。

理想はプラットフォーム・リーダーだがマイクロソフトやアドビなど少数の例しかない。



ヒット製品やプラットフォームをもらないソフトウェア企業にとって、ハイブリッドソリューションが現実的ゴールではないか

  • ベストセラー製品をつくり規模の経済をねらうことも出来る
  • 製品を補完するサービスの提供によって、製品・ビジネスの側面から収益をあげる
  • サービスの提供によりコピーやコモディティ化を防ぐ

管理するためのスキルセットが必要になる。


以下の方法を検討する必要がある

  • 複数ユーザのニーズに合うようにソフトウェア技術をパッケージ化する方法
  • あまりコストをかけずにここの製品をカスタマイズし、顧客ひとりひとりとの関係を深める術

ビジネスモデルを構築するために

以下の質問を考えることが有益

  • 主として製品企業なのか、サービス企業なのか
  • ターゲットは個人か法人か、マス・マーケットかニッチ・マーケットか。
  • 製品またはサービスは、どの程度水平的か、垂直的か。
  • 好不況に関わりなく入ってくる継続的な収益源は確保できているか。
  • メインストリーム市場の顧客をねらうのか、「キャズム」を回避しようとするのか。
  • 目指すのはマーケット・リーダーか、フォロワーか、それとも補完製品メーカーか。

−会社にはどのような特徴をもたせたいのか。


ソフトウェアビジネスはこれまでバブルとその崩壊にさらされ、絶頂とどん底を経験しているが、今日においてさえ、はるかに大きな波のとば口にさしかかっているにすぎないのではないか。


以上。



感想

この本で推奨されている戦略は、製品で売って、徐々に、その製品の個別カスタマイズ・サポートなどサービス方向で顧客とつながって長期的に稼いでいくというもの。日本のSIerではうまくできているだろうか。パッケージをつくっていても、結局は個別SIに流れてしまう企業が多いように思える。
SIerの偉い人からはサービス化・ソリューション化しようという声はよく聞くけれど、具体的になにをやっているかはよくわからない。やろうと言っているだけで人も予算もかけていないように思える。日本のSIerな企業から、いかに売れるサービス・パッケージをつくっていくのか、という方法論は気になる。考えがなくはないけれど整理できていない。


それと、本書であまり書かれていないこととして、ソフトウェア企業でいかに技術を管理していくかは重要だと思う。日進月歩の情報技術について、どう利用していくか、選別していくか。大きなソフトウェア企業でどうR&Dにお金をかけていけばよいか、どう現場に応用していくかは興味ある。



本書の書きっぷりとして、日米欧での現場経験が豊富な筆者らしく事例はよくでてくるけれど、データに基づいているものは少ないように感じた。主観的とまでは言わないけれど、いくつかの事例から一般化してしまっているような。ただ、おおむね直観通りではある。


1980年くらいから20年間ということでやや古いのが多い。この本に記述されていなく、近年に流行っているビジネスモデルとしてはユーザを集めて広告で稼ぐもの(SNSUGC)やECなどたくさんある。あるヒットした製品もすぐに売れなくなるというのはいまも共通しているかもしれない。ヤフオクや楽天などのようにタイミングが良くてデファクトになって続くサービスもあるけれど、そうでないサービスをどう続けていくか、どう撤退するかは新たな問題だと思う。なにかいい本かエントリかないだろか。



関連記事
システム開発が残念なことになってしまう問題について業界構造から考えてみた - うんこめも
むかし書いた記事。いま見返すと先入観だらだらで恥ずかしい・・・