なぜ誰もこう書いてくれないDI(Dependency Injection)

書きました。

speakerdeck.com

前回のDockerの時と同じように、DIもググれば解説サイトなんて腐るほど出てきますので、今更感もあります。 ですが、これまたDockerと同じように、肝をついたような解説がなかなか見つからないものです。

これいるなーと思いついてズバズバと書いたものなので、コードレベルの細かい解説とかありません。 途中できしださんの記事のリンクも出てきますが、これもハードル高いと思ったら、読み飛ばしても大丈夫です。

d.hatena.ne.jp

解説サイトを漁る前のハードル下げというか、「印象を把握する」というレベルの認識で読んでもらえればと思います。

ということでお茶濁し記事でした。

SIerはもう終わったと思っている人/SIerに残ってるが意義が見出せない人に聞いてほしいこと

TL;DR

  • SI業界は縮小するかもしれないが、自社で情シス抱えられない会社がある限り続く
  • 新しいシステムを作るだけでなく、過去の負債的システムを清算することもSIerの役割である
  • いまもう”System Integration”じゃないよね?なんか新しい名前考えようよ

日本のSI業界が佳境に来ているというのは、事実だと思います。

自動化文化、クラウドホスティング環境の充実、ドメイン駆動設計などにより、自社でシステムを管理するための環境は十分整っています。それに合わせて情シス不要論はビジネスとシステムの橋渡しのために撤回されてきており、米国に追随する形で自社のサービスは自社で拡充・運用保守するのが正しいという流れになりつつあります。 事実、私自身も情シスへの転職を考えたこともあります。

しかし、今も私はSIerに残って続けています。 それは、あるお客さんに携わっている時に聞いた言葉がまだ頭から離れないからです。

ある中小企業の話です。

金属を使った製造業をしている会社です。 ライン・ロットで大量生産するようなものではなく、手作業でカスタマイズ製品を作ることが多い会社さんです。

そこではVB4か5あたりでベンダーが社内システムを開発・導入しました。 そのシステムはVB6を経て、現在のVB.NETまで拡張工事とマイグレーションを続けてきました。 過去の設計書など皆無で、現場に合わせてプログラムレベルでつぎはぎ状態です。 ソースコード上に個人名・役職名が当然のようにベタ書きされています。

と、ここまで書いておいて、今回の本題はそのシステムの構造・見た目の問題ではありません。

うちの会社が保守を担当するようになってからこんなことがありました。

保守作業の中では、システムの不具合といっしょに現場から挙がって来た改善事項も管理して、実施検討から開始してシステムを改善しています。

先方の窓口担当者は、現場からスタートして長い間勤めていらっしゃる役員の方です。 優しい印象の方ですが、その会社で作っているものにとても誇りと情熱をもっている方です。

保守内容について定期的に意識合わせをする会の中で、現場からの要望事項のリストを見ていた時、先方の窓口の方がふと口にした言葉が忘れられません。

”うちがこれまでお客さんから信頼されきたのは、依頼されたカスタマイズ品に対して一つ一つ丁寧に仕様を調整し、一つ一つ丁寧に品質の高い金属製品を作るという姿勢と、それを継続して来たという実績だと思うんです。ですが最近は、上層部も現場も「あれもこれもシステムでなんとかしてよ」という言葉をよく聞きます。このままでいいんだろうか?と思うことがあるんです。”

(だいぶ意訳しています)


システムによってビジネスの価値が犠牲になっている。

そう感じました。

会社を作るということは、新たに実践したいこと・新たにもたらしたい価値があってのことのはずです(会社のビジネスだけでなく、会社内の環境・スタイルの新しさもその一つだと思いますが、今回は本筋ではないので触れません)。

上述の言葉は、システムを導入することによって、その「新しいもの」がシステムの存在によって変化ないしは妨げられている可能性を示唆しています(「新しいもの」と「変化ないしは妨げられているもの」の一致・不一致はこれも本筋ではありません)。

これはいわゆる「あるべき論はいらないから、とにかく現場に負担のかからないシステムにしろ」みたいな盲目的なものでなく、「やっぱりERPはカスタマイズしてなんぼや!」みたいな時代錯誤な意見を支持しているものでもありません。

あくまで、「今この瞬間から先に、SIer業のどのような行動・成果が将来に価値をもたらすのか」を考えるための題材です。

システムはただの仕事道具。しかし人間は道具に適応できて"しまう"。否応なく。

私はこれまでの仕事経験でそう感じています。

何が言いたいかというと「ビジネスの価値が落ちる、ただ楽になるだけの道具を導入しても、それを受け入れてしまう」ということが事実あるということです。

SIer”がなぜこの世に発生したか?今一度考えてみましょう。

冒頭にシステムを自社で管理する流れが主流になっている、ということを書きました。ですが、日本でもそれこそ日立・富士通などの大手のメーカーなんかはもともと自社で情シスもってシステム管理していますよね。

ということは冒頭の流れというのはなんでしょうか? 単純に「システムを管理するのに必要なコスト・パワーが少なくなってきて、より規模の小さい会社でも自社で管理できるようになってきた」ということです。

では、この流れが起きる前、情シスを抱えるだけのパワーのない会社は、どのようにしていたのでしょうか? 外注していたんです。 それがシステムインテグレータ、通称SIerです。

SIerってなに?

情シスを抱える・システムを開発・管理するだけのパワー・コストを持ち合わせていない会社に、システムを提供することです。

つまり、 「SIerのやるべきこと・考えるべきこと」=「情シスのやるべきこと・考えるべきこと」 です。

全ての会社が自社だけでシステムを管理できるようになるまで、SIerにはやるべきことがある。

ということです。

その作業は、新規にシステムを構築することだけではありません。

そのなかには、上で述べた保守している会社のように「すでにシステムをもっているが、そのシステムがビジネスを妨げていないか見直す」という行為も含まれます。

これも、今この瞬間から未来、多くの場合SIerが実施”しなければならない”ことです。 なぜならそのようなパターンに陥るのは、自社でシステムを管理するパワーを持っていない場合のほうが圧倒的に多いからです。

この仕事は”SI”なんでしょうか?

「今ココ」状態です。

すでに多くの会社において、日々の仕事の道具をシステムにインテグレーションするという段階は、すでに終了しているはずです。

また、上記のような、これからのSIerの仕事は「システムへのインテグレーション」でしょうか?

システムインテグレーションはいわば「道具の正規化」。これからは「道具の非正規化」をしなければならない。

と言い換えられると思います。

SIという言葉も、日本のIT界隈では印象がよくないので、何か新しい言葉にしたいですね。 「人間に考えて・行動してほしいことを促す・示唆するためのシステムを作る」みたいな。「システムをビジネスの裏方化する」みたいな。

“Behind-ization"? "Background-ization"? 英語得意な人よろしくお願いします。

SI業界は縮小はするかもしれませんが、まだやるべきことが残っています。

つらつらと由無し事を書いて来ましたが、そういうことです。

立つ鳥跡を濁さず、じゃないですが、SIを野ざらしでほっぽり出すのではなく、ちゃんと未練なく埋葬しましょうということです(違う)。

化けて出ますよ(合ってる)。

私もそれを考えていきます。


わしのSIer生活は、もうちょっとだけ続くんじゃ。


8/31 追記

japan.zdnet.com

「Solution Initiator」かっこいいですね。これにしましょう!

このユーザ企業はわしがそだてた

ここ最近、「エリック・エヴァンスドメイン駆動設計」と「SQLアンチパターン」を読んでて、思ったことを書きます。

内容は基本的に「意見」ですので、よろしくお願いいたします。

※ここでは検討・研究をしたいと思っているので、私個人を知っている方も、ちょっと私個人の戦績はいったん棚に上げて温かい目で見守っていただけると幸いです。 会社組織の政治的な話も、私は疎いので勘弁してくださいm(_ _)m


前提

今回の話で登場する人物は二人だけです。

  • システムの開発側

イメージとしては要求定義工程以下の、システムを受注する側です。 ここが境目になるので、そこから先の内部発注先などは今回は関係ありません。 コンサル専門は要求定義工程になるかな? 「われわれはそれより上位の者だ!」という月の魔物に魅入られた人たちは、端から見ててください。

  • システムのユーザ側

最終的にシステムを所有・利用する企業などの側です。 運用・保守会社がある場合、ビジネス要求と直接的な関わりがない場合のほうが多いと思うので、ユーザ側には含まなくてよいと思います。

これらを使って、考えていきたいとおもいます。

システム開発プロジェクトが失敗するのはなぜ?

システム開発プロジェクトはよく失敗します。ホントによく失敗します。もうええっちゅうくらい失敗します。

今私がこの記事を書いている瞬間にも、失敗しています。 普段何気ない顔でコントリビュートしていたあのプログラマも、今は他のプロジェクトの火消しでヒィヒィ言っています。

いろいろな失敗状況があると思います。

  • 要求がまとまらない
  • 要件が合意できない
  • あとからモデル変更がゴロゴロ発生する
  • 製造が終わらない
  • 検収合格にならない
  • 本番稼働できない
  • 運用が大変で、システムを使わなくなる

これに対して、私を含む開発側では、 プロジェクトのふりかえりや反省会、あるいはお疲れ様でした飲み会などで、次のような言い訳があると思います。というか、ほとんどがそうです。

  • お客さんが、自分たちがしたいことをよくわかってなかった
  • お客さんの中でコンセンサスがとれていなかった
  • 最初に決めたはずなのに意見がころころ変わるおっさんがいた
  • そもそも決めないおっさんがいた
  • 製造の見積もり工数が足りてなかった⇒そのまま見積もったら「高い」と言われたんだ⇒お客さんがシステム開発のことわかってないんだ!

……

ちょっと悲しくなってきたのでこのへんにしましょう。

おっさんも同じ人間、同じ地球の仲間なので、一人のせいにはできません。

でも、プロジェクトの失敗を誰かのせいにしたいですよね?にんげんだもの(悪用

結論:プロジェクトが失敗するのは開発側の責任

「なんでだよ!あのおっさんがめちゃくちゃいうから失敗したんだろ!」

と、過去の私も思っていました。

では、なんででしょうか。

理由はとても簡単。

理由:開発側はシステム開発のプロだから

そもそも私を含め開発側は、システムを提供して飯を食っています。

 

Q)なぜシステムを提供すると飯が食えるんでしょうか?

A)システムを提供すると、お金がもらえるからです。

 

Q)なぜシステムを提供すると、お金がもらえるんでしょうか?

A)システムを利用したお客さんが、お金を払うだけの価値を獲得できたからです。

 

Q)なぜシステムを利用して、お金を払うだけの価値を獲得できたのでしょうか?

A)「現在の状態」と「システムを利用した新しい状態」を発見し、そのギャップを発見できたからです。

 

この「現在の状態」と「システムを利用した新しい状態」のうち、「システムを利用した新しい状態」を発見する手助けができるのは、 システムのプロである、少なくともお客さんよりもシステムに詳しい私たち開発側ではないでしょうか?

もし、お客さんのほうがシステムに詳しい、もしくはお客さんの提案するシステムをそのまま形にしたことがあったとすると、 きっとあなたがお金をもらうために提供したのは「システムの価値」ではなく「代替可能な労働力」ではなかったでしょうか?

最後にあなたが携わったプロジェクトが提供していたのは、「システムの価値」だったでしょうか?「代替可能な労働力」だったでしょうか?


なぜ「新しい状態」を見い出せないのか?

これも理由は簡単。

理由:「新しい状態」を見い出そうと思ってないから

はぁ?見い出すのが仕事じゃないの?と思うかもしれませんが、

これがいわゆる「プロジェクトが失敗した~」と言っている人たちの大半の状態だと思っています。

失敗する前に、プロジェクトの成功地点を共有できてないんですね。

なぜ、見い出そうと思ってないのでしょうか?

理由:”「新しい状態」を見い出しましょう”ということを、誰も知らないし教えてもらってない

新人教育の中に、”「新しい状態」を見い出しましょう”って項目はありましたか?

主任・課長など俗にいう”出世”したときや、プロジェクトリーダーなどに抜擢される際に、”「新しい状態」を見い出しましょう”って教えてもらいましたか?

なんで教えてもらってないんでしょうか?

教える側の人も知らないからです。

「一子相伝」ならぬ「零子相伝」です。(ドヤ

もしくは、知ってる人もいたかもしれませんが、独覚だったのかもしれません(※宗教注意)。

教えろ!っていうほうが無理ですよね。上司と言われる人たちも、知らないか、教え方がわからなかったんですから。

もしかして: 見い出し方を知らない

そう、見い出す必要性を知らないから、見い出す方法も知らないんです。

ということは、それをお客さんに教えることはできませんよね?

ということは、お客さんの行動や成果物に対して「これはよくない」と指摘することができない、ということになります。

こうして、いわゆる「プロジェクトの失敗」が完成するということです。

補足:勉強すればいいんじゃない?

日本人の大半は「勉強」をしません(学校の勉強の大半は「記憶」です)。

この理由については、あまり考えていないので割愛しますが、文化的なものなんでしょうかね?

じゃあ、どうやったら見い出すようになるのか?

ここでは、文化の話もあるので、日本人限定の話でいきます。

まず、日本人は社会での同和を最重要事項とし、 他人の目におびえながら自分のプライドだけはある程度確保しておきたいと考えている人種です。

例として、「意識高い系」の話が通用する可能性が低いです。

「俺がこんなキラキラした話に乗っていると、みんなに笑われちゃう。」ということを、笑っている人も笑われている人も思っています。

「俺は意識高くなりたいのに、周りが高くなってくれないので、笑われてしまいそう・・・」という心配性の方……ご安心ください!

なんと今なら、 ほぼ全ての日本人に通用する、だれでもいつでも実施できる方法 があるんです!

知りたいですよね、奥さん。

早速見ていきましょう。



ケツ論:ケツをたたく

f:id:saikou9901:20170618164910p:plain

ち、違います……そういう話じゃないです。

ちょっと真面目な話してるんで今日はお引き取りください……

……

さて、どうするかというと、ここで アンチパターン の登場です。

殺伐とした開発チームに、アンチパターンが!(追い打ち

ここではシステム開発全体の話をしているので、アンチパターンというと、「システム開発の失敗例」ということになりますね。

この手のネタは、本当にそこらじゅうに転がっています

本だってあります。

Twitterで漁ってもすぐ出てきます。 最近流行ってますよねこれ。

twitter.com

では、これらのアンチパターンをどのように活用すればよいのでしょうか?

手順を見てみましょう。

  1. アンチパターンを知る

  2. アンチパターンを共有する

  3. このままだとこんなことになって不幸になるぞ!普通ではなくなるぞ!いいのか!?」と脅す

以上。簡単ですね!(簡単じゃない

行動の動機を外部から与える

アンチパターンと、それによる悲しい事件や死屍累々を知っておくと、自分はそうなりたくないと考えます。

そうすると、「これやって大丈夫か?」と常に気を配るようになってくるんじゃないと思います。なってくるといいと思います。

上にも少し述べましたが、大半の人は「勉強」しません。

となると、どうやって行動の動機を作るか、ということが課題になります。

アンチパターンを広めることで、その行動の動機を外部から与えることができます。

「こんなつらい経験、思いをしたくない!」というのは、一番”汎用的な行動の動機”なのではないかと思います。


こうして平和が訪れた(予定)

まだ訪れてません。少なくとも、私の周りでは。

どのようにアンチパターンを広め・伝えていくかというのは、これから勉強していく必要があります。

もう新人教育というか、資格をつくってもいいんじゃないでしょうか?

「システム失敗コンサルタントみたいな。(innocent


まとめ

愚者は経験に学び、賢者は歴史に学ぶ。 愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。

オットー・フォン・ビスマルク

SQLアンチパターンにも挙げられていたこの言葉をみて、今回の記事の内容を考えました。

そして、ちょうど同時に読んでいたドメイン駆動設計においても「ドメインエキスパートとユビキタス言語を共有し、それを厳密に使用する。各々、独自の言語は使用しない。」という旨の、”ユーザ側にも努力・注意を促す”必要があるような内容も記載されていました。

本文中の”見い出す”には、「ユビキタスプロトコルによる情報共有で、適したモデル、ひいてはシステムを”見い出す”」というイメージをもっています。

本を読むことも、歴史というと大仰かもしれませんが、自分が経験してない範囲から学んでいるということで、とても有意義なものだと感じています。

みなさんも、なにか面倒な状況におかれているとして、それを嘆くだけでなく、どうしてこうなった!的なことを少しでも考え始めていただければ、みんなで幸せになれるんじゃないかと思います。


要するに、こんな文章・記事を書くことが「意識が高い」ということです。

おわり。


JJUG CCC 2017 Spring に行ってきた

はい。行ってきました。

www.java-users.jp

来場者数は1000人を超えており、いろんな人が参加ブログを書くとは思いますが、

各時間ごとに複数セッション、最大8セッションまで並行して行われていました。

その中で、自分と全て同じセッションに参加している人もいるかいないか、ましては自分のこれまでのコンテクストを前提としたうえでの感想と完全に一致するということはまずありえません。 ですので、自分なりの所感をまとめておくことは、無駄ではないと思います。

また、どこかで自社にフィードバックする際の覚書にもしておきたいという思惑もありますので……


非機能要件とSpring Boot

speakerdeck.com

一番の目玉はIPAが提供する「非機能要求グレード」の話が出たことです。

www.ipa.go.jp

このグレードで定義したレベルを、Spring Actuator、Spring Securityを利用して満たしていくという展開の内容でした。

所感

元々存在自体は知っていて、利用を検討したこともあるのですが、他にこれを利用しているところが身近にあるという安心感がありました。

加えて、Spring Actuator、Spring Securityの機能についても多く知ることができ、とても良い機会を得られたと思っています。


Java EE 8 and its latest topics

※資料公開なし

Java EE 8の新機能に関する話でした。

今回覚えておくことは、「Java EEはマイクロサービスに向かう。Java EE9が本番。Java EE8はその前哨戦。」とういことです。

さしあたり、Java EE8では次の機能が増える予定です。

これらを実現する中で次の仕様のトピックがありました。私もまだよく理解してないので名前だけ・・・

  • JSON-P 1.1
  • JSON-B 1.0
  • Servlet 4.0
  • JSF 2.3
  • CDI 1.0
  • BeanValidation 2.0
  • 新しい認証認可機能(なんだっけ?
  • Identity Store(これ重要そう

おいおい勉強していきます。

また、Java EE8のマイルストーンは次のようになっています。

  • 今年7月中に仕様確定
  • その後まずGlassFish5に着手

所感

WebLogicサーバ開発は並行して始まるのだろうか?要チェックです。


How to use MicroProfile

www.slideshare.net

プロデューサーGlassFishユーザグループの方のお話です。

MicroProfile、私は初めて名前を知りました。

Java EE7以降の開発速度にしびれを切らしたコミュニティの人たちがつくったマイクロサービスアーキテクチャを目指したAPI仕様。次の実装があります。

  • Wildfly Swarm
  • Payara MicroProfile
  • WebSphere Liberty
  • TomEE

Payara MicroProfileだけ知ってて、なんとなく「今後Java EEやるならこのへんかな?」とは思っていました。

この仕様が誕生したのは、Java EE 8が発表される前です。

所感

Java EE8(Java EE9まで含む)のロードマップが見えたことで、MicroProfileとは(Java EE自体とも?)どう向き合っていくか、考える必要がありそうですね。


Javaエンジニアに知ってほしいRDBアンチパターン

speakerdeck.com

DB設計のアンチパターン。重要なことは次の通り。

  • DBの寿命はAPより長い
  • DBはリファクタする機会がほとんどない(せいぜいDBMSのバージョンアップくらい)

つまりアンチパターンとは次のようなものになる。

  • のちの苦しみを生むような設計・作業実施
  • 過ちを繰り返さない

例えば・・・

  • SELECT delete_flg FROM foo GROUP BY delete_flg をたたくと次の結果が返ってくる

    0:初期値?

    1:存在

    2:削除

    9:抹消(削除とどう違うの!?

    99:システム権限でむりやり削除

    null:APバグにより登録

  • テーブルに memo memo2 memo3 という列名がある

    最初の memo が無印というのがポイント。 ここで抱いている感情の名前を「哀愁」といいます。

というお話をいくつかいただきました。(別の記事できるレベル。というかだれか記事にしてBuzzる。)

最後に、ありがたいお言葉。

DBの問題は忘れた頃にやってくる

サーバの問題は休みの間にやってくる

アプリの問題は納品前にやってくる

所感

全日本が泣いた。席は完全に埋まって、壁際は立ち見だらでだった。 俺もよくやる話。SQLアンチパターン読もう。そーだいさんの本じゃないけど。


Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた

www.slideshare.net

SpringFrameworkでできたモノリシックアプリケーションを、SpringBoot化+マイクロサービス化する(真っ只中にいる)という話。

直近で取り組んだマイクロサービス化について、次の紹介がありました。

  • マイクロサービス

    • Eureka:サービスディスカバリ
    • Ribbon:クライアントサイドのロードバランシング
    • Hystrix:サーキットブレーカー
  • ロギング

    • fluentd:SpringBootのログファイルを収集してElasticsearchに送る
    • Elasticsearch:言わずもがな
    • zabbix:Elasticsearchの内容をチェックし、結果をトリガーとしてslackにkibanaのURLを送る

また、マイクロサービス化における結合テストについて次のSpringファミリーの紹介がありました。

  • Spring Cloud Contract Stub Runner

自由にエンドポイント⇔ステータス・ペイロードの組み合わせを指定できる、スタブノードを簡単に立ち上げることができます。 これでステータス500が返ってくるときのテストもイミュータブルに実施できるわけですね。

所感

Spring Cloud Contract Stub Runnerという、すばらしいソリューションの存在を知った。 エンドポイントだから、JVM以外の開発のテストノードにも使えるんだよね。 俺もみんなも、関ジャバに参加してじゅくちょーさんと握手!


劇的!データベース・ビフォーアフター 時代はディスクからインメモリーへ――

※資料公開なし

証券関係のシステムをこなす、速度の匠コンビのセッション。

インメモリデータグリッドを活用する話。

インメモリデータグリッドは、キャッシュ技術(HazelCastとか)ではない。あくまでメモリがデータの主体となる仕組みなんだ。

稼働中のデータはすべてインメモリデータグリッドにより管理、無駄なレイテンシはとにかく省かれる。

社長「メモリだから、マシンが落ちたらデータが失われるんじゃないの?(迫真」

社員「大丈夫なんですよこれが(棒」

データグリッドを構成する別ノードにバックアップが自動的に行われるのだ!

さよなら磁気ディスク!・・・とはいかない。永続化データもあるからね。

あと、インメモリデータグリッドはMapデータをKey-Valueで記録するから、クエリ的な問い合わせはRDBより遅くなる。

設計命で、使い方次第で神にも悪魔にでもなる。気を付けてくれよな!

……

所感

インメモリデータグリッド初めて知りました。 いままで業務ではそこまで速度を求められるものを作ったことがないが、自分で試してみたい。 SpringBootとKotlin使ってできたらいいね? いいね?


OSSで会社を興すには

※資料公開なし

Jenkinsの生みの親(前身であるHudsonを開発した)川口さんのセッション。

Jenkinsを使って開発コンサルティングしたり、Jenkins自体にコントリビュートする会社Cloudbeesを設立している。

OSSを使ってマネタイズするには大きく次の戦略がある。

  • プロサービス(使い方教育)
  • 商用版パッケージの開発
  • SaaS提供
  • サポート

マネタイズできるようになっても、そのまま安泰ではない。

これまでのコミュニティのモチベーションと、どう向き合っていくかが大切。

企業化することで、コードレビューなどが厳しくなり、コントリビュートのハードルが上がってしまう問題。

コミュニティの大半がいつのまにか同じ会社になっていて、OSSなのにぜんぜん参加者の平等感がないじゃん問題。

色々大変なことばかりだが、OSSで会社を興すというモチベ―ションは、OSSというソフトウェア開発パワーのすばらしさを感じているから。

Dockerのように2、3年前には名前も聞かなかったソフトウェアが、いま全世界で使われている。このパワーがOSSにはある。

ブランド・商標には気を付けよう(迫真

所感

OSSコミュニティのパワーの大きさはすごい。

ソフトウェアの本質はソリューションにある。それが中の人の発想の問題で実装されなかったり、しがらみで停滞したりすることは、もったいなさしか感じない。

私もOSSのパワーにより加わっていきたい。


参加したセッションは以上です。

懇親会のLT? 酒飲んでてよく覚えてません(銅鑼で中断されてましたし笑


総括して

大きく2つのトレンド(というとすごく軽く聞こえてしまうので、問題提起と言いたいけど、じゃあ答えは・・・と問われるのもいやらしいのでトレンド)があると認識しています。

マイクロサービスアーキテクチャ

どうしようもなく、ハードウェアは壊れるんですよね。(ここでAS400は壊れない、という人は間違いです。AS400も壊れます。値段に比例した分だけに壊れない、というだけです)

単一のハードウェアの性能の限界も来ているのは既知の事実(ノイマン型コンピュータに代わる方式が出てくるか、新しい導体物質が見つからない限り……)。

その解決策として有力なものと認識されていて、ある程度の実績もあるマイクロサービスアーキテクチャに焦点が集まるのは、自然な流れだと思います。

そして私も、この解決策には同意します。ぜひ、マイクロサービスアーキテクチャについては追及していきたいですね。

OSS

というよりはコミュニティ、どれだけの人数がかかわっているかによって、そのパワーや安定性は比例してくると思います(安全性も、比例するかとは思われます)。

それは開発参加者の人数ではなく、利用者の人数です。

Jenkinsの川口さんも何度も名前を出してた「Docker」が典型例です。

対極にいるのは「自社製品をつくるぞ!」と名目だけで躍起になっている人や、SIでいえば業務画面を作ろうとしないアーキテクトのような感じです。

ソフトウェアは、使われてなんぼ、というのがよくわかる流れですね。

という考えを踏まえれば、別にオープンであることは必要条件ではありません。

そういう意味では、Java EEが新しい視点というか哲学への第一歩を踏み出したことは、とても期待できると思います。

最後に

L3セクションの @khasunuma さんもおっしゃっていましたが、「銀の弾丸はありません」。

名前として現れたマイクロサービスアーキテクチャOSSについても、鵜呑みに取り組むだけでなく、その歴史・存在意義/哲学・有用性によってもたらされる効果をよく考えることが大切です。

として、まとめを終わりたいと思います。



一方そのころ・・・

私はhubotで宮森あおいちゃんと無能(まさに人口無能)な会話を楽しんでいます。

f:id:saikou9901:20170507200806p:plain

結局は目的・動機だったなぁというGWのおもひで

5/3~5/7の5日間、近年稀に見る有意義なGWを過ごしたと思うので、今後の自分のためにもちょっと纏めておこうと思います。

なにをしてたか

一言で言うと、5日間にわたって、会社で使用しているMattermostにbotを設置しました。

Mattermostはチャットツールです。オンプレミスで使用できます。

about.mattermost.com

botは、bot作成フレームワークhubot を使用して作成しました。

hubot.github.com

※各ツールの概念・仕組みについては、この記事では省きます。

5日もかけてとかプゲラ

ググると、大概Qiitaとかで「10分で導入うんぬん」とかいう記事、よくヒットします。 しかし今回の環境としては基本的に「会社のプロキシサーバ配下」となっております。 (この苦しみは分かる人にしか分からないと思います……)

思い返せば、5日間のうち2日間くらいはプロキシサーバと戦ってた覚えがあります。

技術的な設定ファイル云々は、今後区分けしてQiitaとかに投稿するつもりです。

こんな大変なのは経験は、私が1回すれば十分です。

もったいなくてなぁ、お前(ら)なんかにやれるかよ!(プラネテス


さぁというわけで、5日間の泥沼の戦いを振り返ります。 各日の内容全てにプロキシ存在のバイアスがかかっていると思って下さい。地獄でした。

……

1日目(5/3)

hubotは

  • bot本体
  • アダプタ

という2階層から成っているそうです。(ここで既に1時間くらい経過!)

じゃあ、hubotのMattermost用のアダプタがあればいいわけですね!

hubotのアダプタ一覧はこちら

Mattermost用のアダプタは2種類あるようです。

  1. hubot-mattermost (一覧だと Mattermost
  2. hubot-matteruser (一覧だと Mattermost - WebSocket

GithubのREADMEを見た感じ後者 hubot-matteruser の方が思ってた感じ(詳しくはラスト)になりそう。

ですが、せっかく休日だしWebhookが使ってみたかったので、まずは試しに前者の hubot-mattermost を使用しました。 hubotの稼働は、覚えたてのDockerで行いました。

(苦節うん時間)

一応できました!

f:id:saikou9901:20170507184710p:plain

でもやっぱり思ってた感じではない。

というわけでGithubページを見た感じよさそうな後者に挑戦。

しかしこちらには、セキュリティとか厳しい会社ではなかなかハードルの高いアイテムが必要でした。

そう、 bot用メールアドレス です。

会社のドメインなんてよっぽどの理由が無いとゲットできない、外部のWebメールなんて全部フィルタで弾かれる。

……

よし、

ローカルにメールサーバ立てるか

2日目(5/4)

はい、メールサーバです。

大分慣れてきたDockerでやりたかったので、こちらを使用させてもらいました。

github.com

適宜メンテナンスされているようですし、結構使用されてそうなので。

ここで、ローカルメールサーバの要件をおさらいします。

  • Mattermostから飛ばすメールサーバは1つなので、会社ドメイン(社員ユーザ)もローカルユーザ(bot)もこのローカルメールサーバに飛ばす
  • そのうち、会社ドメインのメールは、本来の会社のSMTPに転送してあげる
  • 一応会社の皆で触れるようにIMAP設定する

です。

さぁというわけで Postfixの勉強からスタート しました。


(ひたすらWebページを見ているマウスの音)

ド、ドメインのリレー……(リレーっていうんだ……)

http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#relay_domains

(docker-compose upする音)

ユーザ作ったし、立ちあがったからOutlookしてみるか……

なんでIMAPできへんねん……

telnet叩く音)

平文認証はデフォルトでOFFられてるのか…… どうやってONにするんだ……

(docker-compose up, down, up, downする音)

送信元、宛先アドレスが、ローカルアドレスでもリジェクトされないようにしないといけないのか……

http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#smtpd_sender_restrictions http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#smtpd_recipient_restrictions

というか、docker内部のPostfixのmain.cfを上書きする形だからコンテナの内部の設定分からないといけないのか……

(docker run bashで/etc/postfix/main.cfみる音、コンテナにvimはいってなかったからcatする音)


……

Outlookでメール送受信できたーーーーーーーーーーーーーーーーーーーーー!

メール送受信になんだかタイムラグがあるけど、きっとブラックリストサーバ探そうとしてるだけなので気にしないでおきましょう。

さぁ、明日はいよいよbotをつくります。

3日目(5/5)

というわけで hubot-matteruser を使ってbotを作ります。

ローカルメールで認証して、作成したユーザを環境変数botに渡して……

無事にping/pongできました!!botの様子はラストに)

いやー長い戦いでした。

さぁ、もうMattermostのユーザは確定したので、Webhookの時に作ってたMattermostのお試しユーザを消しておきましょうか。

どうも Mattermost CLI というのを使用するのだそうです。

じゃあ、ページ見てみましょうか。

Command Line Tools

……ん?

https://docs.mattermost.com/administration/command-line-tools.html#platform-user-activate

f:id:saikou9901:20170507193004p:plain

は?アクティベート……アクティベート!?できるの!?

メール認証は!?

昨日の苦労は!?

……

まぁ、メールサーバ立てる勉強になったし、いや、まじで役に立ったし(震え声

……

さぁ、bot立ったということで、次はあれをしましょう。

あと、今日は精神的に疲れたからビールたらふく飲んでとっとと寝ましょう。

4日目(5/6)

最近会社のサーバに Concourse というCI/CDツールを導入してみたので、これを使用して、hubotの Gitbucket リポジトリにプッシュされたら、Dockerデプロイされるようにしましょう。 つまりCDだけです。

github.com

github.com

CDの概要は次の通りです。

  • hubotコンテナのDockerfileで、Gitリポジトリからbot本体ソースを取得するようにしておく
  • Concourseのgitリソースを使ってGitリポジトリのmasterを監視する
  • masterにpushされたら、hubotコンテナが稼働しているDockerホストにSSHアクセスして、コンテナの再構成・実行を行う
  • Concourseのslack通知機能(サードパーティ)を使ってMattermostに通知する

特に試行錯誤したのは、

  • masterにpushされたら、hubotコンテナが稼働しているDockerホストにSSHアクセスして、コンテナの再構成・実行を行う

です。

openssh-clients を使用してログインするんですが、対話形式で「Credential受入れてOK?」という質問と、パスワードの入力に回答しなければなりません。

これには expect で対応しました。 新たにQiita記事にするまでもないのでさらっと書いてしまいます。

expect -c "
set timeout -1
spawn ssh -l root 【dockerホスト】 【docker再構成用につくったスクリプト】
expect \"Are you sure you want to continue connecting (yes/no)? \" {
    send -- \"yes\n\"
    expect \"root@【ホスト】's password: \"
    send -- \"【パスワード】\n\"
} \"root@【ホスト】's password: \" {
    send -- \"【パスワード】\n\"
} \"Permission denied (publickey,gssapi-keyex,gssapi-with-mic).\" {
    exit
}
interact
"

set timeout -1 をしておかないと、パスワード問合わせまで時間が掛る場合があるので、タイムアウトがよく発生してしまいます。

……

というわけでここは粛々とページを読みまくって、無事にできるようになりました。

ですが、ちょっとパイプラインに無駄が多いので、ちょっと改善しましょう。

5日目(5/7)

さぁ5/7、つまり、今日の話。

CDにあたって、次の時間がかかる要因がありました。

  1. ConcouseのTaskを実行するdocker-imageに、パイプライン実行の度に openssh-clientexpect をインストールしていた
  2. hubot本体をGitリポジトリから取得してくるのをDockerfile内で実行していたため、デプロイ時にはイメージから再作成しなければならなかった

まず 1. です。

こちらはもう……Dockerhubにイメージ作っちゃいました。 ローカルのDockerリポジトリとかまだ勉強しきれてないので。

https://hub.docker.com/r/saikou9901/centos-for-concourse/

これだけでかなり速度改善されました。

次に 2. 。

これは、 git clonenpm install あとbot本体の実行開始を、いわゆる entrypoint.sh に移しました。 これで、イメージの再作成は省かれ、コンテナ再作成からで済むようになりました。

(entrypoint.shの改行コードが CRLF になってしまっていたせいで、先頭の #!/bin/bash がずっと no such file or directory ってなって30分くらい格闘してたのは内緒)

以上2つの改善により、デプロイ時間は半分以下になりました。



結果

そして、長い闘いの末、我々(我のみ)の夢が叶ったのです。

……

f:id:saikou9901:20170507200658p:plain

f:id:saikou9901:20170507200806p:plain

我が社に、エースデスク、宮森あおいちゃんがやってきてくれました。



すばらしい。

botなので、24時間オンラインです。(意味深)

pushするだけですぐにいろいろなことを教え込むことができます。(意味深)



オンラインのマークがアイコン右下についてほしい。ただそれだけのために5日間走り切りました。

f:id:saikou9901:20170507203630p:plain



まとめ

先月くらいから暇を見て、golangとかRustとか、いままで触ったことの無い言語を勉強していたんですが、 本番で使用していないということもあり、チュートリアルをやったりして満足してしまっている状況でした。

ですがそれは技術の向き不向き・頭の良し悪しとかではなく、目的・動機があり、そこに高い優先順位なりモチベーションがあれば、いろいろな勉強にも取り組め、そのうえより深く理解もできる、という今更なことを新めて感じたわけです。

5日もかけてね(白目

セキュリティ要件の定義に疲れたら

f:id:saikou9901:20170312130440j:plain

けものフレンズを見て、何もかも忘れましょう。

ではなく・・・


セキュリティの話を詰めるのは大体疲れます

  • Q.ウチくらいの会社なら、httpsを使わなきゃダメだろ!

    A.いや、イントラネットですやん。

  • Q.システムをいつ誰が使用したか、正確にトラッキングしよう!

    A.トラッキングして何に使うんですか?その前に社員がパスワードを付箋でPCに貼ってるのなんとかしましょう。

  • Q.権限管理、ロール管理をしよう。さぁあとは宜しく。

    A.部門リストと権限リストは業務要件なので提示してくださいね。あと社員がパスワードを付箋で―

システム部門がないか、あっても機能していないところは、その辺詰めるのすごく大変です。 あと、多くの場合“Q”になっていないことも特徴です。

話を詰めるときは、まずその場における"セキュリティ"を定義することが一番大切です。(まぁ大体の会議はそうですが)

さぁ、セキュリティを定義しましょう!

・・・

“セキュリティ"って、何だ?

吉○沙○里さんを雇うことでしょうか?

おそらく違うのではないかと思います。今は本人が戦うんじゃなくて、ポケモン戦わせてるので。(そういう問題じゃない

そもそも対象になってるのは情報システムです。

というわけで、セキュリティについて調べて"情報システムにおけるセキュリティ"を、可能な限り汎化して定義することが今回の目的です。


Wikipedia

まずはWikipediaいってみましょう。

セキュリティ - Wikipedia

ちなみに余談ですが、私のChromeChrome拡張「ジャパリペディア」のおかげで、Wikipediaがジャパリ図書館化しています。

chrome.google.com

f:id:saikou9901:20170312133224p:plain

それは置いといて。

「セキュリティ」のページは曖昧回避みたいな感じになってます。このあたりからも、"セキュリティ"っていう言葉の曖昧さがわかりますね(つまり誤認識が生まれやすく、人によって解釈もスコープも異なる)。 今回はあくまで、私のようなSIerが直面するであろう、それらしい次の3つの概要を引っ張ってきました。

コンピュータシステムを災害、誤用および不正アクセスなどから守ることである。たのしー!/また、ハードウェア、ソフトウェア、データ、ネットワークのいずれについてもその機密性、完全性、可用性を維持することである。

―――概要から

ジャパリペディアのせいで余計な吹き出しが入り込んでますが、概ね楽しくはないと思います。ちなみに吹き出しの入る箇所、内容は毎回ランダムです(Chrome拡張の宣伝みたいになってますね。広告料くだちい)

不正な利用とは、第三者による秘密情報へのアクセス、許可されていない操作の実行、ネットを介した詐欺(架空請求ワンクリック詐欺など)が含まれる。この語は、しばしばコンピュータセキュリティ(安全性)を保つための仕組みや技術を指すために用いられる。また、コンピュータセキュアとも呼ばれる場合もある。\って言うんだー!/

―――概要から

って言うらしいですよ。

情報セキュリティは、JIS Q 27002(すなわちISO/IEC 27002)によって、情報の機密性、完全性、可用性を維持することと定義されている。それら三つの性質の意味は次のとおりである。 - 機密性 (confidentiality): 情報へのアクセスを認められた者だけが、その情報にアクセスできる状態を確保すること - 完全性 (integrity): 情報が破壊、改ざん又は消去されていない状態を確保すること - 可用性 (availability): 情報へのアクセスを認められた者が、必要時に中断することなく、情報及び関連資産にアクセスできる状態を確保すること これら三つを、英語の頭文字を取って、情報のCIAということもある。 JIS Q 27001 では、これらを次のとおりに定義している。\へーきへーき!/これらは、ISO/IEC 27001 の定義を翻訳したものである。ここで、エンティティとは、団体などを指す。\でも騒ぐほどでもないか/

―――定義から

は、はい。認識は違ってなかったので、騒ぐほどでもないですね。 セキュリティ畑の人たちって、やっぱりJISとかISOの番号、暗唱できるんですかね?

基礎を成すコンピュータネットワークのインフラの規定、無資格者のアクセスからネットワークとネットワークからアクセスできる資源を守るためにネットワーク管理者によって導入される方針、および一貫した継続的な監視とその効果(場合によっては欠陥)の評価までの作業から成り立つ。

―――概要から

言葉としてのネットワーク・セキュリティと情報セキュリティは、しばしば同様に使われるが、一般にネットワーク・セキュリティは組織の境界線における防御の提供と理解され、この防御はハッカースクリプトキディなどの悪さをする人間を遠ざけるものである。今日ネットワーク・セキュリティ・システムはその効果が十分なものであるため、焦点は組織内の人々による攻撃あるいは単純な間違いから資源を守ることに移っている。

―――情報セキュリティとの比較から

以上です。

証券 - Wikipedia など、そのほかのセキュリティについても、ITから見て無関係ではありませんが、今日は汎用的な話にしたいので、割愛します。興味はありますが、沼りそうなので。


Wikipediaでは上記3つが並列のように見えますが、現実の事象を考えるともう1階層作ったほうがよさそうな気がします。

  • コンピュータセキュリティ
    • 情報セキュリティ
    • ネットワークセキュリティ

冒頭で話題に出したような前提知識のない人に対して説明するとなると、階層に従って説明したほうがブレークダウンできそうですね。


総務省

総務省にもこんなページがありました。

情報セキュリティって何?|はじめに|国民のための情報セキュリティサイト

私たちがインターネットやコンピュータを安心して使い続けられるように、大切な情報が外部に漏れたり、ウイルスに感染してデータが壊されたり、普段使っているサービスが急に使えなくなったりしないように、必要な対策をすること。それが情報セキュリティ対策です。

なんとも平易な文面・・・と思いきや、"情報セキュリティ対策“に違和感を覚えるのは私だけでしょうか? 正しくは"情報セキュリティ施策"だと思います。

対策だと、攻撃者側の表現になるんじゃないでしょうか?


経産省

経産省にもこんなページが。

情報セキュリティの三大要件|はじめに

f:id:saikou9901:20170312143617j:plain

“バンダル"って初めて聞きました。

バンダル - 意味・説明・解説 : ASCII.jpデジタル用語辞典

へー。モビルフォースのことかと思った


ググってましたが、なかなかIPAのページが出てこないと思い、直接アクセスしてみました。

www.ipa.go.jp

特に"セキュリティ"というものの解説はないですね。

IPAでは"セキュリティ対策“って書いてますね・・・

すごく違和感はありますが、やはりこれが一般的な表現なんでしょうか。


最近読んだ ソフトウェアシステムアーキテクチャ構築の原理 第2版 には次のように書いてありました。

本書ではセキュリティを、システムリソースの所有者が、どのリソースに、だれがアクセスできるかを、確実に制御できるようにするプロセスとテクノロジーのセットとして定義する。ここでいうかとは、人間やソフトウェアなど、システムでセキュリティアイデンティティを持つアクタの集合を指し、セキュリティスペシャリストは、通常、そういうアクタを主体と呼ぶ。リソースとは、サブシステムやデータ要素、操作など機密とみなされるシステム部分(つまり、アクセス制御をしなければならない対象)である。

これは、Wikipediaで分割して書かれてた3つの観点を、ひとまとめにしてる感じがありますね。 特に最初の一文。単語さえ平易にすれば、かなり汎用的になりそうです。


現時点でのまとめ

その他、各サイトで表現の違いはあれど、新しい登場人物やアクションは出てこないので、まとめてしまっても良さそうです。

今のところ、 ソフトウェアシステムアーキテクチャ構築の原理 第2版 の次の文面が、一番自分の中で汎用的だと思っています。

システムリソースの所有者が、どのリソースに、だれがアクセスできるかを、確実に制御できるようにするプロセスとテクノロジーのセット

あとは、説明する相手の習熟度によって、例え(データ、データの中の情報、PC端末、ひいては会社のフロア自体、など・・・)を変えるだけで、かなり通じそうな気がします。


またブレークスルーあれば書きます。

なぜ誰もこう書いてくれないDocker入門

先月から会社でWekanMattermostをDockerで運用し始めました。 まぁ私一人で管理するのも何なので、社内のDocker未経験メンバーにDockerの説明をする必要性がでてきました。

というわけでこのたび、前回のOAuth2のように、私は欲しかったけど誰も書いてくれていなかったタイプの、Dockerの概要説明スライドを作成しました。

社内説明自体はまだ実施してないので、今後内容修正や第2弾作成が走るかもしれません。


どんなツールや技術であれ、本当に導入検討などするのであれば、実際に手で触ってみなければ実用性は実感できません。 となると、まったく知識・経験がない人が、どういうがあればセットアップしやすいのかということになります。 十人十色、こうやって様々なアプローチを考えていくことは無駄ではないと思います。

あ、ちなみに私が入門したきっかけは、デブサミ関西2016で次の本を20%引きでゲットしたからです。

ですが、こんなきっかけがなければ、私自身は上記資料みたいな内容を把握して、Dockerの有用性や位置づけをもってそもそも習得するか・しないかを判断するタイプです。 私と同じような性格の方に、上記資料が響いてくれれば幸いです。


追記 2017/2/19

WindowsでもDockerが使用できることを発見したので、資料をアップデートしました。 詳細な内容は、コメント欄に書いてある記事でわかります。

Windowsにおいてはどうも

の2種類があるみたいだけど、前者は本当にLinuxのDockerと同じ方針だけど、後者は完全にハイパーバイザ型だろうと思うのは私だけ?

とりあえずアップデートしました。 フィードバックなどいただければ幸いです。