近頃話題のDX、本当は何をやればいいの？
最近、デジタル・トランスフォーメーション(以後、DX)というキーワードが浸透してきているのを感じると共に、以下のような悲観的な意見をちょこちょこと見かけます。
２０２０年は「デジタル・トランスフォーメーション」がキーワードとなって、様々な情報技術が一般の企業に導入されて、生産効率の向上などを目指しますが、実際には、ほとんどが計画倒れに終わります。そこで得をするのは 、それを請け負う IT ベンダーだけでしょう。#メルマガのネタ #2020年の展望
— Satoshi Nakajima (@snakajima) 2019年12月13日
正直、儲けさせていただく側の立場である私としても、計画倒れになるのを同様に危惧しています。
社会価値が無いですよね。
…というわけで、そうならないために、私なりに正しいDXのやりかたについて、本エントリにて説明させていただきます。
少しでも参考になれば幸いでございます。
そもそもDXって何？
まずは、経済産業省から出ているレポートを見てください。
色々と課題が書いてありますが、企業は以下の指針に則って、IT投資対策をした方が良いと記載されてます。
この画像だけみればほぼOKです。
効率の良い投資方法や、システム構築の組織やプロセスについて言及されているだけで、具体的にどう変わっていくべきか？の指針は示されていません。
具体的な変更の指針は、業界ごと会社ごとに異なるため、国が一括で指定するのが難しいのは理解できます。
とは言え、このままでは「2025年の崖」という言葉だけが独り歩きして「必要性の薄い基幹系システムのリニューアル」が実施されたり、具体的な減税があるIoT関連だけに投資がなされそう。
それは、経済産業省も本望ではないはず。
では何をするの？
DXを成功させるには、各会社のIT投資に対する考え方を変える必要があります。
具体的には
コスト削減、業務効率化 から 売上・利益アップ
への意識改革です。
コスト削減、業務効率化は、既存のビジネスを前提にして、プロセスを自動化したり、不要なプロセスを排除したりといった行為です。
既存ビジネスの延長線の中で考えていて、いわゆる連続的成長になります。
これはDXではありません。
では、売上・利益アップで考えると何を変える必要があるのか？
それは、
何を売るか？どう売るか？を起点にIT投資を考える
ことになります。
この過程で、顧客が望んでいるものを考え、売場をオンラインに変えよう、契約をサブスクリプションに変えよう等のビジネスモデルが変わるような、非連続的な成長が出てきます。
ケーススタディ
実際、自分がDXを推進する立場になったとして、衰退産業の象徴としての「本屋さん」をDXするケースを考えてみましょう。
いままでのIT化発想だと・・・
- 無駄な店舗オペレーションを最適化
- 売れ筋商品をいち早くつかんで目立つ棚に置く
- 店員不要な無人レジ化
- 流行のキャッシュレスに対応
といった提案になっていました。
では、DX的な発想で考えてみましょう。
- 店舗に来るまで分からなかった在庫をネットで検索できるようにする
- 見つかった書籍をボタン一つで15分後には宅配できるようにする
- 自分の買った本を書店の中で格安に保管できるようにする
- 保管している中古の書籍をその場で中古販売できるようにする
- 書店経由で電子書籍を買ったお客様にはリアルな本を無償で貸し出す
- 色々な書籍が読める体験をサブスクリプションで提供する
といった具合です。
1つ1つのアイディアについて説明は省きますが、全てのアイディアで、書籍を売って終わりだった顧客との関係性を、継続的に取引が出来る関係性へと変えています。
また、地域に密着したリアル店舗という強みを最大限に発揮することで、ネットの脅威(Amazon)に対抗できます。
これが正しいDX的な発想です。
それだけではDXには足りない
実は上記したアイディアを実施して、仮に上手く行ったとしても、DXには足りません。
他のお店や、大手事業社に真似られて終わりです。
では、何が必要か？それはデータです。
色々なところで「データが大事！データが大事！」と何度も見かけているかもしれませんが、まさにデータが大事です。
顧客との関係構築するうえでえたデータは、他社は早々追いつけません。
そのビジネスにおいての一等地を、先に抑える感覚に近いです。
また、データが膨大になればなるほど、改善や予測がしやすくなります。
一見、同じサービスを提供しているように見えて、事実の積み上げであるデータを元に強くなっていったビジネスと、真似ただけのビジネスでは、中身がまるで違うでしょう。
まとめ
DXという抽象的な言葉を、私なりに具体的に説明してみました。
そもそも正確な定義のない言葉なので、私の説明とは意見が違うという人も多数いらっしゃるでしょう。
重要なことは、デジタル化した社会において、最適なIT投資をしていく際に、誤った方向に行かないことです。
自社のやろうとしているDXが正しいか？もっと良い未来はないのか？常に意識して、恐れずに変えていきましょう。
壁打ちでも良いので、まずは相談相手が欲しい場合は、以下の会社までお問い合わせくださいませ【PR】
人月単価も需要と供給で決まるけど、簡単に上げられるよ
最近、3連休多すぎません？
ダラダラする時間があったので、またまたblog書いてみました。
ITエンジニアを経験している人なら、一度は聞いたことがあるだろう人月単価。
今日は、この人月単価についてBlogにまとめます。
■人月単価は何によって決まるのか？
人月単価は、その人の持っているスキルの高さによって決まると思っている人はいませんか？
あと、会社名によって決まる、とか笑
それ、全くの間違いです。
他の大多数の商品と同様で、需要と供給で単価が決まります。
その辺の説明をします。
■需要と供給とは何か？
「プログラミング言語別の年収ランキング」といったものを見たことが無いでしょうか？
最近だと、GoとかScalaあたりの年収が高い！みたいなことが言われています。
この理由、分かりますか？皆さんなら分かりますよね？
単純に、企業が求める技術者数と、それに応えられる技術者数のギャップでそうなってます
もっと分かりやすく言えば、GoやScalaは使ってる技術者が少ないってことです。
需要と供給のギャップが大きい技術が使えるエンジニアほど、人月単価が高いということになります。
■スキルの高さに連動している？
同じ説明になりますが、使っている人が少ない技術を使いこなせるというだけでは価格は上がりません。
買う側が、その技術を求めていないといけません。
買う側＝企業ですが、企業は合理的に利用技術を選択するので、今後廃れない技術か？今後優位性のある技術か？といったあたりを見て、利用技術は選択されます。
・・・まぁ、かっこよく「合理的に」とか書きましたが、単純に言えば「権威が使い始めた」「流行っている」という理由で選ばれます笑
権威(GoogleとかGoogleとかGoogleとか)が推奨し、かつ流行っている技術は、大体、技術好きな人が先行して使っています。
そのため、そういったスキルレベルの高い人(技術好き)は、年収の高い仕事が選びやすいというのは事実としてあります。
■もうちょっと複雑な要素も絡む
人月単価という話になると、企業対企業の関係性が絡んできます。
大手企業は色々な制約のもと、大手SIerにしか開発案件をお願いできません。
そのせいで、人月単価が高止まりします。
よく「大手に頼むと高い！もっと安いところもいっぱいあるのに！」と文句を言うエンドユーザもいますが、これは大きな間違いです。
大手しか受けられないような制約があるから、大手しか提案しないし、安く出来ないのです。
ようするに、これも需要と供給のバランスによりこうなっているのです。
■いわゆる低スキルが高単価ということもある
最新の技術に明るくて、小規模開発のPMが出来るSEの単価が、月150万だったとします。
どうです？よく聞く感じの単価じゃないですか？
でも、マーケティングの知識が少しあってSQLが書けるだけの技術者(と呼んでいいのか…)の単価が、200〜300万円みたいな、普通じゃないことが起こります。
ちなみに、ここでいうマーケティングの知識というのも、本を数冊読んで、２～３週間もキャッチアップすれば誰でも理解できるようなレベルの話です。
「SQLだけしか書けない＝低スキル＝低単価」だったはずなのに、高単価で出回ることがあるのですね。
また、こういう例もあります。
「COBOL＝絶滅していくスキル＝高齢技術者で低単価」みたいなイメージがあったかと思いますが、これも実は違います。
「COBOL＝絶滅していくスキル」というイメージが強すぎたせいか、COBOLが消滅する速度より早く、技術者の数が減ってしまいました。
また、長期間安定的にメンテナンスしてくれる高齢技術者に一定の需要があり、意外とそこそこの単価で取引されています。
若い人たちに、今更、AS/400＋COBOL覚えて！とか言えませんし、お願いしたら速攻辞めちゃうますよね？そりゃ、技術者が増えるわけがない。(ある意味、高スキル…)
こういった需要と供給のギャップで、低スキルの方々も高単価になったりします。
■需要と供給はコントロールできる
供給に関しては、望まれている流行っている技術を学べばいいので、これは技術者本人の努力でコントロール可能です。
それは分かりやすいかと思いますが、実は需要側もコントロールが可能です。
企業が気づいてない需要を作っていく、気付かせば良いのですが、そこまで難しくありません。
■需要を作り出す方法
需要を作り出す＝高単価の仕事を作り出す、と定義します。
そのやり方は、低単価な仕事に付加価値を付けて高単価にし、企業にそちらの方が良いと思わせるだけです。
企業と言うのは、過剰に失敗を恐れます。
なので、私に頼めば失敗リスク減りますよ、と言うのが一番簡単な需要創出です。
■失敗リスクを減らす方法は？
手っ取り早いのは、業務に詳しくなることです。
企業のIT担当者(主に情シス)は、自社の業務に詳しくないケースが多いです。
何故ならITは専門職なので、営業や販売員などの現場を経験をしてない人が多いからです。
また、仮に経験していたとしても、その担当部分しか詳しくない上に、業界知識や競合他社の状況等は把握していないケースが多いです。
対して、ITエンジニアの方は現場を選べるので、複数回同じ業界の仕事をこなすと、知識が増えます。
加えて、複数社の実例を知っていると言う、プラスの特典が付きます。
このエンジニアに頼むと高額になるけど、失敗しなさそう、と思わせることが出来ます。
■単価をあげたいなら
技術好きになりましょう。
やる仕事は選びましょう。
その価値を企業にPRしよう。
2020年度から始まる小学校のプログラミング教育では「ITシステム化教育」もして欲しい
■2020年度から小学校でプログラミング教育が始まるそうです
小学1年生の子を持つ親としても、SIerの経営者としても、ちょっと気になるトピックでしたので、何を教えるのかを調べてみました。
その際、たまたま見かけた記事ですが、良記事だったので触発されました。
私も1つ意見を書いておきます。
上記記事では、以下のような記載があります。
このプログラミング教育の目的は、いわゆるプログラミングの技術を習得することではなく、「プログラミング的思考」を身につけることだそうです。
簡単に言えば「目的達成に必要な手順を論理的に考える力」ということです。
「目標達成に必要な手順」とは、プログラムそのものを指すので、言い換えると「プログラムを論理的に考える力」です。
「プログラムを書くこと」が重要ではなく「プログラムを書ける能力(論理的思考)」が重要である、ということですね。
完全に同意です。
プログラミングのスタイル、利用される言語、実行する環境などは、時代とともにガンガン変わっていきます。
小学校時代に習ったプログラミングスキルが、大学を出た後にそのまま通用するとは考えられません。
そもそも、ほとんどの人がプログラマにはならないので、具体的な言語スキルをみんなに学ばせるのは時間の無駄とすら言えます。
それであれば「プログラムを論理的に考える力」といった普遍的な技術を学ぶことこそ重要というのは、非常に理にかなっています。
・・・であればこそ「ITシステム化教育」についても勉強に組み込んで欲しいなぁと思った次第です。
論理力を鍛えるだけであれば、既存の枠組みの中で、読解力や算数の力を伸ばせば良いだけで、あえて「プログラミング」を学ばせるなら、それを利用する目的も正しく教えて欲しい。
■ITシステム化教育で何を学ばせたいのか？
ITを駆使する職業であるSIerであっても、プログラムを書くという行為は一部の手段です。
最終的に作りたいのは「ITシステム」です。
また、ITシステムは利用開始されるタイミングからが本当のスタートです。
初期に作った原形のまま何も手を加えられないITシステムなど、ほぼ存在しません。
仮にあったとしても、そのシステムは「ほとんど利用されていない」状態でしょう。
では、そういったITシステムを構築する上で必要な「アジャイル型開発」の手法を学ばせれば良いのか？・・・というと、そう主張したいわけではありません。
では、何を学んで欲しいのか？
それはズバリ、ITシステム化するメリット、ITシステム化する観点を学んで欲しい。
しかも一度作ったら終わりではなく改善し続けるというITシステム特有の観点を学んで欲しい。
■ITシステム化するメリットはどう学ばせるか？
ITシステム化されたことで生活がどう変わったのか？についての歴史を学ぶ授業をやれば良いと思います。
例えば、スマートフォンの普及でどう生活が変わっていったのかなどは良い例です。
スマホ普及前と普及後を比較して、どんなメリットが得られるようになったか？を例示すればよいでしょう。
または、やや古い例になってしまいますが、切符からSUICA・PASMOに変わった例は、小学生にも伝わりやすいのではないでしょうか？
IT化するメリットが非常に分かりやすく伝わるとともに、IT化の楽しさ、面白さが伝わると日本にとって良い未来が待っていると思います。
また、このような教え方をすることで、歴史の暗記物教科に出来るので、教えるのも、テスト化するのも簡単という学校側のメリットも挙げておきます(笑
■ITシステム化する観点はどう学ばせるか？
難しいのは「ITシステム化する観点」を学ばせることです。
ITシステム化する観点としては、自動化、細分化、情報共有化など様々な点が挙げられますが、個別の事象を抽象化して理解する必要があることを、小学生相手に教えるのはやや難しいかな？とは思います。
また、ITシステム化する観点を教育・計測するためには、自由回答式の問題とその回答を用意する必要があり、教えるのも、テスト化するのも負荷が高いと思われます。
とは言え、ここを避けてしまうと『IT化する未来は明るいけど「では、どうするの？」に応える力が育たない』とあっては、片手落ちも良いところです。
現状の日本のDX(デジタル・トランスフォーメーション)が進んでいない最大の理由でもあります。
■改善し続けるというITシステム特有の観点について
「サービスや商品を作って販売して終わり」ではなく「むしろサービスを提供してからスタート」という、ITサービス特有の仕組みも合わせて教えてほしいです。
これも成功している事例がたくさんあるので、事例で学ばせれば良いでしょう。
あえて、この観点も学んで欲しいと思う理由は、日本人特有の完璧主義というか、他人のちょっとしたミスに対する厳しさが、いかにITシステム製作と相性が悪いのかを、早いうちから理解しておいて欲しいからです。
■銀の弾丸はないけど狼人間は倒せる
今回の教育メニュー改善の目的は、たぶん、国際社会、IT化社会において、どんどん力を失っている日本を、いかに立ち直らせるか？だと思ってます。
国の一部には「GAFAのようなIT企業に対する規制強化で何とかしよう」と言うような馬鹿馬鹿しい考えもあります。
そういう使えない銀の弾丸とは関係なく、日本の国力をいかに正しく上げていくかを真剣に考えてた人達の成果だと思います。
だからこそ、もう1歩踏み込んだITの力を使って、より社会を豊かに変えて行く、そういった力を伸ばして欲しいと思った次第です。
BizDevOpsで気をつけること
昨日(2018/9/20)こんな記事がシェアされてきました。
クラウドサーバー側がCI/CDの脆弱性までサポートしてくれる時代になったかぁ、と感慨深いですね。
…とは思うものの、未だに「CI/CDって何それ？美味しいの？」みたいなIT技術者が、沢山いるのも事実。
さて、そんな訳で、これからBizDevOpsに取り組みますよ！取り組み始めたばかり！という人向けに、この辺を積極的に取り組んできた我々のナレッジから、気をつけるべき点をまとめておきます。
ご興味あれば読んでくだされ。
そもそもBizDevOpsとは？
知ってる方は、この項目は無視してください。
BizDevOpsを要約すると、ITシステム開発における推進方法、体制について表した言葉で、ビジネス部門、運用・開発部門が一緒に作ってこうぜ！ビジネス要件に合わせて、短い期間で改善してこうぜ！という内容です。
今まではビジネス部門が企画して、開発部門が要件定義し、外注SIerに丸投げして、それを運用部門が嫌々使う(社内システム)なり、ビジネス部門が「これじゃない」と不満タラタラで売ってくる(外販サービス)といった事態になっていたわけです。
それで駄目なのは明白なので、チーム一丸となって、利用者(顧客)目線でシステム開発して行きましょう、と言う至極まっとうな話になったわけです。
Dev部分にフォーカスすれば、1日100回でもリリース出来るような環境を用意することとなります。
BizDevOps(DevOps)のダメなところ
ただし、これが必ずしも上手くいかない。
上手く行かない話としては、こんな感じでしょう。
継続的インテグレーションは死んだ | To Be Decided
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ
DevOps あるいは BizDevOps におけるパワーバランス - ☕ B1AC1CC0FFEE
BizDevOps自体は素晴らしい考えだけど、なかなかうまく運用が回らない、という話ですね。
原因としては、文化・組織の壁がある、強力な推進役がいない、過剰なビジネス優先(品質ボロボロ)になりがち、といったところでしょうか？(大手企業あるあるですね)
例示したブログが2年くらい前なので、いまでは変わってる可能性もありますが、未だに、多数がこんな感じかな？とは思います。
どうやって上手く回すの？
上記の問題点を読むと、「組織を変えましょう！文化を変えましょう！決裁者を推進役に据えよう！」みたいな結論になっちゃいますが、それはなかなか難しい上に、それぞれの企業に合わせて丁寧に解決していくしかないところです。
今回伝えたいのは、どんな企業であっても、使える共通のポイントです。
2つほどあります。
1.対象ITシステムでチームをつくり、オーナーを決める
各部門には部門長がいますが、個別のITシステムの判断を、そこに依存させないようにすべきでしょう。
部門側の権利としては、チームにメンバーをアサインするかしないか？だけにしておくと良いと思います。
あとは、オーナーが全てを決める。
2.ミッション・ビジョン・バリューを作る
BizDevOpsも結局は手段です。
このチーム、このシステムのミッション・ビジョン・バリューを決めた方が良いでしょう。
そこに向かって頑張るべきです。
また、短いサイクルで改善すべきなので、都度都度、要件定義などやってられません。
誰もが判断を間違えない軸が必要です。
目先の要望や売上に振り回されそうになったら、ここに立ち返りましょう。
まとめ
BizDevOps自体は特に難しいことではないですし、色々と挑戦して失敗して、それでも改善し続ければ良いモノになっていくと思います。
是非、挑戦してみてください！
オフショア開発の正しい使い方
最近よく「技術者が採用できない」という悩みを相談されます。
昨今の技術者不足は説明するまでも無いかと思いますが、いざ自分でも探してみると本当に痛感させられます。
テック会社を経営している身としては、技術者採用がダイレクトに経営数値につながるので、本当に困っちゃいます。(皆さん採用するの辞めてw)
さて、そんな時は皆さんどうしてますか？
私の場合、ケースによってですが「オフショア開発どうですか？」と提案してます。
…で、大体皆さん同じような反応が返ってきます。
「だってオフショア開発って失敗するでしょ？うちじゃ使えないよ」
はいはい、分かります。
そう思っちゃう気持ち、よくわかります。
でもこれ誤解なんです！
今回のエントリーでは、その辺の誤解を解いていきます。
興味ある方は、是非お読みくだされ！
オフショア開発は上手くいかない？
正直、上手くいってないケースは多いです。
ネット記事では成功してるケースもありますが、あれは企業のPRのためで、話半分で見た方が良いし、そう読んでる方も多いでしょう。
そして、失敗ケースは表に出ないため、詳細をぼやかした「悪い噂」となって伝わるのですが、残念ながら、この悪い噂の方が圧倒的に多いです。
こうした事実は、オフショア開発を商品としている我々としては困ったものです。
では、実態としては、どうか？
数年間オフショア開発をやっている我々からするとハッキリ見えている事があります。
それは「成功しやすい案件では大体成功し、失敗しやすい案件では大体失敗する」ということです。
要するに「正しい利用用途が判れば、使えますよ」ということ。
これが分かってないため、不向きな案件に利用して、失敗しているのでしょう。
上手くいかない理由
正しい利用用途を説明する前に、失敗する理由、不向きな理由？と言ってもいいかもしれませんが、それを説明します。
よく言われる話ですが、上手くいかない理由として「4つの壁」が挙げられます。
- 言葉の壁
- 文化の壁
- 距離の壁
- 高品質の壁
この壁達が、高いこと、高いこと。
細かく一つ一つ説明する必要はないと思いますが、共通して言えるのは、日本人は日本語しか話せないせいか、異文化への理解、許容範囲が狭いです。
弊社の提供しているオフショア開発はベトナム拠点ですが、中国やフィリピン、他のアジア各国であっても似た話になるかと思います。
この辺を理解せずに、かつ不向きな用途で使ったら、そりゃー失敗もしますよ。
お客様の要望と提供サービスに矛盾がある
「今すぐオフショア開発を利用したい！」という依頼をいただくケースがあります。
売手としては大変ありがたいのですが、これらも大体は失敗に終わります。
こういう依頼をざっくり分類すると以下になります。
- 激安で作りたい
- 少額で試しに利用したい
- スポットで大量に技術者が欲しい
本来、断らないと行けないのですよ、こういう依頼は。
でも、オフショアについているイメージが、
「安い」「少額で頼める」「大量に技術者がいる」
となってしまっているので、売手側もついつい売っちゃうわけです。
開発会社と名乗りながら、正社員が営業しかいないような「ブラックSES会社」が、まともに教育してないような外国人技術者を、無理やり売っちゃうわけですよねぇ…。
こうして、失敗案件が増えていくわけです。
正しい利用用途・方法は？
ズバリ、以下の3つのケースであれば、利用をオススメしています。
- 大規模受託開発
- 小規模開発チーム
- 運用サポート
大規模受託開発での利用
最近は少なくなっていますが、大型SI案件をやる場合、ガチガチのウォーターフォール型で製造のみを大量の人数にやらせます。
これにはオフショア開発が使えます。
テストケース、コード品質さえ担保されれば、誰が書いても同じわけですから、安ければ安いほど良い。
事実、かなり安く抑えられます。
王道の使い方ですね。
この際、新興のオフショア会社に発注するではなく、大手オフショア会社にした方が安全でしょう。
小規模開発チームでの利用
「小規模の単発開発での利用」ではないですよ！小規模開発"チーム"での利用です。
開発者が数名しかいないような小規模チームに、技術者を追加したい場合、SES契約で日本人を追加しても良いのですが、オフショアメンバーを加えた方が、それに比べて30〜40%くらいは安く済みます。
社員を雇えれば、それに越したことはありませんが、すぐに社員を雇えないのであれば、この方法がオススメです。
いわゆるラボ型開発と言われるやつです。
運用サポートでの利用
ある程度マニュアル化出来る比較的単純作業を長期間お願いするのも向いてます。
定期的にバージョンアップがあり、その都度、テスト工数が必要だったり、手運用が無くせない場合などです。
こちらもラボ型開発ですね。
小規模チームで、かつ運用も兼ねているような場合にはラボ型開発は最適です。
他にも選択肢があるケース
売手の悩みですが、オフショア開発には同業以外にも多数の競合がいます。
代表的な競合が、以下の2つ。
クラウドソーシングとニアショア開発です。
ご相談いただく案件によっては、クラウドソーシングとニアショアの方が良い場合があります。
具体的には、以下のようなケースです。
小額受託開発
これは、完全にクラウドソーシングに依頼した方が良いです。
またはフリーランサーに直接依頼するなどですね。
100万円未満の小さい案件では、絶対にそうした方が良いです。
小～中規模受託開発
小～中規模受託開発であれば、ニアショアがオススメです。
東京の人月単価と比べて20～30%安いので、オフショア開発と比較しても悪くないケースが多いです。
「会って仕事をする」ことに拘りがないのであれば、これもオススメです。
上記二つのケースは、オフショア開発でも一応対応は出来るのですが、上記に比べると満足のいく結果にならないケースもあります。
私なら積極的に提案しません。
まとめ
長々と書きましたが、簡単にまとめます。
- オフショア開発には向き不向きがある
- 向いてる案件は、大規模開発、小規模チーム、運用サポート
そして、使い始めるなら今です！
上記したような誤解があるので、未だにオフショア開発は人気がありません。
逆に人気がない今だからこそ、適正以下の価格で手に入ります。
弊社でもラボ型開発の提供をやっているので、是非、お問い合わせくださいませ～♪
システム内製には良い内製と悪い内製がある
せっかく良いこと言っているのに、業界批判によるプチ炎上狙いの記事になっていて、正しく伝わらない。
これは、勿体ない。
お節介ながら、私が一部抜粋&追記させてもらいます。
悪い内製
抜粋「パッケージ製品かクラウドでも使えばよい基幹系システムでさえ、個々のユーザー企業ごとに作る。
その結果、業務の効率化などに寄与するどころか、非効率な業務を“固定”してしまい、競争力を奪う。」
仮に、単体の製品だけでは実現できない自社オリジナルな基幹業務があったとしても、その部分だけカスタマイズすれば良い。
また、別製品と組み合わせれば大抵のことは可能になる。
一般的なツールが想定している業務から、あまりにもかけ離れた業務を行っている場合は、業務を見直した方が良い。
その上で、新しい製品が出たら、都度、業務を変えて乗り換えるくらいの感覚でいる方が良い。
良い内製
抜粋「ユーザー企業もようやく、バックヤードのシステムにカネを投じるムダに気付き、デジタル分野に投資する。
戦略的なシステムについては内製化し、自らだけでは実現できない領域ではITベンチャーとも組む。」
Google、Facebook、Amazonなど、彼らはオンリーワンのシステムを持っているが、これに外部の製品を使う必要はない。
差別化要因になるシステムは、内製すべきだし、惜しみなく投資すべきである。
この際、初期開発部分を、SIerに一括で丸投げするのは絶対にダメ。
「SIerを使うな」ということではなく「丸投げ」がダメである。
自社で内製し、SIerからは「テクノロジー支援」を受けるべきである。
「テクノロジー支援」が何を指すかについては、こちらのエントリーを是非読んでほしい。
www.ryuzee.com
6年前に書かれているものだが良いエントリー。
これを日本のSIerが、当たり前のように実現出来ていないのが、残念でならない。
ITサービスで売れるものを作るのは簡単！とりあえず売るまでは…
受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング
このスライドが、なかなか良かった。
弊社も似たようなことをしているので、非常に共感できる。
私もSIerがプロダクト開発に乗り出す際に重要な点をブログにしておく。
最初に断っておくが、自社の経験と、私の知ってる他社事例だけで書いてるので、必ずしも正しいわけではない。
1.売れるサービスをつくるのは簡単
少数のお客様相手に、売れるサービスを作るのは簡単。
その少数の声を聞いて、欲しいという通りに作るだけ。
受託開発にかなり近い。
たぶん、コンシューマー向けであっても一緒。
数名の「この機能があって300円なら使いたい」みたいなニーズを聞いて、作るだけ。
100発100中とまではいかないが、かなりの確率で売れる。
2.思ったより売れる
一定数売れたサービスは思ったよりも売れる。
SNS、ブログなどで宣伝したり、少額でも広告を打てば、必ず反応があるし、意外と買ってくれる。
世間は広いな、と。
3.継続的な黒字化は難しい
そりゃそうだ。
営業頑張るか、マーケティング頑張るか、何かしら頑張るしかない。
少数売れてるのだから、ニーズはあるはず。
「長くやってる」と言うことも評価されるので、頑張り続ければ何とかなるケースもある。
ここを耐える体力は必要。
4.黒字化してからも大変
黒字化できる程度に売れだすと、サポートや既存バグに悩まされる。
既存の大きい競合に目をつけられたり、新規競合も出てくる。
どんなに差別化しても、その差は長続きしない。
と言うわけで、作るば意外と売れるし、頑張ればなんとかなる。
SESや、受託開発しかやってないSIerさんは、是非自社プロダクトに挑戦して欲しい。
