2012-02-05
■ITを活用できる組織を増やす為に必要なこと
Publickeyさんで特許庁の基幹システム問題が取り上げられています。今回の件はどう考えても特許庁の体制が根本的な原因なので、TSOLが50人を1300人に増やしたことを槍玉に挙げても不毛だなと思っております。
特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態 ? Publickey
この辺のITのメディアの言説は大抵「なぜXXXプロジェクトは失敗したか」的なざっくりとした問題提起なのですが、失敗にも色んなケースがありますので、本来はそれらを因数分解して細部を議論しなければ教訓は得難い。後に残るものは、ワイドショーレベルの非生産的な言説をみのもんたが茶化すぐらいの微妙な空気ですか。こういう言説がIT業界のイメージダウンに繋がっていることを認識してもらいたいものです。Publickeyさんみたいに、生産的な言説が増えていかないといけない。そういうITのメディアを作っていきたいものです。
で、上記エントリにある「萩本氏の指摘するIT業界に巣食う本質的な問題」を解決する為に必要だと感じたことを、書いていきます。
萩本氏の指摘を一言で言うと「オーダーしている人間が、何をオーダーしているのか理解していない」ということです。この問題を考える時には、注文住宅とのオーダーと対比すると理解しやすいです。
注文住宅の設計書は図面だから、出来上がってくるものが図面通りに出来る。工法の詳細は知る必要は無い。チェックポイントも限定的なので、お互いコミュニケーションが取りやすい。しかし、ITのシステムにおける設計書は料理のレシピに良く似ている。レシピを読んだ所で、自分が望む料理になるかを判断するためにはレシピの作り手と同等の専門性が必要となるので、情シス部門ならまだしもエンドユーザーは口に入れないと正しく判断することが困難になる。「トマトソースのパスタ」って料理を注文して「口に合わないから下げろ、これはオレが頼んだものではない」という発注者の言い分が、まかり通ってしまう。注文住宅で「とりあえず家を作ってよ。住んでから検収するから」っていうのは通らないけれど、ITの場合は往々にして通ってしまうのは、この辺のズレに問題があると常々感じています。
萩本氏は上記のような問題を生む工程は不要にすべき(=仕様書は発注者が作るべき)と考えつつも、人月で食ってる現状を考えるとSIerからしたら仕事を失うことになるのでベンダーが変わることは無理があると指摘されています。正論を言えば、ユーザーは要件定義書や仕様書を精査する必要すら無くできあがったシステムだけで良い(=料理の作り方を知る必要は無い)けれど、オーダーメイドだとそうもいかない。料理は食べたら終わりですが、システムは出来てからが始まりです。プログラミングファーストな作り方で提案するベンダー様も増えてきているのですが、まだまだ小数派。
この辺のズレを埋める為に要件定義を行うのですが、埋められる溝には限界があります。仕様書をベンダーに作ってもらうのではなく自分たちで作成してベンダーに発注し、もっと正確なオーダーを出せるようになるしかない。これが正しいとすると、仕様は業務とITを理解している人間が策定しなければならぬっていう理屈になるのだけど、そのITをコードレベルで把握できるエンジニアがいないなら結局ダメになる確率が高いので、エンジニアを事業会社でもっと活用すべきだと4年ぐらい前からずっと主張しているのがこちらのブログになります。
ま、ぶっちゃけ正確にオーダー出来ないのならベンダーに安易に頼んじゃいけないんですが、提案依頼をされているベンダーの立場とすればそんなこと言えませんよね。営業しにきてるんだし。僕はそんなこと知ったこっちゃないんで、いくらでも口を出しますよ。
受託開発を正しく執り行うには、ある一定レベルのITリテラシーが必須なのでリテラシーが無いユーザー様は安易に業者に発注しちゃダメなんですよ。ハッキリ言っておきますね。そこを認めることが出来ない組織はITで何をやっても大抵失敗に終わります。ベンダーは発注者の期待に応えたいし時には超えようともしていますが、レシピがグダグダならどうしようもありません。「こんなグダグダなレシピでは仕事請けられないです」って言ったベンダーがもしいたら、そのベンダーとは仲良くしておきましょう。信頼できます。
レシピと図面の問題に戻りますが、それを解決するキーワードがこれ。「ITリテラシー」です。ITリテラシーがあるという言葉の意味は、ITシステムで出来る限界を知っているということです。その限界を知らない方への啓蒙活動が本当に必要なんだなと強く感じています。草の根活動として。
ITリテラシーを身につける方法は1つしか無い。自分で手を動かす。それだけです。文章を自分で書かないのに読み書きが出来る訳が無いのと同じです。
今やっている業務を、「自分たちで」ITを使って行うこと。中小企業ならOfficeソフトで充分。Excelで回せる仕事は山のようにあります。そして、Excelの限界に気づく時が来ます。そこが分水嶺でして、ITの限界を知って初めてITは業務の役に立つようになるんですね。その限界を埋める為に仕事の内容をITにフィットさせる意義が生まれ、ITシステムがもたらす効用を吟味できるからです。そこを考えている経営者が少ないのも事実。そこもある意味IT業界の本質的な問題かもしれません。
動かないコンピュータ的な話ばかりが先走りするのは、IT業界の未来に何の希望も与えないと思っています。この仕事をやってる人間が社会的にも意義があることなんだって話を、もっと増やしていきたいじゃないですか。動かないコンピュータのなすり付け合いの結果に残る「業界に巣食う負の構造を認識してない or 丸投げしてる顧客がダメ」対「負の構造があると認識しているのにそこから抜け出せない業者がダメ」っていうエゴのぶつかり合いを超えていかねばなりません。
取り急ぎ、僕に出来ることはITの限界を知らない方にその限界を啓蒙して、ITを武器にしてもらう手助けをすることかなーと思っています。
Think Globally, Act Locally!
2012-01-22
■富士通の3万人SE職務転換大作戦は成功するのか?
全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。
富士通、余剰SE変身作戦
富士通がグループで抱える約3万人のシステムエンジニア(SE)の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むSEは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はSE余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。
富士通、余剰SE変身作戦
実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機感がついに経営陣にまで到達したのかと、勝手に感慨に耽っております。何にせよ舵を切ったのは評価すべきことです。
この記事の骨子であろう「クラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むSEは仕事がなくなる」の意味は、2年ぐらい前から何度も申し上げていることですが人月積み上げの価格設定では明日から使えますよというSaaS,PaaSのビジネスモデルには太刀打ちできない、という文脈でしょう。Salesforce導入なら月10万、オーダーメイドで作ったら500万+運用費。ここを天秤にかけたら、どっちに軍配があがるのは明らかです。顧客はもう、構築費にはお金を払わなくなっている。
業務がパッケージとフィットすればそいつをそのまま突っ込んだ方が速いし安いことが多いんですが、手間をかけたほうが人月では儲かる。つまり、パッケージを担ぐより受託開発をやった方が基本的には儲かる。工数かけたほうが儲かるんだから作り込みにいくぜ、そうすれば下請けにも出せるだけの金額出せるし的な人月の負の側面がありまして。ここに絶望する人多いです。この職務転換からは、人月の負の側面を活かしたビジネスでは3万人の従業員を食わせることが出来ないと解釈することも出来ますので、実はグッドニュースかもしれません。
前ふりはこの辺にしておきまして、ホントの焦点は「個別構築はあかんならクラウドだという単純バカな理屈をどこまで練り込んでいるのか」です。個別システムの作り込みからクラウドサービスの提供への職務を行える人材を作るとのことですが、クラウドを活用して受託開発で成長するんです人月はそのままで的転換だったら、絶対失敗するでしょう。受託開発のPDCAサイクルのスピードを高速にしてクラウドサービスに対抗するのは戦略としてはアリですが、今までよりもディープに顧客の要望を聞き出してそれをソフトウェア上に設計して実装できる人材でなければ破綻します。要望からシステム機能まで瞬時にドリルダウンできないと、スピードは上がらない。今までそのスピードを必要としなかったビジネスで生きてきたSEを、再教育したからといってジョブチェンジできるとは、私には思えません。クラウドって言いたいだけなんじゃないのと揶揄されるレベルでは話にならない。
富士通グループぐらいの大きな会社さんなら、様々なビジネス課題を解決できるソリューションを多数お持ちのはず。それらを人月でヒョウタンツギにしていたパッケージやソリューションを解体して、OSSベースで焼き直してWebで複数のビジネス課題を解決できる運用を含めた新サービスを作るという方向のほうが面白いと思うんですが。職務転換の前にビジネスモデルの転換が先じゃねっていう気がすごくするんですが、3万人抱えていると抜本的な改革は難しいですよね。余剰SEの真因が人月単価への依存だとすれば、ね。
富士通グループが職務転換によって新しいSIの形をどのように作り上げていくのか、業界の先を展望する意味でも楽しみです。
追記(2012/01/23 23:40)
富士通グループの職務転換を示唆している記事がネットにあったのを見つけました。
「まず、顧客の現状を把握・分析する技能を持つフィールド・イノベータが伺い、そこから出てきた課題の解決策をコンサルタントが提案し、その解決策の実現手段をサービスインテグレータが顧客とともに考えて具現化していく。ビジネスプロデューサは文字通り、案件ごとのビジネスをプロデュースする役割を担う」
Weekly Memo:富士通が説くSIにおける人材革新のツボ - ITmedia エンタープライズ
僕が指摘した「受託開発時代の体制はそのままでクラウド担ぎます」という負けパターンのようにしか見えず、大変残念です。この体制を捨てなければ意味がない。人が介在するコストを減らしていく努力が全くこのインタビューからは窺い知れず、3万人いる上級SE(?)を受託開発から自社のなんかよくわからないクラウド的なサービスをみんなで担ぐ体制に焼き直しました以上の意図がこの記事からは読み取れないです。
冒頭の「スキルからロールへのシフト」と書いている一文も全く意味不明で提灯記事もここまで来たかというレベルなんですが、今の人材の保有スキルがマネジメント的な能力しかないので小回りが全く効かないので、もうそこは諦めてクラウドっていう印籠を使って役割だけ挿げ替えてオワコンを延命させようという考えなんでしょうかね・・・。無理だって、それは。2年後にハッキリすると思うけど。
この記事が全てではないと思いますが、現状「変える」ということだけが先走りしており、変革の内容に革新性が全く見受けられないのがとっても残念です。
2012-01-05
■【書評】100万人から教わったウェブサービスの極意 「モバツイ」開発1268日の知恵と視点
著者であるえふしんさん(fshin2000)より献本御礼。
100万人から教わったウェブサービスの極意 ?「モバツイ」開発1268日の知恵と視点
- 作者: 藤川真一
- 出版社/メーカー: 技術評論社
- 発売日: 2012/01/04
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 51回
- この商品を含むブログ (1件) を見る
結論から先に言うと、本書はノウハウ本ではないです。こうすれば100万人が使うWebサービスを作れるようになるよ、という類の本では無い。本書はモバツイというサービスを通して大きく2つのポイントを論じています。えふしんさんが地に足をつけた観点から見た「次のWebの居場所はどこなのか」と、「開発者がWebサービスを成立・継続させていく為のヒント」です。この2つが交差点のように交わりながら話を展開していくのが面白い。
次のWebの居場所を探し当てることは大変困難ではありますが、キーワードは誰が言ってもこんな感じでしょう。ソーシャル、グローバル、ローカル、モバイル。この辺の単語です。ソーシャルでグローバル性がありながらも、各々のローカルに息づくコミュニケーションを喚起させるようなWebサービス。そして、それらをモバイルでありスマートフォンがつないでいく。本書はエンジニア視点が特徴的で、Twitterについてもその仕組みについて中心に語られています。そしてその仕組みと今のWebの相性の良さを絡めながら、実際にサービスを運営しておられる実績から「地に足着いた」言葉で語ってくれているので、どの分析もうなずく所が多かったです。
後者のWebサービスを継続させる為のヒントについてですが、一番重要なのはそのサービスに対する情熱の有無、もっと言えば好きかどうかだと感じました。本書では「Twitterとの出会いは10年に1度のものだった」と語られており、もうその時点で熱が違う。サービス開発者の個人的な好みが最終的なモチベーションにつながることを示唆してくれています。もちろん、好きだからやっていけるものでもないかもしれない。でも、好きでなければ何も始まらない。本書からはそういった著者の「志」というものをひしひしと感じましたし、Webに対する根源的な愛情というか、そういうものも見え隠れてして共感する所が多々ありました。
ただ、あきひとさんも言及されていますが、各々の内容が地に足がついているからこその紙面の物足りなさを僕も感じました。もっと切り口の断面が太いほうが僕は好き。
僕は典型的なPCユーザーで、モバツイを使うまでは携帯でWebサービスを使うことは殆どありませんでした。乗り換え案内とプロ野球速報ぐらいでした。必要最低限の情報を知るだけなら携帯で良いけどそれ以上は親指1本であーだこーだやるのはめんどい、と。Twitterを携帯で使うなんてめんどいと思ってました。ツイートするのがだるそうという点と、当時は1000人近い人をフォローしてたので新着20件しか見れない携帯じゃタイムラインが追えねーと思ってました。
が、使ってみたら実に携帯と相性が良くてびっくりしました。待ち合わせに使ったり、色んな仲間と同時にPOSTしてタイムラインでお互いをシェアしたり、突然「おれもおれも」とサプライズゲストがやってきたり。各々が違う場所から同じものを見ているから、臨場感がすごくあった。Webサービスから臨場感を感じたことはモバツイが初めてでして、この体験は目から鱗でした。これはおもしろいわー、と。モバツイには新しい体験をさせてもらいました。
イマドキのWebサービスの構成要素をふんだんに含んだモバツイを通して語られるWebの世界観を、お楽しみあれ。
100万人から教わったウェブサービスの極意 ?「モバツイ」開発1268日の知恵と視点
- 作者: 藤川真一
- 出版社/メーカー: 技術評論社
- 発売日: 2012/01/04
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 51回
- この商品を含むブログ (1件) を見る
2012-01-04
■【書評】Jenkins実践入門
技術評論社の傳さんより献本御礼。
ソフトウェアを作りリリースする為には、まず動くコードを書くことが求められますが、書いたコードを動くソフトウェアであることを保証することも、等しく重要です。ですが後者のスキルを体系的に入門レベルまで落として書いた本はあまり無いように感じます。後者を手作業でやったら死ぬのは明白なことなのですが、その為には自動化を手助けする武器が必要になります。ビルドシステムを真剣に考える本として本書を位置づけるのが最も妥当ではないか、と感じました。
本書はビルドシステムとはからはじまり、Seleniumや分散ノードでのビルド環境の構築等様々に幅広い使い方が書かれており、Jenkinsに興味があるエンジニアであればスキルレベルに関係なくなにかしら拾える情報があります。これは僕の好みなんですけれど、JenkinsはRuby/PHP/Python、時にはVisual Studioのプロジェクトでもビルドサーバとして活躍できるので、主要フレームワークでJenkinsを使ったサンプル等が仮にあれば、より完璧だと思いました。
システムを作るってことは本当に色んなことをやらなければならず、崩壊するのは容易い。気を引き締めていかんとなぁ、と新年早々身が引き締まる思いがしました。
良いビルドシステムで、良いコーディングを。
ではでは。
■【書評】Windows コマンドプロンプト ポケットリファレンス
技術評論社の池本さんより献本御礼。
- 作者: 山近慶一
- 出版社/メーカー: 技術評論社
- 発売日: 2011/12/09
- メディア: 単行本(ソフトカバー)
- 購入: 2人 クリック: 80回
- この商品を含むブログ (8件) を見る
というかですね、この本ちょっとやりすぎですよ。「最強すぎるにもほどがある」というコピーがぴったりです。
Windowsのコマンドを知り尽くしている人が書いているのでWindowsのコマンドの文法から頭に入る。体系的な理解を促してくれています。リファレンスに書いてあることを応用して独自のプログラムを書けるように留意してくれている。そして、コマンドの解説もさることながら実例も色々文法をかえたり利用シーンをかえたり、普通はこんなにたくさん用途を思いつかないだろっていうぐらいきめ細かいです。わたくし、全然消化できておりません。ポケットリファレンスですから、知らないものがいっぱいあるぐらいでちょうど良いかもしれません。
Windowsでシステム管理している人はもちろんのこと、個人ユーザーでもスケジュール実行やファイル操作等をコマンドで行えるようになるメリットは大きいです。
- 作者: 山近慶一
- 出版社/メーカー: 技術評論社
- 発売日: 2011/12/09
- メディア: 単行本(ソフトカバー)
- 購入: 2人 クリック: 80回
- この商品を含むブログ (8件) を見る
Windowsと仲良くなりたい方へ。本書はマジで効きますよ!
2011-12-28
■2011年を振り返ってみる
今年はブログの更新ペースがかなり落ちてしまいました。その理由は単純で、ブログで書こうと思った内容のいくつかを原稿に回していたからです。昨年末より開始した有料の会員制メールマガジンは6月末で終了させて頂いて、Software Design誌で連載をさせて頂くことなりました。振り返ってみれば1年中お金を頂いて原稿を書いていた、ということになります。
ホリエモンや津田さんを筆頭に有料メルマガが追い風になっておりますが、当方のつたない経験から申し上げますとこれで収益を上げるのはなかなかに難しいものです。お金を払っても得たいという情報は鮮度と密度の両方が求められます。「今、何が起こっているのか」を網羅的にとらえた上で、かつそのメルマガ発行者が持つ知見と人脈を鋭い視点で考察を重ねて考えを深めていける密度の濃さ。常に今をとらえていくには、その分野における高い専門性と公開情報の裏にある真実に肉薄した生の情報を得るための人的ネットワーク、そして何よりも世間的な知名度。これらが伴わないと本業に裂く時間を割いてまで、継続して有料メルマガを発行するのは困難だと感じました。
それはさておき、今年は自分がたまたま見つけたブログが書籍化するという「小悪魔女子大生はワシが育てた(キリッ」と胸を張って言える事件がありました。小悪魔女子大生のサーバエンジニア日記 の書籍化がそれです。
小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる
- 作者: aico,株式会社ディレクターズ,村井純
- 出版社/メーカー: 技術評論社
- 発売日: 2011/01/27
- メディア: 単行本(ソフトカバー)
- 購入: 10人 クリック: 832回
- この商品を含むブログ (49件) を見る
自分のござ先輩アイコンが帯になる日が来るとは思いませんでした。生きてるって素晴らしいっ!
6月から開始しているSoftware Design誌での連載は概ねご好評を頂いておりまして、次月号で連載最終回となります。当初はSI業界の先読みを目指していたのですが、僕が見る限り2009年頃から新しい成長モデルが見いだせておりません。もう、断言しても良いでしょう。であれば、先を読もうとするのではなく別の道を探して新しい働き場所を見つけるためにはどうすべきなのか、に僕の関心が移りました。その中で僕に伝えられることは何かを考え始め、それを文章に落とし込むことに専念しました。連載のきっかけを作って頂いた技術評論社の池本さんに、この場を借りて御礼申し上げます。
また、正直すっごく読みたかったけど大人の事情でどうしてもSD誌が買えなくて・・・というそんなYOUたち。連載終了後、それらの原稿はWebに載せちゃおうかと思っていますので、気長にお待ち頂ければ。
1年間お金を頂いて原稿を書かせて頂く過程において、改めて自分の強みといいますか、自分が最も相手に「響く」言葉を届けられる対象は何なのか、ということについてすごく考えました。同時に、自分の書いてきた・発信してきた言葉によって思考を深めエンジニア人生を切り開かれた方の存在も、少なからず感じることが出来ました。「ござ先輩のブログは、日本のエンジニアのキャリア形成に一石を投じてますよ」とおっしゃって頂いたのが嬉しかったです。エンジニアが主役になれる組織作りやキャリア、開発現場のノウハウをもっと共有して、ハッカー文化を企業に根付かせよう ? Publickeyというコトについても、一助になれるブログでありたい。僕は今どこの企業からもフリーな立場なので、僕が間に入れば色んなヒトが繋がる気がするんです。今後も大きめの石をドンドン放り投げて盛り上げていきますよ。モテギーク方面にね(え
エンジニアType様には創刊当初から大変お世話になり、ありがとうございました。モテギーク拾われた時はどうしようかと思いました。生け贄モテギークになってくれたregtanに深謝しております。モテギークになるとエージェントに頼らないでモテる転職が出来る。そのような言説がまことしやかに言われております。ソーシャル転職の記事はマジオススメ。読みましょう。
来年の抱負と致しましては、まず献本頂いている本の書評がたまっているので、そちらを全部やっつけることが最重要課題と認識しております。また、現在内製している販売管理システムを完成させ、雑貨卸・販売業務の鬼と化した僕が圧倒的なソリューションを提供できるようにするのが必達目標です。既に弊社内で実業務で投入して元気に動いているのですが、まだまだ足りない点が多い。いいですよ、業務アプリは。時代の流れに関係ないところで、ITで解決したい問題が絶対にありますから。売れる物や売り方は変わっても、売った後の業務の流れは変わってないんですよね。地味だけど金脈がたくさんある領域なので、地味にひっそりと儲けたく。今後も「技術を金に換える」という点には執拗にこだわります。
また、だいぶエンジニアのコミュニティ等からご無沙汰しているので色々な人とコラボしたいなーと思っています。コラボのネタは色々頂いているんですけど、単純に僕のリソース配分の問題で・・・orz
まだまだ、やれることもやりたいこともいっぱいあるでー!チャレンジ、チャレンジ!
来年もどうぞよろしくお願い致します。



