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部門が、早く改善される日が来る事を願う。

 

サラリーマンSEがSI業界の悪!

タイトルで言い切った!

その理由を説明しよう。

 

サラリーマンSEとは?

ITの新しい技術に飛び付くでもなく、技術力の問われる業界に飛び込むでもなく、ベンチャー的挑戦もしないで、ただただ目の前に与えられたプロジェクトや保守のみを長期に渡って行う、自称PG、SE。

こういう人は、技術論とか一切語れない。

大手SIerや社内SE向きで、かつ、SI業界の大多数の人がこれに該当する。

要するに、エンジニアじゃないのに肩書きだけエンジニアな方々を指す。

 

特徴は、技術力が総じて低い

サラリーマンSEは、交渉能力、コミュ力なんかがそこそこ高い人が多いから、ビジネスマンとしての技量でみれば、悪くはない。

だからこそ、本来、技術を磨かないといけないはずの技術者なのに、そんなことはせず、目の前の業務を、いかに問題無くこなすかだけにフォーカスし、社内評価を落とさない事にまい進する。

技術が好きでたまらない!みたいな感情が無いから、社内評価(昇級、昇給)が、活動の源泉になる。

そりゃ、技術力なんて上がるわけが無い。

 

なぜ悪か?

技術力の低い管理者が、プロジェクトリーダーに立つから。

技術革新に伴う新しいシステム提案などしないし、新しい技術への挑戦も行われないし、5年くらい前に自分が現役で使ってた枯れた技術の新バージョンを選択し、生産性も一昔前のまま。

なぜか根性論(努力を見せる)による残業も好き。

「火が噴いたら毎日の終電と土日出社でカバー」 みたいな、意味不明な選択を平然とし、最新のソフトウェア工学なんて、一ミリも見ない。

そのスタイルが後輩にも受け継がれ、日本のIT生産性は低いまま。

「WHY JAPANESE PEOPLE!!」

と言われる訳だ。

 

どうすりゃ良いの?

「自分はサラリーマンSEだな…」と思ったら、まずは勉強しよう!

若手なら、最新技術を追って、提案しよう!

社外勉強会、社外交流会に積極的に行こう!

ネット上のossやコミュニティに少しは触れてみよう。

プロジェクトリーダーなら、ソフトウェア工学をしっかり学ぼう!

そして、目の前のプロジェクトや職場を変えよう!

 

そんでもって、何度提案しても、どうしても変わらないような、そんなクソ職場だったら辞めて転職しよう!

転職先は、以下がオススメです。(PR)

≪AI×広告≫機械学習、AIを駆使したモノづくりに挑戦したいエンジニア募集 - 株式会社EVERRISEの求人 - Wantedly

 

PG・SEからPMへなるための5つの心得

最近、PG・SEからPM(プロジェクト・マネージャ)に変わるタイミングを迎えてる人に、意見を言う機会が増えたので、どうせならブログに書いておきます。

PMは忙しいから、手短に5つにまとめました。

 

1.プロジェクト管理の書籍を読んで実践する

まずは、正しい知識をいれましょう。

最初にこれをやらない人が、多いことに毎回驚きます。

自分の知識だけで、なんとかなると思ってるんですかね?

また、運営してて困った事があったら、改めて読み返しましょう。

知識を入れて実践しつつ、自分なりに身に付けよう。

 

2.管理作業をメインにする

下に5人のメンバーがいたら、PM一人が頑張るより、5人を正しい方向に誘導した方が良い。

自分がプログラムを組んだ方が早いと言ってはダメ。

 

3.とは言え自分もやる

メンバーにだけ作業をやらせて、自分は何もやらなくて良い訳ではないです。

むしろ、面倒な雑務、一番難しいところを、しっかりやり切るのは、PMの作業範囲です。

 

4.一方的に決めない

タスクを一方的に部下に押し付けるのは、駄目です。

まったく相談されずに自分のタスクやスケジュールを決められたら、嫌ですよね?

また、報連相も一方的させるのではなく、PMから部下へもしてみましょう。

 

5.進捗遅れを残業で解決しない

問題の対処策に、残業を選ぶのは避けた方が良いでしょう。

ゴールが明確に見えていて、ちょっとだけ踏ん張るのは良いですが、先が見えてない状況ではこの選択は間違っています。

 

他にもたくさん言いたいことありますが、まずはこの5つに注意してやってみましょう。

頑張れ新米PM!

※頑張りすぎて盲目になるのは要注意

 

 

 

 

【4月入社PG】最初の一歩につまずいた君へ

4月入社した新卒プログラマの皆さん、こんにちは。

 

お盆の時期ですね。 

既に研修を終え、初めてのプロジェクトで先輩プログラマから色々教わりながら頑張っている頃でしょうか?

 

「何でも質問して良いよ」と言われたのに、くだらない質問をして「それくらいググれよ!」と怒られてますか?
先輩は、学校の先生とは違いますからね。
ただ、安心して下さい、通過儀礼ですよ。

 

あと、夏休みはいくら待っても来ません。

夏はクーラーの中、外に一歩も出ずに生産性を高める時期です。
慣れるまで大変ですが、慣れればむしろ快適になります。
いずれ「真夏に外出とか無いわぁ」となりますから。

 

そんな学生生活との違いを一つ一つ覚えながら、社会の役に立つように頑張ってる皆さん。

そろそろ同期の中で明確な差が付いてきているかと思いますが、いかがですか?

 

上位2割に居る、あなた!おめでとうございます!

そのまま無理はし過ぎず、頑張ってください。
ただ、東京(駅周辺)で消耗し過ぎてはダメ!
必ず明るい未来が待ってますよ!
ベンチャー社長目指したり、CTOを目指したり、色々と楽しい事が待ってます。

 

中間6割に居る、あなた!ちょっぴり安心していいですよ。

普通のプログラマとしては合格です。
ただし、まだ勝負はついてませんからね。
自分の不得意はなるべく潰して、得意を伸ばしていきましょう。
「インフラが大好物です」「美しいjsに興奮します」とか言っとけばOKです。

 

さて、下位2割の皆さん…、体力的にも精神的にもお疲れ様です。

前置きが長くなりましたが、このエントリーはあなたの為に書いています。
開発現場で「あれ?ついて行けてないかも?」と少しでも思ったら、参考にして下さい。

 

下位2割の皆さんへ

同じ未経験で始めた同期が、バンバンとプログラムを書いてるのを尻目に、自分は上手く書けない。
苦しんでますよね?
経験値を積めば何とかなるから、今は耐えよう!と思ってますよね?

…これ残念ながら、いつまで経っても解決しませんから!

 

目の前の業務だけを何とかこなしていても、いっこうに楽になりませんよ。
上手くなるには、正しい訓練が必要です。

分かりやすい例が、身近にあります。

「あなたの箸の持ち方は、完璧ですか?」
「あなたの書く文字は、綺麗ですか?」
「あなたは歯を完璧に、磨けてますか?」

どうですか?そんなわけ無いですよね?
プログラムも一緒で、どんなに毎日書いてても、適当にやっていれば、いっこうに上手くなりません。

 

どんな訓練が必要か?

皆さんは、入社後に研修をやってきたことでしょう。
ただ、研修はあくまで知識を教えることがメインです。
プログラマとしての地力は、実は訓練していません。

プログラマの地力とは、IQと論理的思考能力です。

 

とりあえず、今のあなたのIQを知るために、以下のIQテストやってみてください。

(くれぐれも、結果のシェアはしないようにw)

curazy.com

一応、プログラマとしては、そこそこ成功した私のIQをお伝えしておくと135です。

全然自慢できる数字じゃないですが135です

上記URL以外にもテストは沢山ありますが、大体、似たような結果になりますよ。

IQは、最低でも120以上にしておいた方が良いです。

出来るプログラマは総じてIQが高い!

 

もう一つの地力である、論理的思考(ロジカルシンキング)ですが、社会人全般に必須のスキルです。

プログラマも例外では無いです。

それどころか、他の職種よりも、強く求められます。

matome.naver.jp

論理的思考能力が高く無いと、意図したプログラムを組めません。

「言ったのと違うの作ってるよね?」とか言われたらガクブルです ( ;゚Д゚)ブルブル

 

ただ、安心して下さい、上記した2つの能力は伸ばす方法があります。

IQであれば脳トレ、論理的思考であれば専用の訓練をやれば良いでしょう。

「好きこそ物の上手なれ」と言われますが、まさにこの辺を好きな人々がプログラマに向います。

結局、好きなやつになれば、勝手にやりますからねぇ。

 

下位2割の皆さん!まずはこの辺の訓練が苦にならないように、好きになりましょう。

 

とはいえ急いでプログラム能力を高めたいアナタへ

「ゆったり勉強して地力をつけてる暇ないッス!今やばいッス!」
そんな心の声が聞こえます。

そんな時、いつもしているアドバイスがあります。

それは、まずは日本語でプログラムを書け!です。

日本語プログラミング言語(有名なのは、なでしこ)で書きましょう、という意味ではないですよ。

日本語で書く事で、まずは内容を完成させましょうということです。

 

内容を完成させるとは?

要は、英語に慣れていない人が、英語の論文を書くときと同じです。

まずは、慣れた言語(日本語)で考えて、内容を完成させてから、翻訳すれば良いのです。
重要なのは「内容(ロジック)が正しい事」です。

ただでさえ実力が足りない未経験者で、しかも地力不足の人達には、いきなりプログラム言語で、正しいロジックを書くのは、ハードルが高過ぎるわけですね。

しかも、言語の問題以外にも、

フレームワークが分からない

・ツールの使い方が分からない

・ライブラリが上手く動作しない

といった様々なトラップが待っているわけです。

一旦そういう問題は無視をして、まずはロジックの完成だけを目指しましょう。

全てに慣れてくれば、遠回りする必要がなくなります。

 

まとめ

やや話が長くなりましたが、簡単にまとめます。

諦めずに、頑張れ!正しい方法でね。

 

既存SIerがベンチャーにDisrupt(破壊)される日

下のニュース見て思ったことを、素早くメモっておく。

jp.techcrunch.com

Fintechが日本で普及したら、その時が大手SIerの再編の始まりですね、と。

 

ちょっと前に話題になった「20万人月4000億円(約5年)のみずほ銀行の基幹システム刷新」や「11万人月2500億円(約3年)の三菱東京UFJ案件」など、これらの超巨大金融系SI案件が、Fintechで無くなっちゃう可能性がある訳ですから、業界としては戦々恐々ですね。

 

こういった月に数千人、数百人が動く開発案件が、定期的にあるから大手SIerの存在価値がある訳ですよ。

ベンチャーが生み出す、画期的かつ少数で作れちゃうシステムとは、相性が悪い訳です。

 

金融、公共、製造業、物流、医療といった巨大SIが必要だった分野は、これから次から次へとベンチャーにディスラプトを狙われ、市場を食われて行く流れです。

 

じゃ、既存の大手SIerはどうすれば良いのか?座して死を待つのか?

・・・そんな訳ない。

 

単純な話、現在の日本で大量の技術者を囲っているのはSIerで、そのアドバンテージは本当に大きい。

そこを活かして、ITサービス企業になれば良い訳です。

コンサルティング企業が、デジタルマーケティングの企業へと転身をはかろうとしているように、SIerもITサービス提供企業に転身を狙うべきです。

 

ちなみに、小中規模SIerは安心か?というと、こちらも大手同様に危ないですよ!
(むしろ大手以上にやばいかも・・・)

 

クラウドワークスやランサーズなどの、クラウドソーシングが、もっと社会的に機能し始め、SIの分業化・リモートワーク化が主流になれば、小中規模企業を利用するメリットはないですよね?

弊社もそうですが、駆逐されないためには、ITサービス提供企業になるしかないんですよ。

 

SIerの皆さん!ITサービス提供企業になるための投資、ちゃんとしてますか?

ある日突然来ちゃいますよ、市場を破壊される日が!