SIer関連メモ書き

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名となります。

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

 

SIerから残業を無くす方法

飛行機の中、暇なんでエントリーを一つ書きます。

電通新人さんの過労自殺問題から端を発して、残業問題へと話が移ってきていますね。
この波は、SIerにも確実に来ます。

そこで、SIerから完全に残業をなくす方法を検討してみます。
この際、売上は落とさず、賃金の上昇も抑える形で実現する事を前提としています。

結論から書きますが、以下の5つを実現すれば可能です。

 

1.規則で残業を禁止する
2.受注方式を変える
3.案件を断る
4.自社サービスを販売する
5.不測の事態を織り込む

 

それぞれ詳しく書きます。

 

1.規則で残業を禁止する
まずは、これが必須ですね。
「残業するな!」と口頭で伝えたくらいでは、必ずやる人がいます。
まずは、ここの線を固く引きましょう。

 

2.受注方式を変える
モノを生産すると言った成果物が伴う契約は一切辞めて、技術支援という形に契約を一律変えましょう。
SIerは事業を進行する上での、技術部分で支援する立場にあると、明確に位置付けることです。
「時間単位での技術支援」×「単価」
で価値を提供すべきでしょう。
「約束したものと違う」「約束した納期に間に合わない」みたいな事がなくなります。

 

3.案件を断る
所定時間で出来ない案件は断りましょう。
その代わり出来る仕事を営業して取りましょう。
出来る単位まで分割して、出来るところだけを受けても良いです。
また、受注後にも仕事を解約(変更)出来る契約もしておきましょう。
出来る仕事を増やす方法は「教育」になります。

 

4.自社サービスを販売する
どんなシステムにも共通して必要な事項があります。
そういったものは、単価を決めて自社サービスとして提供しましょう。
例えば、RFP制作、CI構築、コードレビュー、セキュリティ監査、テスト項目消化、etc

 

5.不測の事態を織り込む
多いと月に数回、少なくとも半年に一回くらいは、不測の事態は起きます。
その際に、費用をもらって対応可能な契約にして起きましょう。
加えて、必ず代休や翌日の時短作業化などを契約に盛り込みましょう。

 

上記5項目を満たせるまでの移行期間は、残念ながら、残業または売上減少が伴いますが、これを超えられれば、確実に残業が撲滅出来た上に、売上も落ちません。
むしろ、上がる可能性が高いです。

 

また「都合よく、上記のような契約で仕事がとれるか?」という疑問はあるでしょう。
これについては、現状、問題ないはずです。
そもそも技術者は人手が足りていません。
また、生産性が劇的にあがるので、今までより多く仕事を受けられるようになります。

 

ただし、欠点もあります。
仕事が確実につまらなくはなりますね。
確実に出来る仕事だけを、極力数多く繰り返しやる訳ですから。

この辺をどう考えるかは、その会社の考え方次第、勤める人次第ですかね。

 

上記5つで、絶対に機能する!とは保証出来ませんし、やったらやったで、仕事がつまらなくなって人が辞めた、みたいな副作用があるかもしれません。

あくまで、参考程度に〜!

 

SI業界叩く前に発注者のRFPを見直せ!

先日、RFP(提案依頼書)をいただいた。

この内容があまりに酷かったので、ダメな点をメモしておく。
SI出身者が社内SEになって、初めて書きました的なクオリティーだった。

SIerを否定する声は多いけど、こんな酷いRFPしか書けない発注元から正した方が良い。

守秘義務があるので内容には一切触れないし、作りたいシステムの中身はこのエントリーの主題とは関係ない。
何がダメなのか?だけを書いていく。

 

目的に数値がない
RFPを書く人にKPIという言葉を知らない人が多い。
どんな数字を達成したいか、明記すべきだろう。
例えば既存社内システムからのリプレースなら、オペレーションの改善時間などは、当然書かれるべきだ。
それらの数字からROIが出せて、提案する側も予算感が見える。

 

曖昧な表現が多い
使いやすい、容易な入力、視認性が良い、ストレスなく動作する、etc
といった曖昧な表現が多い。
そのようにRFPに書けば、SI側が満たしてくれる(後で直させられる)と思っている。
新規開発するシステムのUXが最初から完璧だとでも思っているのだろうか?
初期に満たせる要件と、アジャイル開発で何度も改善しないと満たせない要件の、整理がついてない。

 

開発期間が長すぎる
全部一気に作り切ろう!と言う意気込みはわかるが、1年近く先の全スケジュールを最初から立てられるわけがない。
要件定義どころか、実現性調査すら済んでないもので、期間と費用を出せという。
加えて、1年近くかけて作ったシステムを、リリース直後に全社展開したいとか…。
どう考えても、ハードランディングになるだろうよ。

 

予測を提示させたがる
「サーバの構成と費用を提示ください」
「バッチの処理時間を提示ください」
「保守にかかる費用を提示ください」
要件定義すら済んでない上に、1年近く先に出来上がるシステムの付帯費用って何ですかね?
サーバ費?クラウド使おうよ!
バッチの処理時間?並列処理化してインスタンス並べるか、hadoop系で組もうよ!
保守費?出来上がってもないシステムの保守費って何よ?

 

やたらに長いし、細かい
読む気が失せるくらいにRFPが長い。
納品物の詳細、納品方法、出力したい帳票類、接続したい別システムの仕様書、etc
全部一気に伝えたい気持ちはわかる。
ただ、資料のボリュームがあると、本質から焦点をずらす結果になる。
それが分かってない。

 

他にも沢山ツッコミどころがある。
もう、まるで分かってない。

 

こうして、まるで分かってないシステム担当者が書いたRFPをベースに、提案された酷い計画書を元に、ダメSIが実施され、ガラパゴスシステムが量産される訳だ…。
なんだか、悲しくなる。

 

どうすれば良いか?
要件を整理することすら出来ない社内のダメ人材に任せるのではなく、プロにお願いすべきだろう。
しかも、昔ながらのSIじゃなくて、正しいIT戦略投資を計画できるプロのCIOサービスに頼んだ方が良い。

事業会社のIT部門が、早く改善される日が来る事を願う。