SIer関連メモ書き

SIer関連のメモ書きをしておきます。お客様向けも、業界人向けも、ごっちゃまぜ。

オフショア開発の正しい使い方

最近よく「技術者が採用できない」という悩みを相談されます。

昨今の技術者不足は説明するまでも無いかと思いますが、いざ自分でも探してみると本当に痛感させられます。
テック会社を経営している身としては、技術者採用がダイレクトに経営数値につながるので、本当に困っちゃいます。(皆さん採用するの辞めてw)

さて、そんな時は皆さんどうしてますか?
私の場合、ケースによってですが「オフショア開発どうですか?」と提案してます。

…で、大体皆さん同じような反応が返ってきます。

「だってオフショア開発って失敗するでしょ?うちじゃ使えないよ」

はいはい、分かります。
そう思っちゃう気持ち、よくわかります。

でもこれ誤解なんです!

今回のエントリーでは、その辺の誤解を解いていきます。
興味ある方は、是非お読みくだされ!

 

オフショア開発は上手くいかない?

正直、上手くいってないケースは多いです。
ネット記事では成功してるケースもありますが、あれは企業のPRのためで、話半分で見た方が良いし、そう読んでる方も多いでしょう。
そして、失敗ケースは表に出ないため、詳細をぼやかした「悪い噂」となって伝わるのですが、残念ながら、この悪い噂の方が圧倒的に多いです。

こうした事実は、オフショア開発を商品としている我々としては困ったものです。

では、実態としては、どうか?

数年間オフショア開発をやっている我々からするとハッキリ見えている事があります。
それは「成功しやすい案件では大体成功し、失敗しやすい案件では大体失敗する」ということです。
要するに「正しい利用用途が判れば、使えますよ」ということ。
これが分かってないため、不向きな案件に利用して、失敗しているのでしょう。

 

上手くいかない理由

正しい利用用途を説明する前に、失敗する理由、不向きな理由?と言ってもいいかもしれませんが、それを説明します。
よく言われる話ですが、上手くいかない理由として「4つの壁」が挙げられます。

  • 言葉の壁
  • 文化の壁
  • 距離の壁
  • 高品質の壁

この壁達が、高いこと、高いこと。
細かく一つ一つ説明する必要はないと思いますが、共通して言えるのは、日本人は日本語しか話せないせいか、異文化への理解、許容範囲が狭いです。

弊社の提供しているオフショア開発はベトナム拠点ですが、中国やフィリピン、他のアジア各国であっても似た話になるかと思います。

この辺を理解せずに、かつ不向きな用途で使ったら、そりゃー失敗もしますよ。

お客様の要望と提供サービスに矛盾がある

「今すぐオフショア開発を利用したい!」という依頼をいただくケースがあります。
売手としては大変ありがたいのですが、これらも大体は失敗に終わります。

こういう依頼をざっくり分類すると以下になります。

  • 激安で作りたい
  • 少額で試しに利用したい
  • スポットで大量に技術者が欲しい

本来、断らないと行けないのですよ、こういう依頼は。

でも、オフショアについているイメージが、
「安い」「少額で頼める」「大量に技術者がいる」
となってしまっているので、売手側もついつい売っちゃうわけです。

開発会社と名乗りながら、正社員が営業しかいないような「ブラックSES会社」が、まともに教育してないような外国人技術者を、無理やり売っちゃうわけですよねぇ…。

こうして、失敗案件が増えていくわけです。

 

正しい利用用途・方法は?

ズバリ、以下の3つのケースであれば、利用をオススメしています。

  • 大規模受託開発
  • 小規模開発チーム
  • 運用サポート

 

大規模受託開発での利用

最近は少なくなっていますが、大型SI案件をやる場合、ガチガチのウォーターフォール型で製造のみを大量の人数にやらせます。
これにはオフショア開発が使えます。
テストケース、コード品質さえ担保されれば、誰が書いても同じわけですから、安ければ安いほど良い。
事実、かなり安く抑えられます。
王道の使い方ですね。
この際、新興のオフショア会社に発注するではなく、大手オフショア会社にした方が安全でしょう。

小規模開発チームでの利用

「小規模の単発開発での利用」ではないですよ!小規模開発"チーム"での利用です。
開発者が数名しかいないような小規模チームに、技術者を追加したい場合、SES契約で日本人を追加しても良いのですが、オフショアメンバーを加えた方が、それに比べて30〜40%くらいは安く済みます。
社員を雇えれば、それに越したことはありませんが、すぐに社員を雇えないのであれば、この方法がオススメです。
いわゆるラボ型開発と言われるやつです。

運用サポートでの利用

ある程度マニュアル化出来る比較的単純作業を長期間お願いするのも向いてます。
定期的にバージョンアップがあり、その都度、テスト工数が必要だったり、手運用が無くせない場合などです。
こちらもラボ型開発ですね。
小規模チームで、かつ運用も兼ねているような場合にはラボ型開発は最適です。

 

他にも選択肢があるケース

売手の悩みですが、オフショア開発には同業以外にも多数の競合がいます。
代表的な競合が、以下の2つ。
クラウドソーシングとニアショア開発です。
ご相談いただく案件によっては、クラウドソーシングとニアショアの方が良い場合があります。

具体的には、以下のようなケースです。

小額受託開発

これは、完全にクラウドソーシングに依頼した方が良いです。
またはフリーランサーに直接依頼するなどですね。
100万円未満の小さい案件では、絶対にそうした方が良いです。

小~中規模受託開発

小~中規模受託開発であれば、ニアショアがオススメです。
東京の人月単価と比べて20~30%安いので、オフショア開発と比較しても悪くないケースが多いです。
「会って仕事をする」ことに拘りがないのであれば、これもオススメです。

上記二つのケースは、オフショア開発でも一応対応は出来るのですが、上記に比べると満足のいく結果にならないケースもあります。
私なら積極的に提案しません。

 

まとめ

長々と書きましたが、簡単にまとめます。

  • オフショア開発には向き不向きがある
  • 向いてる案件は、大規模開発、小規模チーム、運用サポート

そして、使い始めるなら今です!

上記したような誤解があるので、未だにオフショア開発は人気がありません。
逆に人気がない今だからこそ、適正以下の価格で手に入ります。

弊社でもラボ型開発の提供をやっているので、是非、お問い合わせくださいませ~♪

お問い合わせ | デジタルマーケティングテクノロジーのEVERRISE(エバーライズ)

システム内製には良い内製と悪い内製がある

itpro.nikkeibp.co.jp

せっかく良いこと言っているのに、業界批判によるプチ炎上狙いの記事になっていて、正しく伝わらない。
これは、勿体ない。
お節介ながら、私が一部抜粋&追記させてもらいます。

 

悪い内製

抜粋「パッケージ製品かクラウドでも使えばよい基幹系システムでさえ、個々のユーザー企業ごとに作る。
その結果、業務の効率化などに寄与するどころか、非効率な業務を“固定”してしまい、競争力を奪う。」

仮に、単体の製品だけでは実現できない自社オリジナルな基幹業務があったとしても、その部分だけカスタマイズすれば良い。
また、別製品と組み合わせれば大抵のことは可能になる。

一般的なツールが想定している業務から、あまりにもかけ離れた業務を行っている場合は、業務を見直した方が良い。
その上で、新しい製品が出たら、都度、業務を変えて乗り換えるくらいの感覚でいる方が良い。

 

良い内製

抜粋「ユーザー企業もようやく、バックヤードのシステムにカネを投じるムダに気付き、デジタル分野に投資する。
戦略的なシステムについては内製化し、自らだけでは実現できない領域ではITベンチャーとも組む。」

GoogleFacebookAmazonなど、彼らはオンリーワンのシステムを持っているが、これに外部の製品を使う必要はない。
差別化要因になるシステムは、内製すべきだし、惜しみなく投資すべきである。

この際、初期開発部分を、SIerに一括で丸投げするのは絶対にダメ。
SIerを使うな」ということではなく「丸投げ」がダメである。
自社で内製し、SIerからは「テクノロジー支援」を受けるべきである。

 

「テクノロジー支援」が何を指すかについては、こちらのエントリーを是非読んでほしい。

www.ryuzee.com
6年前に書かれているものだが良いエントリー。
これを日本のSIerが、当たり前のように実現出来ていないのが、残念でならない。

 

ITサービスで売れるものを作るのは簡単!とりあえず売るまでは…

受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング

このスライドが、なかなか良かった。

弊社も似たようなことをしているので、非常に共感できる。

私もSIerがプロダクト開発に乗り出す際に重要な点をブログにしておく。

最初に断っておくが、自社の経験と、私の知ってる他社事例だけで書いてるので、必ずしも正しいわけではない。

 

1.売れるサービスをつくるのは簡単

少数のお客様相手に、売れるサービスを作るのは簡単。

その少数の声を聞いて、欲しいという通りに作るだけ。

受託開発にかなり近い。

たぶん、コンシューマー向けであっても一緒。

数名の「この機能があって300円なら使いたい」みたいなニーズを聞いて、作るだけ。

100発100中とまではいかないが、かなりの確率で売れる。

 

2.思ったより売れる

一定数売れたサービスは思ったよりも売れる。

SNS、ブログなどで宣伝したり、少額でも広告を打てば、必ず反応があるし、意外と買ってくれる。

世間は広いな、と。

 

3.継続的な黒字化は難しい

そりゃそうだ。

営業頑張るか、マーケティング頑張るか、何かしら頑張るしかない。

少数売れてるのだから、ニーズはあるはず。

「長くやってる」と言うことも評価されるので、頑張り続ければ何とかなるケースもある。

ここを耐える体力は必要。

 

4.黒字化してからも大変

黒字化できる程度に売れだすと、サポートや既存バグに悩まされる。

既存の大きい競合に目をつけられたり、新規競合も出てくる。

どんなに差別化しても、その差は長続きしない。

 

と言うわけで、作るば意外と売れるし、頑張ればなんとかなる。

SESや、受託開発しかやってないSIerさんは、是非自社プロダクトに挑戦して欲しい。

 

 

SI業界をあえて賛美する

「SIer が天職です」に必要なこと - SIer関連メモ書き

↑は、約1年前に書いたエントリーですが、いまだに、ちょこちょこ読まれてます。
このエントリーでは「SI業界はちょっとやり方変えれば良い業界ですよ」と言いたかった訳ですが、まだまだ世間的には「SI業界は微妙」と思われているようです。

個人的には、SI業界はとても良い業界だと思っています。
悪く書かれることが多いのですが、どんな業界にも、良い面と悪い面があります。
ことさら悪い面ばかりを書かれるのも気持ち良いものではありません。

…と言う訳で、今回はあえてSI業界を賛美してみます。

 

<SI業界の良いところサマリー>
1.業界が成長している
2.教育がしっかりしている
3.最新技術を触れる
4.ホワイトな職種
5.ITベンチャーにも行きやすい

 

一つ一つ補足します。

 

1.業界が成長している
働く上で、自分がやってる「業界が成長している」ことって、とても大事ですよね?
業界が明るいニュースばかりになりますし、頑張った分が報われやすいです。
その点、SI業界は成長してます。
業界1位のNTTデータのIRをチェックしてみてください。

今期2兆円予定だそうです。相変わらず、絶好調ですね。
素晴らしい!

 

2.教育がしっかりしている
ユーザー企業のIT部門やITベンチャー企業に入って、まともにPG研修を受けられると思ったら大間違いです。
ユーザー企業では、開発プロジェクトを進行するのに必要な管理業務しか学べません。
ITベンチャーでは、サバイバルナイフ1本渡されて、後は自分で頑張れ!と言うのが、ほとんどです。

 

3.最新技術を触れる
そもそも最新技術が必要なシステム開発は、ごく稀です。
そんな中、比較的最新技術に触れる機会が多いのは、SIerです。
なぜかというと、アーキテクチャの提案が自分たちで出来るからです。
ITベンチャーは最新技術をよく使っているイメージもありますが、あれは広報戦略で魅せているだけで、実はそこまで多くありません。

 

4.ホワイトな職種
今、IT技術者はとても貴重な人材です。無理させて辞められたら、大変な損失です。
ブラックな職場は、採用してもすぐ逃げられてしまうので、結果的に、職場環境が極めてホワイトになります。

 

5.ITベンチャーにも行きやすい
自分でベンチャーを立ち上げる自信がない人も、創業間もないベンチャーのCTOであれば狙えます。
根っからベンチャーの人は、散々「SIerの人は駄目」と言いつつも、SIer出身のしっかりした開発プロセスを身に付けた人材を、いつも欲しがってます。


…と言うわけで、IT技術者にとってSIerは、とても良い環境なのでオススメしています。

 

さらに言うと、教育制度が整っていて、最新技術に触れられて、急成長していて、ベンチャーのように挑戦しているSIerが最高の環境となります。

 

え?そんな企業が本当にあるんですか?
実は、あるんです!

 

こういう理想的なSIerで働きたい方は、EVERRISEへ就職、転職をしよう!(笑
株式会社EVERRISE | ベンチャー企業と新卒・就活生をツナグキャリアサイトパッションナビ

 

未熟な職業プログラマが成長する方法

まだまだ未熟な職業プログラマ(以後、PG)の皆さん!

PGとしての成長に、何をすれば良いか迷っていますか?

そんな人向けに、何をすれば実力が伸びるかを、メモっておきます。

コピペするプログラマに足りないもの 〜 プログラミング脳の鍛え方 | Social Change!

ちなみに、このエントリーに刺激を受けて書いております。

 

最初に予防線を張っておきますが、この意見を裏打ちするような実験結果があるわけではないです。
ただし、PG教育担当をしていた何人かの意見の組み合わせなので、たぶん大外しはしてないと思います。

 

まずは、概要から。

  1. 仕事以外で勉強時間を持つこと
  2. 他人のソースコードを読むこと
  3. 正確にマニュアルを読むこと
  4. 言語やアルゴリズムを暗記すること
  5. レビューしてもらうこと
  6. テストコードを書くこと
  7. リファクタリングすること

特に目新しいことは言ってませんが、一応解説もしておきます。

 

1.仕事以外で勉強時間を持つこと

仕事は品質よりも納期優先になりがちです。
加えて、他人の書いたソースコードを使いまわして、まずは動かして、バグ取りして終了となるケースが多いです。(コピペPGですね)
これだと、正しい書き方、一から構築する力が備わりません。

 

2.他人のソースコードを読むこと

とにかく、これをやってない人は多いですね。
業務で求められる必要なソースコードのコピペしかしないから、いつまでたっても自分でソースコードが書けない。
そのためのナレッジを貯めるには、自分で考えて書くことも重要ですが、他人のソースコードを読む方がよっぽど早いです。

 

3.正確にマニュアルを読むこと

これも全然やられてないですね。
正確な言語仕様を理解せずに書いた「とりあえず動くソースコード」が量産されちゃうのは、Google検索の功罪でもありますかね?
例えば、Java8を使うなら、まずはこれを読みましょう。
https://docs.oracle.com/javase/jp/8/

 

4.言語やアルゴリズムを暗記すること

上記したリファレンスもそうですが、大抵、正確な言語仕様やサンプルのアルゴリズムが無料で公開されています。
「ざっと見る」とか「必要な時に読む」ではなく、重要なものは「暗記」しましょう。
Googleで検索して、見つけて、試して・・・」と、やってる時間で、1~2メソッドが出来上がります。

 

5.レビューしてもらうこと

自分の書いたソースコードを指摘してもらいましょう。
バグ発見、仕様の認識ミス防止にも有効ですが、それよりも「リーダブルである」ことと「正しい言語仕様である」ことが重要です。

 

6.テストコードを書くこと

「要望されたものを作る」のと「要望されたものをテストコード付きで作る」のとでは、レベルが1つ違います。
なぜかと言うと、テストコードを書くには、メソッドの役割を1機能に抑えてIN/OUTを明確にする必要があり、適当に作ると、そうはならないからです。

7.リファクタリングすること

1回書いただけで完璧に近いソースコードを書くのは難しいです。
何度も書き直して初めて完成度の高いソースコードが産まれます。
業務中にそんなゆとりは無いかもしれませんが、1回は書き直すつもりで、時間をとった方が良いでしょう。
その結果、どんどん実力があがるし、ソースコードを書く時間も短くなります。

 

まとめ

職業PGをやるなら、ずっと技術を磨かないと生き残れないので、まずは自分の基礎となる力を正しい訓練をして、付けましょう。

基礎力さえつけば、後は楽なもんです。

そこまで、頑張りましょう!

 

超高速開発ツールにSIerの未来を感じた

先日、SI向けの超高速開発ツールをデモンストレーションしていただきました。

どこの企業のツールかは特に触れませんが、その出来に、正直驚きました。

 

話を聞くきっかけは、大先輩から「開発ツールを紹介したい」と言われたので、期待は持たずに、とりあえず話だけを聞くつもりでした。

それが、良い意味で期待を裏切られた訳です。

 

具体的に凄さを説明しておくと、どんな社内業務システムでも対応可能なCMSと言えば分かりやすいでしょうか?

例えば大規模なWEBサイトのベースを作りたい場合、ワードプレスをインストールして、好みのテンプレートを選んで、ちょっと修正するだけで作ることが出来ますよね?

同程度の労力で、社内業務のための個別システムが作れちゃう感じです。

 

しかも、細かい権限周りの制御、全項目の細かいバリデーション、詳細設計書作成、セキュリティ検査、画面含めた全項目の自動テスト、そのエビデンス取得など、こういった面倒で工数ばかりが掛かっていたものが、ほぼ設計工数のみでまかなえます。

 

これの素晴らしい点は、アジャイル開発に現れます。

2週間スプリントなどを実施すると、検証したい大事な機能のみにフォーカスされ、どうしても、細かい機能がおざなりになります。

しかし、ツールが全自動でやってくれるので、おざなりになる事がありません。

 

また、さらなる発展としては、SIの「ほぼ自動化」があります。

ユーザーへのヒヤリングをAIが実施出来れば、その通りにシステムが出来上がる訳ですから、ツールでは実現出来ない部分だけを人の手で実装すれば、良い訳です。

正直、近いところまで来てるな…と言う印象を受けました。

 

もちろん、全部のシステム開発に今すぐ導入できる訳ではなく、また複雑な業務ロジック部分はまだまただ人手による実装が必須な、不完全なものです。

それでも、SIerが正しい未来に向かっているんだと、分かりました。

 

もしかしたら、日本のSIerが世界の開発センターになる日も来るかもしれない…、そう思わせるだけの片鱗をのぞかせていただきました。

 

 

 

 

フロントを書く人は漫画でいうアシスタント

※幾人かの指摘を受け、最後に大量に追記があります。

 

フロント周りの話が、また盛り上がってますね。

これとか

【翻訳】 2016年にJavaScriptを学んでどう感じたか - Endo Tech Blog

これとか

これから先10年、フロントエンドに関する予言 - mizchi's blog

 

要するに、デファクトスタンダードがないし、異常に複雑だし、誰得なの?と言った感じでしょうか。

 

それでも、意識高い系エンジニアは、この話について行こうと努力するか、自分のお気に入りのスタイルを推進しようとするんでしょうね。

茨の道ですね。

 

SIerを経営してる身からアドバイスしときますが、こんな話に付き合うのは、やめた方が良いですよ。

 

タイトルに結論書いてますが、フロント周りを書く人は、アシスタントです。

技術力の高い低いは関係ありません。

残念ながら、システムのキモを決める位置から最も遠い場所にいる、重要じゃない人に任せられる仕事です。

 

こういうのは、技術力のそこそこ高いオフショア開発に出されます。

オフショアの仕事の技術の細い話とか、どうでも良くないですか?

 

そんなことより、作り上げるシステムが世の中の役に立つかを、真剣に検討した方が良いですよ。

では〜。

 

※11/6追記

facebookコメントで、幾人かの指摘を受けましたので、追記いたします。

 

【フロントを大事にされている皆様へ】
言葉足らずで、大変失礼しましたm(__)m
上記エントリーは、いわゆるSIerの技術者向けに書いたつもりでした。
UI・UXをコンサル・デジタルマーケターの方々が決めて(ココが重要)、設計書に起こされたものを、プログラム言語で作り込んでいくわけですが、ここの作業しかしない技術者向けに書いたつもりでした。
フロント周りの重要性は益々増しています。

だからこそ、そういう仕事は増えて、かつ、その指示通りに手を動かすだけなら、オフショア仕事だな、という結論でした。

 

【漫画家のアシスタントという表現】

漫画作品を作る際、原作者が話をまとめ、作画者がコマ割り・下書きを行い、編集者と細かく詰めていきます。(ストーリーやセリフ一つも)

原作と作画は同じ人のケースが多く、基本、著者1名となります。

著者一人では週刊・月刊での連載は、到底持てず、背景書き込み、細かな表現はアシスタントに任せます。

この際、作品の評価とアシスタントの「技術力の高い低いは関係ありません」

もちろん、アシスタントの技量不足は、作品全体の品質低下を招きます。

(最近の日本アニメは韓国アニメーターに発注して酷い出来だとか…)

ただし、作品の品質は、品質管理をしっかり行う事でカバー出来ますし「技術力のそこそこ高いオフショア」に出せば良い訳です。

…と言うことを考えた上で、このような表現になっています。

 

【オフショアの仕事の技術の細い話】

「オフショア仕事」と小バカにした表現になっており、大変失礼しました。

言いたかった意図とは異なります。

弊社はオフショア子会社を持っており、非常に品質の高い開発を、かつ低価格で提供しています。

ゆえに、フロント周りの開発は、量も多く、手間もかかるため、専用に技術を学んだオフショアメンバーにやって貰っています。

お客様の近くにいて、同じ日本語で文化を共有している日本メンバーだからこそ、お客様のシステムを真剣に考え、かつ、世の役に立つようにするにはどうすれば良いかを考えられます。

細かい技術周りは、オフショアメンバーを信頼して任せよう、と言う宣伝的意図も入ってます(^^;)