Raspberry Pi+Spring Boot + Pi4J で 信号機 WebAPI を簡単に作成してみる

いまさらながらQiitaはじめてみました…(汗)
手始めに最近やってるラズパイの超入門ネタを投稿してみました。

qiita.com

もっとマニアックなネタが書けるように頑張ります!!!

EC-CUBE DAY 2015 に 参加してきました #EC_CUBE

個人的に、10月から業種を金融からECに変更することもあり、ECの現状がどうなっているのか、この大きなカンファレンスに参加すれば何か得られると思い、申し込んでみました。

私は大阪に住んでいるので、東京開催のイベントは毎回面白そうで、非常にうらやましくも思いつつも、なかなか参加できない現状がありましたが、今回はどうしても参加したかったので、夜行バスで往復するという強行スケジュールで挑みました。(おかげで交通費は1万円以内で収まりました(笑))

店頭の力を活かすオムニチャネルとは。「24時間パルコ」の考えるECの未来

株式会社パルコ・シティ シニア・コンサルタントである唐笠氏から、ショッピングセンターである「パルコ」の「現在の取り組み」と「未来」についてのお話でした。

なお、パルコ・シティは母体のパルコのEC事業を営む傍ら、それらに絡むWebコンサルもやっているそうで、EC支援の活動が評価されて2014年には「ネット&リアル相互貢献グランプリ」にて「優秀支援企業賞」を受賞しているそうです。私にはあまり価値がよくわからなかったのですが、http://ecken.jp/?p=2298 が参考になりそうです。

オムニチャネルとは

EC業界にいるとこの言葉を避けて通ることはもうできない世の中になったのではないでしょうか。このセッション以外でも誰もが1度は口に出す言葉であり、じゃぁ具体的になにをするんだというところですが、ポイントは以下の通りです。

  • リアル店舗+EC店舗を連動させて、今以上に顧客の囲い込みを行う
  • 囲い込みも行いつつ、事業全体のスケールを拡大させていく
  • ブランドや店舗のファンになってもらい、どのチャネルでも購入できる
  • 最終的にはこれらの購買行動分析を行い、さらなる発展を目指す

とにかく、今までは店舗は店舗で売ればいいし、ECはECで売ればよかったものをお互いがそれらの特性を生かしながら、1つの大きな「店舗」として運営していこうじゃないかという、結構大きなストーリーが背景にあるようでした。

オムニチャネルを取り巻く背景

その背景には、購買層の購入スタイルが変わってきたことがあげられるようで、唐笠氏は特に「スマホの普及」に焦点を合わせて、以下の大まかな分析からオムニチャネルの推進を掲げているように見えました。

  • 普及台数:6800万台
  • メディアの接触時間がTVに次いで2位である。
  • パルコのスマホ閲覧率が79%に達している
カエルパルコのリリース

今までのECのスタイルを脱却し、新しいECのスタイルを作っていこうと考えられ作られたサービスが「カエルパルコ」となります。

それまで、2015年1月までは、パルコ本部がやり、本部に売り上げがあがる事業として出店型のECモールを中心に展開してきましたが、この形では限界が近づいていましたと。

例として、店舗との接点が希薄になってしまい、各店舗がもつ、販売力・接客力などの戦略を本店が横取りするような形になってしまったりと、いろいろ不都合な面があり、それを見ぬふりするのはできなくなってきましたよと。(売り上げも高止まりするようですね)

そこで、店舗側が運営できるように「ブログ」をベースに、「店舗に売り上げが立つEC」を推進していこうという流れが生まれ、それが「カエルパルコ」として「新しいECの形」としてリリースしましたよと。

特徴としては以下のポイントがあります。

  • 店舗スタッフが「ブログ」を通じて「商品」を独自発信できる
  • 在庫のコントロールを店舗が行い「取り置き」や「発送」を行う
  • スタッフの裁量がそのまま売り上げにつながる

聞いているだけでは本当にいいこと尽くしじゃないかと思いますが、もちろんこれができる「土壌」を提供するために、既にサービスとして提供されている「STORES.JP」をベースにパルコ独自で拡張を行ったようです。

  • 商品登録機能の拡張
  • カエルパルコ連携投稿などのカスタマイズ
  • 取り置き機能・ダイレクト発送の選択肢の追加
  • 店舗情報の集積・管理機能
手ごたえについて

これらの土壌を提供することで以下のような手ごたえを感じているようです。

  • 店頭によってはばらつきはあるがWeb注文だけで月100万円の売上達成
  • 都道府県からの注文、営業時間外の注文が増加
  • 実際にWebで買ったお客様にファンになってもらえるような施策を実施できる
    例:購入者にメッセージやノベルティなどを店舗側がサービスするなど
  • 店舗に裁量を持たせることで、倉庫・物流・仕入などのハードルを低くできる

特にアパレルなんかは商品の入れ替えが激しそうなイメージを持っていますので、店舗に裁量を持たせるメリットを最大限に享受できるような業界なのかなと感じます。

パルコが考えるECの未来

そして、最後にこれからのECの未来についてのお話がありました。冒頭でも書きましたが、スマホはもう日常に溶け込みすぎているので、この媒体を使った戦略は避けて通れないようです。

パルコで提供しているスマホアプリ「POCKETPARCO」の紹介と、それを基軸にした新しい購入スタイルの提案がありました。

  • スマホ独自の文化である、後で見る行為を意識した「クリップ機能」の提供
  • ポイントカードとの連動をすることで購入時の煩わしさの解消
  • 独自のコインシステムを提供し購買欲を上げていく
  • チェックイン機能の追加によりどの地域が活性化しているかの分析
  • Beaconと連動し人の流れをデータ化し店舗設計に生かす

このうち、パルコ以外でも「無印」や「LOFT」などのアプリで既に実施されしているものもありますが、やはり最後の「Beaconとの連動」は、建物を所有しているところには非常に有利ではないでしょうか。

今までその道のプロフェッショナルがやっていたような、店舗設計なんかも、ビッグデータに基づいて可視化されたものを利用できるのもあってすごく未来を感じました。

 eコマース革命から激動の2年。Yahoo!ショッピングの今後の戦略とは!

次に、Yahoo!ショッピング。ショッピングカンパニー営業本部本部長の畑中氏によるEコマース革命のこれからの戦略についてのお話を聞きました。

Yahoo!ショッピングというと、ガイアの夜明けなどで大きく取り上げられもしましたが、とにかく「なんでも無料」というイメージが本当に定着しましたよね。大きなところでは以下があげられます。

  • 初期費用:約20000円 → 無料
  • 固定費:19800円~49800円 → 無料
  • ロイヤリティ:売上応じて4% → 無料
  • 自社サイト送客:無料(自由)
  • メール送信:無料(自由)

無料にしてほんと大丈夫かと思われがちですが、実はこういう「戦略」なんですよね。赤字でもいいからとにかく業界をどんどん活性化させていこうとしていて、母体の財政状況が強みになっているなぁと感じます。

伸びしろはまだまだあるらしく、市場全体で300兆円までは拡大すると見込んでいるようです。直近の2025年には60兆円になる予定だそうです。

革命から2年後のいま

某R社の実績も交えながら、順調に成長していますよと。

  • 出店数:2万 から 13.4万 
  • 商品数:210%成長
  • 流通総額成長率:123%

要因としてはフロントでは以下のポイントがありますよと。

  • 無料による価格破壊促進(どの店よりも安くできる)
  • Tポイントの大量投下(5倍・8倍はあたりまえ)
  • ショッピングクーポン(発行数日本一)
  • 「お買いものまとめ」というキュレーションサービス
  • 優良なコマースパートナーを積極的に店舗に紹介

バックエンドでは(私の興味ある部分)では以下のポイントがありますよと。

  • フレームワークの改善(今までは米国Yahooのつぎはぎだった)
  • 各種サービスのAPI化を推進(楽天Amazonとも連携できるように)
  • UI・UXの改善(送料のわかりやすさ・Tポイント表示など)
そしてこれから

特に、母体であるソフトバンクとの密な連携は目を離せないかなと。ID・個人情報・決済情報の入力を取っ払って、キャリア決済できる仕組みを取り入れることで、シームレスにお買いものができるようなこともこれからやるようです。

また、アリババ…有名ですよね。越境ECを支援し、ショップを海外にもどんどん展開していきますよと。本当にやることがいちいち大きいです(笑)

通販業界こそ、LINE@(ラインアット) ~LINEでビジネスしよう~

私、寿司好きでございまして、最近近所の「かっぱ寿司」が「LINE@」を利用していることを知り、早速友達になった次第でございますが、LINEを使ったビジネスって広がりを見せてきてますよね。

特にLINEってどれくらいの規模で使われているか気になるところで

  • 世界は230カ国で利用
  • 台湾であれば2300万人中1700万人が使っている
  • 日本人口の45%が加入、アクティブユーザー率が63.6%
  • 30代以上の利用率:60%
  • 20代の利用率:26.7%
  • 10代の利用率:12.9%

この数字をバッグにいろいろ展開していますと。

  • LINE MALL:CtoC形式のサービス
  • LINE WOW:デリバリー系サービス
  • LINE PAY:各LINEサービスで利用できる決済サービス

LINE様もやはりPCとスマホのすみ分けは非常に意識されていて、利用傾向についても日々分析されているようです。

  • スマホは常に持ち歩き、見たものをお気に入り登録する傾向
  • PCはほしいものが決まっているときに利用、スマホはだらだら利用
  • 20代以下の若年層はTVよりもスマホ接触率が高くなってきている
  • PCは2ページくらいで離脱するが、スマホは5ページくらいまでいける
  • 普段使いするアプリは9個・平均は月27個利用

そもそもPCってある程度「時間」や「場所」の制約があって、行動パターンが限られてくると思う(家・会社・ネットカフェ)のですが、スマホって本当にどこでもつながっている(電車・お風呂・ベッド)ので、指向が別れてくるんだろうなぁと感じます。

LINE@とは

このあたりで既におなかいっぱいだったので、LINE@については話半分で聞いておりましたが、FaceBookmixiなどの趣味趣向を軸にしたオープンなSNSから、これからはクローズド・ファミリーなどのくくりでSNSを楽しむ時代になってきまてますよ。なのでLINE@どうですかというところみたいです。

  • 初期費用・月額:無料(リッチコンテンツは有料)
  • LINE@に登録されたお客様に対して1対1のサービスを提供できる
  • 管理画面は夫婦2人でやってる小料理屋でも触れるくらいシンプル
  • 自動メッセージ配信機能がついてます
  • 統計ツールだってあります(クーポン利用数・友達数・ブロック数など)
  • 特にLINEの強みである「プッシュ性」を最大限に生かせます

友人が居酒屋を経営していたりするのですが、ぐるなびとかWebサイトとか、私がやっても結構めんどくさかったので、おのずと店舗側ではだいたい定着しないんですが、「LINE@」であれば普段のやり取りで使っている延長上でも利用できそうですし、特にそういう人たちに薦めたいかなと思いました。

EC-CUBE3をなぜ作ったのか。ロックオンが見る「ECの未来」

いよいよ、このカンファレンスを開いた「EC-CUBE」を作っている株式会社ロックオンの岩田氏のお話。もともと(今も?)技術者なのか、今まで聞いてきた感じよりも技術よりの話でした。

EC-CUBEができるまで

もともとOSS(Linux)に感銘を受け、OSSの可能性を感じていた岩田氏。設立当初からECの案件の需要が多かったものの、その当時は海外製のもののカスタマイズが多くて実用に耐えないものが多かったと。

特に、海外製のECパッケージあたりは、自分もEC-CUBEがリリースされたあたりにECを一時期だけかじっていた時期があって、海外製のパッケージを導入するんだけど、カートの仕様がカナダに合わせてあってとか、そもそものアーキテクチャも古臭かったのもあって、日本国内で運営するのにすごく苦労した記憶がありました。

それからASPが台頭してきて、ある程度ECのハードルは低くなってきたものの、カスタマイズ性があまりなくて、やりたいことがやれないという時期もあったそうで(それもわかります)、こうなったら自ら作っていくかというところで、EC-CUBEの原型ができたようです。

コンセプトとしては「ECサイトに色を」

  • 構築の容易さ:ASP以上にする
  • カスタマイズ性:開発型以上にする

という2点を軸にやってきましたと。でも結局、開発型って「自己責任」である世界観があるので、やはり簡単には浸透していかない。そこで

  • 開発やサポートなどのコミュニティの整備
  • ホスティングパートナー制度(レンタルサーバーを提供するパートナー)
  • インテグレートパートナー制度(カスタマイズできる人をパートナー)
  • アライアンスパートナー(決済・物流・広告などを支援できるパートナー)

のような施策を打つことで、導入の敷居を下げていきましょうと。そのおかげで今では、ダウンロード数で170万。推定店舗数は2万を超え、事例も3000社以上になっているそうです。

なぜEC-CUBE3が生まれたのか

今回のメインテーマであるEC-CUBE「3」のお話ですが、ここに至るまでさまざまな歴史があったようですが、EC業界はEC単体の構築だけでは済まない時代が到来していますと。オムニチャネル・越境EC・IoTなど、さまざまなチャネルを絡めていこうとすると、現状の「2」ではもう限界が近づいていましたと。

そこで「3」では3つの問題点を改善・拡張したそうです。

  1. プラグイン同士の競合について
    EC-CUBEのコアな部分を「2」よりも小さくしてサービスを切り出し
    プラグインを開発を容易にし「つながりやすい」構造にした
  2. セキュリティ面の課題にについて
    これまでオレオレフレームワークだったが「Symfony」を導入
    テスト工数の削減と拡張性を確保しつつセキュリティにも強くなった
  3. 拡張性の課題について
    WEB中心の構造がゆえにEコマースだけしか考えられてなかったが
    様々なAPIによりスマホアプリなどに対応するなど拡張性を重視した

このあたりは、最近の流行だなと感じるところと、特に今までWEBだけで済んでいたものが、いろいろなデバイスにより選択肢が増えたことによる影響も非常に大きく受けているのかなと思いました。

そしてこれから

これからの展望としては以下を想定しているそうです。

アーキテクチャさえ盤石であれば、本当にやりたいことが一気に増えていくイメージはあります。あとは技術的負債をできるだけ溜めていかないように、日々のメンテナンスを怠らないことが重要かな~としみじみ思いました。

1つのタグでコンバージョンを最適化!欧米主要ECサイトで利用される離脱防止策について

最後に、Ve interactive の お話。イギリスの会社だそうで、日本に来て1年くらいでまだ知名度はこれからといったところらしいです。主に「離脱防止策」についてのサービスを提供していますよと。

離脱について

ECに限らずこの「離脱」って言葉、Webサイト運営者にとってはすごく耳の痛い言葉だと思います。そのためにGoogle Analyticsとか使って、訪問者がどういう動きをするのかなどを日々分析している方は多いかと思います。

私も、製品開発をやっているときに、販売チャネルを広げるために専用Webサイトの構築をしたことがありますが、ほんと毎日が戦いでした。デザインであればボタンの色を変えるだけでもアクセスが変わるし、魅力的な文章を書くためのライティング技術、画像1つ1つの魅せ方とか…素人ながらに非常に苦労した経験があります。

ECでは、とにかくコンバージョン(購入)をとにかく上げていくために、できる限りシンプルなカート設計を行っていると思うのですが、ある程度限界があるように思ってまして、「入力がめんどくさそう」「なんかセキュリティ的に」「対応しているカードがない」など、理由はさまざまですがとにかく「離脱」は切っても切り離せない問題であると思います。

そこで、Ve Interactive ですよと…。

おいしい3つの特徴

そこで、Ve Interactive は 利用してくれる人に3つの特徴を用意しています。

  1. 完全成果報酬型:初期導入・運用費用は一切要りません。
    コンバージョン(購入)が発生したときだけお金もらいますよと。
    クリエイティブ(画像とかそういうのね)制作は全部Veがやります
  2. 導入はJSタグを入れるだけなので非常に簡単ですよ。
  3. ユーザーの行動に合わせた表示やソリューションを提供しますよ。

なるほど、クリエイティブ制作までやってくれて、JS埋め込むだけで、ユーザーの行動に応じて効果的な離脱防止策を打ってくれる…まさに夢のようだ…。

主な仕掛けはこんな感じ

実際、タグ埋め込んで何やっているのか気になりますが、大まかには以下の2点。

  • メールアドレスを入力したと同時に一時取得してリマインドメールを送付
    具体的には45分後にメールを送るしくみらしい(法律的にはOKらしい)
    収集したメールアドレスデータは時期をみて完全消去されるしくみ
    勝手に取得ではなくてポップアップで許可を得るタイプもある
  • サイトを離れるとクリエイティブを表示
    タブを閉じたり、他サイトに遷移したりするとPOPUP表示
    一定時間放置していた場合にPOPUP表示

個人的にはどっちも日本でウケるのかどうかは…って思ったりするところです。なにせ特別なことしていないのにメール来たりPOPUPでたりするのって怖いじゃないですか。

うちの嫁さんなんかは、よくネットで買い物しますが、下手したら(=使いどころを間違えると)「一生離脱」とか考えられますので、本当にコンバージョンが上がるのか非常に気になるところです。

参考数値実績

ちなみに参考数値実績は以下のようになっているようです。

  • メール:開封率62%(コンバージョン率+4.5%)
  • クリエイティブ:コンバージョン率+2.6%(配置するページによっては15%)

このパーセンテージの意味合いがまだわからないので評価のしようがないです…。

さいごに

とにかく1日で詰め込めるだけ詰め込んだ感じはしました。O2Oとか越境ECの話をもっと聞けたら嬉しいなと思っていましたが、参加できるセッションが限られていたため残念に思いますが、おおむね今後のECの方向性は見えてきたかなと感じました。

つい先日「PAY.JP | ペイ ドット ジェーピー」がビジネスローンチされましたが「決済サービス」ですね。LINE PAY・PayPalなども有名ですが、このあたりのインフラがもっと整ってくれれば、ECもさらに盛り上がってくるのかなと思います。

特に「スマホ」の動向には常にチェックする必要があると思いました。上記のような決済もそうですが、あらゆるサービスを横串で利用しながら、購入に至るまでの行動を分析して、いかにコンバージョン率を上げていくかというところで、研究を進めていき、最適なルートを見いだせた時、EC業界は今以上に急速に拡大していくのだろうと思います。

あと、個人的ですが「#cart」というサービスがすごく面白そうだったので紹介します。

有名人が商品を紹介してくれるんです。昔「ペニオク」で有名人が叩かれまくった事件がありましたが、#cartはそういった感じではなく、有名人というコンテキストを利用しつつも、あくまでも「紹介」にとどめているところとあたりがうまいなぁと思いました。

 

関西DDD.java スタートアップスペシャル に 参加しました #kandddj

はじめに

関西では「DDD」に関する「勉強会・読書会」などが定期的に開催されていたのは知っていて、興味はあったのですが、実務でDDDを使う機会もなかったためか、自然と勉強する機会も失っていた今日この頃・・・。

今回のような「スタートアップ」的なものだったら自分でもいけるかなと思い、本を1冊も持っていない状態でしたが、ネットやtwitterで事前に情報を仕入れて思い切って参加してみました。

関西DDD.javaって何?

今回の勉強会の幹事である川上氏から、現場でDDDを使い続けて感じていることと、この勉強会を開催した経緯についてのお話しがありました。

既に実践されている川上氏でも「ドメインと出来上がるソフトウェアを一致させること」がいかに難しいかと言うことをおっしゃっていて、個人的にはDDDも(オブジェクト指向設計と同様に)奥深さがあるのだなと感じました。

また、関西とJavaのコンテキストを利用しつつ、DDDを中心とした様々な考え方を共有したいという思いから、

 関西+DDD+.java= 関西DDD.java

を開催するに至ったということで、既に色々やりたいことを発表されてました。次はどのテーマになるかはわからないのですが非常に楽しみです。

対象の本はこちら

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

 

 資料はこちら

それではレッツゴー

プレゼン資料を元に、私のメモと感じたことを書きたいと思います。長くなりそうなので、超絶暇な時の読み物としてダラダラ読んでいただけるとうれしいです。

また、冒頭にも触れてるとおり、私は「DDD」のいわゆる「超初心者」なので、記載内容に関して少しとらえ方が間違っていることもあると思います。そういう部分は「ここはこういう考え方が良いよ」とかのアドバイスをいただけると幸いです。

考え方と背景(まえがきと結論から)

まず、本題に入る前に、今回の登壇者である増田氏から、本の導入についてのお話がありました。本を読み進めて行く上で参考になる情報やDDDについての考え方のウォーミングアップ要素がいくつかありましたのでピックアップします。

  1. 本は読み直してみると「まえがき」と「結論」はすごくいいですよ
  2. パターン本というよりも「成功と失敗の経験や教訓」が書いてありますよ
    ・成長していく様子に着目して読むとすごく面白いよ
    ・1章・7章・8章・13章・15章・結論 が わかりやすい
  3. 前提知識は「オブジェクト指向+XP」 この2つは学ぶべし
  4. 「第2部」の内容だけでは不十分、DDDをやっても全く効果はない
    ・あくまでも基本スキル、3部・4部への繋ぎである
  5. 「変化に適応」する「技術」なんですよ
    ・変化:オブジェクト指向=変更容易性=独立性の高い部品
    ・適応:XP=適応型=日々変化
    ※ スライド「P.15」の表が参考になります。
  6. モデルとコードを最初から「作りきる」のではなく「成長」させるイメージ
    ・現時点のコードがどれくらいモデルと一致しているかがDDDの醍醐味
  7. 「言葉」に敏感に反応し「チーム」による「改良」を目指す
    ・「ドキュメント」よりも「言葉」が非常に大事
    ・「意見交換」の中で設計・モデリングをしていくことが大事
    ・「カタカナ言葉」は日本語で柔らかく具体的に説明できることを目標にしよう

私は「変化に適応する技術」と「ドキュメントよりも言葉」というところがすごく気になったところです。どちらも今の現場ではなかなか実践できていないことだったからです。

特に「言葉」というものを改めて考えてみて、自分自身が毎日交わす言葉が非常に雑多だなと感じることです。毎日チーム内で交わす言葉ですが、意識しているように見えていても、カタカナ用語に流されてみたり、辞書で開くような小難しい言葉を使ってみたりと反省する点が多くあるからです。

いやいや、毎日交わす言葉はきっちり使い分けているよ…っていう方はどれくらいいらっしゃるのか気になりますが、DDDに限らずこの「言葉」はこれから意識して使っていかなければと思いました。

第1部:ドメインモデルを機能させる

まずは各章に入る前にドメイン・モデルについてのポイントの説明がありました。

  • ドメインドメインでないことの区別はしっかりつけましょう
    例えば、画面仕様書とか機能一覧はドメインではありませんよ
  • アクティビティ図・業務フロー図などを使い重要な要素を発見する
  • モデリングとは、重要な関心事を文章で論理的につなげることができるか
    すなわち「利用する言葉を組み合わせて論理的に説明」することができるか
  • クラス図・パッケージ図を使い、未来のコードのイメージを膨らませる
  • ドメインが研ぎ澄まされていればコードも研ぎ澄まされていく

この後に、各章のお話しが始まりました。

第1章:知識をかみ砕く

変化と成長の様子を読み取ることがこの章のポイントでありますと。

ほとんど何もわかっていない状態からモデリングを行い、新しい言葉が増えてきて、モデリングしていくうちに、どんどん本質的な関心事をとらえながら要件定義(成長)していくストーリーを学べる章になっていますと。

第2章:コミュニケーションと言語の使い方

ここで出てくる「ユキビタス言語」ですがポイントは以下の通り

  • コードの複雑さを言葉で共有できるようにところを目指す
  • 他の言葉や表現の不一致に敏感になること(別の概念が潜んでいることがある)
  • ドメインモデルのサブセット的な存在ですよ
  • 1つ1つの「言葉の意味」を「的確」に捉えて使えるようにしていく

良いモデリングをするためには、きちんと声に出すことが重要ですと。上記にも書いた通り、表現の不一致には敏感になって、普段から会話などを通じて、お互いの情報を共有していくイメージ。もちろん毎日、継続的にね。

ドキュメントに落とすって考え方もいいんだけど、それに偏るのは良くないよねと。毎日鍛錬されている「言葉」でやりとりする方が反応も早いし、いいタイミングでいい指摘などもできるメリットを享受しやすいよねと。(ドキュメント絶対ダメという感じではなく、必要最低限のドキュメントでいいじゃないかというスタイルっぽかった)

第3章:モデルと実装を結びつける

モデルとは「要点を選び抜いた簡潔な表現」ではあるものの「でも簡単には見つからない」だから「言葉とコードを書くことだ(実験することだ)」ということですと。

UMLでお客様とやり取りできるかというテーマについては、それ単体だけでは厳しいという感じで、ラフスケッチで画面のナビゲートをする感じでクラス図を説明すればいけるそうです。(たしかに上に行けば行くほどわからない人多いもんね)

実践的モデラのところでは、コードを書く人がドメインの知識をかみ砕き、ユキビタス言語を作り上げていく(骨格を作り見せていく)ことが、より効果的なソフトウェア、早いソフトウェアの構築ができるよというお話しもいただきました。

第2部:モデル駆動設計の構成要素

でも実際、DDDを始めてみると、頭の中の理解とコードが違うことって多くあって、なかなか一致しないよと。それは、実装者があるときに「自分の都合のいいように翻訳=バイアスをかけちゃったり」しちゃうから。しかも後でなぜこうなったのか…と聞かれると説明ができなくなったりするものだから厄介ですねと。

だから、モデルとコードの不一致が生まれないようにというところで、基本ではあるんだけれども、サッカーに例えると90分の89分までちゃんと、第2部のテーマである「基本」ができるように日々努力しないといけないよね…というところで、第2部が始まりました。

第4章:ドメインを隔離する

レイヤ化アーキテクチャにより、各層の位置づけを明確にし、特にドメイン層の位置づけをしっかり保ちましょうよというお話し。特に「ドメイン層以外にドメインの知識が入り込んでいないか」というところを意識していきましょうと。

プレゼン資料では P59 あたりは、現実に直面したお話しがあり、

  • コントローラー層やページ記述に「業務知識」が染み出していることがある
  • 複雑なSQL文に「業務知識」が紛れ込んでいることがある

といった感じで、わかりやすい例を元に「業務知識の紛れ込み」に敏感になっていきましょう、継続的にリファクタリングしていきましょうと。そのために2ステップビュー(2段階でやっていく)という小技・アプローチがありますよ。

  1. ドメインオブジェクト(ActionListオブジェクトなど)で論理構造を返却
  2. 各層に適宜ヘルパークラスを用意し、ドメインオブジェクトを変換

個人的には、ドメイン層をちゃんと各レイヤーで分けたいのであれば、他の層との「ギャップ」を埋めなければいけないところがでてくると思っていたので、ヘルパークラスの存在って重要だなと思いました。(もうちょっと具体的な中身を知りたかったかな…とは思いました)

第5章:モデルをプログラムで表現する

(P68)にもあるように、モデルが分割されてデータベースとのマッピングはめんどくさいように見える(別にDDD以外の設計もあるんだからやらないという選択肢もあるんだろう)けど、DDDはそこ(関心事を発見してクラスに抽出する)を行くのが基本の考え方ですよと。

値オブジェクトは、積極的に型を宣言すること (P72) により「知識豊か」にしていき、何が関心事なのかをどんどん明確にしていくことで、よりよく(人間の関心事に近づく)なっていきますよと。

エンティティは、見つけやすいけど、使いすぎるとどんどんエンティティが肥大化してしまうので注意が必要ですよと。なので「識別」をきちんとすることで、利用者の関心事に集中し、文脈なども絡めてとことん「スリム」にしていくのが良いですよ。

ドメイン層のサービスクラスでは、なんとかDO・なんとかプロシージャー…うーんこれは危険ですと。手続き型プログラミングになっちゃってそこにロジックが集まって暗黙のビジネスルールの宝庫になりがちだからおすすめしませんと。

これは、もう一方の考え方として、先ほどにもあった「ドメインオブジェクト」の考えを意識し、サービスクラスの「引数はドメインオブジェクトじゃだめよ」というルールを作ることでガードを作ることが有効ですよと。

例えば、男性料金・女性料金などの多態の場合は、インスタンス変数を持たずに、ロジックとしてしか持たないようにするなどしたりしてますよと。

また、2つの用語についての説明もありました。

  • ファーストクラスコレクション
    ListやSetをラップしたドメインオブジェクト
    昨今ではハードウェア・ソフトウェアの性能もあがっているので、
    SQLの抽出を細かくせずに、取得したでデータ上で操作する方法もアリで、
    楽な設計・安全な設計にもっていけるようにしておく
  • 区分オブジェクト
    場合分けの書き方あれこれ - Google 検索」で検索!

また、この章では、オブジェクトのライフサイクルの管理(永続化など)は、複雑になりがちであるので、別のクラス・枠組みで外だしを行って、モデル・エンティティ・バリューオブジェクトの関係を「シャープ」にするための工夫を説いているのですよと。

第6章:ドメインオブジェクトのライフサイクル

ごめんなさい。言葉の意味がわからないことが多くて難しかったです。トランスファインタフェースって何?って感じでしたが、これは後で勉強することにして…。

この章では、モデルと実装の関係を単純明快に保つために「集約」「ファクトリ」「リポジトリ」がありますよというのが趣旨となっていますと。

第7章:言語を使用する:応用例

この章はチームで共有してほしいと、12の項目があるけれども、「2:ドメインを隔離する:アプリケーション層の導入」が大きなポイントですよとのことでした。なぜならここで隔離をチームできちんと共有できていないと良いモデル駆動設計はできないから。

実は、入出力項目・画面帳票定義・テーブル設計は、DDDではほとんどでてこない。なぜならプレゼンテーション層・データ層からドメインを作りに行くのではなく、その逆であるということ。画面やデータから見つかる言葉も多いから重要なこともあるんだけど、ドメイン駆動設計のアプローチ(関心事の抽出)としてはちょっと違うんだなと。

画面にはでてきていないけど、関心事はこういうことだから、こういう画面がいいのではないですかというアプローチがDDDのあるべき姿であると。(すぐできるかどうかは別で、毎日戦いですと)

第3部:より深い洞察へ向かうリファクタリング

見つけたときは明快に表現できていない、整理できていないものを第3部で洗練させていきますよと。

コード的な「リファクタリング」の観点ではなく、ドメインの表現としていい表現になっているかという観点からの「リファクタリング」を進めていきましょうと。例えば、コードが重複していたとしても、ドメインの関心事として残しておくべきものなのであれば、重複コードも良しという場合もあるよと。

このあたりから時間が足りなくてかなり早回しになってしまったので、要点だけまとめる形とさせて頂きます…m(_ _)m

第8章:ブレークスルー

「わかった」という成功体験・経験を思い出しながら読んでみるとよいですよ。そして変化のリズムというのはいつだって「ゆるやか」なんですよということ。基本的なことの地道な繰り返しがブレークスルーにつながっていきますよと。そしてその変化の1つ1つをチームで納得(共有)しながら実験を進めていくというアプローチ。

第9章:暗黙的な概念を明示的にする

ここはキモですよ。何度も読み返すと良いですよ。チェックリストとして起こしておくのもありで、コードレベルも含めて実践的なテクニックを書いているのはこの章である。暗黙的な概念の掘り返し、チャレンジの手法などが書いてありますよと。

補足として

  • 制約
    LocalDateで誕生日。10億年前なんておかしいだろ…気持ち悪さの発見をしよう
  • プロセス
    オブジェクト指向の苦手である時間軸に沿ったものごとの考え方を身に着けよう
  • 仕様
    ビジネスルールを的確にシンプルにとらえてコードでスッキリ表現しよう
第10章:しなやかな設計

言語仕様の一部である。Javaは比較的古い設計の言語にあたるので、他の言語仕様で勉強してみても面白い。KotlinなんかはJavaの古いところを新しく定義しようというような流れもあるし、増田氏も非常に感動しておられました。

また、総合レッスンな形で「バリューオブジェクト」「ファーストクラスコレクション」には良い題材かなとおっしゃっていました。

第11章:分析パターンを適用する

分析パターンはゴールではなく出発点で、便利だから分析パターンを使うのはいいよということを説いていますと。

ネタを探すために「APIとして公開されたサービス」や「言語・概念」を掘り起こすために、その分野の文献(目次・図表・用語集)を読んだりすることを心掛けましょう(英語ならそのままパッケージ名にも割り当てられるしね)…ってところなのかな。

第12章:デザインパターンをモデルに関係づける

ドメイン駆動の観点からデザインパターンを読み直してみると良いですよ。ドメインを表現する一つの「手段」としても使えますよと。(概念的にも技術的にも)

第13章:より深い洞察に向かうリファクタリング

リファクタリングのきっかけは「違和感」になりますよ(当然ですよね)。但し、方向性を間違えないように(ゴクリ…)、いくつかルールを作っといたほうがいいですよと。

  • 選抜チーム(有能な人)と一緒に取り込むことが大切ですよ
  • 言葉を駆使して実験をしていこういう「DDDの根底のスタイル」を大事に
  • ドメインエキスパート(その道のプロ?)の「納得感」が大切ですよ

増田氏もおっしゃっていましたが、タイミングとして「疎結合」というキーワードかなと思いました。疎結合=しなやかにできる機会があるならやっていきましょうというところです。

個人的には、この「エキスパート」がいるかいないかというところで、なんちゃらマスターとかいう公開されている「資格」があれば、安心だなぁと思いました。

第4部:戦略的設計

日々変わるチームや政治的な要因など、大きくなればなるほど、変化すればするほど、意思決定が難しくなるんだけど、やはり「言葉」による「発見」と「改良」を強調して書いてありますよということ。

そして、戦略を推進していく上では、コードを現場で書いている人間が「戦略」を考えるべきで、そうすることによって「戦略=実装」になっていきますよ。それを地道に続けていくことで「ブレークスルー」が発生し、より「成長するものづくり」ができますよと。

第14章:モデルの整合性を維持する

技術的な要素はあまりなく、意思疎通・協力関係で起こる問題のパターンはどういうものがあって、(チーム・言語・意思疎通の観点から)どうやって解決していくかという手法が書いてありますよと。

第15章:蒸留

コアドメインを見つけだしにいく。プログラム的な構造的なコアという意味ではないですと。あくまでもドメイン設計の文脈で「ビジネスにとってここがコアなんだ、価値を見出すのはここなんだ」という観点で探しに行くんだということ。

モジュールの間の依存関係を「意識・検証」しながら整理していきましょうと(パッケージ図は書いたほうがいいよ!!!)。

そして、最終的にそれらが「抽象化」されたパッケージになることで「破壊力のあるコアドメイン」となると。(もちろん一発では作れないから成長させる気持ちで作り上げることになります)

第16章:大規模な構造

規模が大きくなってきたときに「俯瞰力」を持っていこうというところが中心なテーマでありますと。

第17章:戦略をまとめあげる

14・15・16章を組み合わせた章になりますと。重要なのは2点あり、コードと戦略は絶対に引きはがしてはならないということと、しつこいようですが「言葉」の重要性をすごく説いてますと。

さいごに

非常に長くなってしまいましたが、4時間で1冊分のお話しがあったわけなので、非常に濃密な勉強会であったのは伝わっているかな…と思います。

参加するまでは「DDD」って全く新しい設計手法なのかなぁ…とぼんやり捉えていましたが、既存の「オブジェクト指向」「XP」をうまく組み合わせることで、より変更に強い設計手法なんだなというところで腹に落ちた感じはします。

まだ本は読んでないのですが、この著者であるエヴァンスは「成長するものづくり」を様々な方向からアプローチした結果「DDD」に行きついているのかなとも思いました。

次回の開催はいつになるのかわからないのですが、次回までにこの記事のポイントをうまくとらえながら読書できればと思います。

Developers Summit 2015 KANSAI に参加しました

2年ぶりのデブサミ関西に参加してきました。久しぶりに朝から夕方までみっちり参加してきたのですが、とてもよい刺激を受けましたので、書ける範囲でいくつかご紹介できたらと思います。

スライドが見当たらなかったので個人メモみたいな感じになりますことご了承ください。一部ちょっと違うよというのがあると思いますので気になるようでしたらご指摘いただけると幸いです。

2年前(2013年)に参加したデブサミでの所感

2013年は基調講演が「AWS」で、内製回帰の流れや、各業種に応じた適用事例などが紹介されていて、おぼろけながら「クラウド」の世界がこれから急速的に伸びていくんだろうなぁと思っていた頃でした。ですが、そのときはまだ「検証段階」に入ったところなのかなと部分的に感じておりました。

また、ちょうど「DevOps」などのキーワードも流行していたのもあり、ソフトウェアとインフラについて協調体制で行こうよ!って流れもあったりしつつも、当時はHTML5Javascriptなどのフロント技術とかのベストプラクティスや、既存の技術の掘り下げなどをみんなで考えようという感じだったように思います。

参加にあたって

2年経って、フロントもバックもネタは出尽くした感もあって、そろそろ流行の人工知能とか、ビッグデータについてのお話とかがあるのかなと思いつつ、改めて今回のセッションを見てみると・・・そういう感じではない。自分の会社の人の参加率も異様に低かったので若干不安はございました。(ごめんなさい…私は参加してよかったと思ってますよ)

[基調講演]クラウドファーストから、クラウドネイティブへの挑戦 by 東急ハンズ

実は、2013年の基調講演で「東急ハンズ」の移行の話に触れていたというのは、この記事を書いている最中に知った次第でありますが、実際にAWSを使ってどういうプロセスで移行を進めてきたのかという「検証」を含めた「戦略」を聞くことができました。

登壇された長谷川秀樹氏は非常に考え方がシンプルで、1つ1つの考えが的を得ていることばかりでした。それがまた「理想論」だけではなく、それらを「実現する力」「交渉力」なども備えているあたりが、移行に対して非常に前向きになれているのだなと直感しました。(こんなトップがいたら確実に成長するんでしょうね)

段階的な拡張戦略

2008年まではオンプレミスでやっていて、システムは外部のベンダーに任せてたんだけど、謎テクノロジーが増えていきますよね…だからそれを内製化しようとする動きがでてきましたと。

でも、当時のAWSのEC2とかは容量が少なかったりと、思っていたよりも非力だったから全部をAWSに移行するのは厳しいなというのを感じていたそうで、段階に応じて拡張をしていこう。というわけで、大まかに以下のような戦略でいったようです。

  1. EC2を使って、中身の技術は変えずに仮想への移行しようか
  2. 新しく出てきたしくみ(DynamoDBなど)を使ってさらに拡張しようか
  3. Amazonさん全部やってくれそうやから全部移行しようか

この「徐々に拡張」というところのバランスがうまいなと感じました。長い目でシステムを構築する場合に、そのときの最良を選んで、減価償却までそれを使い続けて…って結構あるある話だと思うのですが、「常に攻め続ける」ことで、あるある話のデメリット部分に柔軟に対応されているのだなと感じました。

利用環境の刷新

EC系は今や「オムニチャネル」という言葉通り、すべてのチャネルを統合していこうという流れがすぐそこまで押し寄せてきていて、それらを取り巻くテクノロジーを最大限に利用していかないともうだめだと。そしてその1つ1つのサービスは常にオープンにしてこうよという話がありました。出てきたキーワードとしては以下のようなものがありました。

  1. AWS
    ここは必ずやっていかないといけないよね
  2. Google Chrome
    ブラウザはたくさんあるけどひとまずこれで抑えておこう
    まだ追いついていない技術も色々あるんだけど
    究極論「全部HTTPS」でやりとりしたらいいじゃないか
  3. アップル製品+IOT
    いまや、POSも含めて専用端末なんて古い
    もちろんこれからでてくるIOT関連はどんどん取り入れていく方向
    (ちなみに東急ハンズiPod Touch端末らしい)
  4. 開発言語
    やっぱエンジニアが集まりやすい言語がいい。
    (おそらくものづくりの速度を気にしているのかなと感じた)
  5. レガシーな手法
    一瞬たりともクラサバをつくるのはやめといたほうがいい
    また、レガシーシステムの延命してつぎはぎだらけにするのはもうやめよう

常に最新を見据えた戦略を考えていて、あとはテクノロジーさえ追いついていけばピックアップしていくぞというあたり、非常にドライブ感があるなと思いました。

エンプラIT業界のスーパースターの条件

EC業界だけではなく、エンプラ界のスーパースターの条件についても、長谷川氏の経験談からピックアップして発表していただけました。

  1. 売り上げを伸ばすためのプロモーションができる人
  2. インターネットテクノロジーがわかる人
  3. 社内の業務システムがわかる人

私なんかはこの場面はグイっと聞き入ってしまいました(笑)

常識にとらわれず捨てていく選択も

このあとに「常識を捨てていかないといけない」というお話があり、長谷川氏の感じている「危機感」みたいなものが伝わってきたのでいくつかピックアップします。

  1. システムROIなんて絶対でるわけないからやめようよ
    大企業はROI気にしているけど、日々天気も変わる。人も変わる。
    そんな中で正確なROIを出すのは非常に困難。
    たくさんのドキュメントを作ってもほとんど見ることはないし、
    結局のところ動いているものがどうなのかというところに落ち着く。
    そんな時間があったらさっさとリリースしたらいいじゃないか。
    (内製化の強み…といったところなのかなとも思います)
  2. IT部門・ユーザー部門のコミュニケーションをもっとせよ
    ユーザーが欲しいものを作ればいいだけの話なのに、
    いちいちIT部門にお伺いを立てを立てないといけない閉塞感。
    すべてが100点になるわけではないけどとにかくユーザー欲しいもの重視。
    そこはちゃんとお互い「やる・やらない」を決めてってやればいいし
    意見を受け取りやすいアーキテクチャにすればいいじゃないか。
  3. システム同士のデータのやりとりをシンプルにしようよ
    リソースに対して限定的なインタフェースを構築していると、
    どうしても拡張性が落ちてしまうし開発人件費がかかる。
    今や回線も太いしサーバースペックも高くなってきているのだから、
    必要なデータはもう全部もらいますというスタンスでやったらいい。

これ以外にも「夜間バッチはやめたほうがいい」とか「ベンダーロックインだけは絶対避ける方向で」とか、結構大胆な発言が多かったように思います。

私なんかは、SIerに所属しているのですがどうしても「細かいところ」で「たくさんお金取りたくなっちゃう」戦略とりがちですね…見習いたいです(苦笑)

 最後はものすごく早回しだった

あまりにも熱いお話が続いた結果、最後のほうは非常に巻き巻きになってしまい具体例などのお話が少し聞けなかったのが残念でしたが、冒頭でも触れましたが全体的に非常にシンプルな考えを持ってシステムの構築をされているのだなと思いました。

また、新しいことをしようとすると、必ずといっていいほど、経営層が「それはなにがおいしいんですか?」みたいな感じになることが多いんだけど、長谷川氏が発表しているその節々に「絶妙なたとえ話」がちりばめられていて、それが非常に明快であり、なるほど…やってみようか…という気になったのは言うまでもありません。

私なんかは、情熱はあるんですが、どうしても技術一辺倒で担当者をねじ伏せてしまおうというところが多々あるので非常に参考になりました。

[午後Ⅰ]サービスをつくりなおす決断をするとき

ChatWork株式会社の山本正喜氏の発表。私自身ChatWorkはこれから使う予定をしているところなのですが、最近PHPからScalaに移行したという話は聞いていて、どういう形で移行したのか、非常に興味があったセッションです。

いきなり驚いたのは、代表取締役の山本敏行氏は実兄というところ…私も兄弟で同じ会社に所属しているので、参加者の方々とは別に、最初のつかみで完全に引き寄せられてしまいました(笑)

開発体制

主に以下の体制で、CTOからのエスカレーションが強めに感じました

  1. サーバー・フロントエンド
  2. 基盤(チャットツール以外の管理画面や支援ツール)
  3. クライアントアプリ(AndroidiOS・DeskTop)
  4. CTO室(アーキテクチャ・R&D)

個人的に、ものづくりにおいてアーキや分析ベースからのエスカレーションってすごく大事で、技術的戦略や分析されたデータをしっかり経営に結び付けて、リーダーシップをとっていく人たちが「CTO」になるべきだと思っているので、この体制は理想です。

当時の振り返り

当時はSkypeを使っていたが、色々と課題感をもたれているようで(わかります)、山本氏が中心になって、少ない予算の中で6ヶ月でChatWorkの原型をPHPで作り上げたのこと。ひょんなことからChatWorkが世に出て行くわけですが、当時からLINEは一般向け、ChatWorkはビジネス向けな立ち位置で成長できるんじゃないかと思っていたそうです。(すでに実現できてますね)

でも、急速に発展していくサービスに対して、スピードを突き詰めて取り組んでいくうちに、以下の点に目がいくようになってしまう。(よくある話ですよね)

  1. 低いテストカバレッジが増えていく
  2. 命名規則が曖昧になっていく(Message・Chat…どっちでも取れるみたいな)
  3. スケールを考慮できていないところがボトルネックになる
  4. 本番環境と一致しない(ローカルでは起きないが本番では起きる現象など)

また、技術的負債が多くなっていくにつれて、以下の点にも問題がでてくる

  1. 見積もりが大きくずれていく
  2. 蜜結合により影響範囲がわかりにくくなる
  3. 網羅テストがしにくくなりテスト工数が増大していく
  4. SPoF(単一障害点)が多くて、まれな条件で一瞬で落ちるなど
改善への施策

これではいかんということで、カイゼンに踏み切るわけですが、まぁ経営層はなんで動いているものを作り変えるんだと…こうなりますよね。山本氏も経営層に説得するのに非常に苦労したようですが、当時のスライドの画像がその的を得ていて、思わず笑ってしまいましたが、非常にわかりやすかったです。

カイゼンでは、ボトルネックになっている処理をSQSに持っていったり、スケールアウトを容易に行えるような仕組み作り。DynamoDB・CloudSeach・SendGridなどさまざまなサービスを利用したりと、とにかく完全に刷新したなという印象を受けました。

受けたと同時に、旧システムからの移行はどうするんだろというところも気になりました。というのもファイルデータだけでも76TB(テラバイト)あるそうなので、容易に移行なんてできるはずもないと思っていたからです。

再構築のメリット

なお、メリットとしてはやはり以下が上げられます

  1. 既に確定した仕様でコードを再設計できる
  2. 再実装時に仕様の細かい精査ができる
  3. 最新の技術を制約なく利用可能

ということで、これらをどの言語でやるかというところで、

  1. Ruby (不採用)
  2. Python (不採用)
  3. Scala (採用)
     静的型付き言語の保守性とパフォーマンス
     AWSはJavaSDKがもっとも充実している
     リアルタイム処理と相性がいい

となったようです。ScalaはDDDとのからみもあったのかなと感じた次第です。(どの言語でもDDDは実践できるようですが、PHPからの移行、チーム編成、静的型付き言語など総合的にみて相性がよかったのかもしれないです)

新旧混同のしくみ

やはり既存システムをとめずにゼロベースでやるのは非常に難しいと考えていたようで、既存システムを動かしつつ、新システムを稼動させるといった感じ。

そのつなぎは大まかには「API(APIベースにすることで蜜結合を防ぐといった戦略もあった)」でたたけるようにしていき、徐々にデータを新システムに移行させるような方式を取っているようでした。

このあたりは新旧との間に「新たな層」を作ることで、利用ユーザーからはシームレスになっていることと、蜜結合を極力排除することで、エンジニア側からは拡張容易性が格段にUPしているのではないかと思いました。

最後に

やはり「作り直す」というのは相当な「覚悟」がないとできないものだなというのがヒシヒシと伝わってきました。

システムはある程度まで構築すると徐々に技術的負債が生まれてきて、でもそう簡単には改善できなくて、いっそのこと「こんなの1から作り直したらいいやん」とかいう人がチラホラでてくるんですが、それを「経営にうまく寄り添わせた状態で具体的にこうしよう」というところまで考えている人は少ないように思います。

いや、最初からいいもの作ればいいやんという発想は安直ですが非常に大事ですよ。ですが、それもそれで時間との戦いになって、サービスのローンチが遅れてしまえば競合他社に抜かれてしまうので非常にリスキーでもあります。

この両方のバランスを「DDD」という新しい設計で切り開いているあたりが、非常に参考になりましたし、これからどういう風に成長していくのか個人的にはすごく期待しております。

[午後Ⅱ]ゲーム開発素人集団がゲーム作り始めていつのまにか40倍の組織になっていた話

後発だったゲーム業界への参入、ノウハウ0、少ない開発者によるものづくりの体制から、徐々に拡大していく過程で起こってきた問題点などを聞けました。技術スコープというよりも組織スコープの内容でしたが、これから大きくなっていく組織を考えていく上で非常に重要な観点を学べる内容でした。

採用の罠

「技術力:熱意・コミット意識が少ない」

 と

「熱意:こだわりが強い・リーダー意識の欠如」

私は採用にはどちらも重要だと考えておりましたが、一長一短あるということです。おっしゃるとおり何かしらの「バイアス」がかかってしまい、適切な判断ができないことも多くあるように思います。

これを打破するにはやはり「対話」が必要で「人柄・一緒にやっていけるか」をきちんと見ていけるように、採用側も努力していかないといけないなと感じました。

職種の差

中途採用の場合はどうしても「前職」を元に判断をしてしまうし、採用された本人達も「前職」ベースで仕事を遂行していこうとするために、仕事のやり方にばらつきがでてしまい、どうしても揉め事が多くなりがちになるとのことでした。

確かによく口癖で「前の現場ではこうしてましたから」とか言う人は多いように思います。(悪いことではないですけど、それに固執しすぎるのはよくないと思います)

しかも後から入ってくる人は、仕事内容が「ワーカー的」なものが増える傾向にあるため、内容に価値を見出しにくくなるというのは同感でした。DMM様は、これに対して1人1人にフォーカスを当てた「体制図」を作り、

  1. メイン業務
  2. やらない業務

を明確にし、合意をとることでこの差を埋めていきましたということでした。大変そうだけど、人間って「これを頼む」といわれるとやっちゃうし、逆に「これは誰かがやる」って決めていたら任せちゃったりできますよね。

曖昧耐性(これが一番大事)

組織の制度・体制の不十分さというのは、人の増える速度が速ければ速いほど追いつかなくなるもので、かといって1000人規模のしっかりした制度・体制をきっちり作っても、やはり所属している人数によりけりで、枠の中に納まりきらないことが多々ありますよと。

なので、曖昧なものを曖昧として受け止められるかという「曖昧耐性」がとても必要になってきます。「まぁいいか」の精神でしょうか、とにかく「目の前の仕事」を淡々とやっていける「平常心」といいますか、そういうのが大事ですねと。

でも、だからといって不満がないわけではないので、そこは必ずマネージャーがキャッチアップできる体制を必ず作りましょうというところです。

  1. 個人面談は1ヶ月・1回・30分
  2. 面談共有は2時間・月4回

80人いたら、約 48時間 / 月 の時間を割いている計算にはなりますが、こういう個別の面談を設けることで、何かを発言しようという意識はでてくるように感じているようで、DMM様もこの4つの中でも非常に重要だとお話されていました。

確かに、昔は飲みに行ったり、社員旅行があったり、そういう文化もありましたが最近はそういうのもあまりない文化になりつつあるなかで、1人1人と向き合う時間って削られていきがちですし、人数が多くなると少しずつでも主体性が薄れていってしまうので機会を与えるという側面だけでとらえてみても重要だなと感じました。

根付かないクレド(=行動理論)

私自身、所属している会社にクレドが根付いていないので、イマイチピンと来なかった部分ではありますが、行動理論というのは、上の人が作っていくのではなく、チーム内の推奨文化としてチーム単位でつくることで愛着を持たせ、お互いの行動を意識しあうことで、価値観の共有を図っていこうというお話がありました。

ただし、これはあくまでもチーム内の話で、部・社に当てはめられるかというとそうではないようです。

最後に

組織って小さい間は、個々の裁量の幅が大きく、常にアンテナを張っている状態で主体的に動いていることが多いですが、大きいものは少し作りづらい。

かといって組織を大きくしていくと、大きなものにじっくり取り組めることはできるものの、個人の裁量や主体性が少しずつ薄れていってしまうがゆえに、少しずつ中で歪(ひずみ)がでてきてしまい、それを放置していると幹そのものが折れてしまう。

組織というのはコミュニケーションが非常に大事だけど、とりあえず話せばいいとかで完結するのではなく、お互いの「合意」を中心とし、その先にある「ゴール」に全員が導けるように組み立てていくものなんだなと感じました。

組織ってこれといった「ゴール」はおそらくないような気もするので「常に変わることのできる柔軟性」を持った人を、じっくりと「育成」していくことが重要なのかもしれないです。

長くなりましたが・・・

このほかにも参加したセッションはあったのですが、記事のボリュームが非常に大きくなりそうなので割愛させていただきます…(ごめんなさい) が、総括をすると「現場のカイゼン 2015年版 」といったところでしょうか。

昨今はさまざまなテクノロジー・開発手法の選択肢が非常に多くなってきていますが、ただそれらも栄枯盛衰といいますか、諸行無常といいますか、「常に変化」していくものだとも感じます。

その変化にうまく対応できるアーキテクチャであったり手法をうまく取り入れ、チーム内でトライアンドエラーを繰り返す。そして、そのナレッジを新しい変化にうまく結びつける体制を作っていくことが、これからの未来のシステムを構築していく上で重要なファクターであるということはどのセッションでも感じたことであります。

技術者に限らず、この業界のすべての人が常に新しいものにチャレンジできるような土壌を作り続けられるように、私も日々の行動を少しずつ「カイゼン」していけたらと思いました。

はぁ・・・うまいことかけたかしら・・・汗

IntelliJ IDEA ことはじめ

はじめに

だいぶ遅れた感がありますが、
Intellij IDEAを使ってみたくてインストール。
いきなりハマったので書いてみました。

前提条件

GitHubアカウントは持ってる
https://github.com/

GitHubからMixer2のサンプルアプリをインポートしよう

GitHubを選んでみるとこんなエラーが

Cannot run program "git.exe":createProcess error=2, 指定されたファイルが見つかりません。

GitHubアプリのインストール

https://windows.github.com/

git.exeの場所を探し出して…

C:\Users\<<ユーザー名>>\AppData\Local\GitHub\PortableGit_c2ba306e536fdf878271f7fe636a147ff37326ad\bin

Intellij IDEA の Configure を開く

※ 途中で白ベースに変えたので統一感ないですがごめんなさい…。

Intellij IDEA に設定(1)

Setting -> Version で検索して「Git」を選択・設定

Intellij IDEA に設定(2)

Setting -> Version で検索して「GitHub」を選択・設定

Mixer2を取得してくる

IdeaProjectsフォルダはあらかじめ作っておこう

Mixer2初期設定

Mavenを選びます

springboot版を選択

先に進めて…

JDKを選んで

プロジェクト名を指定して

Server.javaを実行!!!

無事にサンプル画面開いた!!!

最後に

これからEclipseと比較しつつ、
両刀使いになりたいところですね…(;´Д`)アセアセ

GhostScriptでPDF変換するとフォントが適用されなくなることがある

受け売りですがすいません

一緒に働いているhanzouさんから教えてもらいましたが、
きっと困っている人が沢山いそうなので私も書こう…。<< GhostScriptでMSゴシックを出力する方法 >>
http://www.hanzou.jp/tech/index.php?GhostScript%E3%81%A7%EF%BC%AD%EF%BC%B3%E3%82%B4%E3%82%B7%E3%83%83%E3%82%AF%E3%82%92%E5%87%BA%E5%8A%9B%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95

GhostScriptのインストール

http://www.ghostscript.com/
今回は「gs916w32.exe」を利用しています。

変換Script

<<インストールディレクトリ>>\bin\gswin32c.exe -dBATCH -dNOPAUSE -sDEVICE=png16m -r300 -sOutputFile="出力画像ファイル名%02d.png PDFファイル名.pdf

文字化け発生

以下のようにPDFではきちんとMSゴシックになっていますが、
GhostSciriptを経由するとフォントが適用されず、
他のフォントになってしまっています。

フォントの指定がおかしいのかと考えますよね。
なので、libフォルダにあるcidfmapというファイルを開きます。
以下のようにMSゴシックあるはずなんだけどなぁ…。ってなります。

…
/Gungsuh << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/batang.ttc) /SubfontID 2 /FileType /TrueType >> ;
/ArialUnicodeMS-GB << /CSI [(GB1) 2] /Path (C:/Windows/Fonts/arialuni.ttf) /SubfontID 0 /FileType /TrueType >> ;
/MS-Mincho << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msmincho.ttc) /SubfontID 0 /FileType /TrueType >> ;
/Meiryo-BoldItalic << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/meiryob.ttc) /SubfontID 1 /FileType /TrueType >> ;
/MalgunGothicRegular << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/malgun.ttf) /SubfontID 0 /FileType /TrueType >> ;
/MS-PMincho << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msmincho.ttc) /SubfontID 1 /FileType /TrueType >> ;
/Batang << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/batang.ttc) /SubfontID 0 /FileType /TrueType >> ;
/Gulim << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/gulim.ttc) /SubfontID 0 /FileType /TrueType >> ;
/MS-PGothic << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msgothic.ttc) /SubfontID 1 /FileType /TrueType >> ;
/MingLiU << /CSI [(CNS1) 2] /Path (C:/Windows/Fonts/mingliu.ttc) /SubfontID 0 /FileType /TrueType >> ;
/DotumChe << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/gulim.ttc) /SubfontID 3 /FileType /TrueType >> ;
/MS-Gothic << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msgothic.ttc) /SubfontID 0 /FileType /TrueType >> ;
/SimHei << /CSI [(GB1) 2] /Path (C:/Windows/Fonts/simhei.ttf) /SubfontID 0 /FileType /TrueType >> ;
/BatangChe << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/batang.ttc) /SubfontID 1 /FileType /TrueType >> ;
…

解決法

MSゴシックという文字(全角なのがミソです)を
SJIS(16進)変換してあげてcidfmapに追記してみます。
ちなみに変換は以下のサイトを使うと便利です。
http://www.ahref.org/app/mozicode/

…
/Gungsuh << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/batang.ttc) /SubfontID 2 /FileType /TrueType >> ;
/ArialUnicodeMS-GB << /CSI [(GB1) 2] /Path (C:/Windows/Fonts/arialuni.ttf) /SubfontID 0 /FileType /TrueType >> ;
/MS-Mincho << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msmincho.ttc) /SubfontID 0 /FileType /TrueType >> ;
/Meiryo-BoldItalic << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/meiryob.ttc) /SubfontID 1 /FileType /TrueType >> ;
/MalgunGothicRegular << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/malgun.ttf) /SubfontID 0 /FileType /TrueType >> ;
/MS-PMincho << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msmincho.ttc) /SubfontID 1 /FileType /TrueType >> ;
/Batang << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/batang.ttc) /SubfontID 0 /FileType /TrueType >> ;
/Gulim << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/gulim.ttc) /SubfontID 0 /FileType /TrueType >> ;
/MS-PGothic << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msgothic.ttc) /SubfontID 1 /FileType /TrueType >> ;
/MingLiU << /CSI [(CNS1) 2] /Path (C:/Windows/Fonts/mingliu.ttc) /SubfontID 0 /FileType /TrueType >> ;
/DotumChe << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/gulim.ttc) /SubfontID 3 /FileType /TrueType >> ;
/MS-Gothic << /CSI [(Japan1) 3] /Path (C:/Windows/Fonts/msgothic.ttc) /SubfontID 0 /FileType /TrueType >> ;
/SimHei << /CSI [(GB1) 2] /Path (C:/Windows/Fonts/simhei.ttf) /SubfontID 0 /FileType /TrueType >> ;
/BatangChe << /CSI [(Korea1) 3] /Path (C:/Windows/Fonts/batang.ttc) /SubfontID 1 /FileType /TrueType >> ;
<826C8272835383568362834E>cvn << /Path (C:/WINDOWS/Fonts/msgothic.ttc) /FileType /TrueType /SubfontID 0 /CSI [(Japan1) 3] >> ;

再度実行


うまくいきました。

楽天トラベルの領収書の再々発行

最近、東京出張がかなり多いんですが、
プリンタのトラブルで領収書が発行できなくなり、
非常に困りましたが楽天トラベル様に
とてもよい対応をしていただいたので、
ブログに載せておきます。

楽天トラベル様にメールを送ろう

http://travel.faq.rakuten.co.jp/app/answers/detail/a_id/5668

[楽天トラベル]
 -> [ヘルプ]
  -> [支払方法について(領収書やキャンセル料やカードの返金など)]
   -> [【国内宿泊予約】 領収書の発行について]
    -> 問題は解決しましたか?のところで
     -> いいえ、解決していないので問い合わせます。

メール本文

プリンタの不具合から、
領収書の印刷ができませんでした。
他のプリンタに繋ぎ直そうと試みましたが、
再発行ができない状態になりました。

予約番号:XxxxYyyy01

申し訳ありませんが、対応方法をご教授ください。

楽天トラベル様からの回答

ご利用ありがとうございます。
楽天トラベルカスタマーサービス●●でございます。

この度はご予約をいただき誠にありがとうございました。
早速ではございますが、以下ご案内申し上げます。

領収書発行について、この度はご事情を考慮させていただき、
【個人ページ】において【領収書発行】ボタンを再表示させて
いただきましたことをご報告申し上げます。

                                                      • -

○○ホテル:XxxxYyyy01

                                                      • -

【個人ページ】
http://my.travel.rakuten.co.jp/mytravel/

お手数ではございますが印刷時にはご注意いただき、今一度
お手続きの程お願い申し上げます。
(更なる再発行につきましてはお断りさせていただく場合がございますので、
予めご了承の上、再度お手続きの程、お願い申し上げます。)

ご利用誠にありがとうございます。

その他、ご不明な点がございましたらご連絡の程お願い申し上げます。

今後とも楽天トラベルを宜しくお願い申し上げます。

さいごに

楽天トラベル様、本当にありがとう!!!
今後も楽天トラベルさん一本で行かせていただきます!!!