読者です 読者をやめる 読者になる 読者になる

SIer関連メモ書き

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

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

まだまだ未熟な職業プログラマ(以後、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部門が、早く改善される日が来る事を願う。

 

サラリーマン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!

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