決まった答えを知りたい、あると信じたい
その裏には、労せず安心したいという弱さがある
何事も答えを探し求め続ける中にこそ真理がある
修証一如（修証一等）という考えに近い気がする
開発プロセス然り。しっかり迷い悩み楽しみたい
認定スクラムプロダクトオーナー（CSPO）を取得しました
オンライン・認定スクラムプロダクトオーナー研修 by James Coplien
講師：ジム・コプリエン - James O. Coplien(Jim Coplien)
日時：2021年03/16（火）〜03/19（金）
実は6年前に認定スクラムマスター（CSM）の研修を受講したのですが、その時もジム・コプリエン氏（以降、Copeと呼ばせてもらいます）の研修でした。
その時の記事はコチラ（↓）です。
これまで書籍やコミュニティや研修などで得た知識を自分なりに咀嚼して考え、スクラムの考えやエッセンスを現場に取り入れてきたつもりですが、最近あらためてモヤモヤすることが多くて、（たぶん）原点回帰するきっかけを無意識に探していたような気がします。そんな時、たまたまCopeのCSPO研修を見つけたので勝手に運命を感じて受講することにしました。
研修形式はコロナ渦ということもあり、オンライン形式（全4日間）でした。オンサイト形式であれば、おそらく丸２日間の研修ボリュームだと思いますが、オンライン形式の研修を丸１日間ぶっ通しで実施するのは、講師も受講生にもかなりのストレスを伴うと思いますので、半日（14～18時）x４日間というスケジュールは妥当に思えました。
全研修日程を終えて感じたのは、新たな知識を得た、というよりは、ぼんやりと分かった気になっていた基本的な知識や理解を再確認する機会になった、ということでした。
この研修を受講するにあたりスクラムガイド（日本語版）を事前に読んでおくように言われていたので、しっかり読み込んで研修に臨みました。そのうえで、疑問点を色々と講師に質問してみたのですが、スクラムガイドに書いてあることは尊重はすれども、それに固執し過ぎたり忠実であろうとし過ぎると、決まった答えのみを求め、型の中に納まってしまい、逆に成功から遠ざかってしまう、それは本意でなないという回答を得ました。型はあれど、決まった答えはない（※良く言う "It depends" というやつ）という当たり前な事を、改めて考えさせられたように思います。（若干、煙に巻かれたような気もしましたし、賛否はあると思います）
では初心者は何から手を付けたら良いのか？よく言われている「The 3-5-3 of Scrum」を忠実に守るべきなのか？という問いに対しては、答えは成であり否でもあるという。もやはこれは禅だな、と思ったいたところCopeから「十牛図」なるものを薦められた。
【『十牛図（じゅうぎゅうず）』とは、逃げ出した牛を探し求める牧人の様子を、段階的に描いた十枚の絵で、禅を学ぶための入門書として北宋時代に成立したもの】
だそうです。そのまんま『禅』じゃないか、、、そうか真のスクラムは禅なんだな。考えてみれば、別にスクラムに限らず決まった答えがない殆ど全てのことに通じる話でもあります。（いぜん「スクラム道」というのがあったのも何となく納得。もはや開発プロセスではなく道（Tao）なんです）
【型はある。その意味について自分で考え、試しカイゼンし続けること。型を意識すれども、それに縛られて真の目的を見失ってはならない】
と頭の中で整理しました。
普通に考えて、ゆるふわな覚悟で出来ることではないので、つまるところ、そういう覚悟を持ってこれから（も？）腹括って生きろよ、ということなんだと思えました。
最近足りてなかったものは確かにこれだったのかもしれない。
【My New New journey has begun. I'll do my best.】
気付けは、新たな覚悟が必要な旅が始まってました（サボり症なので丁度よかった）
最後に、講師の Cope と Kawaguchi さん。そして、最終日に翌朝４時までエンドレスな打ち上げにお付き合いいただいた同期の皆様、どうもありがとうございました。
Thank you for 4 days, Cope! It was precious time for me.
スクラムとウォーターフォールに纏わるメモ
スクラムとウォーターフォールに纏わる呼び方がいくつかある中で、下記の言葉の定義を誤解していたので忘備録として書き残しておく。
- ウォータースクラム
- スクラマーフォール
- ウォータースクラムフォール（ウォーター・スクラム・フォール）
ウォータースクラム ／ スクラマーフォール
スクラムに「ウォーターフォール」スタイルの開発を重ねたもの。 たとえば、分析スプリント、設計スプリント、コーディングスプリント、テスティングスプリントのように進んでいく。 この呼び方は書籍『エッセンシャル スクラム』P.34, 377で紹介されている。
著者であるケネス・S．ラビン（Kenneth Rubin）はスプリントの考え方におけるよくある間違い（アンチパターン）として下記のように述べている。
「
スプリントの考え方でよく間違えられるのは、各スプリントで一種類の作業だけに集中してしまうことだ。
：
（中略）
：
スクラムでは、工程に対して一度に作業をすることはない。フィーチャーに対して作業するのだ。したがって、スプリントが終わるときには、
価値のあるプロダクトインクリメント（プロダクトのフィーチャーの一部）を作り出している。
」
ウォータースクラムフォール（ウォーター・スクラム・フォール）
InfoQで10年ほど前に紹介されている呼び方で、原文では「Water-Scrum-Fall」と記載されている。
下記のように説明されており、
- Water – 多くの場合はITとビジネスの間に行われる、前倒しのプロジェクト計画プロセスの定義
- Scrum – 「Water」段階で最初に定められた計画全体を達成するための反復・進化型のアプローチ
- Fall – 組織方針やインフラの制約によって定められる、制御された、頻繁でない本番リリースサイクル
こちらはハイブリッドアジャイル、エンタープライズアジャイルとかいう文脈で語られるものに近い。
（下記のようなイメージ）
IPAの事例紹介
https://www.ipa.go.jp/files/000049403.pdf
Agile Japan 2016（セッションB-2）の記事
https://www.manaslink.com/articles/15328
上記の例は下記の本の関係者が紹介してるっぽい。
エンタープライズアジャイルについても明確な定義はなく（エンタープライズアジャイル勉強会）の書籍
によると
「小さなチーム単位で浸透しつつあるアジャイルによるシステム開発を、より大きな組織やシステム向けにスケールアップしたもの」
ということらしい。
また、同じエンタープライズアジャイル勉強会の実行委員であるGraat社の鈴木雄介氏の論文
エンタープライズ領域のアジャイル開発の課題─アジャイル開発がもたらす意思決定プロセスの変化─
では
「ウォーターフォール開発プロセスを主に実施している組織において実施されるアジャイル開発プロセスのこと」
と定義されおり、定義が揺れているので、コミュニケーションする際は（あとで事故らないよう）注意が必要ですね。 （「アジャイル」や「DevOps」もですけど、、、）
*[本]人月の神話
昨年の12月はAWS re:Invent 2019へ向かう途中でマウンテンビューのコンピュータ歴史博物館へ立ち寄った。そこに、この本の原著（と思われる本）が展示されていた。 最初の刊行は1975年だから、きっとその当時のものだと思う。
初版から既に45年が経っているにも関わらず、この本は今でも尚、大規模開発プロジェクトのソフトウェア工学の古典として読み継がれている名著と言われている。本の横に書かれているのは、あの有名な『ブルックスの法則』で
「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ(Adding manpower to a late software project makes it later.)」
というやつです。最近たまたま、この本を思い出すきっかけがあったのであらためて手に取ってみた。
まず、本の表示の獣を何故かずっと熊と思い込んでいたのだが、実はメガテリウム（オオナマケモノ）という新生代（約5百万～1万年前）の生物だった。確かに熊と違って尻尾が太い。全長6～8mで体重3tにもなるそうで熊よりよっぽどデカい。そして、第１章「タールの沼」の直前に下記の絵が掲載されており、左側にサーベルタイガーも描かれており確かに古代（新生代）を前提とした絵であることが分かる。
この本の中で、著者のブルックスは、大規模なソフトウェア開発をもがけばもがくほど絡みつくタールの沼に例えている。
そして著者はソフトウェア開発の複雑性を次のように区別して考えている。（第16章）
●「本質的な複雑性」
ソフトウェアの性質に固有な困難のこと
【本質：データセットやデータ項目間の関係、アルゴリズムや機能呼出などが組み合わさったコンセプトで構成されたものであり、同じ概念構造が多くの異なる表現で表されるという点で抽象的である。にもかかわらず、非常に正確で十分に詳細であるということ】
【困難：概念構造体の仕様作成とデザインおよびテスト】
●「偶有的（副次的あるいは不随の）な複雑性」
目下の生産性にはつきまとうが本来備わっているものではない困難のこと
【例：実装（言語、ランタイム、ツール、プログラミング手法）にかかわるもの】
このように区別したうえで、ソフトウェア技術の進歩（例：高水準言語、オブジェクト指向プログラミングなど）は、主に偶有的な複雑性を解決して生産性を向上してきたが本質的な複雑性を攻略できた訳ではないと主張している。（確かにそうかも）
つまり、本質的な複雑さは、依然として攻略困難な課題として存在し続けており、それこそがソフトウェア構築は（当時と比べて飛躍的にテクノロジーが進歩した今でもなお）いつでも困難であり続けており「銀の弾丸はない」ということに繋がっているように思う。
この本は、最初の刊行では15章までだったけど、この20周年記念贈訂版では16～19章が付け加えられており、当時から20年の時の経過をふりかえっての後日譚が多く記載されている。
その中で、順次モデルまたはウォーターフォールを改良したウィンストン・ロイスについても触れているのが興味深い。それにも関わらず、未だにロイスは改良前（フィードバックが許されない古典的な）のウォーターフォールの父として語られているのを耳にすることがあるので少々気の非常に毒に思う。聞くたびに「そうじゃないんだよ」と訂正しているけど。あと、米国防総省の黒歴史DOD-STD-2167のことも書いてあった。日本にも強い影響を与えた仕様ですね（今や黒歴史？）
漸増的（インクリメンタル）構築モデルの利点を述べ、常にシステムが動く状態にしておくことの重要性についても触れているのは興味深いし、（当時の）マイクロソフトの「毎晩構築」アプローチは、継続的インテグレーションとデイリービルドの考えを地で行ってる感じがした。
『人間が全て（そう、だいたいのところは）』の節で言及している「成功のためには、プロジェクトに携わる人々の質、およびその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因であると考えている」という点にも一考の余地があると思う。同じページでデマルコの「ピープルウェア：生産的なプロジェクトとチーム」も引用されていた。両翼からのアプローチは大事ですよね。
経済学者E.F.シューマッハーの「小さいことは美しい：あたかも人間を重視するかのような経済学の研究」を引用して、チームに権限を委譲して自由を与え、結果の責任を持たせることで準企業体を目指す企業がいる、など他にも興味深い話は多々あったけど、キリがないのでこの辺で。
本書の最後の節に「ソフトウェアエンジニアリングというタールの沼は、これから当分の間厄介なままだろう。人類が、手の届く範囲の、あるいはギリギリで届かないところにあるシステムを、ずっと試していくことは容易に想像がつく。ソフトウェアシステムは、人間の作り出したもののうちで最も複雑なものだろう。」と書かれている。これは増訂版が出版された1996年に書かれたもので、その時点から更に25年が経過している。
ソフトウェアエンジニアリングが今尚タールの沼のままなのかどうかはさておき、ソフトウェアの本質的な複雑性はさほど変わっていないと思う。ので、考えてみれば大変な（だが面白い）仕事を生業にしたもんだな、とつくづく感じる。（勿論いい意味で、）
ArgoCDを使用したGitOpsのデモ
今年は有難いことにk8sをお仕事で使用する機会に恵まれました。その中で、アプリケーションやインフラのデリバリをGitOpsで実現する手段としてArgoCDを使用しました。
イメージはだいたいこんな感じです。
ArgoCDとググれば公式サイトをはじめ結構たくさんの情報がヒットします。なので、今更まとめ記事を書く必要もなさそうです。ハマりどころをスキップしてサッと試せるサンプルがあれば十分かなと思ったので、AWS EKSでk8sクラスタを作成してArgoCDでGitOpsを試すサンプルを作成してGitHubに置きました。
とりあえず適当なアプリでArgoCDがどんなものか触ってみたい人は試してみてください。
※補足
k8sサンプルアプリはいつものやつ（Sock Shop）を使用してますが、EKS:v1.18だとAPIバージョンなど廃止された記述があってうまくapplyできないのでマニフェストをForkして少しだけ修正してあります。
AWS 認定DevOps エンジニア – プロフェッショナル（DOP）を取得しました
AWS 認定DevOps エンジニア – プロフェッショナル を取得（11/29）しました。
スコアは844でした。試験対策や所感などをメモがてら書き残しておきます。
AWS認定について
詳細は以下の公式ページに記載されています。
ざっくり言うとAWS（Amazon）が公式に認定するベンダー資格です。大きくは２つのレベル（アソシエイトとプロフェッショナル）に分かれています。
- 基礎コース
- アソシエイト
- プロフェッショナル
- ソリューションアーキテクト（SAP）
- DevOps エンジニア（DOP） ←★今回取得した認定
また、プロフェッショナルとは別に専門知識というカテゴリも用意されており、以前は英語のみ受験が可能だったのですが、現在は全て日本語での受験が可能になっているようです。（なんかどんどん増えますねぇ、、、今や全部取得すると12冠なんですって）
- 専門知識（スペシャリティ）
- ビッグデータ（BDS）（2020年7月1日に廃止。後継はデータアナリティクス）
- 高度なネットワーク（ANS）
- セキュリティ（SCS）
- 機械学習（MLS）
- Alexaスキルビルダー（AXS）
- データアナリティクス（DAS） （New：2020年）
- データベース（DBS） （New：2020年）
DOP試験対策について
試験対策ですが先達の方々からのアドバイスによるとUdemyの教材が良いと聞いていたのでセール期間にいくつか購入していたのですがいずれも英語の教材でした。英語が嫌い過ぎてどーにもやる気が出ず2週間前くらいまで『無』の境地で諦めモードでした。が、なんと試験2週間くらい前になって、いい感じの日本語の教材を見つけました！
-
AWS認定 DevOpsエンジニア – プロフェッショナル (DOP-C01) 模擬試験 (2020年試験対応版) | Udemy（※有償：¥3000 yen → ¥1200 yen）
- 日本語の模擬試験問題集です。しかも非常にリーズナブルな価格で、なんとAWS公式の模擬試験よりも安いにもかかわらず、DOP本番試験と同じ問題数（75問）の模擬試験が4回分（※年内には5回分になるらしい）も掲載されています。さらにセール期間に買えば¥1200 yenです。試験問題や回答選択肢の日本語が怪しい点も忠実に（？）再現されています。試験2週間前くらいから慌ててひたすら過去問を解いて、間違えた問題を中心に解説を読みました。解説だけで納得できないものは解説に記載されているAWS公式ドキュメントにも軽く目を通しました。試験対策は、ほぼこれだけ
他にやったことは、公式のサンプル問題を解いたくらいですね。
-
公式のサンプル問題（※無料）
- AWSが公開しているサンプル問題集です。10問しかありませんが、回答と解説がちゃんと記載されているので、こちらも試験前に1度は解いておくのが良いと思います。
現時点でDOP日本語の教材は非常に少ないので、他には下記くらいだと思うのですが、今回はいずれも利用しませんでした。（そう考えると対策のコスパ良かったな）
- AWS WEB問題集で学習しよう（※有償：¥5480 yen 90日★ダイヤモンドプラン）
- オリジナルのAWS認定試験対策問題集を有償で公開しています。前回SAP試験の際は活用しましたが、DOPの試験問題はまだそこまで充実していない印象を受けたので今回は利用しませんでした。
- 模擬試験（※有償：¥4000 yen）
- AWS認定の模擬試験をオンラインで受けることができます。本試験と同じような画面レイアウト（時間制限なども本番に近い）で体験できるので、一度はやっておくと良いと思います。が、今回はUdemyの過去問だけで十分だとな気がしたので今回は利用しませんでした。
試験会場は行きつけの歌舞伎座テストセンターにしたかったのですが、日程が合わず断念。自宅でAWS認定試験が受験できるようになったので、自宅で受験しようとも思ったのですがバウチャーが利用できないのでそれも断念。最終的に、昔SAA受験した時に利用した（PSI試験で嫌な思い出のある）田町テストセンターで受験することになったので会場（というよりは試験中の異常なまでの監視）に不安があったのですが、前回のPSI試験の時とは違って、入室前に身分証明書などを提示してカメラで顔写真を撮った際の事前チェックをしてからは、Webカメラでの監視や試験官とのチャットでのコミュニケーションなども一切なく試験に集中して淡々と進めることができました。今回はピアソンVUE試験だったからかな？これなら歌舞伎座じゃなくても良いかもって思いました。
お疲れさまでした。
[2020/05/15(金)］アジャイル・ディスカッション！！オンライン へ参加してきました
新型コロナウイルスによる自粛生活が始まってから集合形式の勉強会は殆どがキャンセルされ、久しく社外勉強会に参加していませでしたが、最近ではオンライン形式の勉強会も増えてきました。これまで何度が参加させてもらったアジャイル・ディスカッション勉強会も遂にオンラインで開催されるということで参加してきました。
そもそもオンラインで大人数のディスカッションなんてできるのか？など一体どんな雰囲気になるのか想像もつきませんでしたが、うまくツールを活用してオンラインのディスカッションを実現していました。
利用したツール
オンライン勉強会では以下のツールを活用しました。
Discord
テキスト・音声どちらも使えるチャットツールです。
Mural
特に付箋に特化したオンラインホワイトボードです。
オンラインディスカッションの進め方
オンライン勉強会は、OST（オープン･スペース・テクノロジー）形式で進められました。OSTでは、その場に居る人達が議論したい内容を持ち寄って、自分達でディスカッションしたいテーマを決定します。1つのOSTの中でテーマは複数あり、テーマごとに同時並行でディスカッションを進めます。どのテーマのディスカッションに参加するかは自由に選択できます。具体的な進め方は、実際にディスカッションのテーマ出しをする前に、Mural上に用意されたアウトラインのスライドに沿ってDiscordボイスチャットで説明してくれました。運営の方、事前準備どうもありがとうございました。
Discordには、ディスカッション用の部屋が複数用意されていました。参加者が出し合ったディスカッションテーマを部屋ごとにひとつ割り当てて、前半／後半の2つのタイムボックスでそれぞれディスカッションしました。
ディスカッションへの参加度合いは人それぞれ自由で、積極的に話すファシリ役から聞き役まで様々で、ディスカッション前の説明ではOSTへ参加する役割について次のように説明されました。
3つの役割
- Bird（さえずる鳥🐦）：トピックを決めて議論をファシリテートする人
- Bee（群がる蜂
）：トピックに群がり議論を前に進め、建設的な提案をする人 - Butterfly（飛び回る蝶
）：複数のトピックを回りながら、他家受粉を促す人
私はテレワークをもっとカイゼンしたかったので「オンラインでのふりかえり方法」や「オンラインでの困り事」のディスカッションに参加させてもらいました。テレワークが始まって以来、社外の人とSNSなどで情報交換したことはありましたが、口頭で議論するのは初めてだったので良い情報交換ができました。
まとめ
Discordを初めて使用したのですが、多人数（30人弱）で利用しても遅延を感じることもなく全体をとおして通話品質が良いなという印象でした。初めての利用でしたが、ワンクリックでの部屋移動など、操作も簡単でした。オンライン勉強会でも結構やれるな、と思った反面、話し手（※特にメインスピーカ）の顔が見えないので、音声以外の情報（表情や仕草など）から雰囲気や感情を感じ取れないのは辛いな、とも思いました。今度Discordのカメラ機能を使ってカイゼンできないか試してみたいところです。
総合的にみて オンライン勉強会いいな！ という感想を持ちました。今まで私が参加してきた対面形式の勉強会は自宅から遠いことが多かったので、終電や長時間の移動を気にせず参加できるオンライン勉強会は神です。今までのような対面形式の勉強会と比べて不便はありますが、メリットも大きいと感じました。オンライン勉強会が定着して、その不便もカイゼンされていけば、いつでもどこからでも世界中の勉強会に参加できますね。今後のオンライン勉強会の進化に大いに期待したいところです。
