読者です 読者をやめる 読者になる 読者になる

GoTheDistance

ユーザ系SIerから全く別業種の会社で「ひとり情シス」として内製してる変わったエンジニアのブログです

4年に1度だけ訪れる結婚記念日

あれから4年か。人生は短い。

gothedistance.hatenadiary.jp

盟友のタケルンバ卿も、本当に何の口裏合わせもしてないのに同じ日に結婚して、同じく4年に1度の結婚記念日を迎えた。おめでとうございます!

lord.takerunba.com

奥さんに出会えたことを、改めて嬉しく感じられる日が、結婚記念日。毎年そういられるよう、努力します。大好きなので。

僕は妻のための仕事って思ったことはないけど、家族を不安にさせるような仕事ではあかんし、僕がつまんなそーに仕事してたらアレなので、いつだってリスク背負って立ってGot to go my wayで頑張ります。

まなめも結婚したそうだし、はてなクールボーイズで同窓会やろうね。

クラウドワークスで月収20万超え、わずか111名。働き方革命の未来はどこにある?

元ネタはこちらのTweet

公式資料かどうかを確認すべく、クラウドワークスさんの決算説明資料のWebページをチェック、当該Tweetで掲載されている画像の資料は、
2016年9月期 第1四半期決算説明資料(PDF)に掲載されているもので、公式の見解ということになります。

働き方はやっぱり正社員がNo.1

正社員という雇用形態が崩壊に向かい非正規雇用者が増えている中で、正社員でないと社会的信用や経済基盤等が損なわれてしまう。雇用にも限界があるわけだから、「個人」に対して仕事を供給して実績と信用を構築・適用できるプラットフォームがあれば、新しい雇用形態が生まれて個人も企業もWin-Winになる。ザックリとしていますが、クラウドワークスさんが目指している姿はそういう社会像だと認識しています。

で、その未来像を目指し着実にユーザーとクライアント企業を増やした帰結を端的に示しているのが、このページです。

f:id:gothedistance:20160224124933j:plain

数年の運営を経て得られた帰結は、「登録ユーザー80万人に対し、月収20万に到達する方は110人程度」でした。110名の90%はITエンジニア/Web制作 or デザイナーで占められており、クラウドソーシング関係なくある程度の収入は確保できる方々です。発注者が個人にマウントを取り、お小遣い稼ぎでも良いと割りきっている方を都合よく使っているイメージが拭えません。お小遣い稼ぎならば、クラウドワークスで仕事を請けるよりもメルカリのほうが効率が良くリスクもないので、そちらのほうが...と思ってしまう。

働き方として確立するためには安定性が最も重要な要素ですが、クラウドワークスさんのIR資料から際立って見えてくるのは、「企業組織と個人の関係は、やっぱり正社員がNo.1」という皮肉な示唆のように見受けられます。

今後の成長にも疑問符

さっきリンクを張ったPDFに書かれているPLの報告です。

f:id:gothedistance:20160224124951j:plain

1Qで10億の売上に対し、営業利益は△1.17億で赤字。通年は単純に4倍の40億の売上に対し営業費用の増加を見込み、営業赤字は△8.5億に膨らむ見通しです。

収入源は成果報酬型(契約額の何%かを貰う)モデルなので、これを拡大するために「ユーザーを増やす」か「単価を上げる」の2つの策が取れます。でも、月収20万超えが110人ですから契約単価の向上を見込むのは難しそうです。これを数万人に出来るんでしょうか。「個人」では限界があるように感じます。月収の高い人が増えてくればクラウドワークスで自分が取ったクラウドワークスの仕事を回すというロックな事案が増えそう。あれ? 元請けが下請けにマージン抜いて丸投げするアレじゃないですか? まじかよ〜。

ユーザー数を伸ばしましょうといっても、ユーザーが増えればサポートに関する諸業務が増えてしまう為に営業費用が嵩みます。オートメーションは無理がある。単純な物品の売買じゃないから。現在80万人のユーザーがいるそうですが、仮に200万ユーザーになったとしても成約額が小さいなら赤字体質の脱却は難しい。個人で請けられる仕事は、たかが知れていますから。売上40億で8.5億の赤字って結構辛い数字です。

ただ、「クラウドソーシングで武者修行をすることで、形を変えたOJTとして機能させることにより、人材紹介・教育研修の受け皿としてトータルなキャリアサポートを実現する」企業となり、そこで輩出した人材の能力が高く評価されるようなサイクルが出来上がってくるのであれば、働き方革命の幕開けかもしれません。新卒一括採用というスキームを形骸化させ、誰にでもセカンドチャンスを与える、と。

本資料からは「滅茶苦茶ユーザーを増やせばいつかはペイするンゴ」以上の戦略を読み取ることが出来ませんでした。まだ始まったばかりですから、5年後には僕が赤っ恥をかいているかもしれません。今後の成長を注視したいです。

【書評】システムインテグレーション再生の戦略

技術評論社、傅さんよりご恵投頂きました。システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?の続編という位置づけです。

システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか?

システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか?

本書は全体的に横文字が多く拡散的になっていますが、方向性を指し示すのが目的ですのでこんなもんかなと思います。「これしかありません」という話はできないですから、色んなヒントを得られるように構成されています。

工数積算やめてどうするの?

ポストSIビジネスというものに問われているのは、「工数積算を辞めて何をしたらええねん?」が主たるものです。ポストSIビジネスモデルとして合計12個のモデルが提示されていますが、切り口が違うだけで提示されているメタ視点は実は同じではないか、と。それが下記です。

「工数積算をやめる為には、納品までのスピードを”圧倒的に”速くするしかない。速くするにはスクラッチ開発を減らしてメニュー化する(or 自動生成する)しかない」

工数積算で3000万じゃペイしないとしたら、まず3000万を下げる必要がある。仮に1500万としましょう。半額にしてもエンジニアの人件は同じように発生する。でも工数は圧縮しなければならない。スピードを上げて単価を下げるためには、クラウドなのかPaaSなのかわかりませんがスクラッチ開発を可能な限り極小化してメニュー化するしか無く、「どこでメニュー化するのか」が切り口として違うだけ、という見方をしました。

お金をもらうスキームは、月額定額 / 買い切り/ 成果報酬などがありますが、どの選択肢を選んでも額は下がる。期間を短縮すると「そんなに速く出来るのに、この値段って高くない?」が絶対に前に来ます。技術的価値を正しく理解しろって言っても無駄。殆どの人は真価に興味はなく、ボリュームで判断するしかありません。速くすれば単価は絶対に下がりますから、数を叩くしか無いです。

アジャイルで請負開発ねぇ...

いい加減にしてくれませんかね、これ。前作の崩壊編でも未来図のひとつとしてこの話が乗ってたんですけど、地雷の可能性がとても高い。

本書では「納期と工数と金額をあらかじめ確定させ、その範囲でビジネス目的達成における重要度から開発対象となるビジネスプロセスの優先度を決定し、順次開発する。その期間で優先度が変わっても、着手されていないプロセスの開発順序が変更できるので、変更への柔軟性を担保できる。」のがアジャイル型請負開発の概要として書かれています。100pです。

・・・これ、まんまウォーターフォールじゃん? どこがアジャイルなの? 営業の手の平かな?

優先度が変わっても別の機能を作ればいいって、クリティカルパスが死んでるのに枝葉埋めてデスマになる絵しか浮かばない。寒気がする。

納期・工数・金額が決まってるなら「コレ以外やりません」or「多少のブレを見越して、リスクバッファーを積んでカネを取る」しか身を守る術はないの。ビジネス価値を正しく見極めるためのアジャイル。わかる。でも、その価値はコードを書いてから「これじゃない」とブレていくのが肝。決めた内容を作ることに成果責任を問われる以上、それを守るのが最優先になるって。ウチはアジャイル開発が得意なので開発の順序は優先度や内容については変更が効くようになってます、アジャイル開発だからご安心ください的な営業トークは、もう完全にホラー映画の世界。

このモデルを推すのであれば実際にこのモデルで成果を出している会社の事例をビシっと書いて欲しいです。請負が求められないとは言いませんが、本書のはじめに一括請負は構造的欠陥を生み出す的な文脈で書いてあるのに、なんでアジャイルで請負はOKになるのか僕にはわからなかった。ユーザーが本当に必要なものを作ることがどれだけ難しいか、考えてほしいものです。

システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか?

システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか?

本書に書かれているように新しい動きは確実に始まっています。ざっと現状を整理し、長期的な流れがどうなっていくのかを考える為に本書を当たるのは、もちろんアリです。


アジャイル請負だけは賛同できないけど。

地方のIT業界に必要な顧問エンジニアというモデルを考えてみた

システム開発

facebookに流れてきたこのエントリ、衝撃的な内容でした。

risingsun-system.biz

技術者と会話が成立しない

うわっ・・・となった。

こちらのお客様は、過去何度も地元のソフトウェア開発会社に仕事を頼もうと、いろんな会社とコンタクトを取られたといいます。しかし残念ながら、どの会社とも取引にいたることはありませんでした。

理由は様々ありますが、煎じて詰めると「技術者と会話が成立しない」ということでした。

自分の住みたい地方のIT業界をより良くするために必要な構造変革とは?

「業務がわかるエンジニアがいない」→「地方のユーザー企業から元請けの仕事を取れない」→「大手の下請けに入る」→「地元で業務が設計できて実装まで行えるエンジニアが育たない」→「業務がわか(ry」のループに入っている様子が鮮明に見えちゃいました。上記のエントリを書いた方は長野県の方ですが、どの県でも同じようなものでしょう。

中小企業向けのSIが成り立たないワケ

この手の話になると「下請けだからアカンねん」と必ず言われますが、そう簡単に辞められるワケがない。非常に難しいと見ています。やりたくてやってるんじゃなくて、対価が下がる中で重層構造になったんですよ。建築業と同じ理屈です。

こちらの調査を御覧ください。

itpro.nikkeibp.co.jp

記事によれば、平均で年商の0.75%しかIT予算を割いていないとあります。年商が100億以上の会社が母数の半分を占めているのがポイントで、年商10億未満に限定すれば「OfficeソフトとスタンドアロンのXX販売のみ」みたいな会社もわんさかいると思われます。

仮に年商3億の企業の場合、3億の0.75%は225万円。「年間」ですからね。年間で225万の予算しかない所に人月80万で見積もりしますと言っても「は?」ってなるので、スクラッチはまず無理。パッケージやSaaSの導入支援しかないけど、それだけでは全然儲からない。なので、カスタマイズをして売上を獲得しようとするけれど、今度は手離れが悪くなって利益率が悪化するので痛し痒し。中小企業は大手よりも現場が強いから、カスタマイズ要求も熾烈になりやすい。

・・・大手の傘の下で仕事を請けるしかないじゃん?

苦労して利益が少ない導入支援案件を回すより、効率もいいし納品におけるリスクも少ない。大手のしわ寄せを食らうという別次元のリスクは残ってるけど。

どうすれば地方のITビジネスが蘇るのか

まとめちゃうと、人月積算が通用しないけど単なるパッケージ導入じゃ意味が無いという状況だと睨んでいます。なので下請けに入らざるをえない。人月積算でオッケーだから。

仮にコレが正しいすると、打破するには「要件定義はしっかりやって、開発はPaaSを使って瞬殺する」しかないのではと考えています。そういうことをやる人をモデル化したのが下記の資料です。

www.slideshare.net

ITの相談相手にめぐりあえて自社のプラントとなるIT像が描けても、開発に何ヶ月もかけていたら中小企業には響かない。中小企業はカネも時間もないの。大手より条件は厳しい。PaaSならすぐデプロイ出来る。また、実装コードが人に依存しないので、ツールの使い方を覚えればある程度のことが誰でも出来る。ノウハウが溜まりやすい。WordPressの感覚で業務システムが組めるようになる時代は、もう来ていると思う。

今の時代はLAN前提のパッケージを導入するよりPaaSサービスを活用するほうが安いので、顧客と「対話」をして最適なITをキチッと落とし込んで、これだけのビジネス上の価値が生まれるよというイメージをしっかり共有する。

どれだけIT予算が渋い中小企業も、100万なら出します。アルバイトを1人年間で雇うのと同じだから。パッケージを入れてもその隙間を埋めるのに人が必要ならバイトを入れるのと大差がないですが、バイトを入れて回すほうがITを導入するより安上がりで確実だと考えているしゃちょーさんがとても多い。知らないからね、ITのツボを。エンジニアとしては看破できないし、マンパワーに頼るのはブラックの始まり。なんとかしたい。

仮に100万で考えると、要件定義フェーズは3回打ち合わせして50万。構築はPaaSを使い、ユーザー企業の担当者を教育しながら月額数万円で顧問ビジネスを行う。この値段感で勝負するしか無いと思う。

こんなビジネスを既に人月で食ってる組織が請け負えるわけがないので、僕のように事業会社にいるとか一人親方エンジニア等が中心となるでしょう。スケールすることはありませんが、会計士に代表される「士ビジネス」と同じ形を取れたら裾野が広がる。地方のITエンジニアが地方のユーザー企業の経営に資するITを提供できるようになれば、少しづつ流れが変わるはずです。

・・え???

そこまでビジョン見えてるなら、その顧問エンジニアというビジネスをやってくれ?

安心してください、着々と準備を進めていますよ!

昨年末に1件ゲットしております。3月頃から弊社の取引先を中心にウチの社長に本格的に営業に行ってもらうよう手筈を整えてございます。窓口を作る能力は本当にすごい、弊社の社長。天才だと思う。窓口さえ作って頂ければ、後は僕の腕の見せ所。手応えはありますので、今しばらくお待ちください。

出来ない人のレベルに合わせてはいけない

あるあるネタだと思いますが、組織がより優れたパフォーマンスを出す為にやっちゃいけないことが「出来る人とできない人がいた場合、出来ない人のためにレベルを下げること」です。

優れた解決策を持ってる人に合わせよう

簡単にいえば「↑」のようなことです。非エンジニアの方にはわかりにくい例ですが、Excelをファイル名+日付+バージョン名で複製して管理するのはとても大変ですよね。そんなことをしなくても良いツールがあるんです。それを使える人がいるのであれば、皆がそれを最低限使えるように努力すれば良い。できる人のレベルまでたどり着けではなく、できる人の邪魔をしないレベルまで下駄を履かせることにすごく意味があります。

昔、なんかの記事でExcelで手計算しているシートをマクロか計算式を組んで簡単にしたら怒られたみたいな話を読みました。ソースはごめんなさい、忘れました。が、Excelというツールを高いレベルで使いこなせる人が皆さんが苦労しないように「ひとつ上」のステージに上がれるよう腐心したのが怒られる理由が、ちょっとわかりませんでした。

出来ないひとに迎合した場合は、ずっと「ファイル名+日付+バージョン名」で差分管理をすることになる。Excelの手計算を続けなくてはならない。やらなくても良い作業をやらねばならず、何も生み出していない作業に時間が食われる。「みんなで頑張ってます」といえば聞こえはいいのでしょうが、出来る人はできない人の為に足を引っ張られて、ひとつ上のステージに行けるチャンスを逸している。恐ろしい話。

出来ない人に合わせていたら、誰も幸せになりません。できる人の邪魔をしないこと、阻害をしないことが、翻ってみんなの為になる。ExcelマクロでもGitでも同じことで、そのような優れた解決策があれば、出来ない人でも有る一定の質の成果が出る状況を作ってくれるので、会社を経営する立場からすればこれほどありがたいことは無い。

頑張ってもしょうがないこともある

僕、頑張るって言葉あまり好きじゃないです。努力するしか無いわけですけど、優れた解決策に迎合する努力をしないで、ただ目の前のことを頑張っているというのは、全員が不幸になる恐れがあります。ボトルネックを解消せず、ボトルネックをそのままにしておいて皆で頑張りましょう的な考え方は、大変危険です。誰も幸せになりませんから。頑張らなくても良いことに全力で努力しても...ねぇ。僕はエンジニアなので、余計にその思いが強くあります。

人の頑張りというボトルネックを解消しよう

ボトルネックが生まれるのは、その作業が自動化(仕組みとして整備されていないという意味で)出来ていないことが多いです。差分管理もそうですし、手集計もそうですよね。優れた解決策を持っている人がいるのに、それを「出来ない人がいるから」という理由で捨てるのだけは、本当にやめて頂きたい。生産性が上がらない→休みたくても休めないような状況に追い込まれる→疲弊する→優秀な人がやめる→生産性が(ry のループに入ったら終わり。

「出来ない人に迎合したら終わり」→「出来る人はあんだけ努力してるのに何なの」という個人の自助努力を批判する方向に行くケースもあって、これが最悪。生産性を上げるのに努力は不要です。そのやり方に従っていれば、誰でも一定の成果が上がることを生産性が向上したと言えるのであって、人が頑張ってパフォーマンスを上げているのは、俯瞰して見るとボトルネックでしかありません。その頑張りに依存しているのだから、大変なリスクです。

人の頑張りというボトルネックをコードで解決するエンジニアを頼って、みんなで休みを取りましょう!マジでそう思います!!

【書評】お金をドブに捨てないシステム開発の教科書

技術評論社、傅さんよりご恵投頂きました。

本書は公認会計士でありながらシステムコンサルタントをされている中川さんが、システム構想づくりの重要性をじっくりと説く一冊になっています。そう簡単に出来ることではないので「経営・会計・業務・システム」の4つの視点に分けて考えるべきと説いております。詳しい目次はこちらの著者の方の会計事務所のWebサイトにあります。

nakagawa-cpa.jp

本書で挙げられているメッセージは僕の中で違和感が多かったので、書評の内容も「なんでそういう説明になるのかな」という話が中心となります。

構想づくりの大切さを説く「なぜ」が弱すぎる

僕が感じた、本書の最大の不満がこれです。20pの1ページしか、何故システム構想が大切なのかが書かれておりません。システム構想づくりの大切さを説く本のはずなのに、「経営者の決意の重さをこめろ」とか「何故システム構想が難しいのか→ビジネスが多様化しているから」という論理展開は雑です。教科書と謳う以上は、もっと詰めて説明して欲しい。

例えば、経営者の決意をどれだけ込めようが、しょうもない設計書からはしょうもないシステムが出来るので絶対に辞めろ。これが教科書に書くべきことですよ。マジで。

4つの視点を集約しましょうという構成ですが、一読してもう一度頭から読み返すと一体何が大切だったんだっけかなぁとわからなくなりました。視点を切り替えて語ることは必要なことですが、構想を語る為の最終的なドキュメントは下記の構成物で構成され、こういう手順でしっかり詰めましょう、という構成が良かったんじゃないかなぁと思います。会計システムと販売管理システムでは検討事項が異なりますが、本書ではそれを包括的に教科書としてまとめようと腐心されたのでしょうけど、システム開発暗黙知が多いので大変難しいことだと改めて感じた次第です。

僕が考えるITでお金をドブに捨てない方法

この3つだけ、最低限考えましょう。

  • 経営者の思いは適当に受け流せ。
  • 自分の仕事の判断基準を全て書き下ろし、ボトルネックを潰せ。
  • いきなり作るな。ASPで代替出来ないかを常に検討しろ。

経営者の思い。重要ですよね。プロジェクトの本気度を図る指標としては有用ですが、システム構想には不要なこともあります思いが間違ってることも多いです。僕は自社で内製しましたが、経営者の思いを全く汲んでおりません。聞くだけ無駄でした。やりたい事とやらなくちゃいけない事は、全く別なんです。詳しくは下記をご覧ください。

gothedistance.hatenadiary.jp

業務の洗い出しが重要だ〜とよく言いますが、その8割ぐらいは「で、あなたはその仕事を終える為にどんなことを判断してるの」で説明ができます。判断基準がわかれば、完了基準も例外となることもわかります。そうすれば、業務担当者のボトルネックを見つけてその原因となる構造がどうなっているのか、議論ができます。まずはここを潰さなければ。使う人に使う意味がなければならず、その意味が経営に資するかどうかは、また一つ上の議論です。

ボトルネックの兆候としては、ミスが多い・確認が多い... など。ボトルネックになるのは個人の問題ではなく、組織運営の問題です。その問題が生まれてしまう構造をAs-Isを分析しましょう。その精度が低いと、どうしようもないToBeが出てきてしまいます。新規事業等でAsIsが存在しない場合はToBeから描くしか無いので、余計に難しくなります。

で、最後に。構想を練って業務プロセスを描いて、こういうオペレーションが出来れば改革ができるという段階になって、次に検討すべきはASP等のサービスの活用です。出来合いのもので済ませることが出来るのか出来ないのかを、じっくり吟味する必要があります。昨日の記事で「プラント型ITの構築は企業競争力の優劣の鍵」と書きましたが、中小企業においてはいくらその部分を強化しても無駄なので月3000円払って借りてくるのが最適解であるケースもあります。最終的に業務と業務を繋ぐ血管を作るためにプラント型ITが必要になるとは思いますが、まだその段階まで至っていないケースもありますから。特に新規性が高い業務の場合は。

みなさんのシステム開発が実り多きものであることを祈ります。

【書評】会社のITはエンジニアに任せるな!

システム開発

著者の白川克さんよりご恵投頂きました。

こちらの白川さんは、エンジニア上がりのキャリアを武器にIT寄りのコンサルタントとしてご活躍されていらっしゃいます。僕も長年「ITを使いこなせない(武器に出来ない)会社が多いのは、何がアカンのか」という話をブログに書いていますが、白川さんもずっとこの問題に向き合っており、ITを武器にする為のメッセージが「会社のITはエンジニアに任せるな」という本のタイトルに凝縮されております。

ツール型ITとプラント型IT

本書では「そもそもITって何なの」という話を、ツールとプラントという概念で分けて考えています。ツール型は、メールやカレンダーのように用途が限定的で完結型のITです。プラント型は「業務と密接に関係しており、ITがその会社での人の動き方を決めるようなIT」のことで、前者と後者は全くの別物。プラントを動かすためには確固たる哲学が必要だから、丸投げするには大事すぎると続いています。

プラントって、↓ なやつ。

f:id:gothedistance:20151220232903j:plain

ITを武器にする=プラント型ITを築き上げる

何故プラント型ITなるものが必要なのって話です。ここが重要である理由が伝わらないと、本書を読み進める意義も薄れるので強めに補足します。

最大の理由は、ITで結合された業務を回すためのインフラがあるのと無いのでは事業運営のレベルが全く違い、企業の競争力に大きな差がでるからです。

ITシステムは無くても、Excel/Access無しで業務を回してる会社は皆無でしょう。業務が暗黙知Excelで回っている状態は、舗装されていない荒れた道を、最小限の機器を積んだ車でドライバーが勘と経験で運転して目的地まで向かってるようなもの。が、経営の立場から見れば、業務を回す工程が人に依存するのはデメリットしか無い。生産性が人に依存しているので改善もクソも無く、現状維持が精一杯になります。この状態で業務改革を実行するのは単に2倍働け(給料は据え置きで)という話ですので、まぁふざけろ、と。

プラントの設計図を書くためには、「業務担当者が判断していること」から「業務上の重要な判断基準」を抜き出して、それを経営の視点から煮詰めます。煮詰めた判断を時系列でつなげていくと、ベストなプラントの完成イメージ図が出来ます。こいつが「ビジョン」です。ビジョンだけでは糞の役にも立たないので、そのビジョンを作業手順まで落とし込んでITに載せてやる必要があり、その作業はプラントの構築のように複雑です。簡単に手間いらずな事業運営など、あり得ません。

そうやって育てられたITがあれば、誰がやっても正しく事業運営が出来ますし、経営判断を業務の中に埋め込むことが出来ます。ヒトに依存しないので、ITシステムを改良することで、更に生産性が上がります。逐次的でありながら、やるほどに加速度が上がります。弊社がそうですので。ヒトが頑張れば早く進むことは出来ます。歩け→走れは簡単なこと。でも、遠くへ進むことは出来ません。取っつきにくいプラント型ITですが、一度プラントが構築できてまわり始めると、会社はガラッと変わります。

これが「ITを武器にする」意味で、その果実を得るためにどうしたら良いのかは、本書に様々な角度から語られています。

プラント型のITを作るためには、経営・業務・ITの3つの視点が必要です。最も足りないのがITエンジニアですよね... 描かれたイメージを素因数分解してレシピに落とす作業がどうしても必要で、その道のプロにしか出来ない。レシピも画一的なものはなく、自社にとって意味があるレシピを作るのは手間がかかるけど、やる意味はすごくあります。

メールベースの相談ならいくらでも乗るんで、僕で良ければお気軽にお問い合わせ下さい。

色んな会社さんにITを武器にしてもらいたいので、事業運営のあり方を変えたい方に本書を読んで頂ければと思います。

「一括請負はお互い不幸」から「作らないSI」へ

システム開発

僕がSIerを退職して5年。大きな潮目を迎えているのかもしれない、SIビジネスのお話。

itpro.nikkeibp.co.jp

簡単にまとめると「一括請負はゼロサムになってお互い不幸なんで、XaaSを使って作らないSIをやり始めている」という話を「オルタナティブSI」という言葉で表現しているようです。この5種類に分類してくれていますが、ただ並べただけで軸はバラバラです。

  • 月額契約型サービス「納品のないSI」
  • 固定料金でシステムを構築する「定額パッケージSI」
  • 自動生成ツールを使う「自動生成SI」
  • クラウドでITインフラを構築する「クラウドインフラSI」
  • ユーザー企業自らシステムを外販する「コミュニティSI」

作らないSIはずっと前から目指していた

代替となる選択肢は色々あるけれども、根幹にあるには「作らないSI」を目指していることだと思っています。

僕がSIerにいた10年前も「作らないSI」をやりたいと社内で議論されていました。ソフトウエア開発は技術力の高低によって、成果物に大きなブレがあります。だけど、仕事として請ける以上は質の均一化は当然のこと。会社の信用問題です。均一化を目指して10年前に生み出されたのは「俺のフレームワーク」という皮肉。OSSベースの標準フレームワークを頑張って作っても「オレの案件、VB。お前のフレームワークJava。糸冬。」という話がとても多かった記憶があります。内製で頑張って標準化を進めてもあまり見返りがないし、稼働率を重視する人月の世界では可動が最優先ですから、なかなか厳しい。

でも、クラウド技術が当たり前になりまして、サインアップすれば誰でもITリソースがジャンジャン使える時代になり、ようやく作らないSIが出来る環境が整ったのではないでしょうか。ボタン一個でサーバー起動で自動スケール、メールサーバやスマホプッシュ通信、VPNもどんとこいというサービスを使うことが出来て、質も良いしお安い。よほどの理由がない限り、使わない理由がなくなってきました。関係ないけど、AWSこえ〜。AWS lambdaでついにサーバーレスのSIまでやり始めた。何でもアリやな。

作らないから、契約も変えられる

作らないでやれるんだったら、契約の方法もそれに適したものに変えていく。作らないわけですから、期間と人数を掛け算してもしょうがない。人月計算型で3,000万のシステムが下手すれば100万に収まるとすると、積算する意味が無いってこと。成果報酬は揉める要素が大きいので、固定額(買い切り)とサブスクリプション(月額定額)が多いみたいですね。固定額の内容が人月ベースの成果補償から別の形に変わっていく。健全な変化ではないでしょうか。

ある程度の技術力はクラウドが担保してくれるので、技術力で差をつけられる要素は少なくなりました。なので、自分たちの技術をどうパッケージングして売り出していくかというマーケティングが、これからのSI企業に最も必要な力だと考えています。倉貫さんの「納品のないSI」みたいな感じ。マーケティングって要はポジショニング。自分にカネを払う理由を教えてあげるわけですよ、今そこにないポジションを取ることで。

どの会社にもCTOが必要であって欲しい

作らないSIが出来ることで、委任に近い格好でSIビジネスが出来るようになった。請負でなければ、極論すれば個人でもSIが請けられます。コード書かなければ、誰がやってもシステムのコード品質は保てます。システムそのものに価値があるかは、全く別ですけど。

作らないでシステムを作ることがどんどん進んでいけば、よりユーザーが自分たちの袖にあったシステムを手に入れられるようになっていくでしょう。必要なシステムを最低限のコストで手に入れられるし、作らないのでコードがブラックボックスにならないのなら、中小企業のIT活用の最大の問題点である「ITがわかる人材がいない」というハードルをクリア出来る気がします。技術者を雇用するというハードルを下げることが出来ますし、ユーザ企業のビジネスの仕組みを支える技術顧問というロールを担うエンジニアが、増えていくとすごく面白いと期待を頂いています。3文字で言えば、CTOですね。

この10年で一番変わったことの一つに、「CTO」という言葉が当たり前になったことを僕は挙げます。10年前にはCIOという言葉しか無かった。でも、今はCTOっていう言葉が業界内では当たり前に使うし、CTOを輩出する上場企業もバンバン出ている。

今後10年で、色んな会社さんにCTO(社内外問わず)が在籍してビジネスの下支えをしてくれるような形になるのが、作らないSIの先にある未来であってほしいなと思います。

カネにならないブログを続けているけど、楽しいです

ブログでの収益報告に対す賛否両論出てきて、とても良いですね。こういうネタが量産されるのがはてな的だ。稼ぐということは手段は何であれ大変なことだな〜

kutabirehateko.hateblo.jp

収益を上げるためにブログを運営することは何の問題もない。他人の不幸やFUDを煽りまくりの炎上商法は嫌いだけど。人生を楽しむためにブログで稼ぐ。ええ話。楽して稼ぎやがって的な嫌儲感は持ってはいけない。それを嫉妬だと断罪する筋の悪さは困り者だけど。

収益報告の最大の弊害は「カネになれば、なんでも良いんだろ?」と嫌悪感を抱かれ、究極的には品格を疑われることなのかもしれないな、と思いました。同窓会で旦那の年収自慢して勝ち組と思っている鬼女かお前は、と。怖い怖い。

報告する方は、純粋に嬉しいだけかもしれない。自分の頑張りで稼げることが。イノセントなだけで。その1万円があれば、自分の人生の選択肢が広がるコトも充分にある。僕も生活費に困ってたら収益第一路線になっていたと思います。ただ「おれはすげぇm9(^Д^)wwww」ってのはカッコ悪い。

世間的知名度を持たない一個人がブログを続けられる理由って、ほとんどない。しかし、カネにならないブログを僕は3つも持っている。こういう人間が異常。自覚は有る。このブログと、プログラミング等のことを書くブログと、野球のブログ。大好きな野球でも、相変わらず小難しいことを書いています。文章を書くのが大好きなのと、何度も何度も「この記事に出会えて嬉しい」という感想を頂いたのと、探していることがある。これが全て重なりあったので、カネにならないブログを持つ意味があるだけ。

今後も「はぐれブロガー純情派」として確固たるポジションを築きたいと思っています。ご愛顧のほど、どうぞよろしく。

【書評】エンジニアとして世界の最前線で働く選択肢

技術評論社傅様よりご恵贈頂きました。

本書では、「日本人エンジニアがアメリカの現地企業に就職して生きていくとはどういうことか」を中心に書かれています。僕の書評では、アメリカのソフトウェア企業はどのようにエンジニアを評価しているのかにフォーカスしてお届けしたいと思います。

ソフトウェアエンジニアのエコシステムがある

本書に挙げられているアメリカで働くメリットとして、下記が挙げられています。

  • 平均給与額が高く、ジョブマーケットの募集数も多い
  • 外国人であるというハンディが少ない
  • 転職回数が不利にならない

特に印象的だったのが、転職回数が不利に働くことはないということです。むしろ、転職回数が少なすぎると「他社に迎合されなかったのではないか」という評価を受けてしまうことがあるぐらいとのこと。ソフトウェアエンジニアは転職するのが当たり前で、企業の規模を問わず流動性がある為、エンジニアをいろんな環境で活用できるエコシステムが出来上がっていると言っても過言ではない印象を受けました。

シリコンバレーのような場所では、シリコンバレーという1つのメジャーリーグの一員になるようなものだそうです。AmazonからMicrosoftに移るというのは、レッドソックスからヤンキースに移るようなものみたい。おはエルズベリー。

専門色の高い知的労働者の世界は、プロ野球選手とよく似ていると思います。重要なのは流動性。この風潮は全体的なコンセンサスになると良いなぁと思いました。能力が高い人が集う世界は、できる人にあわせたほうが絶対に良いので。

エンジニアがエンジニアを評価する

第3章の転職のセクションがとても面白かったです。まずは電話面接(と言ってもSkypeのようなチャットツールでの面接)があって、そこでも腕試しにコードを書くことを求められるそうです。アメリカは広大ですし時差もありますから、オンサイトで呼びつけるのは最後の最後なんですね。

電話面接をクリアしたあとには、ホワイトボードコーディング面接が待っています。これを突破して初めて内定となるそうです。ホワイトボードコーディング面接については、本書の第4章に詳しく書いてありますのでご参照下さい。

最終的にはフェローかマネージャー

それしか無いもんね。技術を極めてピラミッドの頂点を目指すか、マネージャーとなって守備範囲を広げていくか。ただ、本書にあったのが「自分は仕事で全くコードを書かないのは無理だ」と主張して、マネージャーとしてのランクを1つ下げてまで自分でコードを書くことを選んだケースがあるそうです。すごいな〜。

英語はどこまで出来ればいいんですか?

読み書きと文法がわかれば生きていけるし、ネイティブ以上にもバイリンガルにもそう簡単にはなれないから、英語よりも仕事ができるということが一番重要だって書いてありました。R社の公用語の試みはどうなっているんでしょう。言語を統一するメリットはどこにあったのか、どこかのメディアが記事して欲しいです。脱線しました。

自分の足元を見直す一冊

本書ではアメリカに移るということで発する外国人としての生活環境や、日本的では無い就業環境に多く触れています。特にコアタイムが無いのは素晴らしい。時差もあるし、全員が同じ場所を共有できない前提で仕事が進められる仕組みづくりは大いに参考になりました。それだけに、自分が所属している組織が何を持って評価をしているのか、評価の良し悪しはどこでなされているのかを理解できていないと面食らうことになるのでしょう。

本書を読んで隣の芝生の感じながら、自分にとって譲れないものと目指したいものは何なのかを見直すの一冊となると思います。エンジニアの採用フローなんかはすごく面白かったので、ぜひご一読あれ。