機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

LeSS Study 読書会でプレゼンターやってきました(第8章 プロダクトオーナー)

コロナ前オンサイトで開催されていたLeSS Study 読書会が今年2月からオンラインで再開されました。私は4月の事例講演のイベントから毎回参加させてもらっています。

 

less-study.doorkeeper.jp

 

これまでオンライン読書会は未体験だったのですが、進め方としては自分が担当する章やセクションを読んで、本の内容をスライドにまとめます。イベント当日はDiscordというオンラインチャットツールを使用して、スライドを画面共有しながら参加者同士で意見を交換します。自分が本を読んだときに感じた疑問点、感じたことなどをスライドにコメントとして記載しておくと、参加者や翻訳を担当したイベント主催者の方々からいろいろとコメントやフィードバックがもらえるので学びが深まります。時々(というかかなりの頻度で)脱線して色々な話題で議論が(いい意味で)盛り上がったりすることもあって、LeSS以外の様々な知見を深めることもできます。

 

直近に開催された と8/27[金]のイベントではプレゼンターを務めさせてもらいました。その時に使用したスライドをSpeakerDeckにアップしたのでメモがてら、こちらに記載しておこうと思います。

 

speakerdeck.com

 

今後も継続して参加して理解を深めていきたいと思います。オンライン開催ということで気軽に参加できるので、興味のある方は参加してみてはいかがでしょうか?(※本がなくても参加OKらしいですw)

 

※参考:

https://less.works/

less.works

DockerHubの自動ビルドが有償化されたようです(2021年6月18日から)

ひさびさにGithubのDockerfileを更新したがDockerhubでビルドが開始されない、、、

f:id:orinbou:20210804204240p:plain

と思ったら、2021年6月18日から無料利用枠でのAutobuildを廃止したようです。

www.docker.com

上記ブログにも記載されていますが、悪意のある人物の標的になっているため無料利用枠でのAutobuildの廃止を発表したんだとか。悲しい、、、😢

 

既にマニュアル(英語&日本語)にもしっかりと明記されてますね。

Set up Automated Builds | Docker Documentation (英語)

自動ビルドの設定 | Docker ドキュメント

 

非常に残念ではありますが、Dockerhubでコンテナイメージを自動ビルドしたい人は有償プラン(Pro or Team)にアップグレードするしかないようです。プランは下記のとおりです。

Docker Pricing & Subscriptions for Individuals & Teams

 

支払いは月払い、年払いのどちらかを選択します。いつまで有償プランを利用するか分からなかったので、とりあえず割高な月払いでアプグレしましたが、ずっと利用するつもりなら年払いの方がお得です。利用頻度に応じた支払い方法を選択すると良いと思います。

決まった答えなんてない

決まった答えを知りたい、あると信じたい

その裏には、労せず安心したいという弱さがある

何事も答えを探し求め続ける中にこそ真理がある

修証一如(修証一等)という考えに近い気がする

開発プロセス然り。しっかり迷い悩み楽しみたい

認定スクラムプロダクトオーナー(CSPO)を取得しました

オンライン・認定スクラムプロダクトオーナー研修 by James Coplien

 を受講してCSPOを取得しました。

f:id:orinbou:20210328142622p:plain

CSPO

講師:ジム・コプリエン - James O. Coplien(Jim Coplien)

日時:2021年03/16(火)〜03/19(金)

 

実は6年前に認定スクラムマスター(CSM)の研修を受講したのですが、その時もジム・コプリエン氏(以降、Copeと呼ばせてもらいます)の研修でした。

 

その時の記事はコチラ(↓)です。

 

これまで書籍やコミュニティや研修などで得た知識を自分なりに咀嚼して考え、スクラムの考えやエッセンスを現場に取り入れてきたつもりですが、最近あらためてモヤモヤすることが多くて、(たぶん)原点回帰するきっかけを無意識に探していたような気がします。そんな時、たまたまCopeのCSPO研修を見つけたので勝手に運命を感じて受講することにしました。

 

研修形式はコロナ渦ということもあり、オンライン形式(全4日間)でした。オンサイト形式であれば、おそらく丸2日間の研修ボリュームだと思いますが、オンライン形式の研修を丸1日間ぶっ通しで実施するのは、講師も受講生にもかなりのストレスを伴うと思いますので、半日(14~18時)x4日間というスケジュールは妥当に思えました。

全研修日程を終えて感じたのは、新たな知識を得た、というよりは、ぼんやりと分かった気になっていた基本的な知識や理解を再確認する機会になった、ということでした。

 

この研修を受講するにあたりスクラムガイド(日本語版)を事前に読んでおくように言われていたので、しっかり読み込んで研修に臨みました。そのうえで、疑問点を色々と講師に質問してみたのですが、スクラムガイドに書いてあることは尊重はすれども、それに固執し過ぎたり忠実であろうとし過ぎると、決まった答えのみを求め、型の中に納まってしまい、逆に成功から遠ざかってしまう、それは本意でなないという回答を得ました。型はあれど、決まった答えはない(※良く言う "It depends" というやつ)という当たり前な事を、改めて考えさせられたように思います。(若干、煙に巻かれたような気もしましたし、賛否はあると思います)

 

では初心者は何から手を付けたら良いのか?よく言われている「The 3-5-3 of Scrum」を忠実に守るべきなのか?という問いに対しては、答えは成であり否でもあるという。もやはこれは禅だな、と思ったいたところCopeから「十牛図」なるものを薦められた。

 

【『十牛図(じゅうぎゅうず)』とは、逃げ出した牛を探し求める牧人の様子を、段階的に描いた十枚の絵で、禅を学ぶための入門書として北宋時代に成立したもの】

 

だそうです。そのまんま『禅』じゃないか、、、そうか真のスクラムは禅なんだな。考えてみれば、別にスクラムに限らず決まった答えがない殆ど全てのことに通じる話でもあります。(いぜん「スクラム道」というのがあったのも何となく納得。もはや開発プロセスではなく道(Tao)なんです)

 

【型はある。その意味について自分で考え、試しカイゼンし続けること。型を意識すれども、それに縛られて真の目的を見失ってはならない】

 

と頭の中で整理しました。

 

普通に考えて、ゆるふわな覚悟で出来ることではないので、つまるところ、そういう覚悟を持ってこれから(も?)腹括って生きろよ、ということなんだと思えました。

 

最近足りてなかったものは確かにこれだったのかもしれない。

 

My New New journey has begun. I'll do my best.

 

気付けは、新たな覚悟が必要な旅が始まってました(サボり症なので丁度よかった)

 

最後に、講師の Cope と Kawaguchi さん。そして、最終日に翌朝4時までエンドレスな打ち上げにお付き合いいただいた同期の皆様、どうもありがとうございました。

 

Thank you for 4 days, Cope! It was precious time for me.

f:id:orinbou:20210328160319p:plain

Thus Spake Master Cope

スクラムとウォーターフォールに纏わるメモ

スクラムとウォーターフォールに纏わる呼び方がいくつかある中で、下記の言葉の定義を誤解していたので忘備録として書き残しておく。

  1. ウォータースクラム
  2. スクラマーフォール
  3. ウォータースクラムフォール(ウォーター・スクラム・フォール)

ウォータースクラム / スクラマーフォール

スクラムに「ウォーターフォール」スタイルの開発を重ねたもの。 たとえば、分析スプリント、設計スプリント、コーディングスプリント、テスティングスプリントのように進んでいく。 この呼び方は書籍『エッセンシャル スクラム』P.34, 377で紹介されている。

books.rakuten.co.jp

著者であるケネス・S.ラビン(Kenneth Rubin)はスプリントの考え方におけるよくある間違い(アンチパターン)として下記のように述べている。

「 スプリントの考え方でよく間違えられるのは、各スプリントで一種類の作業だけに集中してしまうことだ。

(中略)

スクラムでは、工程に対して一度に作業をすることはない。フィーチャーに対して作業するのだ。したがって、スプリントが終わるときには、 価値のあるプロダクトインクリメント(プロダクトのフィーチャーの一部)を作り出している。 」

ウォータースクラムフォール(ウォーター・スクラム・フォール)

InfoQで10年ほど前に紹介されている呼び方で、原文では「Water-Scrum-Fall」と記載されている。

www.infoq.com

下記のように説明されており、

  • Water – 多くの場合はITとビジネスの間に行われる、前倒しのプロジェクト計画プロセスの定義
  • Scrum – 「Water」段階で最初に定められた計画全体を達成するための反復・進化型のアプローチ
  • Fall – 組織方針やインフラの制約によって定められる、制御された、頻繁でない本番リリースサイクル

こちらはハイブリッドアジャイル、エンタープライズアジャイルとかいう文脈で語られるものに近い。
(下記のようなイメージ)

f:id:orinbou:20210220165830p:plain

IPAの事例紹介

https://www.ipa.go.jp/files/000049403.pdf

Agile Japan 2016(セッションB-2)の記事

https://www.manaslink.com/articles/15328

上記の例は下記の本の関係者が紹介してるっぽい。

books.rakuten.co.jp

エンタープライズアジャイルについても明確な定義はなく(エンタープライズアジャイル勉強会)の書籍

books.rakuten.co.jp

によると

「小さなチーム単位で浸透しつつあるアジャイルによるシステム開発を、より大きな組織やシステム向けにスケールアップしたもの」

ということらしい。

また、同じエンタープライズアジャイル勉強会の実行委員であるGraat社鈴木雄介氏の論文

エンタープライズ領域のアジャイル開発の課題─アジャイル開発がもたらす意思決定プロセスの変化─

では

「ウォーターフォール開発プロセスを主に実施している組織において実施されるアジャイル開発プロセスのこと」

と定義されおり、定義が揺れているので、コミュニケーションする際は(あとで事故らないよう)注意が必要ですね。 (「アジャイル」や「DevOps」もですけど、、、)

*[本]人月の神話

最近あらためて「人月の神話」を読みました。

f:id:orinbou:20201221010023p:plain

人月の神話(20周年記念増訂版)

昨年の12月はAWS re:Invent 2019へ向かう途中でマウンテンビューのコンピュータ歴史博物館へ立ち寄った。そこに、この本の原著(と思われる本)が展示されていた。 最初の刊行は1975年だから、きっとその当時のものだと思う。

The Mythical Man-month:人月の神話

初版から既に45年が経っているにも関わらず、この本は今でも尚、大規模開発プロジェクトのソフトウェア工学の古典として読み継がれている名著と言われている。本の横に書かれているのは、あの有名な『ブルックスの法則』で 

「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ(Adding manpower to a late software project makes it later.)」

 というやつです。最近たまたま、この本を思い出すきっかけがあったのであらためて手に取ってみた。

 

まず、本の表示の獣を何故かずっと熊と思い込んでいたのだが、実はメガテリウム(オオナマケモノ)という新生代(約5百万~1万年前)の生物だった。確かに熊と違って尻尾が太い。全長6~8mで体重3tにもなるそうで熊よりよっぽどデカい。そして、第1章「タールの沼」の直前に下記の絵が掲載されており、左側にサーベルタイガーも描かれており確かに古代(新生代)を前提とした絵であることが分かる。

f:id:orinbou:20201223013526p:plain

タールの沼

この本の中で、著者のブルックスは、大規模なソフトウェア開発をもがけばもがくほど絡みつくタールの沼に例えている。

 

そして著者はソフトウェア開発の複雑性を次のように区別して考えている。(第16章)

 

●「本質的な複雑性」

 ソフトウェアの性質に固有な困難のこと

【本質:データセットやデータ項目間の関係、アルゴリズムや機能呼出などが組み合わさったコンセプトで構成されたものであり、同じ概念構造が多くの異なる表現で表されるという点で抽象的である。にもかかわらず、非常に正確で十分に詳細であるということ】

【困難:概念構造体の仕様作成とデザインおよびテスト】

 

●「偶有的(副次的あるいは不随の)な複雑性」

 目下の生産性にはつきまとうが本来備わっているものではない困難のこと

【例:実装(言語、ランタイム、ツール、プログラミング手法)にかかわるもの】

 

このように区別したうえで、ソフトウェア技術の進歩(例:高水準言語、オブジェクト指向プログラミングなど)は、主に偶有的な複雑性を解決して生産性を向上してきたが本質的な複雑性を攻略できた訳ではないと主張している。(確かにそうかも)

 

つまり、本質的な複雑さは、依然として攻略困難な課題として存在し続けており、それこそがソフトウェア構築は(当時と比べて飛躍的にテクノロジーが進歩した今でもなお)いつでも困難であり続けており「銀の弾丸はない」ということに繋がっているように思う。

 

この本は、最初の刊行では15章までだったけど、この20周年記念贈訂版では16~19章が付け加えられており、当時から20年の時の経過をふりかえっての後日譚が多く記載されている。

 

その中で、順次モデルまたはウォーターフォールを改良したウィンストン・ロイスについても触れているのが興味深い。それにも関わらず、未だにロイスは改良前(フィードバックが許されない古典的な)のウォーターフォールの父として語られているのを耳にすることがあるので少々気の非常に毒に思う。聞くたびに「そうじゃないんだよ」と訂正しているけど。あと、米国防総省の黒歴史DOD-STD-2167のことも書いてあった。日本にも強い影響を与えた仕様ですね(今や黒歴史?)

 

漸増的(インクリメンタル)構築モデルの利点を述べ、常にシステムが動く状態にしておくことの重要性についても触れているのは興味深いし、(当時の)マイクロソフトの「毎晩構築」アプローチは、継続的インテグレーションとデイリービルドの考えを地で行ってる感じがした。

 

『人間が全て(そう、だいたいのところは)』の節で言及している「成功のためには、プロジェクトに携わる人々の質、およびその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因であると考えている」という点にも一考の余地があると思う。同じページでデマルコの「ピープルウェア:生産的なプロジェクトとチーム」も引用されていた。両翼からのアプローチは大事ですよね。

 

経済学者E.F.シューマッハーの「小さいことは美しい:あたかも人間を重視するかのような経済学の研究」を引用して、チームに権限を委譲して自由を与え、結果の責任を持たせることで準企業体を目指す企業がいる、など他にも興味深い話は多々あったけど、キリがないのでこの辺で。

 

本書の最後の節に「ソフトウェアエンジニアリングというタールの沼は、これから当分の間厄介なままだろう。人類が、手の届く範囲の、あるいはギリギリで届かないところにあるシステムを、ずっと試していくことは容易に想像がつく。ソフトウェアシステムは、人間の作り出したもののうちで最も複雑なものだろう。」と書かれている。これは増訂版が出版された1996年に書かれたもので、その時点から更に25年が経過している。

ソフトウェアエンジニアリングが今尚タールの沼のままなのかどうかはさておき、ソフトウェアの本質的な複雑性はさほど変わっていないと思う。ので、考えてみれば大変な(だが面白い)仕事を生業にしたもんだな、とつくづく感じる。(勿論いい意味で、)

ArgoCDを使用したGitOpsのデモ

今年は有難いことにk8sをお仕事で使用する機会に恵まれました。その中で、アプリケーションやインフラのデリバリをGitOpsで実現する手段としてArgoCDを使用しました。

 

イメージはだいたいこんな感じです。

f:id:orinbou:20201221004822p:plain

ArgoCDの利用イメージ

ArgoCDとググれば公式サイトをはじめ結構たくさんの情報がヒットします。なので、今更まとめ記事を書く必要もなさそうです。ハマりどころをスキップしてサッと試せるサンプルがあれば十分かなと思ったので、AWS EKSでk8sクラスタを作成してArgoCDでGitOpsを試すサンプルを作成してGitHubに置きました。

 

github.com

 

とりあえず適当なアプリでArgoCDがどんなものか触ってみたい人は試してみてください。

 

※補足

k8sサンプルアプリはいつものやつ(Sock Shop)を使用してますが、EKS:v1.18だとAPIバージョンなど廃止された記述があってうまくapplyできないのでマニフェストをForkして少しだけ修正してあります。