アジャイル開発の基礎知識を問う「アジャイルソフトウエア開発技術者検定試験 Lv.1」に合格した

昨日「アジャイルソフトウエア開発技術者検定試験 Lv.1」に合格した．試験問題に関係する内容は NDA を厳守するため書かず，今回は「試験紹介（普及のため！）」にフォーカスする．正直言って，まだまだ知られていない資格だと思う．また，あくまで理解度を証明する「資格」であるため，合格したらすぐにアジャイル開発を実践できるという意味ではなく，あくまでマインドセットを合わせられる程度だとは思う．とは言え，個人的には「アジャイル開発を知る第一歩として」なら価値があるように思う．

agilecert.org

僕自身はアジャイル開発の経験（スクラムマスター含む）が4年ほどあり，さらに「認定スクラムマスター (CSM : Certified ScrumMaster)」も取得しているため，試験対策はほとんどせず，移動時間に試験対策本を Kindle でザッと流し読みした程度となる．試験対策本らしく体系的に書かれていて，入門書としても良いと思う．

アジャイル検定公式テキスト アジャイルソフトウエア開発技術者検定試験 レベル1対応

アジャイルソフトウエア開発技術者検定試験とは？

「アジャイルソフトウエア開発技術者検定試験（アジャイル検定）」は「アジャイルソフトウエア開発技術者検定試験コンソーシアム」が運営している試験で，現在は「Lv.1」と「Lv.2」が提供されている．特に「Lv.2」に関しては，今年6月に受験できるようになった新試験となる．近々「Lv.2」も受験してみようと思っている．

• アジャイルソフトウエア開発技術者検定試験 Lv.1
  • 概要 : アジャイル開発の基本的な知識とアジャイル開発の経験から得られる実践的な内容
  • 大項目
    • アジャイル開発に対する基礎知識
    • 開発チームの運営
    • アジャイル開発プロジェクト管理
    • アジャイル開発の技能
  • 試験要項(Lv.1試験) | アジャイルソフトウェア開発技術者検定試験
• アジャイルソフトウエア開発技術者検定試験 Lv.2
  • 概要 : 開発チームのメンバーがプロジェクトに入る前に必要な実践的な内容
  • 大項目
    • モデリング
    • コーディング
    • 構成管理
    • テスト
    • 常時結合
    • デザインパターン
    • リファクタリング
    • チームのスキル
  • 試験要項(Lv.2試験） | アジャイルソフトウェア開発技術者検定試験

試験概要

「アジャイルソフトウエア開発技術者検定試験」の試験概要を公式サイトを引用しながら紹介する．試験は「プロメトリック」で受験する．会場ごとに受験可能日が異なり，予約が取れれば希望日に受験できる．料金は10800円となる．僕は今回慣れた「渋谷会場」で受験した．問題数は「60問」となり，合格ラインが「80%」と公開されているため，単純計算で「48問正解」がボーダーラインとなる．

• 問題数 : 60問（四肢択一）
• 試験時間 : 60分
• 合格ライン : 正解率 80％以上

試験範囲

• アジャイル開発に対する基礎知識
  • アジャイル・マニフェスト
  • アジャイル原則
• 開発チームの運営
  • コミュニケーション
  • 自律性と協調
  • ルール
  • 振り返り
• アジャイル開発プロジェクト管理
  • 会議体
  • ロール（役割）
  • 反復
  • ドキュメント
  • チーム編成
  • 計画
  • 見積り
  • ビジョン
  • 品質
• アジャイル開発の技能
  • ペアプログラミング
  • リファクタリング
  • 常時結合
  • テスト駆動開発

試験対策

試験対策本以外だと，やはり「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」を繰り返し読む．

• アジャイルソフトウェア開発宣言
• アジャイル宣言の背後にある原則

他は試験対策本に参考文献として載っているアジャイル関連の名著を合わせて読むと効果的だと思う．例えば「アジャイルサムライ」や「エクストリームプログラミング」や「アジャイルレトロスペクティブズ」など．スクラム関連の名著も多く参考文献に載っているけど，本試験は「アジャイル開発」全般をテーマにするため，スクラム用語は出てこなく，個人的には戸惑う場面もあった．

アジャイルサムライ−達人開発者への道−

エクストリームプログラミング

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

試験結果レポート 🎉

試験を終えると，すぐに試験結果レポートが出る．満点合格できたら良いなぁーと考えていたけど，選択肢の日本語が微妙なものもあり，結果としては「93点」だった．単純計算だと4問間違えているらしく残念だった．どこを間違えたんだろう！

分野	正答率
基礎知識	88%
開発チームの運営	100%
プロジェクト管理	92%
開発技能	92%

まとめ

• 「アジャイルソフトウエア開発技術者検定試験 Lv.1」に合格した
• あくまで理解度を証明する「資格」であるため「アジャイル開発を知る第一歩として」なら価値があるように思う
• 先月から受験できるようになった新試験「Lv.2」も近々受験してみようと思う

小ネタ : Scrum Alliance Certificant Directory

今回の試験とは直接関係ないけど，「認定スクラムマスター」など Scrum Alliance で認定されている場合，Certificant Directory で認定者を検索できる．例えば「Japan x Certified ScrumMaster」だと，既に4000人を超えている！案外知られてなく，小ネタとして紹介しておく．

• Scrum Alliance - Members Directory
• Yoshiaki Yoshida - Scrum Alliance

nginx でリクエストを複製できるモジュール「ngx_http_mirror_module」

nginx でリクエストを複製できるモジュール「ngx_http_mirror_module」を使うと，簡易的な「Shadow Proxy」を構築することができる．例えば，本番環境のリクエストの一部を開発環境に流せるようになる．この「ngx_http_mirror_module」は nginx 1.13.4 で実装された機能で，2017年8月リリースなので，最近のバージョンだとデフォルトで使えるようになっている．今回は「リクエストの複製」を試すため，Docker Compose を使って検証環境を構築した．

nginx.org

検証環境

今回 Docker Compose を使って，nginx と Sinatra を起動する検証環境を構築した．コンテナは計3種類で，以下の構成図にまとめた．基本は Frontend と Backend でリクエストを処理し，今回は Mirror にもリクエストを複製する構成にしている．ドキュメントにも記載されている通り，Mirror からのレスポンスは無視される仕様になっている．

• Frontend (nginx)
• Backend (Sinatra)
• Mirror (Sinatra)

特に設定はなく，すぐに docker-compose up で起動できるようにした．今回エンドポイントは Sinatra で / と /ping を実装している．なお，Docker Compose の設定などは GitHub に公開した．

$ docker-compose up

$ curl http://localhost
Hello, backend!

$ curl http://localhost/ping
Pong, backend!

github.com

Frontend (nginx)

ドキュメントを参考に nginx.conf に mirror を設定した．リクエストは proxy_pass で Backend に転送し，さらに複製されたリクエストは proxy_pass で Mirror に転送される．ポイントは複製用の /mirror ロケーションを内部用にしておくことと，転送先の URL に $request_uri を追加する点で，ドキュメントにも記載されている．なお，デフォルトで mirror_request_body が on になっているため body も転送される．

location / {
    mirror /mirror;
    proxy_pass http://backend;
}

location /mirror {
    internal;
    proxy_pass http://mirror$request_uri;
}

動作確認

さっそく / と /ping にリクエストを投げる．

$ curl http://localhost
Hello, backend!

$ curl http://localhost/ping
Pong, backend!

すると，Docker Compose のログに以下のようなアクセスログが出力される．今回 WEBrick のアクセスログは抑止しているため，nginx と Sinatra のアクセスログとなる．そして，期待通りに Backend と Mirror に転送されていることが確認できる．簡単にリクエストを複製できる「ngx_http_mirror_module」は便利だ！

mirror_1    | 172.22.0.4 - - [22/Jul/2019:13:17:44 +0000] "GET / HTTP/1.1" 200 14 0.0073
backend_1   | 172.22.0.4 - - [22/Jul/2019:13:17:44 +0000] "GET / HTTP/1.1" 200 15 0.0074
frontend_1  | 172.22.0.1 - - [22/Jul/2019:13:17:44 +0000] "GET / HTTP/1.1" 200 14 "-" "curl/7.54.0" "-"

backend_1   | 172.22.0.4 - - [22/Jul/2019:13:18:20 +0000] "GET /ping HTTP/1.1" 200 14 0.0071
mirror_1    | 172.22.0.4 - - [22/Jul/2019:13:18:20 +0000] "GET /ping HTTP/1.1" 200 14 0.0118
frontend_1  | 172.22.0.1 - - [22/Jul/2019:13:18:20 +0000] "GET /ping HTTP/1.1" 200 14 "-" "curl/7.54.0" "-"

nginx : resolver 127.0.0.11

検証中にうまくリクエストを Mirror に転送できず，nginx から出力される no resolver defined to resolve mirror というエラーに悩まされていた．実際に出力されていたエラーは以下となる．

frontend_1  | 2019/07/22 13:28:06 [error] 6#6: *3 no resolver defined to resolve mirror, client: 172.22.0.1, server: localhost, request: "GET / HTTP/1.1", subrequest: "/mirror", host: "localhost"
frontend_1  | 2019/07/22 13:28:11 [error] 6#6: *1 no resolver defined to resolve mirror, client: 172.22.0.1, server: localhost, request: "GET /ping HTTP/1.1", subrequest: "/mirror", host: "localhost"

調査したところ，Docker の Embedded DNS に関係していることに気付き，今回は nginx.conf に resolver を指定して解決をした．Embedded DNS の詳細は以下のドキュメントに載っている．正直結構ハマった！

server {
    （中略）
    resolver 127.0.0.11;
    （中略）
}

docs.docker.com

まとめ

nginx でリクエストを複製できるモジュール「ngx_http_mirror_module」を試した．簡易的な「Shadow Proxy」を構築することができる．今回は Docker Compose を使って検証環境を構築して，疎通確認をしたけど，トラフィックを増やした場合に複製による負荷がどの程度なのか，追加で検証してみたいと思う．

投票サービス「DirectPoll」を使ってイベントを盛り上げよう

最近イベント中に「参加者アンケート」を取得する必要があり，普段はお手軽に挙手をして頂くことも多いけど，より臨場感のある演出を検証するため，前から気になっていた投票サービス「DirectPoll」を試してみた．投票するとリアルタイムにグラフが更新されるため，とても盛り上がった．「DirectPoll」は無料で使えて，すごく便利なので，基本的な機能を紹介したいと思う．

directpoll.com

設定画面（"Cockpit" と呼ぶ）

新規投票（"Poll" と呼ぶ）を作る場合，"Cockpit" と呼ばれる設定画面にアクセスする．以下はブログ記事用のサンプルとして「よく使うプログラミング言語は？」という新規投票を作った．タイトルと選択肢を直感的に入力できるし，迷うことはなさそう．さらに右側に「SETTINGS」と「QUESTION TYPE」があり，細かな設定もできるため，後述したいと思う．

投票画面（"Vote" と呼ぶ）

作成した新規投票を公開すると，以下のような "Vote" と呼ばれる投票画面にアクセスできるようになる．

もし設定画面で「multiple choice」を有効化すると，以下のように複数項目に投票できるようになる．

投票結果画面（"Results" と呼ぶ）

実際に10件ほど投票し，"Results" と呼ばれる投票結果画面を表示すると，以下のようにシンプルなグラフで結果を確認することができる．投票するとリアルタイムにグラフが更新されるため，大人数であるほど臨場感が出る．大きなスクリーンに表示するとなお良し！

また設定画面で「Show results in %」を有効化すると，以下のように % 表示をすることもできる．投票数よりも割合を重要視する場合は「Show results in %」を使うと良さそう．

投票結果画面のデザイン（"Look" と呼ぶ）

"Look" と呼ばれる投票結果画面のデザインは以下の計4種類から選ぶことができる．

• Dark background look（デフォルト）
• White background look
• Transparent background, light look
• White background, single colored bars

例えば，2番目の「White background look」を選ぶと，以下のように白基調になる．

Restricted Poll

設定画面で「Restricted Poll」というオプションを有効化すると，プライベート利用を前提とした新規投票を作ることができる．プライベート利用として，投票画面にアクセスする前にトークンを求められるため，事前に管理者からトークンを配布する必要がある．

トークンは設定画面からダウンロードすることができる．以下のような5文字のランダム文字列となり，最初から500個取得できた．

axwqn
e4pw3
rtmpm
xfe69
ukhm7

まとめ

• 投票サービス「DirectPoll」を試してみた
• 「single choice」や「multiple choice」や「Show results in %」など細かな設定もできる
• プライベート利用の場合は「Restricted Poll」を有効化して使う

2019年(1-6月)のプルリクエストを振り返る

2016年から OSS に送ったプルリクエストを振り返る記事を書いている．今までは毎年年末に振り返っていたけど，今年は既にプルリクエストの件数が多いため，2019年(1-6月)の期間で振り返ることにした．過去の振り返りは以下にある．そして，2019年(1-6月)で「計12件」だった．

• 2016年のプルリクエストを振り返る - kakakakakku blog
• 2017年のプルリクエストを振り返る - kakakakakku blog
• 2018年のプルリクエストを振り返る - kakakakakku blog

プルリクエストを振り返るための検索

プルリクエストを振り返るために GitHub の検索条件を使う．created:2019 を使うと2019年に限定できるけど，今回は「2019年(1-6月)」に限定する必要があるため created:2019-01-01..2019-06-30 を使う．

is:pr is:public author:kakakakakku -user:kakakakakku created:2019
is:pr is:public author:kakakakakku -user:kakakakakku created:2019-01-01..2019-06-30

日付の検索条件は，GitHub の公式ドキュメントに「Query for dates」として載っている．今回使った .. 以外にも :> や :>= などもサポートされている．とても便利！

help.github.com

2019/01

docker/docker-bench-security

「Docker Bench for Security」を試していたら README.md に載っていないオプションを発見して，修正した．Docker (Moby) 関連のリポジトリにプルリクエストを出す場合，コミットメッセージに署名を追加する必要があり，git commit --signoff を経験することもできた．

github.com

「Docker Bench for Security」の詳細は以下の記事にまとめてある．

kakakakakku.hatenablog.com

openfaas/workshop

FaaS フレームワークの「OpenFaaS」に興味があり，公式ワークショップを試していたところ，日本語の手順に誤りがあり，修正した．もう1件は手順として意図を読み取れなかった部分を修正したけど，Close となった．

github.com

github.com

「OpenFaaS」の公式ワークショップの詳細は以下の記事にまとめてある．

kakakakakku.hatenablog.com

2019/02

awsdocs/aws-sam-developer-guide

AWS SAM CLI を使って sam init --help を実行したときに，ランタイムの一覧がドキュメントと異なることを発見して，修正した．

github.com

2019/03

awslabs/aws-devops-essential

CI/CD を体験できるワークショップ「aws-devops-essential」を試していたところ，Markdown をより読みやすく改善できる部分が多くあり，修正した．

github.com

2019/05

microservices-demo/microservices-demo

マイクロサービスの学習に使えるサンプルアプリケーション「Sock Shop」を試していたところ，Fluentd + Elasticsearch + Kibana を使ったログ可視化の機能が動かず，Docker Compose に指定されているイメージ名に問題があることを特定した．本来なら Elasticsearch 7 など，最新バージョンを使うべきだけど，アプリケーションの実装と合わない部分があり，ワークアラウンドとして Elasticsearch 5 + Kibana 5 にして，動くようになった．

github.com

「Sock Shop」の詳細は以下の記事にまとめてある．

kakakakakku.hatenablog.com

jmespath/jp

「JMESPath」の仕様を学ぶために JMESPath CLI : jp を試そうとしたら，README.md に書いてある brew の手順に誤りがあることを発見して，修正した．早めに Merge してもらえると良いんだけど．

github.com

「JMESPath」の詳細は以下の記事にまとめてある．

kakakakakku.hatenablog.com

awslabs/aws-devops-essential

3月に続き「aws-devops-essential」を試していたところ，手順に不明確な部分があったり，AWS Lambda のランタイムとして指定されている Node.js 6.10 が EOL になったりして，うまく動くように修正した．ワークショップを今後試す人たちのためにも継続的にメンテナンスをしていく．Merge してもらえると良いなぁー！

github.com

github.com

github.com

mackerelio/documents

mkr コマンドの新機能 mkr wrap を試していたところ，ドキュメントに typo を発見して，修正した．Mackerel 関連のドキュメントは今年3月頃に OSS 化されている．今後も積極的にプルリクエストを送りたいと思う．

github.com

mkr wrap の詳細は以下の記事にまとめてある．

kakakakakku.hatenablog.com

mikegcoleman/todo

Amazon Lightsail Workshop を試していたところ，サンプルアプリケーションで TODO を編集するとエラーになった．MongoDB 関連の実装に問題があることを特定して，修正した．

github.com

まとめ

2019年(1-6月)で「計12件」のプルリクエストを送ることができた．2019年(7-12月)も頑張る！

「DevLOVE X」に参加してスピーカーの情熱を感じた

6/23,24 に開催された「DevLOVE X」に参加した．少し遅れてしまったけど，印象に残っているセッションを中心に紹介したいと思う．どのセッションもスピーカーの情熱を感じた．DevLOVE X では，久し振りに会う人がいたり，ブログメンタリング卒業生に会えたり，Twitter でフォローしている人に会えたり，様々な出会いもあり楽しかった！

devlove.wixsite.com

僕自身は「Day.2 4-D」に発表し，既に記事を書いているので，合わせて見てもらえればと！発表でも「勉強会参加レポート記事の大切さ」を説明している．勉強会に参加したらレポート記事を書こう！

kakakakakku.hatenablog.com

Day.1 1-C : 「嫌われない」を諦めない @ykmc09

• アジャイル推進組織の仕事領域
  • トレーニング
  • チームの支援
  • 社内アジャイルコミュニティの構築
• 大切なのは「背中を押すこと」
  • リーンとアジャイルを好きになってもらいたい
• 「勝手に広まっていきそうか？」が重要
• 「マーケティングファネル」を参考に「Lean/Agile Promoting Funnel」を作った
• 手段に固執せず，本質的な課題を探す
  • 「スクラムを導入するべき」とは絶対に言わない
• 最初の成功にこだわる
• Don't just Do Agile, Be Agile

DevLOVE X 最初のセッションは，前職でのチームメイトでもあった @ykmc09 の応援に行った．事前に発表資料の相互レビューをしていたため，プレゼンテーションを楽しめた．名言も多く出ていたけど，特に「最初の成功にこだわる」という話が良かった．「失敗から学ぶ」ことも重要だけど，それでも失敗より成功が良いし，最初の小さな成功が次の一歩に繋がる．そして「誰が言うか」という話もあり，今までは「信頼残高のある人が言うと良い」という前向きな理解をしていたけど，「あの人が言うから嫌い」という後ろ向きな側面もあることに気付き，これは個人的に盲点だった．何かを推進するときに気を付けたいと思う．

ykmc09.hateblo.jp

Day.1 3-B : エンジニア、エンジニアリングマネージャーとして成長するために必要なこととは？ @tsuyok

• 成長とは何か？
• 個人の成長に対するアプローチはあまり情報がない
• 「学び」のベース
  • コルブの経験学習モデル
• 「エンジニア」の学び
  • 「学びの根源」が様々ある
  • 小さな行動を習慣化する
  • 自分自身を振り返る
    • KPT + 感じたこと
• 「エンジニアリングマネージャ」の学び
  • オーセンティックでいる（自分らしさを貫くこと）
    • ジョハリの窓
  • アンラーニングする

僕自身とても興味のある「成長とは何か？」がテーマだったので参加してみた．「コルブの経験学習モデル」や「ジョハリの窓」など，今まで学んできたことが多く出てきて，理解を整理することができた．「小さな行動を習慣化する」という話は重要だし，僕としては書籍「小さな習慣」をオススメしたい．また 1 on 1 活動に取り組まれているという話もあり，僕のブログメンタリングと似ている部分もあり，共感できた．

• ストレッチ + リフレクション + エンジョイメント /「経験学習」入門を読んだ - kakakakakku blog
• 小さすぎて失敗すらできないステップを毎日繰り返そう /「小さな習慣」を読んだ - kakakakakku blog
• アウトプット駆動学習を習慣化する - kakakakakku blog

途中に「自分自身を毎週振り返っている人はいますか？」という話があり，僕は毎週日曜日の振り返りをもう4年以上続けているので，振り返りもオススメしたい．発表資料を見直して，もっと学んでみたいと思う．

www.tsuyok.work

Day.1 7-A : モブプロの聖地 Hunter Industries で学んだこと @kawaguti

• アギレルゴアジャイル研修
  • アギレルゴ アジャイル研修
• Enterprise Agile と Agile Enterprise
  • Enterprise Agile or Agile Enterprise? - High Performance Redefined with Michael K Sahota
• Culture Bubble
  • 新しい文化の境界面はシャボンの泡のように壊れやすい
  • リーダーとアダプターが重要
• 「場所」=「モブ」=「プロダクト」
• 人事異動などのメールを読むこともモブで行う
• マルチモブ

大好きな書籍「Fearless Change」の翻訳者でもある @kawaguti さんが，実際に Hunter Industries に行かれた話をするということで，絶対に聞きに行こうと思っていた．特に「モブプログラミングは場所である」という話は刺さった．現場に行かれたからこそ気付けたことなのかもしれない．マシントラブルが起きたときに別の場所に行き，その場所にいるチームのタスクに着手したという話も「モブプログラミングは場所である」からこそだと思うし，噂は聞いたことがあったけど，本当だと知れて興奮した．また Enterprise Agile と Agile Enterprise の話なども興味があり，話を聞けて良かった．

kawaguti.hateblo.jp

Day.2 7-E : テスト駆動開発ライブ @t_wada

• TDD
  • Red → Green → Refactor（を繰り返す）
• FizzBuzz 問題
• テスト → 仮実装 → 三角測量 → 実装

今まで @t_wada さんのライブコーディングを見る機会がなく，今回とても楽しみにしていた．内容としては FizzBuzz 問題をテスト駆動開発（実況解説付き）で進めていく．Eclipse を使って Java + JUnit で実装していくけど，ステップバイステップに進むし，ステップごとの実況解説で思考がうまく言語化されていて，わかりやすかった．何よりも，見ていてモチベーションが高まった．テストコードのメソッド名は日本語で書いて良いことや，テストを通すための return "1"; にも意味があることなど，実践的な学びもあった．前に Fukabori.fm で聞いた話を思い出したりもした．より良くするために，あえて1点フィードバックを送るなら，実況解説が早口過ぎて，聞き取れない部分も多かった．時間不足である制約は理解した上で，もう少し工夫できる余地もありそう．

fukabori.fm

Speaker Deck に発表資料がなく，Togetter を載せておく！

togetter.com

運営フィードバック

DevLOVE X 運営メンバーの皆さんがいたからこそ素晴らしいイベントになったと思う．本当にお疲れさまでした！今後のために個人的に感じた点をフィードバックしておこうと思う．参考まで！

• （当日にページが分割されたけど）スピーカー一覧ページの表示が重すぎた
• 有料イベントだし，スポンサーも入っていたので，一般参加者の皆さんにランチの提供かコーヒーの提供があると良かった
• 計5部屋のサイズがバラバラで，特に人気のセッションだと座席数が不足していた

まとめ

• 「DevLOVE X」に参加した
• どのセッションもクオリティが高く，スピーカーの情熱を感じた
• また今度 DevLOVE コミュニティに参加するぞー！
  • DevLOVE | Doorkeeper