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

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

アジャイル宣言について今思うこと

2012年に書籍「アジャイルサムライ」と出会ってから今年で10年が経ちました。この10年間で、自身の現場で試行錯誤しつつ、本を読み、勉強会やコミュニティ活動へも参加させてもらって本当に色々な経験をさせてもらいました。今思い出してもビフォア・アジャイル時代と比べて、ソフトウェアやITシステムの開発のことを考えることが楽しく、そして好きになりました。かつて私は開発の仕事に嫌気が差して非IT系へと職を変えたこともありましたが、今こうして開発の仕事を楽しめるようになったのは、アジャイルとの出会いがあったからこそだと思います。その出会いに感謝しつつ10年目という節目に改めてアジャイル宣言を読み返して気付いたことを書き留めておこうと思います。

宣言の内容

宣言の内容は下記のとおりとなっています。

(英)https://agilemanifesto.org/

(日)https://agilemanifesto.org/iso/ja/manifesto.html

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

今この宣言を読んで思うことは、題名が「アジャイル宣言」ではなく「アジャイルソフトウェア開発宣言(原文:Manifesto for Agile Software Development)」だったんだと言うことです。この宣言を常に意識している人からすると何を今更という当たり前の話かもしれませんが、この気付きは私にとって大きなものでした。昨今、アジャイルという言葉は、開発だけにとどまらず、組織や教育あるいはビジネスなど実に様々なシーンで用いられるようになっています。そんな流れもあってか、最近では「開発」だけアジャイルにしても部分最適でしかなく、ビジネスそのものをアジャイルにしないと意味がないという至極最もな意見も増えてきており、その結果「アジャイル開発」ではなく単に「アジャイル」と表現することの方が多くなってきたように感じています。

原則の内容

原則の内容(日本語訳)は下記のとおりとなっています。

(英)https://agilemanifesto.org/principles.html

(日)https://agilemanifesto.org/iso/ja/principles.html

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

シンプルさ(ムダなく作れる量を最大限にすること)が本質です。

最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

ここでは宣言のことを「アジャイル宣言(原文:Agile Manifesto)」と略して(?)呼んでいます。略して呼ぶことで、前段の「宣言の内容」で述べたように、開発だけに閉じないようなニュアンスにも聞こえますが、やっぱりソフトウェアの開発を大前提とした原則について書かれています。これは上位に位置する宣言の中で「ソフトウェア開発の実践、あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。」と記載されているため、至極当然と言えます。また、先月発売された書籍「アジャイルメトリクス 」では、原則の文章をワードクラウドで可視化する例が紹介されています。面白そうだったので私も試してみました。(下図がその結果です)

この結果からもソフトウェアの開発を前提にしていることがはっきりと読み取れます。

一旦整理する

ここまでの私の理解を一旦整理しておきます。

  • 正式な題名は「アジャイルソフトウェア開発宣言(原文:Manifesto for Agile Software Development)」
  • 題名は「アジャイル宣言(原文:Agile Manifesto)」と略されることがある
  • この宣言はそもそも「ソフトウェアの開発」を大前提としてまとめられている

これらを踏まえて、今思うことについて以下に述べたいと思います。

いま思うこと

アジャイルな開発を目指す試行錯誤の中で「迷った時はアジャイル宣言に立ち返れ!」ということを、これまで何度も耳にし、また、目にしてきました。自身の取り組みの中でも、自分達が今やっていること、やろうとしていることが、果たして正しいのだろうかと迷った時、それに助けられたりもしました。今年ご縁あって本「ぼくのアジャイル100本ノック:親方Project」の一部を執筆をさせてもらう機会がありましたが、何名かの著者の方がそれに近い文脈でアジャイル宣言について触れておられました。確かにソフトウェアの開発を中心に考えれば、今もってそこに違和感はありません。

しかし、前述したとおり、昨今ではアジャイルはソフトウェア開発についてのみならず、もっと広い文脈(アジャイル組織アジャイル経営、etc.)で使われるようになっていると感じています。例えばアジャイルを実践する手段としてスクラムがありますが、非ITの現場で活用された事例なども目にするようになってきました。そのことは2020年に改定されたスクラムガイドの文面からも読み取れます。(「スクラムガイド(2020年11月)」の「スクラムガイドの目的」から抜粋)

成⻑を続ける複雑な世界において、スクラムの利⽤は増加しており、我々はそれを⾒守っている。スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。そうした状況を⾒ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専⾨家もスクラムを利⽤するようになった。スクラムでは「開発者」という⾔葉を使っているが、開発者以外を排除しているのではなく、単純化のために使⽤しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。

スクラムの起源が1986年に発表された論文「The New New Product Development Game」(野中郁次郎 竹中弘高)であり、当時世界のモノづくりの中心を担っていた日本の製造業の新製品開発の手法を参考にしたものであることを考えると、特別不思議なことではないように思えます。

重要なのはビジネスアジリティを高めることであり、ソフトウェアをアジャイルに開発することは、その要素に過ぎないと思います。そう考えた時、ビジネスアジリティを高める際に、迷った時の拠り所となるものが「アジャイルソフトウェア開発宣言(アジャイル宣言)」で本当に良いのだろうか?という疑問を感じてしまいました。これは決して宣言の内容が悪いとか古くなったと言っている訳ではありません。宣言誕生から20年以上の時を経て「アジャイル」という言葉が表現する領域が想像以上に大きくなってしまった結果なのだと思います。(※ソフトウェア開発の文脈においては、アジャイル宣言は引き続き重要であり続けると思います)

おわりに

もともと「アジャイルソフトウェア開発宣言(アジャイル宣言)」は、2001年に様々なソフトウェア開発手法の提唱者達17名が米国ユタ州のソルトレイクシティの郊外に集まって当時のソフトウェア開発手法やカルチャーに対するアンチテーゼとして「アジャイル」と言う名前を付けて発表しました。それから20年以上の時が過ぎたにも拘わらず、ソフトウェア開発の文脈において、今尚ソフトウェア開発を生業する私たち開発者の心の拠り所となっていることについては本当に感謝と尊敬の念しかありません。

しかし、アジャイル開発を実践する具体的な手段であるスクラム、SAFeなど様々なフレームワークや方法論がビジネス状況の変化と共に今も見直され続けている一方で、アジャイル宣言においてはその機会が無いまま今日に至っているものと思われます。

非ITのビジネスアジリティを考える場合においても「アジャイル」という言葉が使われる昨今のビジネスシーンにおいて、ソフトウェアの開発を前提としない新しいアジャイルの拠り所があると嬉しいなと思う反面、安易に「迷った時はアジャイル宣言に立ち返れ!」と言い放つことがないよう十分気を付けて生きていきたいと思います😅

*[本]「ソフトウェアアーキテクチャの基礎」: エンジニアリングに基づく体系的アプローチ

話題の近著「ソフトウェアアーキテクチャの基礎(エンジニアリングに基づく体系的アプローチ)」を読んだ感想などを中心に書き留めておきます。

www.oreilly.co.jp

はじめに

ソフトウェアアーキテクチャ、アーキテクトについての基礎や定義を網羅的に解説してくれています。ソフトウェアを中心としたシステム開発を生業にしている人にとって、ソフトウェアアーキテクチャは、身近なものだと思いますが、その定義について立ち止まって考える機会は意外と少ないのではないでしょうか?少なくとも私には、これまであまりその機会はありませんでした。この本は、過去からの経緯と昨今の時代の変化を踏まえて、ソフトウェアアーキテクチャやアーキテクトというもののあり方についての認識を考えさせられる一冊だと思います。

 

本の構成

本の構成は、下記のような章立てになっています。

<構成>
1章 イントロダクション

第Ⅰ部 基礎
2章 アーキテクチャ思考
3章 モジュール性
4章 アーキテクチャ特性
5章 アーキテクチャ特性を明らかにする
6章 アーキテクチャ特性の計測と統制
7章 アーキテクチャ特性のスコープ
8章 コンポーネントベース思考


第Ⅱ部 アーキテクチャスタイル
 9章 基礎
10章 レイヤードアーキテクチャ
11章 パイプラインアーキテクチャ
12章 マイクロカーネルアーキテクチャ
13章 サービスベースアーキテクチャ
14章 イベント駆動アーキテクチャ
15章 スペースベースアーキテクチャ
16章 オーケストレーション駆動サービス指向アーキテクチャ
17章 マイクロサービスアーキテクチャ
18章 適切なアーキテクチャスタイルを選ぶ

第Ⅲ部 テクニックとソフトスキル
19章 アーキテクチャ決定
20章 アーキテクチャ上のリスクを分析する
21章 アーキテクチャの図解やプレゼンテーション
22章 効果的なチームにする
23章 交渉とリーダーシップのスキル
24章 キャリアパスを開く

 

詳細な目次は、前述したO'Reillyさんの書籍ページもしくは実際の書籍をご覧ください。この目次だけでなんとなく伝わるかもしれませんが、ソフトウェアアーキテクチャについて現代的な視点も踏まえて網羅的に記載されているため、かなりボリューム(約400ページ)があります。読み方は人それぞれですが、個人的には最初から最後まで同じ密度で読むというよりは、「第Ⅰ部」の基礎編を読んだら「第Ⅱ部」はざっと目を通しつつ気になる所を読むくらいが良いかなと思いました。「第Ⅲ部」は、アーキテクトに求められる要素(しかも必須の)としてチーミングやリーダーシップなどのソフトスキルについて記載されており、そこまで求めてくるか…ぐぬぬ…、と少し驚かされました。

 

印象に残った点

印象に残った点、思ったこと、感じたことを以下に列挙しておきます。

1章 イントロダクション

1.2 アーキテクトへの期待

与えられた役割や肩書き、職務に関係なく、ソフトウェアアーキテクチャには主に次の8つが期待される。

  • アーキテクチャ決定を下す
  • アーキテクチャを継続的に分析する
  • 最新のトレンドを把握し続ける
  • 決定の順守を徹底する
  • 多様なものに触れ、経験している
  • 事業ドメインの知識を持っている
  • 対人スキルを持っている
  • 政治を理解し、かじ取りする

→最後の2つについて言及しているのは個人的に新鮮でした。特に「アーキテクトには、チームワークやファシリテーション、リーダーシップなど、卓越した対人スキルを持ち合わせていることが期待されている。」は、期待値高過ぎない?とも思いました。

1.3 アーキテクチャと交わるもの

未知の未知があるため、すべてのアーキテクチャはイテレーティブにならざるを得ない。アジャイルはそのことを理解していて、より早く未知の未知に対処するようになっている。(著者のひとりMarkの言葉を引用)

→アーキテクチャを考えるうえで、アジャイルのようなイテレーティブ(というか適応的な?)なプロセスの方がより適しているのは、かつてのソフトウェアとは違い変化を前提とした昨今の状況を鑑みた結果なのかな、と感じました。

1.4 ソフトウェアアーキテクチャの法則
第一法則:ソフトウェアアーキテクチャはトレードオフがすべてだ。
第二法則:「どうやって」よりも「なぜ」の方がずっと重要だ。

→シレっと記載されていますが、特に第一法則は、この本全体を通した(強めの)メッセージングだと感じました。

4章 アーキテクチャ特性

4.2 トレードオフと少なくとも最悪でないアーキテクチャ

決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないアーキテクチャを狙おう。

→文脈を加味して読めば、言わんとすることに対して、あまり違和感や矛盾はないと思うのですが、文脈なしでこの言葉がひとり歩きすると、アジャイルマニフェストに記載された12の原則に記載されている「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」を読んだ人が混乱しそうだな、とは思いました。

5章 アーキテクチャ特性を明らかにする

5.1 アーキテクチャ特性をドメインの関心事から捉える
事例:ヴァーサ号(の悲劇)

→トレードオフを無視して言われたまま仕様を全部のせしようとした結果、処女航海で沈没するという、このメタファ好きです。

6章 アーキテクチャ特性の計測と統制

Simian Armyの起源

→Netflixが生み出した有名な(?)カオスエンジニアリングのエピソード好きです。

9~18章 第Ⅱ部 アーキテクチャスタイル

以下のアーキテクチャスタイルとそのアーキテクチャ特性について解説されています。

  • レイヤードアーキテクチャ
  • パイプラインアーキテクチャ
  • マイクロカーネルアーキテクチャ
  • サービスベースアーキテクチャ
  • イベント駆動アーキテクチャ
  • スペースベースアーキテクチャ
  • オーケストレーション駆動サービス指向アーキテクチャ
  • マイクロサービスアーキテクチャ

それぞれのアーキテクチャ特性をざっと比較するには一覧表があると便利そうだったので作成してみました。Githubに置いておくので参考までにご覧ください。

アーキテクチャスタイルのアーキテクチャ特性比較

19~24章 第Ⅲ部 テクニックとソフトスキル

19章 アーキテクチャ決定

19.1 アーキテクチャ決定に関するアンチパターン
19.1.1 資産防御アンチパターン

重要なアーキテクチャ決定を下すのを、最終責任時点まで先延ばしすることだ。これは、正当であると検証するのに十分な情報が得られるまで、決定を先延ばしすることを意味している。ただし、開発チームを待たせたり、分析麻痺アンチパターンに陥ったりするほど長くは決定を先延ばししてはならない。

→言っていることは分かるが、現実問題として最終責任時点のタイミングの見極めが相当難しいのでは?本人としては、アーキテクト本人が最終責任時点だと思っていても、まだ早かったり、もう遅かったりということが多々ありそうな気がする。

19.3 アーキテクチャデシジョンレコード

アーキテクチャ決定を文書化する最も効果的な方法の1つに、アーキテクチャデシジョンレコード(Architecture Decision Records、ADR)ある。

→今までは使ったことない。アーキテクチャ決定したWhyの記録(ソフトウェアアーキテクチャの第二法則)として効果的なのであれば、今後のアーキテクチャ決定時に試してみたい。

21章 アーキテクチャの図解やプレゼンテーション

新米アーキテクトがよく口にすることに、アーキテクトになったのは技術的な知識や経験があったからだというのに、アーキテクトの仕事がそれだけでなく、非常に多岐にわたっていることに驚いた、(中略)。アーキテクトがどんなに素晴らしい技術的なアイデアを持っていたとしても、マネージャーに資金を出してもらい、開発者に作ってもらえなければ、その素晴らしさは決して実現しないからだ。

→うーん、確かに仰る通り。でも、そこまでやれる人がどこまでいるだろうか、、、

22章 効果的なチームにする

22.1 チーム境界

アーキテクトが作る制約があまりにも緩いと(もしくはまったく制約を作らないと)、重要なアーキテクチャ決定をすべて開発チームに任せてしまうことになる。これは制約が厳しい場合と同じくらい悪い。

→この点は個人的に反省する点が多い。複数のスクラムチームで比較的大きなソフトウェアを開発する場合、スクラムの文脈を考えると、全てを自己組織化したチームに委ねてしまいたくなる。というより、むしろ委ねないといけない気すらしてしまうのだが、成熟してないチームだと当然カオス気味になる。スクラムにはアーキテクトというロールはないので、有識者が居たとして、どこまでスクラムチームに干渉(最初から制約を突きつけたり、積極的に助けてあげたり)するかは、特に初めてのシチュエーションではなかなか判断が難しいと思う。とはいえ、過去の反省を踏まえた今ならば絶対必要だと思うし、体制面としても明確にしておくべきだと思う。

22.2 アーキテクトのパーソナリティ

プロジェクトの複雑さやチームのスキルレベルによっては、アーキテクトがコントロールフリークの役割を果たす必要がある場合もある。しかし、ほとんどの場合は、コントロールフリークアーキテクトは、開発チームを混乱させ、適切なレベルのガイダンスを提供せず、邪魔となり、チームを率いてアーキテクチャを実装することに関して効果を発揮しない。

→このあたりのバランスはとても難しそう。経験値が大きく問われそう。

22.3 エラスティックリーダーシップ

効果的なソフトウェアアーキテクトは、開発チームをどの程度コントロールするかをわかっている。この考え方は、エラスティックリーダーシップとして知られており、Roy Osheroveによって広く提唱されている。(中略)。主に5つの要因がある。

  • チームの親しさ
  • チームサイズ
  • 全体的な経験
  • プロジェクトの複雑さ
  • プロジェクトの期間

→確かに状況によって柔軟にコントロールするレベルを変えないと効果的でないのは理解できる。上記の要因や指標があっても尚難しそうだが、さじ加減を考える上での参考にはなりそう。

22.5 チェックリストの活用

万策尽きた場合には、ホーソン効果を活用しよう。ホーソン効果とは、自分が観察されたり監視されたりしていることを知っていると、人は行動を変え、概して正しいことをするようになるというものだ。

→チェックリストの作成まではよくやる。すべてのチェックリストを検証することは現実的には難しいと思うけど、ロット検査のようにランダムサンプリングによる抜き取り検査ならできそう。それによるホーソン効果も期待できそう。(もちろんそんなことしたくはないが、、、イザとなったらロット検査するよ!と伝えるだけでも良いかも)

23章 交渉とリーダーシップのスキル

23.2 リーダーとしてのソフトウェアアーキテクト

ソフトウェアアーキテクトはリーダーでもある。アーキテクトはアーキテクチャの実装を通して開発チームをガイドする。私たちは、効果的なソフトウェアアーキテクトであることの50%は、優れたピープルスキル、ファシリテーションスキル、そしてリーダーシップスキルを持っていることだと考えている。

→このあたりのバランス感覚まで兼ね備えてしまうと、もはやアーキテクトの能力を持った有能なスクラムマスターという感じ。もはや君子

24章 キャリアパスを開く

24.1 20分ルール

このテクニックは、アーキテクトとしてのキャリアのために新しいことを学んだり、特定のトピックを深く掘り下げたりするのに、1日に少なくとも20分は費やすというものだ。(中略)多くのアーキテクトはこの考え方に従って、昼休みや仕事が終わった後の夕方に20分ほどかけてこの作業をしようとする。しかし、経験上、これがうまくいくことはほとんどない。ランチタイムはどんどん短くなり、休憩や食事の時間というよりも、仕事の追い込み時間になってしまう。夜はもっとひどい。状況が変わったり、予定が入ったり、家族との時間が重要になったりして、20分ルールが実現しなくなってしまう。私たちが強く勧めるのは、一日の始まりである朝一番に20分ルールを活用する方法だ。しかし、このアドバイスにも注意点がある。(中略)そのため、私たちは、朝一番のコーヒーや紅茶を飲んだ後は、メールをチェックする前に、20分ルールを発動することを強くお勧めしている。少し早めに出勤する。これをすることで、アーキテクトの技術的な幅が広がり、効果的なソフトウェアアーキテクトになるのに必要な知識を身につけられる。

→めちゃワカル。メール見ないようにしてても、私信で来たチャットとかを、つい見ちゃうとそこで試合終了なんですよね。分かっちゃいるけどついやってしまう。キヲツケねば。

24.4 別れの挨拶

アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。(著者のひとりNealの言葉を引用)

→ソフトウェアアーキテクチャの第一法則と同じ内容を言葉を変え最後に語っている。著者(ら)がこの本を通して伝えたかった重要なメッセージングなのだと思う。

 

おわりに

ソフトウェアアーキテクチャには、絶対的な正解が存在しない。すべてはトレードオフなのだ、というこの本の強いメッセージに少し気後れはありますが、だからこそ追い求める価値があるものなのだという、冒険の旅のようなワクワク感もあります。そういえば、最近出版された「O'Reilly Japan - ソフトウェアアーキテクチャ・ハードパーツ」は、今回の「O'Reilly Japan - ソフトウェアアーキテクチャの基礎」の続編のようなタテツケで、長編の英雄譚(サーガ、Saga)の体で書かれているんだとか。ソフトウェアアーキテクチャを学び、追い求めることはまさに冒険なんですね。積読が滞留しているのですぐ手を出せませんが、少し時間を置いてから、そちらの本も読んでみたいと思います。

 

参考

*[本]「ゾンビスクラムサバイバルガイド」: 健全なスクラムへの道

翻訳者の たくぼん さん、 たかS さん、水野 さん から献本いただきました。ありがとうございます。

ゾンビスクラムサバイバルガイド: 健全なスクラムへの道 | 木村 卓央, 高江洲 睦, 水野 正隆, Christiaan Verwijs, Johannes Schartau, Barry Overeem |本 | 通販 | Amazon

本を読んだ感想などを中心に書き留めておこうと思います。

概要

何となくスクラムを始めたがうまくいかない、
型通りにやっているけど何かが違う気がする、
スクラムを取り入れたがメリットを感じない、
etc.

など、既にスクラムに取り組んでいる人や組織で発生(発症?)しがちな形骸化やその他さまざまな問題を、ウォーキング・デッド(いや、もしかしてバタリアン?)のゾンビに例えて、ゾンビウィルスに打ち勝つ対策について事例を交えて解説してくれます。

内容

本の構成は、下記のような章立てになっています。

<構成>
第1章 はじめに
第2章 応急処置キット

第1部 (ゾンビ)スクラム
第3章 ゾンビスクラム入門
第4章 スクラムの目的

第2部 ステークホルダーが求めるものを作る
第5章 症状と原因
第6章 実験

第3部 速く出荷する
第7章 症状と原因
第8章 実験

第4部 継続的に改善する
第9章 症状と原因
第10章 実験

第5部 自己組織化する
第11章 症状と原因
第12章 実験
第13章 回復への道

 

各部のテーマに対して「症状と原因」の章で問題や課題を取り上げ、次章の「実験」で具体的な処方箋について手順も交えて説明するという流れになっているので、テンポよく読めます。これが理解しやすさに繋がっている気がしました。(※但し、理解しやすいから実践しやすい、という訳ではないので注意ください)

翻訳本はモノによって読みにくい文章になっていることもありますが、この本の文章は非常に読みやすくて良かったです。翻訳の表現があまりに不自然だと、どう理解すべきか考え込んで疲れてしまい、読むのが辛くてやめてしまったりしたこともあったので、その点については個人的にポイントが高かったです。

この本の中には、例として様々なゾンビスクラムの症状が出てきます。

「なんか見たことある!」とか「まさに今そうなってる!」など、各読者ごとに様々な思いが浮かんでくるんじゃないかと思います。症状が進行しすぎて既に何も感じなくなってしまったりしていると、最初の小さな一歩を踏み出すのも難しい場合があるかもしれません。そんな時は、本の中でも紹介されている「助けてくれる人を探す(応急処置キット)」を意識して、社内外の協力者をうまく頼って地道に実践していくのがゾンビスクラムで生き残る道なのではないでしょうか。

おわりに

個人的に最小の労力(スキル:★ or ★★)で最高のリターン(効果:★★★★★)が得られるコスパ良い処方箋をパッと知りたいと思ったので、Excelで「ゾンビスクラムと戦うためにチームでできる実験」のチート資料つくってみました。

こんな感じのやつ【↓】

ゾンビスクラムと戦うためにチームでできる実験(のチートシート)

これで楽して成果を得られるぜ!って、、、ん?

よく見てみると確かにスキル要らないのもあるけど、あくまでも著者のコンテキストや目線ですよね。世の中そんなに甘くない、ということですね(デスヨネー、笑)。とは言え、考える上での目安にはなると思いますので、参考までに チートシート を添付しておきます。このシートは、困った時に本のどこを見れば良いかすぐ分かるので、ちょっと便利なインデックスとしても使えるんじゃないかと思います。(※もし内容に問題あればすぐ更新 or 削除します)

 

参考

AWS 認定ソリューションアーキテクト – プロフェッショナル(SAP)を【再】取得しました

AWS 認定ソリューションアーキテクト – プロフェッショナル (SAP-C01)を【再】取得(9/23)しました。

合格するまでの勉強方法などのメモです。誰かの何かの役に立てば幸いです。

AWS認定について

AWS認定の情報はググれば死ぬほど出てくるので、敢えてここで詳細を語る必要もないかと思います。AWS認定の詳細は以下の公式ページに記載されています。詳細はこちらをご覧ください。

aws.amazon.com

ちなみに今年の8/10でSAP認定がEXPIREしてしまっていたので今回は更新(再認定)ではなく再取得でした。EXPIREした理由は主に2つで、更新(再認定)のメリットをあまり感じなかったのと、新規取得の時と比べてモチベーションが湧かなかった点でした。ちなみに一度失効するとセットの下位資格(今回はSAA)の認定バッジは無くなりますので撃墜マークとして認定バッジ数を気にされる方はご注意ください。

再認定について

再認定の詳細は以下の公式ページに記載されています。詳細はこちらをご覧ください。

aws.amazon.com

なぜこのタイミングなのか?

そんな中、なぜこのタイミングでSAPを再取得したかと言うと、ちゃんと理由があります。それは、今年の11/15[火]から試験がバージョンアップ(SAP-C01→SAP-C02)されてしまうからです。既に次バージョンの試験ガイドやサンプル問題が公開されてはいますが、新しいバージョンの試験対策において試行錯誤するファクターが増えそうです。新しいバージョンの試験についての詳細は以下の公式ページに記載されています。

aws.amazon.com

AWSも「現在の AWS Certified Solutions Architect - Professional 試験の準備をしている方、または再認定が必要な方は、2022 年 11 月 14 日 までに現在の試験を受けることをお勧めします。」と言っており、これが今回の一番のモチベーションになりました。

現行バージョンの試験の終了時期が割と間近に迫っていることも考慮して、少しリスクをとって学習レベルがギリギリ合格ラインに達したくらいで一旦1回目を受験することにしました。これは、もし不合格だった場合、再試験、再々試験くらいまでを視野に入れるとすると、試験の間隔を2週間以上空けないといけないからです。

※ちなみに、SAAは今年の8月末から既に新しいバージョンの試験(SAA-C03)に移行しており、旧バージョン(SAA-C02)で受験することはもうできません。

SAP試験対策について

以上の理由から、今回の試験対策は短期決戦を意識して準備を進めました。今回の対策で使用した教材は下記のとおりです。

  • 参考書:AWS認定ソリューションアーキテクト - アソシエイト
    • こちらの物理本を買いました。本は頭から順番に読まず、中の問題をまずは一周解いてみて、自分の弱点を炙り出しました。その際、間違えた問題、解答に自信がない問題(と解説)の再検索を容易にするためインデクシング(赤ペンでチェックを付けて、ページの角をドッグイヤー)しておきました。インデクシングした問題は、解説を読んで納得できればそれでOKです。納得できない場合は、ググって調べて、自分なりにある程度納得できる状態にしておきました。

      books.rakuten.co.jp

    • 前回の時と違って、今はSAPの試験対策本や問題集があるので短期決戦の準備をするにあたりその点はとても助かりました。
  • 模擬試験:AWS Skill Builder(※無料)
    • AWS認定の模擬試験(20問)をオンラインで受けることができます。本試験と同じような画面レイアウト(時間制限なども本番に近い)で体験できるので、やっておくと良いと思います。以前の有償(¥4000)だった頃と違い、試験後に模擬試験の問題を見返して復習することもできます。残念ながら日本語の問題は現在は下記の1コースのみしかないようです。こちらはSAPの公式ページにある「公式練習問題集」リンクから辿れます。
    • 模擬試験の受け方については、下記の情報を参考にさせてもらいました。

      blog.serverworks.co.jp

  • サンプル問題:AWS Certified Solutions Architect - Professional(※無償)
  • Udemy:AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集(※有償:¥2440)
    • 375問(75×5set)のAWS認定SAPテスト問題集(解説付き)です。こちらは前述の3つの教材をひと通りやり終えてから、試験当日までの短期強化対策として取り組みました。1set解くのに約180分を要し、間違えた問題の解説を読み、更に分からない点はググって調べる、とかなり時間がかかりました。今回は試験当日までに300問(4/5set)を実施しました。

      www.udemy.com

    • 【注意】ちなみに、この問題集は本試験と比べてもかなり難しいと思います。今回の準備期間である程度学習してから解きましたが軒並み5割くらいでした。なので、この問題集のスコアはあまり気にし過ぎず、前述の教材でカバーし切れない領域の知識を補強してくれる教材という程度に受け止めておけば良いと思います。
  • その他
    • 地味に大事なのが受験会場ですね。受験会場によってだいぶ当日のストレスや疲労に差が出ると思います。過去の実績から歌舞伎座テストセンターを選択したかったのですが、2021年頃からAWS認定試験の対応を辞めてしまったのか、今回は選択することができませんでした。そんな訳で、今回は自宅から近い 町田ITテストセンター(ピアソンVUE)で受験したのですが、そんなに悪くなかったです。近いし、次回もここで受験しようかな。
    • 試験会場では、感染症対策の観点からマスクをした状態で受験することになります。花粉症などの対策でマスクに慣れてる人は良いですが、慣れてない人にとっては長時間マスクした状態で試験し続けるのは、頭がボーっとして地味にしんどかったです。ので、もしキニナル人は自宅で模擬試験やる時、1回くらいシミュレーションしとくとよいかもです。

 

以上の対策を実施した結果、今回は運良く1回でパスすることができました。

お疲れ様でした。ギリギリで恥ずかしいのでスコアは秘密ですw

来年はDOPの更新が待ってます。取得時期ズラしといてホント良かった、、、

 

※補足※

ちなみに来年からPSIでの受験はできなくなるそうです。

AWS Certification のよくある質問

[2022/9/11(日)]技術書典13@池袋オフライン へ参加してきました

2020年前半から新型コロナウイルスによる自粛生活が始まってからオフライン形式のイベントに最後に参加したのがいつだったかもはや思い出せませんが、超久しぶりにオフラインのイベントに参加してきました。今回参加したのは技術書典13です。

技術書典は、その名のとおり技術書に関するイベントで、技術書を中心に数多くの作品(技術同人誌)が出展されており、新しい技術に出会える素敵なイベントです。2020年以降コロナの影響で暫くオンラインで開催していたようですが、約3年ぶりにオフラインでイベントが開催できたようです。(※ちなみにオンラインイベントは只今絶賛開催中9/10[土]-25[日]です!)

#技術書典 #技術書典13

今回、ご縁あって、こちらのイベントに出展される本「ぼくのアジャイル100本ノック:親方Project」の一部執筆をさせていただく機会があったので、折角なのでオフラインイベントに参加してみようということで初参加してきました。当初は一般参加するつもりだったのですが、売り子が足りないということで、急遽スタッフとして参加することになりました(笑)そんな訳で初参加ながらいきなり貴重な経験をさせてもらいました。開場前の販売ブースの様子はこんな感じで文字通り本が山のように積まれています。

大変嬉しいことに、こちらの450ページの超分厚い本(※ネタで鈍器と呼ぶ人も居ましたが)を多くの方に買っていただけました。一部ではありますが、自分が執筆した本が目の前で買ってもらえるというのは不思議で貴重な体験でした。とても嬉しかったです。

 

せっかく来たので私も会場をまわって興味のある技術書を買い漁っていたら思ったより沢山になりまして、帰り道とっても重かったです。物理本をこんなに纏めて買ったのはいつぶりだろう(いや、初めてかw)。やはりオフラインのイベントだと、わざわざ足を運んでいる、せっかく来たからには、という気持ちがオンラインより圧倒的に強くなるので、購買意欲もマシマシになりますね。是非来年も参加したいです。

執筆機会をいただけた、あじゃてくことAgileTechEXPOさんありがとうございました。本の編集や校正そして熱意あるフォローやリマインドなど親方Project親方さんには大変お世話になりました。オフラインイベント当日も含めていろいろと勉強になりました。

 

<補記>

折角なので今回の本「ぼくのアジャイル100本ノック」は会社の本棚へ献本させてもらいました😊

本の厚さはこのとおり…私はよくタウンページくらいと表現していたのですが、これが鈍器と謂われる所以ですw

脆弱性診断ツールTrivy(トリビー)を触ってみた

コンテナを前提としたDevSecOpsを実現する手段について調べていたらTrivy(トリビー)に出会った。

Trivy(トリビー)とは?

Trivy(トリビー)は、GitHubでソースコードが公開されているOSSのコンテナイメージ脆弱性診断ツールです。 もともとイスラエルいくべぇ@knqyf263さんが趣味で作ったツールをイスラエル企業のAqua Security Software Ltd.(以降「Aqua社」と呼ぶ)が買収した経緯があるそうです。 ツールも進化してコンテナイメージの脆弱性スキャンだけでなくファイルシステムのスキャンもできるようです(※未検証)

公式情報

作者の情報

イスラエルいくべぇ(福田鉄平)さん
Aqua社で唯一の日本人。Trivyの開発者。Aqua Open Source Team所属。


作者は、現在Aqua社へ入社して唯一の日本人エンジニアとして活躍しているということらしく、物語としても胸アツです。(※以下、作者ブログ参照)

作者のストーリー


やったこと

セットアップの手間を省き、かつ、どの環境でも同じく実行できるようTrivyの公開コンテナイメージ

https://hub.docker.com/r/aquasec/trivy/

を使用した脆弱性スキャンを試してみました。

その1:最新Dockerhub公式イメージをスキャン

Linux系の最新の公式イメージが安全なのか調べてみます。(※下記URL参照)

https://hub.docker.com/search?type=image&image_filter=official&operating_system=linux

docker run aquasec/trivy image ubuntu:latest
docker run aquasec/trivy image alpine:latest
docker run aquasec/trivy image debian:latest
:(※省略)

デフォだと脆弱性レベルが高いものから低いものまで全て表示されて見にくいのでフィルタしてみる。(CRITICAL,HIGHのみ)

docker run aquasec/trivy image --severity CRITICAL,HIGH ubuntu:latest
:(※中略)
ubuntu:latest (ubuntu 22.04)
===========================
Total: 0 (HIGH: 0, CRITICAL: 0)

docker run aquasec/trivy image --severity CRITICAL,HIGH alpine:latest
:(※中略)
alpine:latest (alpine 3.15.4)
=============================
Total: 0 (HIGH: 0, CRITICAL: 0)

docker run aquasec/trivy image --severity CRITICAL,HIGH debian:latest
:(※中略)
debian:latest (debian 11.3)
===========================
Total: 14 (HIGH: 14, CRITICAL: 0)

+--------------+------------------+----------+-------------------+-------------------+---------------------------------------+
|   LIBRARY    | VULNERABILITY ID | SEVERITY | INSTALLED VERSION |   FIXED VERSION   |                 TITLE                 |
+--------------+------------------+----------+-------------------+-------------------+---------------------------------------+
| e2fsprogs    | CVE-2022-1304    | HIGH     | 1.46.2-2          |                   | e2fsprogs: out-of-bounds              |
|              |                  |          |                   |                   | read/write via crafted filesystem     |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-1304  |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| gzip         | CVE-2022-1271    |          | 1.10-4            | 1.10-4+deb11u1    | gzip: arbitrary-file-write            |
|              |                  |          |                   |                   | vulnerability                         |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-1271  |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| libc-bin     | CVE-2021-3999    |          | 2.31-13+deb11u3   |                   | glibc: Off-by-one buffer              |
|              |                  |          |                   |                   | overflow/underflow in getcwd()        |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2021-3999  |
+--------------+                  +          +                   +-------------------+                                       +
| libc6        |                  |          |                   |                   |                                       |
|              |                  |          |                   |                   |                                       |
|              |                  |          |                   |                   |                                       |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| libcom-err2  | CVE-2022-1304    |          | 1.46.2-2          |                   | e2fsprogs: out-of-bounds              |
|              |                  |          |                   |                   | read/write via crafted filesystem     |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-1304  |
+--------------+                  +          +                   +-------------------+                                       +
| libext2fs2   |                  |          |                   |                   |                                       |
|              |                  |          |                   |                   |                                       |
|              |                  |          |                   |                   |                                       |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| libgcrypt20  | CVE-2021-33560   |          | 1.8.7-6           |                   | libgcrypt: mishandles ElGamal         |
|              |                  |          |                   |                   | encryption because it lacks           |
|              |                  |          |                   |                   | exponent blinding to address a...     |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2021-33560 |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| liblzma5     | CVE-2022-1271    |          | 5.2.5-2           | 5.2.5-2.1~deb11u1 | gzip: arbitrary-file-write            |
|              |                  |          |                   |                   | vulnerability                         |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-1271  |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| libss2       | CVE-2022-1304    |          | 1.46.2-2          |                   | e2fsprogs: out-of-bounds              |
|              |                  |          |                   |                   | read/write via crafted filesystem     |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-1304  |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| libtinfo6    | CVE-2022-29458   |          | 6.2+20201114-2    |                   | ncurses: segfaulting OOB read         |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-29458 |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| logsave      | CVE-2022-1304    |          | 1.46.2-2          |                   | e2fsprogs: out-of-bounds              |
|              |                  |          |                   |                   | read/write via crafted filesystem     |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-1304  |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| ncurses-base | CVE-2022-29458   |          | 6.2+20201114-2    |                   | ncurses: segfaulting OOB read         |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2022-29458 |
+--------------+                  +          +                   +-------------------+                                       +
| ncurses-bin  |                  |          |                   |                   |                                       |
|              |                  |          |                   |                   |                                       |
+--------------+------------------+          +-------------------+-------------------+---------------------------------------+
| perl-base    | CVE-2020-16156   |          | 5.32.1-4+deb11u2  |                   | perl-CPAN: Bypass of verification     |
|              |                  |          |                   |                   | of signatures in CHECKSUMS files      |
|              |                  |          |                   |                   | -->avd.aquasec.com/nvd/cve-2020-16156 |
+--------------+------------------+----------+-------------------+-------------------+---------------------------------------+

さすがに最新の公式イメージにCRITICALはありませんでしたが、debianにはHIGHの脆弱性が14 件あるようでした。(※2022/05/06時点)

その2:古いDockerhub公式イメージをスキャン

Linux系の古い公式イメージが安全なのかをいくつか調べてみます。

docker run aquasec/trivy image --severity CRITICAL,HIGH debian:10.12
:(※中略)
debian:10.12 (debian 10.12)
===========================
Total: 39 (HIGH: 31, CRITICAL: 8)
:(※省略)

docker run aquasec/trivy image --severity CRITICAL,HIGH debian:10.12-slim
:(※中略)
debian:10.12-slim (debian 10.12)
================================
Total: 39 (HIGH: 31, CRITICAL: 8)
:(※省略)

やはり古いコンテナイメージだとHIGHだけでなくCRITICALの脆弱性が多数含まれているようです。

その3:Trivyの公開コンテナイメージをスキャン

そもそもTrivyの公開コンテナイメージに脆弱性がないのか気になったので、TrivyでTrivyの公開コンテナイメージをスキャンしてみました。

docker run aquasec/trivy image aquasec/trivy
aquasec/trivy (alpine 3.15.4)
=============================
Total: 4 (UNKNOWN: 0, LOW: 1, MEDIUM: 3, HIGH: 0, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+---------------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |                 TITLE                 |
+---------+------------------+----------+-------------------+---------------+---------------------------------------+
| libcurl | CVE-2022-22576   | MEDIUM   | 7.80.0-r0         | 7.80.0-r1     | curl: OAUTH2 bearer bypass            |
|         |                  |          |                   |               | in connection re-use                  |
|         |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2022-22576 |
+         +------------------+          +                   +               +---------------------------------------+
|         | CVE-2022-27774   |          |                   |               | curl: credential leak on redirect     |
|         |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2022-27774 |
+         +------------------+          +                   +               +---------------------------------------+
|         | CVE-2022-27776   |          |                   |               | curl: auth/cookie leak on redirect    |
|         |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2022-27776 |
+         +------------------+----------+                   +               +---------------------------------------+
|         | CVE-2022-27775   | LOW      |                   |               | curl: bad local IPv6 connection reuse |
|         |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2022-27775 |
+---------+------------------+----------+-------------------+---------------+---------------------------------------+

さすが、HIGH以上の脆弱性はありませんでした。素晴らしいですね。(※2022/05/06時点)

その4:ArgoCDの公開コンテナイメージをスキャン

もともとやりたかったことがこれです。k8sで運用中のコンテナイメージの脆弱性に自動で気付ける仕組みが欲しかったので、、、 例えば以前デモ用に作成したArgoCD

blog.orinbou.info

がいい感じで古くなっているのですが、このデモの中で古いArgoCDのコンテナイメージを参照しています。

https://github.com/orinbou/argocd-demo/blob/main/argocd/install.yaml

上記k8sマニフェストから参照しているコンテナイメージをスキャンしてみました。

docker run aquasec/trivy image --severity CRITICAL,HIGH argoproj/argocd:v1.7.9
argoproj/argocd:v1.7.9 (debian 10.6)
====================================
Total: 346 (HIGH: 290, CRITICAL: 56)
:(※中略)
Python (python-pkg)
===================
Total: 3 (HIGH: 2, CRITICAL: 1)
:(※中略)
usr/local/bin/argocd (gobinary)
===============================
Total: 5 (HIGH: 5, CRITICAL: 0)
:(※中略)
usr/local/bin/argocd-application-controller (gobinary)
======================================================
Total: 5 (HIGH: 5, CRITICAL: 0)
:(※中略)
usr/local/bin/argocd-darwin-amd64 (gobinary)
============================================
Total: 5 (HIGH: 5, CRITICAL: 0)
:(※中略)
usr/local/bin/argocd-repo-server (gobinary)
===========================================
Total: 4 (HIGH: 4, CRITICAL: 0)
:(※中略)
usr/local/bin/argocd-server (gobinary)
======================================
Total: 6 (HIGH: 6, CRITICAL: 0)
:(※中略)
usr/local/bin/argocd-util (gobinary)
====================================
Total: 5 (HIGH: 5, CRITICAL: 0)
:(※中略)
usr/local/bin/argocd-windows-amd64.exe (gobinary)
=================================================
Total: 5 (HIGH: 5, CRITICAL: 0)
:(※中略)
usr/local/bin/helm (gobinary)
=============================
Total: 12 (HIGH: 12, CRITICAL: 0)
:(※中略)
usr/local/bin/kustomize (gobinary)
==================================
Total: 11 (HIGH: 11, CRITICAL: 0)
:(※省略)

エグイほどの数の脆弱性が検出されました。が、気付きたかった下記の脆弱性が検出できませんでした。何故だ、、、


まとめ

コマンドラインで実行可能なシンプルなツールなので、CI/CDパイプラインへ簡単に組み込むことができそうです。 しかし、デプロイ時に気付けてもあまり意味がないので、利用しているコンテナイメージを対象にした脆弱性スキャンを定期実行(1日1回くらい)するのが良さげです。 あとは、誤検知や同じ脆弱性が複数回通知されないような仕組みも必要かと思いますが、その辺の自作はそこまで大変ではなさそう。(でもマネージドサービス欲しい)

また、実運用を考えると今回気付きたかったArgoCDの脆弱性(CVE-2022-24348)が何故検出できなかったか、などについてもう少し調べてみる必要がありそうです。


参考

フロントエンドフレームワーク関連で読み方が怪しい子達

フロントエンドフレームワーク関連で、人によって読み方に揺らぎがある子達。
会話していて本当に同じものを指しているのか不安になったので一般的な読み方と用途を整理しておく


Next.js:ネクスト.ジェーエス(React系)

OSSのSPA/SSR開発用Webアプリケーションフレームワーク。TypeScriptで書ける。


Nuxt.js :ナクスト.ジェーエス(Vue.js系)

OSSのSPA/SSR開発用Webアプリケーションフレームワーク。TypeScriptで書ける。

Nuxt2(for Vue2)

Nuxt3(for Vue3)


Vite:ヴィート

フランス語で「速い」の意味。高速なビルドツール。
JavaScript(vanillaJS)Vue.js、React、SvelteなどのフレームワークやTypeScriptにも対応しており、Nuxt3でも採用されている。


Svelte:スヴェルト

Web上で動作するユーザーインターフェースを構築することができるフレームワーク


補足

2022/05/26[木]追記

後日また間違えそうなキーワードを見つけたので追記しておく

Nest.js:ネスト.ジェーエス

サーバーサイドアプリケーション開発に使用される Node.jsのフレームワーク
TypeScript(もしくはJavaScript)で記述可能