こんにちは。ラーメン二郎歴１年半のyenjojiです。
この記事はラーメン二郎アドベントカレンダーの17日目の記事です。

今日は、ラーメン二郎が好きなエンジニアが、いかにしてワンチャンスを逃さずにラーメンを食べるかを考えた結果作るに至ったサービスについて書きます。
完全なる自分向けサービスなのですが、同好者の皆さんのお役に少しでも立てば幸いです。

TL;DR

• 二郎が好きなので現在地から近い順に二郎を検索するWebサービスを作りました
• データをGitHubで公開しているので、ラーメン屋さん情報を提供してくださる優しい方がいればプルリクお願いします
• 要望とか、データが違うよとかご意見は専用Twitterアカウントまでよろしくお願いします。

今すぐ食べたいをサポートするサービス

勉強会などで、普段行かない場所に訪れることがありました。
概ね懇親会があったりしますが、中には懇親会がなく、そのまま解散になる勉強会もあったりします。

そんな、あまり馴染みのない土地で、21時位に時間ができてしまったら？
まっすぐ家に帰るのもよし、
そのへんでノマドするもよし、
でも、せっかく普段は行かない場所にいるのなら、そこから行ける二郎（インスパイア）でラーメンを食べたいものです。
そんな土地勘がない場所でも、迷わずラーメンを食べに行けるようになったらいいなと思い、このサービスを作りました。

データが少ないので

人力でデータを入力している関係もあって、データはラーメン二郎の各店舗と、自分がいったことのあるインスパイア系の店舗を中心になっています。
自分が行ったことのない店舗もどんどん追加していきたいので、おすすめの店舗があればぜひ教えてください。

データファイル(JSON)形式をgithubリポジトリにおいてありますので、お時間がある方はデータファイルを作成して、プルリクエストなど投げていただければ更にうれしいです。
（間に合ってないですが、そのうちReadmeにデータフォーマットを書きます！）

ご意見、ご要望など

データが間違ってる、この店舗を追加して欲しい、こんな項目を表示して欲しいなどは専用Twitterアカウントまでよろしくお願いします。

それでは、皆さんよいラーメン二郎ライフを！

11/8 に渋谷ヒカリエの31F株式会社medibaで行われたソフトウェア品質勉強会「開発とテストが一体となったソフトウェア開発」 に参加してきました。

内容は、JaSST 2016 Hokkaido の基調講演の再演＋会場の参加者との多めの質疑応答でした。
主催者の方が、せっかくなので、講演だけでなく質疑応答を多めにできるようにした。という作戦がはまって、活発に質疑がかわされて良い会でした。

感じたこと

• 組織としてのお墨付き
• 適切というか大胆な権限委譲
• 適切な評価システム
  このあたりが整っているとチームは自律的になるんだなと感じました

セッションの内容はスライドが公開されているので、そちらを参照していただくのがいいと思います。

以下メモ

テストエンジニアのチームとの関わり方

• Agile Testingのスライドに書いてある部分を読めばわかる

  • テストエンジニアならよりよく分かる→著者がテストエンジニアだから

• テストエンジニアはプロジェクト初期から関わる

  • なぜか？

• Yahoo!も道半ばなので、完成形ではない。

• パターン1

  • プロジェクト初期からバリバリ関わっているわけではない

  • 自動化したほうが楽なものはプログラマが自動化

    • → テストエンジニアがプログラマに提案する感じ？
  • プログラマとテストエンジニアがみつにコミュニケーションを取っている

• パターン2

  • テストエンジニアは業務委託さんへお願いするところを決める＋質問とかのカウンター
  • パターン1より処理できるテストケース数はスケールする
    • 大きな案件に向く
  • プログラマと業務委託のプロキシがいるのでスムーズに行くことが多い

• パターン3

  • 典型的なパターン
  • 細かいテストはプログラマがやる

  • テストエンジニアはサービス全体を見据えたテスト設計＋実施（リリース前）

    • 自分の現場に一番近い形

  • 小さいリリース

    • 軽微な変更（誤植とか）

  • もともとWFだったところがやっているプロセス

    • WFでやっている案件だとこういうパターンになるかもね → あー、そうだね～。うちの現場。

  • Q:それぞれのチームの規模感は

    • A:1チーム10人いかないくらい
      • 大きくなったら分割して、多チーム構成にします
  • Q:Sprintのきかんとか、リリースの単位とかは
    • A:早いところだと2日くらい→緊急リリース的な
      • Agile開発しているところは1w,2wが多い
      • サーバーサイドはできたらすぐ出す
      • アプリは審査があるのでちょっとサイクルが長めになる傾向
  • Q:テストは一斉にしますか？　順次しますか？
    • A:プロダクトによる、アプリとかはまとまってやる
      • できれば切りたいので、細かくする方向に持っていきたい
  • Q: チームは解体とか結構しますか
    • A:人の入れ替えは半期、一年とか
      • チームのライフサイクルはプロダクトに依存する
    • Q: 解散してしまうとノウハウが消えてしまうんじゃないか
      • A: そこは社内でも問題、だがずっと一緒のチームにいると学びが落ちて行く人もいるので
  • Q: パターン3でのコミュニケーションのスキームは
    • A:変更点とかをビジネスの人と、テストを変更しなければいけないところ
      • 基本的にはテストエンジニアとプログラマが近くにいるので、適宜コミュニケーションをすればいいと思ってる
  • Q:テストの範囲→テストエンジニアはQAですか？
    • A:QAって？　→第三者検査をする人
      • みんな当事者なので、第三者的な感じではなくプロダクトを一緒に作っていく人
      • 外部部門というスタンスではなく、ちかしい感じ
  • Q:ドキュメントは
    • A:情報共有できる雑な最低限のものをConfluenceやExcelとかに残っている
      • 粒度はまちまち
  • Q: ドキュメントがない状態のばあい、ミドルウェアのバージョンアップのときとかにフルにリグレッションテストとかをしないといけないと思うけど、困りませんか
    • A:全く前回と同じテストしないといけない理由が無い
      • お客様が使えないといけないというところが担保できていればいいので（そこは担保されているということ？　自動化されているとか？　いつもやってるテストケースがあるとか？）

組織の話

• 部門が分かれていると、部門ごとに責任分界点が生まれる　→　ビジネスにフォーカスできないよね！

  • なので組織を変えていく
    • （ここに関しては今の現場はできている、ところもある）

• 参考書籍：JAICAのPDFがいい感じ、安い、生々しい

• なぜ、あじゃいる

  • なんかアジャイルだと解決できるらしいぜ！　→　やってみっぺ！　→　うまく行った！　→　テンション上がった！　→　普及した！

• 経営陣刷新　→　爆速

  • COOのトップメッセージとしてスモールチームでやりなさい
    • 作ったら出していいよへのシフト
      • QAへ責任転嫁できない　→　開発チームの責任感が大きく　→　テストしないとヤヴァイ！　→　チームへテストエンジニアが参画！

  • QA担当のパラダイムシフト

    • 受ける人から、自分で取りに行かないといけないように

  • Q: もともとQA担当の人ってどれくらいいました

    • A: 40人位、業務委託の人も使っていた
      • テスト範囲も広くない＆リードタイムが長かった
      • Q: テスト支援部門は
        • A: 15人位
        • Q: 15人ですべてのチームの手伝いを？
          • A: 各チームのテストエンジニアのサポートと、テストしたいビジネスの人にコンサル的なことをする
  • Q ：もともとテストエンジニアじゃなかった人はジョブチェンジしましたか？
    • A: テストオペレーター的な人は、テストエンジニアになったり、テストしつつデータ解析したり、ビジネス系にいったりとか
  • Q: のこった2個の承認プロセスってなんですか
    • A: ビジネスをやるかやらないか、セキュリティやコーポレート・ガバナンス的なところの2つくらい
  • Q:似たようなアプリができたりしませんか
    • A: ある。けどカンパニーを分けているのでサービス的にはかち合うことがすくない
  • Q:セキュリティ以外の非機能要件はチームに任されている？
    • A:任されている、そこも含めてビジネスをすることを任されている
  • Q:ゲートを外したらヤバイと思った、思った人はサービスの人ですか？
    • A:いい方　→　サービスをちゃんとしないといけないというモチベーション
      良くない方　→　仕事が増えたので、テストエンジニアの人を取り込んでやってもらおう
  • Q:ゲートが外れた途端に品質がさがりましたか（バンバンリリースできるので、なんでもいいからバンバン出そうぜ！　みたいになって、品質が後回しにならないですか？）
    • A:下がりました、今は戻ってきているとき
  • Q:品質についてショック療法的になっていますが、コレは狙いましたか？
    • A:狙っていません
      • そんなにインパクトがあったわけではなく、じわっとヤバイとなった感じ
  • Q: テストスキルを上げるための取り組み
    • A:もともとレベルが低いので、ほんに書いてあることをティーチングできればOK　＋　サービスに合わせて行ければやっていけた
  • Q:課金系は権限委譲していますか
    • A：権限委譲はしています
      • 法的な部分とかそういったところは組織でチェックしていく
      • 会社としてはサービス組織に以上している
  • Q: 品質あげようとするとコストとか時間がかかるが、そのあたりにビジネス層からの圧力や軋轢とかはありますか
    • A:現実的にはある
      • Q: どうやって解消していますか？
        • カイゼンも含めてサービスの向上なので、ビジネス、カイゼン含めて優先順位を決めていく
          • 短期的視点と中長期的な視点で考える
  • Q: アーキテクチャとか、プロセスとかを標準化したい人がいるものの、そこはチームごとに最適解を目指していきたいけどどうやってその辺標準化厨を抑えてますか？
    • A:まとめたいひとと、まとめないほうがいいと思う人が話し合い
      • ライセンスとか、全社的に考え無いといけないときはそこで話し合う
      • 部分最適の人は勝手にやる
      • コメント：標準化とすると最適にしないといけないけど、平準化として、ベースラインを決めると進めたほうがやりやすいって聞いたことがある
  • Q: コンテンツなどがカニバることってありますか？
    • A: コンテンツがカニバるときはある。
      • カニバらないようにするのは、チームの自助努力に任されている
      • メディア・コンテンツの上の方の人たちは見てる＋分野がわかれているので
  • Q:サービス毎の機能連携
    • A：基本的にはチーム間での話し合い
      • 戦略的にやるときは、コンダクトする人が出てくる（サービスの責任者級のひとたちで、カンパニー長は出てこない）
    • Q: システムIF　が変わってデグレしたりしませんか
      • A:します、けどスピード重視
      • Q:そのへんは原因分析して、再発防止とかしますか
        • A:事故の規模、深刻度による
  • Q:チームの知見とか、グッドプラクティスは支援部門として広めるのですか？
    • A:支援部門がキャッチデキるところについてはそうしてる
      • でも、全部が把握できないので、そういったものはノウハウを持っている人が他チームにいったタイミングで拡散する
  • Q:コンフルエンス検索ダメじゃないですか？
    • A:検索やさんなので、頑張って改善しています
      • Googleの検索エンジンをバックエンドに使っているものの、そのまま使っているわけではなく、カスタマイズしていてまだまだ検索やさんがいます
  • Q:もともとQA部門があったからテストエンジニアができたとおもうけど、テストエンジニアになろうとする人のモチベーションを上げるには
    • 理想的なチームにするためにはどうしたらいいですか
    • A:テストするスキルは必要だが、テストエンジニアが必ずしも必要とはかぎらない。みんなでやればいい
      • テストスキルがその人に依存しているという状態はよろしくない
    • Q:テストできる人と、できない人のスキルレベルが違う　→　そこは揃えたい
      • A:プログラマと一緒で、シニアなエンジニアがジュニアなエンジニアを教育するのが理想じゃないか
        • コーディング規約みたいにテスト規約とかもあってもいいかもね
  • Q:テストコードを書ける人と、テスト設計デキる人って違う人だと思うのですが、そこの住み分けは
    • A:得意分野の差であり、違う職責としてはいない
  • Q: スキルを上げていく必要があるということにたいして、チームではなくて、会社、カンパニーとかで取り組んでますか
    • A:オフィシャルにはない、勉強会とか、支援部門としてセミナーをやったりしている
      • だいたい本を読めばわかることがおおい、それ以上は個別にコンテキストに応じたアドバイスをしないといけないので、使い分けている
  • Q: テスト勉強してこなかったプログラマにおすすめの本は？
    • A: みんなが読んだ本で良いんじゃないか
  • Q: テストを含めてどれくらい自動化してますか？
    • A: サービスがおおいので、均一な自動化はしていない
      • テスティングのプラットフォームを整備している
        • 環境、CI、CDを用意する
        • 支援部門が教えに行く

感想

Yahoo!のいろいろな立場の方に過去話を聞いたことがあったが、
その人の立場とかやっていることによって話す内容や、話から受ける印象が違うのが楽しく、ためになるなぁと感じた。

山口さん、呼べばどこでも講演してくれるそうなので、話を聞きたかったら呼んでしまいましょう。

要旨

jsonなどのデータを臨機応変に集計したいとき、あると思います。
もちろん自分でスクリプトを書くとかjqなどのコマンドを駆使して頑張るのもいいけど、
Apache Drillを使うと、SQLで集計できるので、SQLできる人ははかどりますよ！というお話。

本題

Story

「今稼働しているVMから、名前がかぶっているインスタンスがあるか調べてくれない？」
たとえば、ある日突然お客さんからこんな依頼が来たとします。
そんなときも安心、そうApache Drillならね。

やりたいこと

CloudStackのAPIで取得できるVMの情報から、同じドメインに同じなまえのインスタンスが存在するか？ を調査したい！

データ

JSONレイアウト

対象のデータは こんな感じのJSONが

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "listvirtualmachinesresponse": {
    "count": 99999,
    "virtualmachine": [
      {
       "VMのJSON"
      },
      {
        "VMのJSON"
      }
    ]
  }
}

こんな感じにラップされてます。
では、このJSONをApacheDrillで集計してみましょう。

集計

準備

インストールはMacならHomeBrewで

1

brew install drill

SQLの実行

準備は整ったので実際に集計してみましょう！

drillの起動

まず、Drillを起動します。

1

drill-embedded

起動すると、Drillのプロンプトが返ってくるので、そこにおもむろにSQLを叩き込みます。

SQLを実行する

あとは、SQLを実行するだけ。
いつものSQLと違うのはFROM句でテーブルを指定せず、ファイルを指定するくらいです。

1
2
3
4
5
6

select vms.vm.name, vms.vm.domain, count(*)
from ( select flatten(t.listvirtualmachinesresponse.virtualmachine) as vm from dfs.`/Users/yenjoji/Downloads/listVirtualMachines.json` as t) as vms
group by vms.vm.name, vms.vm.domain
having count(*) > 1
order by vms.vm.name
;

おまけ

私は、みんな大好きエクセルで後加工したかったので、こんなオプションつけました。

• ヘッダを最初だけにする

  1	!set headerinterval 0

• 出力フォーマットをTSVにする

  1	!set outputformat tsv

• 出力をファイルに保存する

  1	!record result.tsv

と、しておくとTSVになるので、Excelにはっつけてピボットテーブルでどうにかしたりなど加工し放題です。

感想

• JSONをSQLでサクッと検索できるのはちょっとうれしい。
• 1回使う手順を覚えてしまえば、2回め以降が楽になるし、ちょっと集計方法を変えたりなんかの対応が柔軟に出来る。

こんにちは。
みなさんはいかがお過ごしでしょうか?　私はすっかりDockerかぶれになっています。

Dockerは気軽に環境を作ったり壊したりできる手軽さと、Virtualboxと比べてリソースをそこまで食わないのが嬉しいところですね。

VagrantでVMを3つくらい起動した挙句メモリが足りなくなり、
Macがグレーの画面でハングアップなんていうVagrantあるあるからおさらばできるだけでもかなりのメリットがありますね。

そんなDockerにすっかりかぶれてしまった私なので、当然CIはDroneを使うわけです。
droneは DockerベースのCIサーバーで、特徴としては

• Docker上でビルドを行うので、常にクリーンな環境でビルドできる。
• 設定がTravisCI、CircleCIのようにリポジトリのルートにおいた yaml ファイル一個で済むのでスマート＆Git管理下における。

という感じの田中美奈子と同じくらいナウいCIサーバーです。

詳しくはこの辺を見ていただくとなんとなく特徴がわかると思います。

そんなある日、プロジェクトで使っているCIサーバーであるDroneでOracleJDKをつかいたくなってしまいました。
OpenJDKのコンテナなら、Oracleから提供されているので

1

image: oracle/openjdk:8

などと、.drone.ymlに設定すれば、たやすく環境が手に入ります。
しかしながら、OracleJDKはライセンスの関係か、オフィシャルのコンテナイメージ用意されていないようです。

ローカル環境で使うだけならば手元で docker build してあげればいいのですが、Droneちゃんは、レジストリからしかイメージを取得できないようでした。

自前でプライベートレジストリを構築するという選択肢もありましたが、ここは将来的に ECS を使うことも見据えて ECR を使っておこうということになりました（自分の中で）。

まとめ

手順等も書きますが、そもそもそんなに難しくないですし、AWSの画面にコマンド一覧出るので、とりあえずここでは言いたいことだけ書きなぐっておきます。

• ECR簡単なので、Docker使っている場合は選択肢に入れていいと思います
• 転送量課金なので、そこは気をつけたほうがいいかも
• 現在バージニア、オレゴン、アイルランドでしか提供されていないので、それ以外のリージョンで「あれ？ 出てこない？」とかならないように注意
• EC2にIAMロールつけとくと、アクセスキーとか、ユーザーとか気にしなくていいからお気楽です(Amazonも推奨してます。)

一応雑な手順も書きましたので、興味があったら以下手順も見てみてください。

手順

Amazon ECR の準備

ECRは現在 3つのリージョンでしか使えませんこの辺参照。
なので、今回は us-east-1 RegionでECRを使いたいと思います。

ECR Repository の作成

1. はじめてECSを使うとウィザードに誘導されます。今回はひとまずECRだけ用意するので「Store container images securely with Amazon ECR」だけにチェックを入れて進みます。
2. 次の画面でリポジトリ名（dockerのイメージ名）を設定すれば作成完了です。

ECR イメージ作成用インスタンスの作成

1. EC2用IAMロール作成
   今回は、アクセスキーの管理の手間を省くため、EC2のIAMロールに ECR関連の権限を付与することにします。そのため、先にEC2用のIAMロールを作っておきます
   1. IAM -> 「新しいロールの作成」
   2. 適当なロール名を設定
      • 「ECR_CREATER」とかなんでもいいと思います
   3. AWS サービスロールから Amazon EC2 を選択
   4. 「AmazonEC2ContainerRegistryPowerUser」あたりをチェックしてロールの作成
2. EC2インスタンスの作成
   1. 適当なイメージからEC2インスタンスを作成します
      • リージョンはどこでも良いので、いつも使っているリージョンで良いと思います
      • AMIもdockerが使えればなんでも良いです。今回はAmazonLinuxにしました
      • インスタンスタイプもまずは t2.micro とかで大丈夫です。足りなかったら後でスケールアップしましょう
      • たくさんイメージを作る・使う場合はディスクを大きめにしておくといいかもしれません

3. イメージの作成

   1. 作成したインスタンスへログイン

   2. dockerのインストール

      1	yum install docker

   3. dockerの起動

      1	service docker start

   4. イメージの作成

      1	docker build -t ${dockerのイメージ名} .

4. イメージをRepositoryへ登録

   1. ECRへのログイン

      • aws ecr get-login でログイン文字列がもらえるのでバッククォートで直接実行するとログインできます。

        1	`aws ecr get-login --region us-east-1`

   2. イメージへのタグ付け

      • ecr のマニュアル通りです

        1	docker tag ${dockerのイメージ名}:latest XXXXXXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com/${dockerのイメージ名}:latest

   3. イメージのPush

      1	docker push XXXXXXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com/${dockerのイメージ名}:latest

最後に

こんな感じにDockerレジストリが作れてしまうとは！ と、私はひとりで感動してしまいました。
AWSなんでそれなりにお金はかかりますが、懐に余裕があれば選択肢の一つにしてもいいかも知れません。

こんにちは。

先日、知人に私の月々のお小遣いの額を正直に言ったら、可哀想な表情をされました。
それでも私は元気です。円城寺です。

話は変わりますが、nu boardをご存知でしょうか？

スケッチブックのような見た目のホワイトボードのノートです。

ホワイトボード愛好家の私としては、以前からこのノートがほしかったのですが、意外と高価でなかなか手が出ませんでした。

だが欲しいものは欲しい。
「買えぬなら、作ってしまえホトトギス。」
と誰かが言ったとか言わなかったとか。

よくよく見ると、100円ショップで買えるようなものでそれっぽいものが作れるんじゃないかという気がしてきました。

「よし、新プロジェクトの旗揚げだ！」

材料

今回はすべてダイソーで揃えました。

• ホワイトボードシート x 2

• 厚紙 黒 3枚入り x 1
  

• カードリング x 1
  

今回はプロトタイプ一回目ということで、今回は2ページ構成でためしてみることにしました。

ちなみに材料費はここまでで 432円 です。 すこぶる財布に優しいです。

この他に、
カッター、カッターマット、穴あけパンチ、定規 が作業に必要ですが、自宅にあったので今回は材料費には入れません。

工作

もはや解説の余地もない気がしますが一応作業手順をば。

1. ホワイトボード部分の作成
   厚紙の両面にホワイトボードを貼ります。
   今回購入したホワイトボードは裏側がシールになっているため、そのまま厚紙に貼ってしまいます。
   特にコツはないと思いますが、私は先ずホワイトボード上端部分だけ粘着面を出し、
   
   位置あわせをしてから残りの部分を貼りました。

2. 穴を開ける
   パンチで適当に穴を開けます。
   後々市販のリフィルなどを使いたいという場合は使う予定のリフィルと穴の位置を合わせておくといいでしょう。

3. カードリングで冊子状にまとめる
   開けた穴にカードリングを通して、冊子状にすれば出来上がりです。

まとめ

500円かからずにnu boardっぽいものは作れました。

意外と厚紙がしっかりしているので、机の上でなくても使えそうです。
何より、ヌーボードのラインナップにないB4サイズというのがいいです。かばんの収まりがいまいちですが。

ただ、ページを本家と同じく8ページに増やすと材料費だけで1500円くらいにはなってしまうので
全体的な出来栄えを考えると4000円くらいなら買ってしまってもいいかなとも思いました。

まぁ、工作も簡単なので今後もバージョンアップを考えていきたいと思います。

みなさん、Docker使ってますか？

私は使ってません。

しかし日常的には使っていないものの、ちょっと新しいプロダクト試そうかなと公式サイトのQuickstartとかを眺めると、Dockerのコンテナが用意されているケースが増えてきた気がします。世間の流れですね。いわゆるBigWaveです。乗らないとイカンやつです。

そんな中、現在のプロジェクトでKONGというミドルウェアを使うことになりました。

KONGがどういうものかは この辺（Ryuzeeさん） や この辺（クラメソ） を読むとなんとなくわかるかもしれません。

同じカテゴリのプロダクトとしては WEB API Degignを配布している、Apigee　が有名です。

〜閑話休題〜

このKONGなる謎のミドルウェア。使ったことがないので、どんなものかもわかりません。
最終的にはAWSに環境を構築するので、それを待つのもいいのですが、さしあたってどういうものかを試してみたいのが人情ってやつです。

そんな時、今まではVagrantなどで環境を構築して試用するのが常でしたが、最近ではDockerが流行りのようです。時の流れってやつですね。

実際、公式のインストレーションのページでもDockerが筆頭になっていますし、ここはDockerで行くべきなんだと思います。

ということで、公式の手順を読んでみると、どうやらKONGは　DB( cassandra または postgresql )と KONG本体の2つのコンテナが必要のようです。

ここは手順通りにおとなしくDockerコマンドを2回粛々と実行するのが大人のたしなみという説もあるかもしれませんが、違いのわかる大人になるため、エレガントにdocer-composeコマンド１回で２つのコンテナを自在に操って見たいと思います。

手順

ということで、任意のフォルダに “docker-compose.yml” をこの内容で作成します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

kong-database:
  image: postgres:9.4
  ports:
    - 5432:5432
  environment:
    POSTGRES_USER: kong
    POSTGRES_DB: kong
kong:
  image: mashape/kong
  links:
    - kong-database:kong-database
  ports:
    - 8000:8000
    - 8443:8443
    - 8001:8001
    - 7946:7946
    - 7946:7946/udp
  environment:
    DATABASE: postgres

必要ならdocker-machineを準備し

1
2

$ docker-machine create -d virtualbox kong
$ eval "$(docker-machine env kong)"

おもむろに docker-compose up を実行するだけで、さくっとKONGが起動っ

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ docker-compose up
Starting vagrant_kong-database_1...
Starting vagrant_kong_1...
Attaching to vagrant_kong-database_1, vagrant_kong_1
kong-database_1 | The files belonging to this database system will be owned by user "postgres".
kong-database_1 | This user must also own the server process.
−中略−
kong_1          | [INFO] kong 0.8.3
kong_1          | [INFO] Using configuration: /etc/kong/kong.yml
kong_1          | [INFO] Setting working directory to /usr/local/kong
kong_1          | [INFO] database...........postgres host=kong-database database=kong user=kong port=5432
kong_1          | [INFO] dnsmasq............address=127.0.0.1:8053 dnsmasq=true port=8053
kong_1          | [INFO] Leaving cluster..
kong_1          | [ERR] serf is already running
kong_1          | [ERR] Could not start Kong

エラーになりました!!!!

が、めげずにKONGへアクセスしてみると、

1
2

$ curl http://192.168.99.100:8001/status
{"server":{"connections_handled":7,"connections_reading":0,"connections_active":1,"total_requests":7,"connections_accepted":7,"connections_writing":1,"connections_waiting":0},"database":{"oauth2_tokens":0,"jwt_secrets":0,"response_ratelimiting_metrics":0,"keyauth_credentials":0,"oauth2_authorization_codes":0,"acls":0,"apis":0,"hmacauth_credentials":0,"consumers":0,"ratelimiting_metrics":0,"basicauth_credentials":0,"nodes":1,"oauth2_credentials":0,"plugins":0}}

正常にアクセスできる!!!
KONGの起動メッセージがなんとなくすっきりしませんが、何故か起動完了。

まとめ

Docker Composeを使うことにより、コンテナ起動の手間を省いたり「コンテナ起動手順」の代わりに”docker-compose.yml”を配布するなんてこともできたりして、
環境構築のめんどくささが減るんじゃないかなぁ。減るといいなぁ。そんな感じです。

みなさんも良いDokcer Lifeを！

５月３１日はアジャイルジャパンでした。
今まではなんかスーツ色が強そうで避けていたんですが、今回はじめて勇気を出して参加しました。

公式ページ
Togetter

感想

• Awesome Joe の 基調講演面白かった
  • 戦闘機を一週間スプリントで毎スプリントリリースしてるとか、Scrumでワイン造りをしているとか。
• Awesome Joe ゆっくり話してくれたから英語聞き取りやすかった！
• 牛尾さん相変わらずテンション高くて面白かった。声がでかすぎてマイクの音が割れてた。
• 高橋陽太郎さん、サービス開発中止になって号泣 → 号泣する程本気で向き合ってる姿勢がすごい！
• 会場のシャッター音に苦言を呈しているかたが多かった。私は気にならない派。

参加したセッション

• 初心者向けミニチュートリアル
• 実行会長あいさつ
• IPA 激励メッセージ
• 基調講演１ スクラムがイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜
• 基調講演２ アジャイルなIoTプラットフォーム開発
  • http://www.slideshare.net/SORACOM/agile-japan-2016-iot
• D-1 請負で企画・開発・運用・拡張まで担当するアジャイルチーム
  • http://www.slideshare.net/gaoryu/agile-japan2016-d1
• D-2 事業会社でのアジャイル奮闘記
• A-3 アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～
  • http://www.agilejapan.org/2016/image/A-3_YujiKishira_AgileJapan2016.pdf
  • http://www.agilejapan.org/2016/image/A-3_yoshino_AgileJapan2016.pdf
• B-4 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！
  • https://docs.com/ushio-tsuyoshi/8981/agilejapan2016
• C-6 アジャイル開発における品質保証と人材活用

セッションごとの感想など

初心者向けミニチュートリアル

ざっくりアジャイルを説明しようとするとやっぱこうなっちゃうよねぇという感じのセッション。
知ってる人が聞くと言いたいことはわかるけど、ほんとに伝えたい人に伝わるかは未知数。。。

実行会長あいさつ

道元の言葉「知るとわかるはちがう」
http://www2j.biglobe.ne.jp/~mano/message/08.html

IPA 激励メッセージ

日本のScrum認定者はすくないらしい。

基調講演１ スクラムがイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜

Scrumは生産性の超兵器 - 驚くほど効果的

と Awesome Joe こと Joe Justice さんが言ってました。

ソフトウェアエンジニアだけじゃなく、ハードウェアエンジニアも一緒のチームでScrumを行っているという事例など。
自動車や、スパークリングワイン、果ては戦闘機(コレ の４ページ目)や法律までScrumで作っているという話。

固定観念からか、どうしてもScrumといえばソフトウェア開発を想像してしまっていました。
むしろ昔良く聞いた「組み込み系（含むハードウェア）にはアジャイルは向かないよねぇ」となんとなく思っていた考えが粉砕されました。
パイロットもチームに入れて、戦闘機を週一回リリースするとか 空前絶後 （言いたいだけ）ですね。

そう言うキャッチーな話とともに
「Scrumは毎スプリントコストを下げてValueをあげていけるから投資家はScrumが好きなんだ」
とか
「スクラムマスターの主要な仕事はチームをハッピーにすることです、チームのフラストレーションを取り除くのがスクラムマスターの仕事です」
など、サラッといいことも言っていましたさすがAwesome。

基調講演２ アジャイルなIoTプラットフォーム開発

あのいまや飛ぶ鳥を落とす勢いの玉川さんによる基調講演。

基調講演の内容も良かったですが、個人的には最後に紹介されていたモジュール５個で八王子全体をカバーできるというLoRAがすごい！と思いました。

玉川さんががおっしゃっていた「オープンでフェア」「ものづくりの前にリリースノートを書くのはAmazonカルチャー」はカッコ良かった。

A-3 アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～

岸良さんの話が聞けるということで、個人的にかなり期待していたセッション。
内容としてはCCPMの手法はアジャイルプロセスとも相性がいいよ！というお話。

そういえばクリティカルチェーン読んでないので、今度読んでみよう。

岸良さんはさすがの話し上手で楽しく話を聞けました。

B-4 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！

• https://docs.com/ushio-tsuyoshi/8981/agilejapan2016

久しぶりの牛尾さんセッション。
相変わらずの開幕ハイテンションで、スピーカー割れるほどの音量で”デブオプス！！！”って叫んでました。

DevOpsについては牛尾さんのブログを見てねということだったので、おそらくこの記事を読めば良いのではないかと思いました。

今回は時間の関係上DevOpsの話少なめで、最近牛尾さんがよく言及している文化の違いについての話がメインでした。

「日本の文化で、アジャイルを導入した場合の問題点は、その文化の違いから”うっすいカルピス”みたいになる。」

それを避けるためには西洋文化を（部分的に）インストールのが近道であるということ。
ただ、すべて西洋式にする必要はなくて、アジャイル（DevOps）と日本文化のジョイント部分だけ西洋文化をインストールするといいよという話でした。
「Be Lazy」「エッセンシャル思考」などが、サラッと語られていましたが、その辺り＋αが「西洋文化」なんだろうなと思いました。

どうやってインストールするかというところについては余りフォーカスして語られなかったので、とある若者が聞いてみたいとつぶやいたりしていました。

セッションでウシオさんという方が、アジャイルを導入する前に、西洋文化をインストールしろっていってたけど、じゃあそこをどうするのかって話をすごく聞きたかった。懇親会で見つけれなかったしすごく残念。#agilejapan

— まっさん.do (@toyosge) 2016年5月31日

久しぶりの牛尾さんセッションは相変わらずのハイテンション＆クオリティで素晴らしかったです。

なんとなくのまとめ

いろいろな立場の人のいろいろな話を聞けて、現在のアジャイル開発の一つの側面みたいなものが感じられ、
また、今の自分のチームのどの辺がいい感じでどの辺が足りてないみたいなことを考えるヒントになったのかなと感じました。感じたような気がします。

伊藤さん(@hageyahhoo)による、資格申請の仕方の記事を参考にして、4/12に申請を行い、5/10 認定を頂きました。

途中記載不備があり、レビュアーから、「もう少し詳しくどういうことをしたか教えておくれよ。」というコメントをいただき、
たまたま連休中だったので、私の返答が遅れたので、「およそ3週間」というレビューの一般的な期間より、多少時間がかかってしまいました。

指摘された点は、SEUのうち Category-D のボランティア活動の内容があまりに淡白すぎたため、もう少し具体的にどんなボランティア活動を行って、どういった効果があったのかを書いてほしいというレビュー指摘でした。

頂いた指摘を修正し、再レビュー依頼をしたところ4日ほどで、レビューOKの返事を頂きました。

資格を撮ったからといって、何ができるようになるわけでは無いですが、少しでもスクラムのプロフェッショナルに近づけるよう頑張っていきたいと思います。

アジャイルひよこクラブ「つの習慣に学ぶ！！開発者から見たプロダクトオーナーとのよい付き合い方」に参加してきました。

隔月開催のため、前回に引き続き2回連続の参加です。

今回はPO Studyの主催者であり、7つの習慣ボードゲーム公認ナビゲーターでもある、
関さんによるプロダクトオーナーとのつきあい方についてのセッションでした。

時間が無い人向けのあらすじ

付箋の使い方

• プロアジャイラーにになるための付箋の剥がし方
  • 下に引っ張る ＞ 横に剥がす ＞＞＞＞＞ 普通に剥がす
• プロアジャイラーにになるための付箋の貼り方
  • のりを下にして貼ると重ねた時の取り回しがらく＆重なった重みで落ちない

７つの習慣に学ぶ！！開発者から見たプロダクトオーナーとのよい付き合い方

• 7つの習慣は習慣化しないと意味ない
• プロダクトオーナーとチームはちゃんと要望の意図を共有しないと良いものが作れない
• コンペティティブインテリジェンス重要

当日の流れ

自己紹介

まずは自己紹介です。
前回は４人くらいのグループを作って、グループ単位での自己紹介でしたが、
今回はひとりずつ全体に向かってテンプレに沿って自己紹介です。

７つの習慣に学ぶ！！開発者から見たプロダクトオーナーとのよい付き合い方

関さんのセッションです。

アイスブレイク 付箋のめくり方

はじめにアイスブレイクで付箋の正しい使い方のレクチャーです。

• 剥がし方
  • 横にめくる
    • ここのような剥がし方をすると、貼った時に丸まらないです。
  • 引っ張る
    • ここに書いてあるとおり、付箋を平行にのりを上に持ち下に引っ張って剥がします。これぞ玄人の剥がし方だそうです。
• 貼り方
  • のりを下にしてはる
    • こうすると、重ねて貼った場合に一枚の付箋に重さが集中して落ちるという事がなくなります。
    • 下に貼った付箋も上の付箋をめくると見えて便利

言葉の定義と意識合わせ

次に、会場で話していることの認識がずれないように、
用語についての認識合わせということで、アジャイル開発とプロダクトマネジメントについての解説です。

アジャイル開発について

• アジャイル
  • 今できないことを次にできるようにしましょう → コレ以外言っていない
  • プロジェクトマネジメント、プロダクトマネジメントが入っていない → これが原因で失敗するケースがおおい
• アジャイル開発導入の時失敗したこと
  • アジャイルマニフェストの下2行が話されていないこと
  • みんな勘違いして大変なことになった（ドキュメント書かなくていいんだ！！！ とか）

プロダクトマネジメントとは

• マネジメント対象
  • プロダクト
  • 市場
  • 顧客
• 上流と下流がある
  • 上流
    • 市場投入まで
    • SIerとかLeanなかんじのひととか
  • 下流
    • 市場投入したあと
    • メタップス、電通、博報堂とか
• コンペティティブインテリジェンス
  • 意思決定するために必要な情報を集めるスキル

7つの習慣

最近各所でよく話を聞く７つの習慣について、図を用いて紹介です。

• 事前アンケート
  • ７つの習慣を読んだことがある人は結構いましたが、それを習慣化できている人は一人でした。
  • 関さん曰く７つの習慣は習慣化できないと意味が無い
• 7つの習慣について紹介
  • 1-3の習慣
    • 社会人としてできていないとまずい
  • 2-6の習慣
    • チームで仕事するときにできていないとまずい
  • 7の習慣
    • 成功の習慣化
      
      

プロダクトオーナーとのつきあい方について

ワークショップ

ここからワークショップ形式です。

7つの習慣の配布資料について、配布時にはA4の紙半分に図が印刷されていて、かつ図が内側に来るように半分に折られていました。

これは、図を目一杯印刷してしまうと、メモを取るスペースが無くなってしまうため、あえて半分の大きさにして印刷したそうです。

そこで、関さんからの質問です。
「この配布資料を会場の皆さんだったらどう作りましたか？」付箋に書いてみてください。

私の答えは

• 折らずに配る
• 縮小した図をセンタリングして印刷する
  でした。

ワークショップ解説

このワークショップの意図は、POである関さんと、依頼を受けた我々が
目的を共有しないと依頼を受けた側が適切な対処ができない（コミュニケーションギャップが発生する）ということを再認識するためのものでした。

我々は事前に「メモを取りたいから」という要望を聞いていたので、資料の印刷方法について適切に判断できましたが、
もし、その意図がないまま「A4の資料をA5縮小で印刷してほしい」という依頼を受けたらどうなるか、
もしかしたらA4の紙にA5サイズの図を2つ印刷してしまうかもしれません。

POの立場としても、それを聞くチームとしても、ユーザーストーリーのテンプレートでいうところの「なぜ」の部分（＋コンペティティブインテリジェンス）をちゃんと共有しないとまずいということを再認識しました。

• 話の流れは忘れてしまったけど手元にメモしてあったこと
  • 人が前に進むときにどんなもの（情報）が必要なのか、それをチームビルディング時に合意できていれば良い仕事ができる。
  • 本当はどういう姿になっていれば、もっと良い仕事ができたんだっけ？
  • ちゃんと先のことを考えられるチームが必要

LT おのさん

• チーム14人

  • Srrumの定義的には多すぎというが何が悪いのか？
  • コミュニケーション取れてますし、ちゃんとチームが強調して作業できてます。
  • 問題ない！

• ディレクターに質問

  • シモネタで会話できること
  • シモネタはコミュニケーションツール

質問タイム

PMがチームに必要になると、人数が多くなりませんか

• 専任で用意せよというわけではなく、ロールを定義しましょうという話
• 大事なのは、PO、SM、チームだけでオッケーと言う誤解した状態でやらないこと
• チームの外にはマネージャーとかいると思うので、チームの構成と、組織までスコープに入れた構成で考えたほうがいい

PMとプロダクトマネジメントを同時にやるのって難しくないですか

• 現在は無理だと想います。
• 昔はリリースの間隔が長かったことも有り、一緒にできた
• 最近はリリースサイクルが早くなった＋技術要素など複雑になった
• 自分たちのプロジェクトでは分けたほうがいいか？一緒にやったほうがいいかちゃんと考えて判断する
• 一ヶ月のプロジェクトだったら、マネジメントはチーム各自で行うなど場合によって考えたほうがいい

悩み相談

トレードオフできない

• 意思決定する情報がたりないので、みんなトレードオフの判断ができないという状況という可能性もある
• どんな情報があったら優先順位が決められるかという話をしてみる

• コンペティティブインテリジェンスを探す旅に出るのもおすすめ

• どんな情報があったら決められますか？と聞いてみる。

主体性がないメンバーにどうやって主体性を発揮させるか

• 主体性が与えられていない人もいるということもいるので、まずそこは確認しましょう

• その場合は契約を変えないといけない

• それでもできないのであれば、要員交代を要求する。もしくはそういった取り組み方だと評価があまりされないということをちゃんと伝える

• チームに慣れていないうちは、さじ加減がわからずできない場合もあるので、やっていいところと、止まってほしいところを事前に共有しておくとよい

他の参加者の回答１

• 以前やってみてダメだったパターン
  • こういう勉強会いったよ、こんな手法があったよと相手を刺激する
    • そもそも興味が無いので響かない
  • アジャイルと言わずにやってみる
    • 定着しなかった
    • 言わないとやらなかった

他の参加者の回答２

• チームメンバーが今できていないことを共有する
  • できていないことに気づくことによって、自発的にやることもある

他の参加者の回答３

• ビジョンを共有する
• 自分が作ったものがどう使われているか見せる→お客さんと合わせる

感想

７つの習慣に学ぶ！というほどプロダクトオーナーと７つの習慣は密接に絡んでいなかった気もするが、
７つの習慣のエッセンスと（駆け足だったけど）プロダクトオーナーについて話を聞けたのは良かった。

アジャイルひよこクラブは質問とか、悩み相談にもウェイトをおいているので、メインスピーカーの話がどうしても短くなってしまうのが悩みどころ。
初心者の悩み相談というコミュニティのスタンスなので、この方式はいいと思うが、プロダクトオーナーの話は別の所でもう少し詳しく聞いてみたくなった。

読んだ本

• 題名
  ビブリオバトル入門―本を通して人を知る・人を通して本を知る
• 所要時間
  2時間 (必要なところだけ拾い読みしました)
• 価格
  ¥0 (図書館で借りてきた)

感想

私が関わっている、とあるイベントでビブリオバトルをやってみたらどうかという企画が立ち上がりました。
興味があったので私もそのイベントのビブリオバトル運営に手を挙げました。

手を挙げて見たものの実はビブリオバトル自体やったことも無ければ、詳しくも知らないので、
まずは基礎知識を得ようということで安定の千代田区立図書館からこの本を借りてきました。

読んだ箇所は

• ビブリオバトルの公式ルールと、ルールの意図について
• 様々なビブリオバトルサークルの活動についてをちょっと
• 今後のビブリオバトルの広がりについてサラッと

読んだ結果わかったことは

• ビブリオバトルのルールはしっかり決まっており、しかも厳密に守ることが求められている。
  • 発表5分という時間一つをとってもちゃんと意図があるため、ビブリオバトルと名乗る以上は勝手にアレンジしてはいけない。
• この本が発行された時点では活動していたサークルが結構活動休止してたりする
  • 下火になってしまったのか？
• でも調べてみると、そこそこビブリオバトルが行われている
  • ビブリオバトル公式サイトカレンダー
  • ビブリオバトル有隣堂

ひとまず、基本的なことは知ることができたので、目的は達成できました。

なお、公式ルールはビブリオバトル公式サイトにも掲載されています。