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生産性は低いまま。
「ＷＨＹ ＪＡＰＡＮＥＳＥ ＰＥＯＰＬＥ！！」
と言われる訳だ。
どうすりゃ良いの？
「自分はサラリーマン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テストやってみてください。
（くれぐれも、結果のシェアはしないようにｗ）
一応、プログラマとしては、そこそこ成功した私のIQをお伝えしておくと135です。
全然自慢できる数字じゃないですが135です。
上記URL以外にもテストは沢山ありますが、大体、似たような結果になりますよ。
IQは、最低でも120以上にしておいた方が良いです。
出来るプログラマは総じてIQが高い！
もう一つの地力である、論理的思考(ロジカルシンキング)ですが、社会人全般に必須のスキルです。
プログラマも例外では無いです。
それどころか、他の職種よりも、強く求められます。
論理的思考能力が高く無いと、意図したプログラムを組めません。
「言ったのと違うの作ってるよね？」とか言われたらガクブルです ( ；ﾟДﾟ)ﾌﾞﾙﾌﾞﾙ
ただ、安心して下さい、上記した2つの能力は伸ばす方法があります。
IQであれば脳トレ、論理的思考であれば専用の訓練をやれば良いでしょう。
「好きこそ物の上手なれ」と言われますが、まさにこの辺を好きな人々がプログラマに向います。
結局、好きなやつになれば、勝手にやりますからねぇ。
下位2割の皆さん！まずはこの辺の訓練が苦にならないように、好きになりましょう。
とはいえ急いでプログラム能力を高めたいアナタへ
「ゆったり勉強して地力をつけてる暇ないッス！今やばいッス！」
そんな心の声が聞こえます。
そんな時、いつもしているアドバイスがあります。
それは、まずは日本語でプログラムを書け！です。
日本語プログラミング言語（有名なのは、なでしこ）で書きましょう、という意味ではないですよ。
日本語で書く事で、まずは内容を完成させましょうということです。
内容を完成させるとは？
要は、英語に慣れていない人が、英語の論文を書くときと同じです。
まずは、慣れた言語(日本語)で考えて、内容を完成させてから、翻訳すれば良いのです。
重要なのは「内容(ロジック)が正しい事」です。
ただでさえ実力が足りない未経験者で、しかも地力不足の人達には、いきなりプログラム言語で、正しいロジックを書くのは、ハードルが高過ぎるわけですね。
しかも、言語の問題以外にも、
・フレームワークが分からない
・ツールの使い方が分からない
・ライブラリが上手く動作しない
といった様々なトラップが待っているわけです。
一旦そういう問題は無視をして、まずはロジックの完成だけを目指しましょう。
全てに慣れてくれば、遠回りする必要がなくなります。
まとめ
やや話が長くなりましたが、簡単にまとめます。
諦めずに、頑張れ！正しい方法でね。
既存SIerがベンチャーにDisrupt(破壊)される日
下のニュース見て思ったことを、素早くメモっておく。
Fintechが日本で普及したら、その時が大手SIerの再編の始まりですね、と。
ちょっと前に話題になった「20万人月4000億円(約5年)のみずほ銀行の基幹システム刷新」や「11万人月2500億円(約3年)の三菱東京UFJ案件」など、これらの超巨大金融系SI案件が、Fintechで無くなっちゃう可能性がある訳ですから、業界としては戦々恐々ですね。
こういった月に数千人、数百人が動く開発案件が、定期的にあるから大手SIerの存在価値がある訳ですよ。
ベンチャーが生み出す、画期的かつ少数で作れちゃうシステムとは、相性が悪い訳です。
金融、公共、製造業、物流、医療といった巨大SIが必要だった分野は、これから次から次へとベンチャーにディスラプトを狙われ、市場を食われて行く流れです。
じゃ、既存の大手SIerはどうすれば良いのか？座して死を待つのか？
・・・そんな訳ない。
単純な話、現在の日本で大量の技術者を囲っているのはSIerで、そのアドバンテージは本当に大きい。
そこを活かして、ITサービス企業になれば良い訳です。
コンサルティング企業が、デジタルマーケティングの企業へと転身をはかろうとしているように、SIerもITサービス提供企業に転身を狙うべきです。
ちなみに、小中規模SIerは安心か？というと、こちらも大手同様に危ないですよ！
（むしろ大手以上にやばいかも・・・）
クラウドワークスやランサーズなどの、クラウドソーシングが、もっと社会的に機能し始め、SIの分業化・リモートワーク化が主流になれば、小中規模企業を利用するメリットはないですよね？
弊社もそうですが、駆逐されないためには、ITサービス提供企業になるしかないんですよ。
SIerの皆さん！ITサービス提供企業になるための投資、ちゃんとしてますか？
ある日突然来ちゃいますよ、市場を破壊される日が！
アジャイルさておき、システム開発で大失敗しない方法
下のエントリーがバズってたので、勢いで「システム開発で大失敗しない方法」を書いてみる。
成功する方法じゃなく、失敗しない方法でもなく、あくまで「大失敗」しない方法についてである。
結論から書くと「まずは少額でシステムのコア機能の検証をやろう！」である。
この話は、色んな人が何度も話してたり、書いてたりするが、全然浸透していない。
開発手法以前に「システムの骨格作り」で、大体みんな間違ってる。
「当然やってるよw」って人は、ここで読むのをやめて、周りに啓蒙しましょう。
なんでやれてない(難しい)かと言うと、その理由が当然ある。
少額と言っても、そこはシステム開発なので、100〜500万円くらいはかかる、検証だけで。
それくらい出さないと判断できないことが多いし、期間も3〜6ヶ月かかる。
牛丼みたいに、早くも安くもない。
その金使って、その期間待って「やっぱダメでした」が日本企業だと、難しいのはよく理解できる。
ただ、大失敗したくないなら、やらないとダメ。
こういう話を発注担当者さんにすると、毎回驚かされるのが「検証してないのに、このシステムが絶対に機能すると思っている」こと。
上手いプレゼン資料だけで「イケる！」みたいな気がしちゃってるから、悪い意味でヤバい。
ウォーターフォールか？アジャイルか？みたいな開発手法の話題は、まずはこの土台があった上での話だと思う。
検証で良い結果が出たら、一気にウォーターフォールで作り切った方が良い。
ちまちま2〜4週間でスプリントする必要はないだろう。
この辺の感覚をやしなうのは、SIerに居ては難しい。
サイバーエージェント、リクルート出身起業家などは、皆さん持ってる。
仮説立てる → 感触・数字見る → 上手く行った → 一気に走れ！
みたいな、そんな当然のことを、当然のようにやれる。
それでも機能するとは限らないし、小さい失敗は限りなく発生する。
「システムを開発するとは、そういうものだ」という共通認識を、まずは啓蒙しましょうって話。
