SIer関連メモ書き

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

BizDevOpsで気をつけること

昨日(2018/9/20)こんな記事がシェアされてきました。

jp.techcrunch.com

 

クラウドサーバー側がCI/CDの脆弱性までサポートしてくれる時代になったかぁ、と感慨深いですね。

…とは思うものの、未だに「CI/CDって何それ?美味しいの?」みたいなIT技術者が、沢山いるのも事実。

さて、そんな訳で、これからBizDevOpsに取り組みますよ!取り組み始めたばかり!という人向けに、この辺を積極的に取り組んできた我々のナレッジから、気をつけるべき点をまとめておきます。

ご興味あれば読んでくだされ。

そもそもBizDevOpsとは?

 知ってる方は、この項目は無視してください。

BizDevOps - Wikipedia

継続的デリバリとは何か? | Ryuzee.com

 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%安いので、オフショア開発と比較しても悪くないケースが多いです。
「会って仕事をする」ことに拘りがないのであれば、これもオススメです。

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

 

まとめ

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

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

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

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

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

お問い合わせ | デジタルマーケティングテクノロジーの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が世界の開発センターになる日も来るかもしれない…、そう思わせるだけの片鱗をのぞかせていただきました。