駄文…というか予想

2019 年の SI 業界予想。

技術は置いておいて、大激変の年になるのは間違いない。

「働き方改革」による、プロジェクト運営方法の変更だ。

コレは予測というよりも、やる・やらないの差が、ブラック企業/ホワイト企業をほぼ明確に分ける。
残業規制や有給の強制取得などが盛り込まれており、守らなければブラック企業（公式）扱いになるためだ。
現実問題として、人手不足という現状があり、その上で作業時間を減らす必要が出る以上、仕事の進め方そのものを変え（時間に対しての作業の質をあげるなど）なければ崩壊するか、ブラックに転落するかしかない。

必要なのは組織運営の見直しなのであって、現場に丸投げする様では、社員はきっと逃げるだろう。

この改革は王手のような巨大組織とそこに紐づく下請け SIer がおそらく暫くはブラックに近くだろう。
組織規模が大きいと変化が難しく、でも残業などは回せないから下請けに流す事になる。
下請けは作業量が増えるので、必然的にルールを守りきる事が難しくなる。
なので下請けは選択を余儀なくされるはずだ。

一度ブラックの称号がついてしまうと、中小に限って言えば、こと求人で言えばかなり致命的だろう。
存続も難しくなるはずだ。

blackcorpmap.com

昨今の新卒や転職社もこのサイトは大体知ってるし、考え方はシビアだ。
するとどうなるか？

• 元請けに対応しきれなくなって下請け事業の撤退、もしくは規模縮小。そこに続く元請け化と内製。
• 下請けがブラック転落、先細り、元請けも先細る。
• 元請け共々働き方改革で協力して共に生き残る。

とても個人的な意見（偏見も多分にあるので、あくまで個人的見解）最後のケース望みが薄い…下請けの力関係みたいなものは体育会系の上下関係に等しいものが見える。もちろんそれが全てとは言わないが、体感的にそんなケースが多いように見える。
SIer の体質（というよりは巨大規模の体質）の変わらなさは個人的に見てもやばいレベルな気がする為だ。
加えて言えば出向を行ってる人貸し業も体質変更は死ぬほど難しい。一人一人体質を変えようにも貸し出して手元にいないのだから変えようがない。
（司令だけ渡してアウェーな現場でそんなの守れるわけもなく…度がすぎると退職者を産む）

逆に中小で内製企業は改革は行いやすい。そういう意味では住みやすくなる可能性は非常に高い（変化を受け入れられるならばだ）。
で、ここにきてどうなるかと言えば、だいたい方向性は見えてる。

• WF/Agile などを適度に使い分けるようになる。

のは大前提だろう。
何か画期的な手法が生まれれば別だが、IT 本家米を見ても Agile 派生が幅をきかせてる位しか見えない。
画期的手法が生まれるというのは望み薄いと思う。
強いて言えば日本人の気質になった Agile にはなるだろうくらい。

WF は不測の事態への対応コストが高すぎて、こう変動期に全部 WF で回すなんて悲惨な未来しか見えない。
規模が小さいからこそ、意思疎通コストの低さを生かして、小さく立ち回れる利点がある。
当たり前だがWFの方が向いてる仕事もある。人命がかかるとか、何を置いても確実性が必要なケースだ。

• 規模の大きな開発系企業から、IT のアウトソースが減り、内製にシフトし始める。

これも結局同じ流れ。
アウトソースして出来上がったシステムが出てくるのは数ヶ月後、結局うまく最新の局面にマッチしなくなる。
結果として、Agile の様に現在の状況に即した開発に切り替わるが、Agile だとすると要するに開発チームを囲い込む状況に近くなる。
ならば内部で開発チーム置いた方がコストがよくなるという発想だ。

SIer は怖れよ、コレには実例がある。
カイゼン・ジャーニー発刊１周年記念イベント「私たちのジャーニー」 - DevLOVE | Doorkeeper

「稼働率100％男が、稼働率100％をやめるジャーニー」というセッションがそうだ。
スライドが見つけれないのが痛いが…

結局こうなるのではなかろうかという予想。

コアな領域では、企業はエンジニアを雇いたがる。そして技術継承も踏まえ、改善しながら持続させる方針をとるはずだ。
一方で、日本は人手不足。小さい開発を行うにしても人手がたらなくなる。
しかしこの小さな開発の為だけに、人員を増やしてしまうと、その後に解雇もしづらく問題になる。

結果として、その隙間を SIer が埋める事になりうる。

今現在 SIer なので、SIer 視点で考えれば

1. 需要はなくならない、しかし大口の開発は減る。
2. つまり、大きな規模としての SIer はその規模を縮小せざるを得ず、中小 SIer もその数は減じる。
3. 中小企業では、ICT 人員を雇う事事態もままならず、これも SIer 頼みになる。

つまり SIer は小さな開発をたくさん受けるような業態に落ち着く。
「売り上げ = こなした数」となるので、人貸しでは稼ぎにならず、社内に仕事を引っ張り込んでパイプラインんぼごとく（リーン）開発するのではなかろうか？

【初心者向け】Kaggleで機械学習を勉強しよう！

liberal-arts-for-tech.connpass.com

ここんい参加したきた。
半分近くが学生さんというすごい状況。
モノが学術方面なので、その分学生のほうが寄り付きやすいのかも知れない。

内容

といっても基本は交流の場＋もくもく会といった状態でした。
Kaggle 初心者の為の入門方法もやってるので、どのタイミングで参加しても初学者に優しそうだ。

その意味で、 勉強会初参加とか、機械学習自体が初学者でも問題なく入っていける というのはとても強みだと思う。

次回はすでに他の勉強会が挟まってるので参加は多分無理なのだけど…

Kaggle 入門

素敵なことに、スライドがあって、Kaggle のアカウント作成〜チャレンジのエントリー〜データのダウンロード〜回答のアップロードまでの手順を順に説明してくれるというとても親切なものだった。
（その横でもくもくしている人もいるという）

ちなみに入門車は Titanic （Kaggle チュートリアルチャレンジ）だった。

真面目な話、アルゴリズム自体は色々弄ってるので、根拠のない自信で「やれるんじゃね？」と思ってたのが甘かった。

チュートリアルレベルでもデータの整形、補完、不要なデータの除去など、前処理を行うらしい。
当然ながら、アルゴリズム実装だけやってると、そんなことはしてない訳で、しょっぱなからつまづいた。

ここでこの勉強会が親切だなと思った点は、前処理〜モデル生成〜性能評価の一連の流れの説明や、Kernel（他の人が書いた解説）なんかの読み方まで説明してくれる点だ。
時間が短かったので、精度を高めるなんて話までは進まなかったのは残念だが、凄まじい刺激である。

個人的にやらんとなーと思ったこと

具体的に（予め断っておくが全て Python3.6+）

• pandas
  データ読み込み、加工、保存のライブラリ。
• scikit-learn
  機械学習ライブラリ

なんてのを弄ってた。
そして悟った…numpy 一つでスクラッチ実装も無駄ではないが、効率考えたらライブラリ使えと。

仕事でやってないで趣味でやってるからスクラッチなんてマネができる訳で（汗
そりゃコンペやるくらいなら、ライブラリでもなんでも投入してやれよなって話だ。

刺激

機械学習を仕事にしてる人の話は過去何回か聞いた。
アルゴリズム自体は研究分野を除けばだいたい一般化していて、結局彼らのお仕事は「前処理係である」とはよく聞く話だ。

で、今回勉強会へ行って驚いたのが、参加した大学（学部）学生がすでにそう言うのが必要と自分で気づいてる点。
コレは乗るしかないこのウェーブにッツツ！！！

reading-circle-beginners.connpass.com

と言うことで申し込んだ！
学生たちの話を聞くのも非常に面白かった。

曰く

• TypeScript どうやって入門しましょう？
  一気に入門しないと書籍は陳腐化するからおすすめは公式
• wasm どうなんでしょう？

みたいな話。
WASM すらっとは出てこないけど、改めて考えると

言語も広まってる。昔 asmjs もあったけど…
結構いろんな言語が対応してきてるけど言語で差が激しい。

多分セキュリティ的なものもあるから、そこまで自由度は増えないと予測。
コアロジック見たいのは書けても、ソケットとかDOM操作とかまではサポートされないと思われる。

ただ、TypeScript/C# 両方が Microsoft なので、TypeScript 中でシームレスに C# が書ける様になる可能性がある。
そうでなくとも、TypeScript 自体は GitHub - AssemblyScript/assemblyscript: A TypeScript to WebAssembly compiler 🚀 経由で WebAssembly 化できるので、その意味でかなり強そう。

やっぱ MS はここ５年くらいでかなり変わった。

カイゼン・ジャーニー一周年記念イベント〜私たちのジャーニー〜

と言うのに参加してみた。
タイパーじゃないので、かなりの漏れはあって、口調みたいなものが消えて訳本臭い書き方になってたりもするけど気にしないで欲しい。

マジでテープレコーダーとかビデオとか買おうかな…

https://devlove.doorkeeper.jp/events/87126

主催: 市谷さん、新井さん

dev summit にて、技術書大賞があった。 そこで大賞は取り損ねたのだけど…

カイゼンジャーニーは現場で越境（役割やこれまでの慣習を断ち切ってすすむ）の為の本。 一人型初めて、チームになって、みんなを巻き込む所まで。 段階を追って行く。

ジャーニーって誰のジャーニーなのか？ これは著者の経験、記録から編集して構成してる。

• 西村さん：agile samurai の訳者。
  カイゼンジャーニーの西方さんは、西村さんがモデル。
• 楽天の及部さん: アジャイル系で登壇しまくるチャレンジャー（逆境好き）の人。
  主人公の江ノ島さんのモデル。
• 角谷さん: 2007 年のデブサミで喋った人。石神さんのモデル。
• 竹本さん: がたせさんのモデル。二人なら始めれる、もっと変えられるって言い出した人のモデル。
  devlove の発祥の人。

こうした人たちのジャーニー、それがカイゼンジャーニー。

TSVInporter を H2 で動くようにしてみた

github.com

TSV インポーターを作ってみた。
とりあえず H2SQL だけ対応した。

非常に残念なことに、java.sql.Types の中に定義してある型を、各 DB がどんな型として扱うのかは、JDBC の実装依存らしい。
そのため、極論するとデータの型変換は、DB の種類分必要ということになってしまう |||orz

https://www.cis.upenn.edu/~bcpierce/courses/629/jdkdocs/guide/jdbc/getstart/mapping.doc.html

ここのドキュメントの 8.2 章がその内容だ。

仕方がないので、変換用 IF だけ置いて、使うとき実装してもらうスタイルに…誰か他の DB とか書いてくれないかなぁ（トオイメ
まぁもともと、DB を使った UT で、Java コードで事前準備レコードなんて書きたくないから用意したわけで、それさえできればよしとしよう（汗

追記: How To Use をリポジトリに追加したのであとは野となれ山となれ。ライセンスに WTFPL としようか一瞬迷った。

TSV からテーブルインサートするライブラリ作成中

github.com

まだ未完成。

• UT してない。
• テーブルカラムに対応したデータ変換ロジックが書かれていない。
• H2SQL しか見てない。（できれば SQLServer は個人的にやっときたい）

突貫工事でバグとかありそうで怖いけどとりあえずコミット。

速攻で Jenkins を練習する環境を用意する

目的は Jenkins を試すことのみ。
それも構築/設定をメインに試すので、なるだけ最短ルートを通る。

Jenkins インストール

今回は Jenkins のセットアップ手順を知るために、Linux にガチで入れます。
Docker コンテナもあるにはあるのですが、今回そっちには逃げません。

とはいえ、Ubuntu のインストールは今回の目的ではないので、こっちは Docker でやってしまいます。

$ docker run --name jenkins-example -it -p 8080:8080 -p 8000:80 ubuntu

Ubuntu にログインしたら

$ apt update -y
$ apt upgrade -y
$ apt install wget git gnupg openjdk-8-jdk -y
$ wget -q -O - https://pkg.jenkins.io/debian/jenkins-ci.org.key | apt-key add -
$ sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
$ apt update
$ apt install jenkins -y
$ /etc/init.d/jenkins start

そこそこ長い…
ここまで来たら、 http://localhost:8080/ を開くと

ヒャッホイ。
画面の指示にしたがってサジェストプラグインをとりあえず入れてしまう。

管理者アカウントも作成して

起動しました

ビルドプロジェクトの作成

「新規ジョブの作成」から、「フリースタイルジョブ」で適当な名前で作成します。

設定が始まりますが、上の方は表示とかメタ情報の類です。
入れたければお好みで

重要なのはリポジトリ設定以降です。
git を指定して、以下の URL を突っ込みます

https://github.com/Sunao-Yoshii/spring-boot-web-example.git

その後の設定ですが

• ビルドトリガ
  定期的に git リポジトリを調べて、新しかったら自動実行…とかできます。
• ビルド環境
  選択肢の通りでしょう。今回は放置します

「ビルド」の欄で、どんどん手順を追加していきます。最悪のケースでも shell を直接設定できるので、Linux の手順はだいたい設定できます。
まずは gradle コマンドを追加してしまいます「Invoke gradle script」を選択して

「test」とだけ打ってみましょうか。

そしたらプロジェクト名を別タブで開きます

サイドメニューから「ビルドを実行」とすると、リポジトリからのチェックアウト、テストが実行されます。
ちなみに「ワークスペース」を開くと、ビルド後のプロジェクトディレクトリの中身がみれます。

そしたらプロジェクトの設定に戻り、「ビルド後の処理の追加」から「JUnit 結果の集計」あたりを選びましょう。
これは JUnit の結果 XML を集計するので、フォーマットが一緒なら他の Unit 系でも使えます。

入力するディレクトリは「build/test-results/test/*.xml」で設定します。
build ディレクトリは gradle 標準のアウトプットディレクトリで、test-resulkts/test も言わずもがなですね…

再度実行して成功すると「テスト結果」の項目が出てきます。
ここでエラーになる場合は、gradle コマンドを以下の２行にして再実行してみてください。

clean
test

設定をみてみれば分かりますが、エラー時にメール通知など色々できるようになっています。
最終的にこのプロジェクトではこんな設定を行いました。

チェックスタイルの追加と、ビルド結果の保存です。
Spring の jar はそのまま実行するとサーバになるので、それでもいいですが、頑張って war にするなら、Tomcat へデプロイとか、Azure AppService へのデプロイとか色々やりようがありますね。

LINE BOT 作ろう！

ちょうど明日勉強会で Jenkins セットアップするので、Line BOT で色々通知できないかなーというノリで参加してみました。
結論から言えば方向性が違いましたが、色々サービスに触れて面白かったのでここで紹介してきます！

x-hack.connpass.com

まず最初に使うサービスをザックリ紹介。

codenvy.io

Codenvy はオンライン IDE なんて言う素敵なアイテム。
勉強会でハンズオンするのに、IDE 宗教とか面倒だろうし、何かと重宝しそうですね。

Git リポジトリを選択すると、Docker 上の Linux に clone して色々な編集ができます。
Linux ターミナルが使える所がまたイイ！

関連記事: Codenvy使ってみた - Qiita

jp.heroku.com

Heroku はクラウド黎明期から速攻で PaaS を始めてるクラウドサービス。
昔使った事が一時期あったのだけど、長らく使う機会がありませんでした。

特徴は、ともかくシンプル！
サービス開始までの手順がもっとも少ない PaaS なのではないでしょうか？

developers.line.me

ラストは…説明不要のサービス。
BOT 作成には Developper アカウントが必要ですが、こちらも基本的に LINE の QR ログインで登録できてしまいます。
いやはや便利になったものです。

開始

自己紹介から開始。
今回の講師は、主：桑原さん、ヘルプ：マツダさん、長岡さん

本日の内容。

github.com

X-Hack さんは、非エンジニア向けにプログラミングの啓蒙等をされている会社さんです。
ごめんなさい現役エンジニアが興味本位で枠奪ってしまって（汗

LINE の設定

まず LINE Developper にログインするとこんな画面になります。

「新規プロバイダー作成」からプロバイダー名を入力して

「確認」「作成する」でさっくりプロバイダーを作ります。
次に「チャンネルを作る」に進んで、適当な名前の BOT を作りましょう。

「Developper Trial」ってイイですねー
ジャンルは適当に選びましょう。どうせ作り終わったら消します（汗

メールアドレスは、自動入力だとエラーになります。
必ず手入力で…キーバインドチェックか何かしてるようです。

確認画面などは代わり映えしないので省略します。
ハンズオンだったのでさして読みきれてませんでしたが、改めて読んでも常識的な事が書いてありました。

作ったチャンネルを選択して

チャンネル基本設定から「Channel Secret」と「アクセストークン」をコピーします。
（ここはそこそこ危険なエリアなので、スクショはなしです）

スクロールしていくと、「LINE アプリへの QR コード」があるので、それを経由で登録してしまいましょう。
ちなみに近くにある項目の「自動応答メッセージ」や「友達登録時あいさつ」は邪魔になるので、「利用しない」に設定しておきます。

Heroku

次は Heroku にログインします。
なお、アカウント作成などは特に説明しませんのでご了承ください。

とりあえずこれで放置（笑

Codenvy

Codenvy にログインしたら

Codenvy

サイドメニューから
Workspace > add workspace を選択し、

• select stack : node
• projects : 「git」を選択して、「https://github.com/x-hack-git/line-messaging-api.git」を使わせてもらいます。

先に進むと、勝手に clone していじれるようになります。

terminal で unix コマンド使えるので Docker かなと思ったら Docker のようです。
10 分位放置するとコンテナ消される（汗

ターミナルに、Heroku のコンソールをインストール。プロジェクトルートに移動して

$ curl https://cli-assets.heroku.com/install.sh | sh
$ cd line-messaging-api

そしたら heroku にログイン

$ heroku login --interactive

ID/Pass は登録したものを使いましょう。

$ heroku create azalea-example-bot
$ git push heroku master

その場で heroku アプリ（兼リポジトリ）をこしらえて push 。
このあとで Heroku の画面をみてみると上がってる…

残りの環境変数設定

先ほど LINE から拾った 「Channel Secret」と「アクセストークン」を、Heroku に設定します。
先ほど作ったアプリケーションを開いて、「Setting」から「Config Vars」に設定します。

コラム: この手のパスワードを、ソースコードに絶対に書いてはいけません。github に上げようものなら、十数分でぶっこぬかれれ、最悪うん十万と支払いが飛んできます。

qiita.com

お次は、Heroku の右上の「Open App」を開きます。
おきまりの「Hello World」ですねーこの URL をコピーします。

最後は LINE Developper に戻って

WebHook URL に最後「/callback/」をつけて登録。WebHook 送信を「利用する」に設定します。

なんかバグっぽい挙動で、 WebHook送信の項目を後に設定しないと、なぜか設定が一部リセットされる模様。

ここまで来たら LINE を確認

初期動作仕様は、適当に喋ったらこんにちはで返してくれるのみです。

実際のハンズオンでは、ここから ぐるなびさん API と連携したりとか色々やりました。
とはいえ、中のソースをみる限りはシンプルに JSON でごにょごにょしてるだけ…！

Web 屋さんならお気づきだろう！なんでもできる…と！

というような内容でした。