2023-04-20

Ubuntu の Firewallツール (UFW:Uncomplicated firewall)を触ってみた

Linux Ubuntu

Ubuntu の Firewallツール (UFW:Uncomplicated firewall)で試してみる。

※ Wikipedia から引用

Uncomplicated Firewall（UFW）は、簡単に使用できるように設計された、netfilter（英語版）ファイアウォールの管理プログラムである。少数のシンプルなコマンドからなるコマンドラインインターフェイスを使用する。内部の設定には、iptablesを使用している。UFWは、8.04 LTS以降のすべてのUbuntuインストールでデフォルトで使用可能である。

はじめに

今回の試行条件は下記のとおりです。

試行環境

今回試した環境は以下（※一応記録しておく）

cat /etc/os-release

実行結果

NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

初期状態

初期状態はインアクティブになっている。

systemctl status ufw

実行結果

● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:ufw(8)

FW設定変更

下記のとおり軽く設定を変更してみる。

TCP接続を許可する

SSH通信用にTCP接続を許可する。

ufw allow 22/tcp

実行結果

Rules updated
Rules updated (v6)

接続を許可する

任意の通信用にTCP/UDP接続を許可する。

ufw allow 80

実行結果

Rules updated
Rules updated (v6)

特定IPからの接続を許可する

特定IP（135.22.65.0/24）から9090ポートへのTCP通信を全て許可する。

ufw allow from 135.22.65.0/24 to any port 9090 proto tcp

実行結果

Rules updated

特定IP（135.22.65.0/24）から9091ポートへのTCP通信を全て許可する。

ufw allow from 135.22.65.0/24 to any port 9091 proto tcp

実行結果

Rules updated

FW有効化

ファイアウォールを有効にして、システム起動時に自動実行されるようにする。

ufw enable

実行結果

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

ファイアウォールはアクティブかつシステムの起動時に有効化されます。

FW実行／停止

手動で実行する

systemctl start ufw

特に何も表示されないため、以下のコマンドでステータスを確認する。

systemctl status ufw

実行結果

● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: active (exited) since Fri 2023-03-31 22:14:06 EDT; 2s ago
       Docs: man:ufw(8)
    Process: 21145 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
   Main PID: 21145 (code=exited, status=0/SUCCESS)

Mar 31 22:14:06 node01 ufw-init[21149]: Firewall already started, use 'force-reload'

手動で停止する

systemctl stop ufw

特に何も表示されないため、以下のコマンドでステータスを確認する。

systemctl status ufw

実行結果

● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Fri 2023-03-31 22:19:12 EDT; 2s ago
       Docs: man:ufw(8)
    Process: 21145 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
    Process: 21953 ExecStop=/lib/ufw/ufw-init stop (code=exited, status=0/SUCCESS)
   Main PID: 21145 (code=exited, status=0/SUCCESS)

Mar 31 22:14:06 node01 ufw-init[21149]: Firewall already started, use 'force-reload'

参考

2023-04-17

Certified Kubernetes Security Specialist (CKS) 試験に合格しました【k8s三冠達成】🐳🐳🐳

CKS CAKD CKA docker k8s kubernetes

本日（4/17）Certified Kubernetes Security Specialist (CKS) 試験に合格しました。過去に取得したCKA、CKADと併せて念願のk8s三冠達成🐳🐳🐳できました！個人的な感想としては、これまで受験した資格試験の中で過去イチ難しかったと感じています。合格するまでの勉強方法などのメモです。誰かの何かの役に立てば幸いです。（※ほぼ未来の自分用ですw）

Kubernetes認定資格について

Kubernetesは、Googleの社内技術を元にオープンソース化されたコンテナオーケストレーションのデファクトスタンダードとも言うべきものです。ググればいくらでも情報が見つかるのでここでの説明は割愛します。

3年前（2020年）はCKAとCKADしかありませんでしたが、現在ではLinux Foundationが認定するKubernetesの認定資格は、次の４種類（KCNA/CKA/CKAD/CKS）があります。2020年11月にCKS、2021年11月にKCNAの認定試験が追加されており、ここ数年におけるKubernetesニーズの高まりを感じます。

略称	正式名	概要
KCNA KCNA-JP	Certified Kubernetes Administrator (KCNA) 認定Kubernetesクラウドネイティブアソシエイト (KCNA-JP)	Kubernetesと広範なクラウドネイティブエコシステムに関する基本的な知識とスキルを証明する（有効認定期間：3年間）
CKA CKA-JP	Certified Kubernetes Administrator (CKA) 認定Kubernetes管理者 (CKA-JP)	Kubernetes管理者の責任を遂行するスキル、知識、および能力を備えていることを保証する（有効認定期間：3年間）
CKAD CKAD-JP	Certified Kubernetes Application Developer (CKAD) 認定Kubernetesアプリケーション開発者 (CKAD-JP)	ユーザーが Kubernetes 用のクラウドネイティブアプリケーションを設計、構築、デプロイできることを証明する（有効認定期間：3年間）
CKS CKS-JP	Certified Kubernetes Security Specialist (CKS) 認定Kubernetesセキュリティスペシャリスト (CKS-JP)	Kubernetesの熟練した実践者（CKA認定が必要）であり、コンテナベースのアプリケーションやKubernetesプラットフォームの構築、デプロイ、ランタイム時のセキュリティを確保するための幅広いベストプラクティス能力を実証する（有効認定期間：2年間）

入門編のKCNA以外は受験費用は何れも$395です（JPは$430と割高です）。およそ3年前にCKAとCKADを受験した時の費用は$300でしたのでかなり値上げされている印象ですね。但し、これまでと同様で費用に1回分の再受験が含まれているので心理的にもお財布的にも嬉しいのは変わらずでした。また、時々割引キャンペーンで受験費用が10〜30%OFFになることがあるので、試験対策を進めながらこまめにチェックするとお得に受験できるかもしれません。

ちなみに、日本語（の試験官）で試験を受けたい場合はJPが付いているものを選択するのですが、現在のLinux Foundationの試験サイトには下記のように記載されています。

2022年12月31日以降、日本語を話す監督官は JP 試験をサポートできなくなります。2023年01月01日以降、これらの試験は英語を話す監督者によって監督されます。（注：試験内容は引き続き日本語で提供されます。)

リモート試験監督のチャット対応は簡単な英語が理解（読解）できれば問題ないですし、試験環境の言語設定を日本語に変更すれば、JP試験を選択せずとも（※2021年7月から）日本語で受験が可能ですので、今回は「CKS」で試験を申し込んで受験しました。ちなみに、CKSの受験者は、前提としてCertified Kubernetes Administrator(CKA)試験に合格している必要があるのでご注意ください。

今回の受験対象となる環境は【Ubuntu20.04、Kubernetes v1.26】でした。

■ 試験対策について

今回の試験対策で実践した内容は３つです。（購入した順番に記載しています）

１．Udemy（※有償：¥4800 → ¥2400）★50%OFF！

一番最初に購入した教材です。CKAやCKADも基本的には、ほぼUdemy講座の一本足打法で学んだので、今回もまずは同じアプローチを採用しました。（後に、コレだけじゃだめだ！となる訳ですが、、、）

この教材の解説動画は英語なので、全部ガッツリ見るというより、概要を把握するためにサラッと参考程度に流して見ました。大切なのは、実技（PracticeとTEST）です。本番のCKS試験もしっかりと実技試験なので、下記のような学習の流れが効率良い気がしました。

解説動画をサラッと見て概要を把握する
実技（PracticeとTEST）をガッツリやる
実技の解説で不明点があれば、そこだけピンポで解説動画／書籍／ネットで学ぶ

また、講座の中で実技環境は「Killer Shell CKS」という環境を利用するのですが、特に試験前の実技練習としては、実技試験は時間との勝負という点もかなり重要です。こちらのシナリオを何度も繰り返して実践して実技に慣れておくことを強くおすすめします。

２．参考書籍

英語が得意でない身としては、Udemyの解説動画やネット検索だけだと学習効率が悪いと感じたため、補助的な教材として、CKSを学ばれた何人かの方がおすすめしていたこちらの書籍を購入しました。

まず本の全体構成を把握するためにサラッと流し読みしました。その後は、ガッツリ全部読むというよりは、前述した実技（PracticeとTEST）を実践した後でポイントを絞って読むのが、個人的にはおすすめの読み方です。日本語で体系的学ぶために良い教材ではありますが、対策として必須か？と言われると少し微妙な気もします。日々どんどんとバージョンが上がっていくKubernetesに対して、本の情報は古いまま更新されていかないので、その点を理解してうまく活用する必要があります。（例：Kubernetes v1.25で削除されたPSPなど）

３．KodeKloud（※有償：$25/月）★サブスク契約サービス

前述の教材１と２で学び、昨年（2022年11月）CKSを受験したのですが、合格には至りませんでした。Udemyの教材を一旦やり切った気がしていたので、同じ教材だとどうしてもモチベーションが上がりそうもなく、加えて同じ教材で学んでも合格できるイメージが湧きませんでした。という訳で、こちらのサブスク教材を購入しました。

こちら教材は、実はCKAとCKADのUdemy教材で講師をされているお馴染みの方（Mumshadさん）で、なぜかCKSの教材はUdemyにないので、KodeKloudのサービスをサブスク契約して直接利用するという感じでした。内容はUdemyの講座と重複する点も多々ありましたが、全体的に簡潔で分かりやすい印象でした。Udemyと同様に実技を中心に実施し、実技の解説で不明点があれば、重点的に解説動画／書籍／ネットで学ぶ、というアプローチは同様です。

４．Kubernetes Exam Simulator（CKS Simulator）

CKSの試験申込みを行うと、こちらの試験シミュレーター（Killer Shell - CKS CKA CKAD Simulator）を2回まで利用できるようになります。1回あたり36時間利用でき、本番に近い環境で模擬試験を実施することができます。厳密には本番の環境とは異なりますが、かなり近しい環境で本番さながらの試験を体験できるので、試験までに必ず活用することをおすすめします。この模擬試験は、解説付き解答が用意されているので、うまく回答できなかった問題は、しっかりと解説を読んで理解します。実技を伴うこの試験では、本番試験中にじっくりと考え込む時間は殆どありません。そのため、ある程度感覚的に手が動くよう訓練しておく必要があります。この模擬試験は、36時間内であれば、何度でも再挑戦することができるので、試験1～２日前くらいにアクティブ化して2～3回ほど模擬試験を繰り返して手を動かしておくと良いと思います。

注意点としては、本番の試験と違い、この模擬試験では試験問題の言語を日本語に切り替えることができないため、Webブラウザ上の試験問題の英文をChromeのGoogle翻訳拡張などで翻訳しながら実施することになり問題文を理解するのに時間を要します。よって、模擬試験に設定された試験時間では足りなくなる可能性が非常に高いですが、本番ではそのようなことはないので、問題文の翻訳に要する時間については、あまり気にし過ぎなくても大丈夫です。

■ 試験本番の注意点

試験本番で気をつけることは、いろいろありますが、これまで受験された方々がいろいろとまとめ記事を書いてくれています。こちらのQiita記事が比較的新しい記事だったので「当日の試験について」を参考にさせてもらいました。当日の注意点の詳細は先達の記事に委ねたいと思いますが、前回CKAとCKADを受験し、今回CKSを受験して大きく変わったと感じた点について少しだけ触れておきたいと思います。

１．PSI Secure Browser（仮想接続を介して安全に試験配信する専用Webブラウザ）

前回（2020年）のCKAとCKADの受験時は、自分のPCにWebブラウザを使用して試験を受験するスタイルでした。そのため事前にBookmarkするなどして、試験で問われそうなドキュメントを準備した状態で試験に望むことができました。しかし、2022年6月から受験専用ツールである「PSI Secure Browser」を使用した環境のみでしか受験できなくなりました。現在はCKSだけでなくCKAやCKADなどの他の試験も同様の環境でのみ受験可能となっています。普段から使い慣れている自分のPC環境のWebブラウザと比べて操作感やレスポンスが大きく違うためこの点についてはかなり注意が必要です。（※以下が試験環境の説明動画です）

２．禁止された常駐アプリ（※これは、前回試験時もあったかも、、）

試験前のシステムチェックで終了させたはずの禁止ツール（Dropbox、OneNote、etc.）のサービスがバックグラウンドで勝手に起動して試験が中断される場合があります。CKSは試験時間が足りなくなることが多くいので、試験問題以外の要因で少しでも時間が削られるようなシチュエーションになると焦って自制心が乱れてしまいそうになりますが、もし中断されてしまった場合でも、対象のツール名がメッセージとして表示されるので、慌てず落ち着いてタスクマネージャなどから対象のサービスを終了して試験に復帰しましょう。もちろん、試験に全集中している時に思考が分断されてしまうのは良くないので、できるだけ自動起動しないように設定した状態で受験するのがベストです。ちなみに、私の環境の場合、試験中に２回ほど中断される羽目になりましたが、最小限のロスで復帰できたと思います。（実は計５回も受験したので大概のことに慣れてしまったという話もありますが...😅）

３．試験中のWebカメラの画角（※但し、試験監督によって差がある）

試験前のチェックで試験監督の指示で、受験する部屋の中をWebカメラで撮影して不正がないことを証明します。全てのチェックが終了して試験が開始されてからは、基本的にWebカメラは受験者の正面に設置し、受験者の顔が中央にしっかりと映っている位置で、リモート試験監督に監視されながら試験を進める必要があります。私の場合、初回受験時に正面でなく、斜め横にWebカメラを設置して受験したのですが、特に注意されることもないまま試験は終了しました。しかし、その後の再試験の受験時に別の試験監督から試験中にカメラ位置の是正を強く要求され、試験監督が納得するカメラ位置になるまで試験が中断されてしまいました。時間にして数分くらいだっと思いますが、どの位置に設置したら試験監督からOKが出るかを試験中に不慣れな英語のチャットでやりとり（※しかも、ChromeのGoogle翻訳拡張などは利用できません）しながら交渉するのはかなり骨が折れました。その後、試験には復帰しましたが、そもそも試験時間が足りないことに加えて、思考の分断、時間の浪費、それらによる焦りなどもあり、その試験はしっかりと不合格になりました。そんなもん、試験入る前に言えよ！って思ったりしましたが、後の祭りでした。ただでさえ時間が足りないCKSの受験においては、こういったちょっとしたことも、事前に把握して、準備しておくことが大事だと感じました。

■ 最後に

ずっと絶え間なく勉強を続けてきた訳ではありませんが、CKSを取得しようと思い立ってから取得までに1年くらいかかってしまったような気がします。結果的に受験履歴はこんな感じでした。改めて見るとひどい戦歴ですね、、、😅

2022/11/06：CKS-JP試験（初陣）←★不合格　※割引クーポン（22%Off）$320
2022/11/23：CKS-JP試験（再試験）←★不合格
2023/04/09：CKS試験　←★不合格　※割引クーポン（50%Off）$198
2023/04/12：CKS試験（再試験）←★不合格
2023/04/16：CKS試験　←☆合格　※割引クーポン（50%Off）$198

CKSの受験条件であるCKAの有効期限がもうすぐ（2023/04/27）切れてしまうこともあり、もう取得は無理かなぁ、と思った瞬間もありました。これまでCKAやCKAD、またAWSのSAPやDOPなどの勉強をして来ましたが、CKSは個人的には過去イチ難しい試験だったように感じました。昔と比べて試験制度が変わったこともあるため単純な比較はできませんが、個人的には、

個人的な試験難易度：CKS>>>>>>CKA>=CKAD

くらいの印象でした。（こちらのQiita記事の試験難易度に激しく同意です。※個人の感想）

なんとか目指してきたk8s認定資格の三冠を達成できたのですが、保有しているCKAやCKADはもうすぐ有効期限切れを迎えます。CKAやCKADの再取得を目指すかどうかは別途考えていきたいと思いますが、残すところ10日くらいある超刹那的三冠生活中は、一旦クールダウンしようと思います（笑）それでは、お疲れ様でした🙇

＜追記＞

ご覧のとおりひどい受験履歴でして、すべての受験費用をまともに定価でお支払いすると$1185（余裕で10万円超え）となってしまいます。が、定期的に公開される割引クーポン（10～30%）や過去にCKAやCKADなどを受験していると、半額バウチャー（なかなか気付かなくて見落としがちなので是非活用すべきです）がもらえたりします。これらを駆使することで全て合計しても$716の負担で済みました。まぁ、見方によっては、これでも十分お高いかもしれませんが、個人的には必要な投資だったかな、と考えて（言い聞かせて？）います。

2023-04-05

k8s NetworkPolicyの条件（ports）記述の注意点

CAKD CKA k8s kubernetes

NetworkPolicyでハマったので備忘録としてメモしておきます。

やりたいこと

名前空間 A の全 Pod を Namespace B の Pod への送信を制限する np という NetworkPolicy を作成する。（受信は特に制限なし）
名前空間 B の全 Pod が Namespace A の Pod からの受信しかできないよう制限する np という NetworkPolicy も作成する。（送信は特に制限なし）
ポート 53 TCP および UDP での DNS 通信を許可する。

やったこと（★失敗）

名前空間 A 用のNetworkPolicy

■ np-A.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: A
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: B
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

名前空間 B 用のNetworkPolicy

■ np-B.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: B
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: A

やったこと（☆成功）

名前空間 A 用のNetworkPolicy

■ np-A.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: A
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: B
  - ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

名前空間 B 用のNetworkPolicy

■ np-B.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: B
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: A

ハマった原因

成功と失敗で何が違うのかぱっと見ても分かりにくいと思うので差分表示してみます。

名前空間 A 用のNetworkPolicy（np-A.yaml）

←（左：★失敗）　｜　（右：☆成功）→

これ（ハイフン「-」の有無）に目視で気付くのは、かなり難しい気がしましす。（少なくとも私には）

しかも kubernetes の公式ドキュメント「ネットワークポリシー | Kubernetes」のサンプルは今回失敗したパターンの「 ports:」の記載のみで、成功パターンの「- ports:」という記載の仕方については、特に触れられていませんでした。これはハマりやすいやつですね。

今回の「ports」とは別のNetworkPolicy設定項目（「namespaceSelector」と「podSelector」）で類似の問題について解説されている記事「Kubernetes道場 16日目 - NetworkPolicyについて - Toku's Blog」を発見して、やっと原因に気付くことができました。（※以下の内容は、記事から抜粋して引用）

しかし、このフィールドは一部のフィールドの組み合わせが許可されており、以下のような指定が可能だ。（中略） なんとも分かりづらいが、 podSelector のハイフンが消えて、1要素になっている。この設定は project=test-app とマッチするNamespaceにあるPodで role=frontend とマッチするものが対象になる。要はこの記述でNamespaceとPodを同時に指定できる。

本当になんとも分かりづらい問題でした。

今後もNetworkPolicyのマニフェストを記述する際は、（portsのみならず）この点に注意したいと思いました。

さいごに

とはいえ、この手の問題は、実際に動作確認して気付くのが近道な気もするので、意図した挙動か下記のようなコマンドでとっととチェックした方が良いかもしれません。

■ 通信OK

kubectl -n A exec app1-0 -- curl -m 1 app1.B.svc.cluster.local
kubectl -n A exec app1-0 -- curl -m 1 app2.B.svc.cluster.local
kubectl -n A exec app1-0 -- nslookup tester.default.svc.cluster.local
kubectl -n kube-system exec -it test-pod -- curl -m 1 app1.A.svc.cluster.local

■ 通信NG

kubectl -n A exec app1-0 -- curl -m 1 tester.default.svc.cluster.local
kubectl -n kube-system exec -it test-pod -- curl -m 1 app1.B.svc.cluster.local
kubectl -n kube-system exec -it test-pod -- curl -m 1 app2.B.svc.cluster.local
kubectl -n default run nginx --image=nginx --restart=Never -i --rm  -- curl -m 1 app1.B.svc.cluster.local

2023-03-27

Dockerfile の Lintツール hadolint を触ってみた

CI/CD docker

ハロウィンのイラスト「黒猫の魔法使い」

Dockerfile の Lintツール hadolint を試してみました。

名前は【Haskell(ha) Dockerfile(do) Linter(lint)】を略して hadolint だそうです。

Dockerfile の記述内容がベストプラクティスに沿っているかチェックしてくれます。

例えば、下記のような使い方ができます。（一部未確認）

インストールせずコンテナイメージとして実行（★確認済）
インストールしてコマンドラインで実行（★確認済）
インストールしてVSCode機能拡張と連携して実行（★確認済）
CI/CDパイプラインに組み込んで自動実行＆通知（☆未確認）

また未確認のものもありますが、

作業記録＆作業レジューム用に今回試したことをGithubに置いておきます。

https://github.com/orinbou/how-to-use-hadolint

github.com

未確認のものは後日試してみようと思います。

2023-03-19

*[本]「Choose Your WoW!」: 働き方を最適化するディシプリンド・アジャイル・アプローチ（第2版）

Agile DevOps 読書開発プロセス Scrum XP

組織的なアジャイルの導入を学ぶために何をしたものかと思い悩んでいたところ、たまたま知人が参加している DA勉強会なるもの知り、私も参加してみることにしました。（DA：Disciplined Agile、ディシプリンド・アジャイル）

見学を兼ねて先月（2月9日）の月例会に参加せてもらったのですが、DA勉強会の教材としてこちらの書籍をご紹介いたいたので、早速購入して読んでみました。

www.kinokuniya.co.jp

ちなみにタイトルに含まれるWoWとは「チームの働き方（Way of Working ）」のことです。（この表現は私は今回が初見でした）

今回、私は電子書籍（Kindle版）で購入したので、すぐ読めましたが、ペーパーブックだと届くまでに結構時間がかかる（確かN週間くらい）らしいので購入される方はご注意ください。

本の構成

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

＜構成＞
第１章　働き方の選択

第２章　規律の実現

第３章　ディシプリンド・アジャイル・デリバリー(DAD)とは

第４章　役割、権利、責任

第５章　プロセス・ゴール

第６章　適切なライフサイクルの選択

第７章　規律ある成功

印象に残った点

DAのコンセプトについて共感できる部分がいくつかあったので、以下のとおり引用させてもらいます。（DAの詳細についてはここでは触れません）

はじめに

本書を読むべき理由

・特定の考え方に依存しないアドバイスを提供する

単一のフレームワークや手法のアドバイスに限定したものでも、アジャイルとリーンにも限定したものでもない。わたしたちの哲学は、出自を問わず優れたアイデアを探すことであり、ベストプラクティスというものは存在しないのだと認識することだ（ワーストプラクティスもない）。新しい技法を学ぶとき、わたしたちはその強みと弱みは何か、そしてどんな状況に適用できるのか（できないのか）を理解しようと努める。

本書の対象読者

アジャイルの純度にかかわらず、「アジャイルの枠組み」にとらわれずにものごとを考え、新しい働き方を実験する意欲がある人々を対象としている。さらに、コンテキストが肝心であること、誰もがそれぞれ独自の状況で独自の方法で働くこと、そして何にでも当てはまるプロセスはないと認識している人々を対象としている。独自の状況に置かれているとはいえ、前に似た状況に直面した他者がさまざまな戦略をすでに考え出しており、それらを採用してテーラリングすることが可能だ。つまり、他者がプロセスについて学習したことを再利用することで、組織にとって重要なビジネス価値を高めることにエネルギーを注げる。本書はこの点を理解している人々も対象としている。

１．働き方の選択

チームが働き方を自ら選ぶべき理由

・わたしたちは最高でありたいと思っている

マーチン・ファウラーは最近、「アジャイル・コンビナート」という造語を生み出した。これは、多くのチームが「似非アジャイル」戦略（「名ばかりのアジャイル［AINO］」と呼ばれることもある）に従っている状況を表現した言葉である。こうした状況は往々にして、組織がスケールド・アジャイル・フレームワーク［SAFe］のような規範的なフレームワークを採用したうえで、チームに対しても、そうするのが実際に合理的であるか否かにかかわらず（合理的ではないケースがほとんどである）、そのフレームワークを採用することを強いている、あるいは、組織の標準として採用されているスクラム［ScrumGuide、SchwaberBeedle］に従うことをチームに強いていることの所産である。だが、本家本元のアジャイルは、個人と対話をプロセスやツールよりも重視するという非常にわかりやすいものだ。つまり、チームは働き方を自ら選び、それを進化させることを許されるべきであり、さらに欲を言えば、そのためのサポートを受けるべきなのである。

２．規律の実現

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

「アジャイル・ソフトウェア開発宣言」の発表は、近年わたしたちが経験してきたようにソフトウェア開発の世界にとって、またビジネス界にとっても、画期的な出来事となった。しかし、時の流れは残酷なもので、アジャイル・マニフェストは次のようないくつかの点で古臭さを感じさせるようになってきた。

1.対象がソフトウェア開発に限定されている

アジャイル・マニフェストは、あえてソフトウェア開発に対象を絞って策定されたため、ITの他の側面はもちろん、エンタープライズ全体の他の側面も対象にしていない。アジャイル・マニフェストの概念の多くは、ソフトウェア開発以外の環境に合わせて調整することもでき、実際に長年そうされてきた。したがってアジャイル・マニフェストは、私たちが進化させることができる貴重な洞察を提供してくれており、当初意図したよりも対象を広げて進化させ、拡張させるべきものなのである。

2.ソフトウェア開発の世界は進歩した

アジャイル・マニフェストは1990年代の環境に合わせて策定されているため、その原則の中には時代遅れになったものもある。たとえば三つ目の原則は、ソフトウェアを2-3週間から2-3ヶ月ごとにリリースすることを勧めている。当時、デモンストレーション可能なインクリメントに分割してソリューションをデリバリーすることは、たとえ一か月ごとに行うとしても偉業だった。ところが現代では、偉業のハードルは大幅に上がり、アジャイルに習熟した企業は1日に何度も機能をデリバリーしている。これは、アジャイル・マニフェストがわたしたちをより良い方向へ導いてくれたおかげでもある。

わたしたちは以下の原則を信条とする

実際のところ、DAツールキットは当初から、さまざまな優れた戦略を組み合わせ、それらすべての戦略同士が実際にどのようにかみ合うのかに注目して開発されてきた。わたしたちは、科学的なアプローチと実際に役立つものが重要であることは信じて疑わないが、そこへたどりつく方法については、特定の考え方には依存しない。

原則：選択肢があるのは素晴らしいこと

この選択主導の戦略は中道である。両極の片側に位置するのは、規範的な手法だ。つまり、スクラム、エクストリーム・プログラミング（XP）、SAFeといった、ものごとを所定の方法で行うことをわたしたちに求める手法である。（…中略…）両極のもう一つの片側に位置するのは、自分たちの課題に注目して独自の手法を編み出し、原則に基づく新たなプラクティスを生み出して、それらを実験として試行しながら学習するという手法である。

おわりに

DAのコンセプトについては賛同できる点がいくつもあり、上記にその一部を引用させてもらいました。ここ最近、自分の中の問題意識として「アジャイル宣言」について思うところがあり、昨年末ブログにその思いの丈を書いたのですが、DAのコンセプトの中では、その点についてしっかりと触れられています。また、「特定の考え方に依存しない」ことを明言している点も、特定の手法を変に神格化しないという意味で好意的に受け止められました。

ということで、DAのコンセプトは概ね抵抗なく受け入れられる気がしましたが、これをどうやって実践し、更に、結果（価値）に繋げていくのか、についてはまだよく分かっていません（まだ実践してないから当たり前ですが）。

特定の考え方や手法に限らないこともあり、DAツールキット（道具箱）に収められた知識ベースは膨大な印象で、効率的に実践に繋げるための具体的な手段（DA Browserというものがあるらしいのですがまだ使ってない）がないと絵に描いた餅になりそうな気もしました。

実践に繋げるためにも、今後もDAのキャッチアップを続けていきたいと思います。

2023-03-18

*[本]「アジャイル開発の法務」: スクラムでの進め方・外部委託・偽装請負防止・ＩＰＡモデル契約とカスタマイズ

Agile Scrum 開発プロセス契約法務

Agile Studioさんから書籍「アジャイル開発と法務」をプレゼントしていただきました。

books.rakuten.co.jp

はじめに

アジャイル開発を実践する上で、契約は悩ましい問題のひとつだと思います。

本書はIPAモデル契約策定に携わった弁護士（梅本氏）が書かれた書籍で昨年2022年11月に発売されたものです。2023年1月30日(月)に開催されたAgile Studioさんのウェビナーに参加したら幸運にも献本いただけました。ありがとうございます🙇

本の構成

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

＜構成＞
■第１章　アジャイル開発の紹介（P.1~30：30頁）
第１　アジャイル開発の概要

第２　アジャイル開発とウォーターフォール開発との比較

第３　プロトタイピング開発、スパイラル開発との比較

第４　アジャイル開発（スクラム）の進め方

第５　アジャイル開発を成功させるためのポイント

■第２章　法務的観点から見たアジャイル開発（P.31~38：8頁）
第１　アジャイル開発に関係する法律

第２　アジャイル開発の外部委託

■第３章　アジャイル開発と契約（P.39~98：60頁）

第１　公表されているモデル契約

第２　アジャイル開発の外部委託契約において検討すべき問題

第３　アジャイル開発に関する裁判例

■第４章　アジャイル開発と偽装請負（P.99~130：32頁）

第１　いわゆる偽装請負とそのペナルティ

第２　厚生労働省の派遣・請負区分基準

第３　アジャイル開発向けの疑義応答集第３集

■第５章　IPAモデル契約（2020年３月公表）の活用（P.131~185：55頁）

第１　IPAモデル契約の活用方法

第２　IPAモデル契約をカスタマイズする際のの注意点

第３　IPAモデル契約の変更例

第４　IPAモデル契約の別紙のカスタマイズ

第３章（60頁）、第５章（55頁）の内容が厚くなっており本書が取り扱うメインテーマについて語られている。特に第３章「第３　アジャイル開発に関する裁判例」では、実際の裁判例が掲載されており個人的にはここが一番面白かった（※注：興味深い、という意味です。詳細は後述）です。また、第５章では、2020年版IPAアジャイル開発モデル契約を参考に、契約のカスタマイズ例や注意点について解説されており、今後の契約を見直す際の参考になりそうでした。

印象に残った点

一番印象に残ったのは（アジャイル開発に関する？）裁判例でした。裁判例を読みながら、裁判に至るまでPM含めたステークホルダーの人々は一体何をしていたのだろう、とか「いや、そうはならんやろ！」→「なっとるやろがい！」が頭の中でグルグルとループしました😅。文章化されない背景には、止むに止まれぬ事情（あんなことやこんなこと）があったのだとは思いますが、それを窺い知ることまではできませんでした。

第３章「第３　アジャイル開発に関する裁判例」

【裁判例１】東京地判平成24年5月30日ウエストロー・ジャパン2012WLJPCA05308009

ベンダが、アジャイル開発であるためドキュメントを作成していないと主張したのに対し、裁判所は、アジャイル開発であってもシステム保守のためには最低限のドキュメントの作成は必要なはずと判断した事例

【裁判例２】東京地判平成26年9月10日ウエストロー・ジャパン2014WLJPCA09108013

ベンダが、アジャイル開発であるためドキュメントは作成されないと主張したのに対し、裁判所は、アジャイル開発でもテスト結果を記録した書面やユーザ側の確認をとった記録はあるはずと判断した事例

【裁判例３】東京地判平成30年2月27日ウエストロー・ジャパン2018WLJPCA02278037

ベンダが成果報酬型収益配分モデルでアジャイル開発を行ったものの、開発が途中で頓挫したため、それまで稼働した分について報酬請求をしたが、裁判所は請求を認めなかった事例

【裁判例４】東京地判令和2年9月24日ウエストロー・ジャパン2020WLJPCA09248012

ベンダが期限までにシステム開発を完了しないまま報酬を請求し、完成義務を負っていたか否かが問題となったが、裁判所は契約に至る経緯と契約書の内容から準委任契約と認定し、報酬請求を認めた（また、ベンダの善管注意義務違反も認定し、ユーザによる損害賠償請求も同時に認めた）

【裁判例５】東京地判平成29年11月21日ウエストロー・ジャパン2017WLJPCA11218019

ベンダが完成すべき成果物の内容が争われたが、裁判所は、当初作成された設計書ではなく別途ユーザの指示する仕様に従って成果物を完成させることが合意されていたとのベンダの主張を認め、完成を認めた事例

【裁判例６】東京地判令和3年9月30日ウエストロー・ジャパン2021WLJPCA09308022

ベンダがウェブサイトへの機能追加を請け負ったが、既存のウェブサイトと異なる開発言語を使って開発を行ったことが債務不履行とされ損害賠償責任が認められた事例

【裁判例７】東京地判令和3年11月25日ウエストロー・ジャパン2021WLJPCA11258010

契約において業務対価が固定されている場合には、ユーザが希望する仕様をベンダに伝えたとしても、その指定がそのまま仕様として確定するわけではない理解を前提に、開発が頓挫した原因は、ユーザが（業務対価に応じた内容に）要求事項を絞り込まず仕様を確定させなかったことにあると判断された事例

おわりに

不幸にもアジャイル開発の間違った解釈（※但し、答えはひとつではない）のせいで生じた訴訟や裁判エピソードのおかげで、アジャイル開発自体が悪者になってしまっているとしたらとても悲しいことです。既に起きてしまったことにタラレバは無意味かもしれませんが、裁判例に記載されたような体たらくであることを考えると、開発手法には関係なく訴訟が起きていたんじゃなかろうか、と思ってしまいました。

但し、このような問題を他人事と考えてはいけないと思います。これまで出会したことがなかったとしても、この先、場合によっては自分が引き起こしたり、誰かに巻き込まれたり、誰かを巻き込んでしまったりすることも十分あり得ると考えるべきでしょう。そうならないよう普段から十二分に配慮しつつ、そうなった場合に対して備えておくことが重要だと思います。

おまけ

手前味噌ですが、以前（もうだいぶ前だな）若手SE向けに契約周りの基本の基(キホンノキ)をまとめたスライドを公開してたことを思い出したんで記事のリンク貼っときます。

SEのための契約知識【超】入門 - 機雷がなんだ！全速前進！

2023-03-04

*[本]「アジャイルソフトウェア開発エコシステム」: Agile Software Development Ecosystem

Agile Scrum 読書開発プロセス XP ASDE

2003年9月に発売された「アジャイルソフトウェア開発エコシステム」を読みました。

books.rakuten.co.jp

はじめに

今からおよそ20年前に発刊された書籍です。

"本書は、以下の3つの基本的な質問に回答する。

（１）アジャイルが最も得意とするのはどのような問題か。

（２）アジャイルとは何か。

（３）ASDE（アジャイルソフトウェア開発エコシステム）とは何か。"

ということで、アジャイル（開発）とASDEについて書かれた本です。

本の構成

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

＜構成＞
■パート１　問題と解決策

第１章　変化主導経済

第２章　IDXシステムズ社

第３章　アジャイル

■パート２　原則と人

第４章　Kent Beck（※補記：ケント・ベック）

第５章　有用なものの納品

第６章　Alistair Cockburn（※補記：アリスター・コーバーン）

第７章　人を信頼

第８章　Ken Schwaber（※補記：ケン・シュウェイバー）

第９章　

第１０章　Martin Fowler（※補記：マーチン・ファウラー）

第１１章　技術的な素晴らしさ

第１２章　Ward Cunningham（※補記：ウォード・カニンガム）

第１３章　最もシンプルなことを行う

第１４章　Jim Highsmith（※補記：ジム・ハイスミス）

第１５章　適応性

第１６章　Bob Charette（※補記：ボブ・シャレット）

■パート３　アジャイルソフトウェア開発エコシステム

第１７章　スクラム

第１８章　DSDM（※補記：Dynamic Systems Development Method）

第１９章　クリスタル方法論

第２０章　FDD（※補記：Feature Driven Development）

第２１章　LD（※補記：Lean Development）

第２２章　XP（※補記：Extreme Programming）

第２３章　ASD（※補記：Adaptive Software Development）

■パート４　ASDEの開発

第２４章　エコシステムの明確化

第２５章　独自のアジャイル方法論の設計

第２６章　アジャイルのメタモルフォーシス

昨今スクラムやXPばかりが取り上げられている気がしてなりませんが、パート３では、それらも含めた主なASDEについて簡単な経緯も含めて解説してくれているのが個人的にありがたかったです。

印象に残った点

印象に残ったフレーズ、以下にメモしておく。

アジャイルとは何か

"他の複雑な概念と同様に、アジャイルには多くの定義がある。しかし、筆者は以下の定義が最も明確だと思う。

アジャイルとは、激動するビジネス環境で利益を得るために、変化をもたらし、かつ変化に対応する能力のことである。"

ASDEとは何か

"アジャイルソフトウェア開発方法論についての本書を書き始めたが、「方法論」という語に常に不安を抱いていた。なぜなら、「方法論」という語はアジャイル開発の焦点である「人、関係、不確定性」に適さないからである。さらに、「方法論」という語を使用すると、アジャイルのプラクティスは従来のソフトウェア開発方法論と比較され、そのため誤った比較の目安が使用される。したがって、ASDE（アジャイルソフトウェア開発エコシステム）という用語を使い、3つの絡み合う構成要素を含む全体的な環境を表現している。この3つの構成要素とは、カオーディック（chaordic：カオスと秩序）な観点、協調的な価値と原則、最小限な方法論である。ASDEの提唱者を表すアジャイリストという用語も、この全体的な環境に含まれる。

「アジャイル」が少ないプロセス、儀式、簡略な文書を意味すると考える人もいる。しかし、「アジャイル」にはもっと広い観点があり、そのため「方法論」という語ではなくエコシステムという用語を使用している。"

カオーディックな観点

"日々のプロジェクト作業で、カオーディックな観点は以下の2つの成果をもたらす。この成果は、厳密な方法論とは正反対である。

●製品目標は達成可能であるが、予測可能ではない。

●プロセスは一貫性を助長するが、再現可能ではない。

主なASDEとその開発者

スクラム（Scrum）

スクラムはラグビーのスクラムから命名された。最初はKen SchwaberとJeff Sutherlandが開発し、その後Mile Beedleと共同開発した。スクラムはプロジェクト管理フレームワークを提供する。このフレームワークはスプリントという30日間周期の開発に焦点を当てる。各スプリント内では特定のバックログ群というフィーチャ群を納品する。スクラムのコアプラクティスは、調整と統合のために、毎日15分間のチームミーティングを行うことである。スクラムは約10年間、幅広い製品の納品を成功させるために使用されてきた。Schwaber、Sutherland、Beedleはアジャイル開発宣言の作成に参加した。

DSDM（Dynamic Systems Development Method）

1990年代中頃にイギリスで開発された。これはRAD（Rapid Application Development ）のプラクティスの派生物かつ拡張である。少なくともヨーロッパでは、各ASDEの中で最も支持されるトレーニングおよび文書化を誇る。DSDMは、活発なユーザ参加、頻繁な納品、チームでの決定、プロジェクトのライフサイクルを通じての結合テスト、開発における可逆変化などの9原則を含む。BennekumはDSDMコンソーシアム役員会のメンバで、アジャイル開発宣言の作成に参加した。

クリスタル方法論（Crystal Methodologies）

Alistair Cockburnは人中心の「クリスタル」ファミリーの作成者である。Cockburnは「方法論考古学者」で、世界中の多くのプロジェクトチームにインタビューし、機能することと、人が機能するということとを分離することに努めた。Cockburnとクリスタルは、協調、帰属意識、協力といった開発における人の側面に注目した。Cockburnはプロジェクトの規模、重要度、目的を使用し、適切に設定したプラクティスをクリスタルファミリーの各方法論（クリア、イエロー、オレンジ、レッド）のために作成する。Cockburnもアジャイル開発宣言の作成に参加した。

FDD（Feature Driven Development）

Jeff De LucaとPeter CoadはFDDを共同開発した。FDDは最小限の5ステップのプロセスで構成される。このプロセスは、総合的な「形状」オブジェクトモデルを開発し、フィーチャ一覧、およびフィーチャによる計画、イテレーティブなフィーチャによる設計、フィーチャによる構築の各ステップを順々に行う。FDDのプロセスは簡潔で（各プロセスは1ページで記述される）、FDDにおける2つの重要なロールはチーフアーキテクトとチーフプログラマである。FDDがXPと異なる点は、「軽い」事前のアーキテクチャモデリングである。オーストラリア人のDe Lucaは50人以上の（アジャイル開発としては）大規模なプロジェクトの事例を2つ提供した。John KernはCoadの会社であるTogetherSoft社のプロジェクト開発責任者で、アジャイル開発宣言の作成に参加した。

LD（Lean Development）

最も戦略的思考のASDEは知名度が一番低い。Bob CharetteのLDはリーン生産方式に由来する。リーン生産方式とは1980年代に日本の自動車製造業界で再構築された方式である。変化に対する従来の方法論的観点は、制限的な管理プラクティスで制御すべき損失のリスクであった。しかし、CharetteはLDでこれを拡張し、変化を、「リスク起業家精神」を使用して実行する「機会」の生産とした。LDはヨーロッパの大規模電気通信プロジェクトで多く使用され、成功した。

XP（Extreme Programming）

Kent Beck、Ward Cunningham、Ron Jeffriesが開発した。XPはコミュニケーション、シンプル、フィードバック、勇気の価値を説く。XPの重要な側面は、変化に対するコストの見方を変えるのに貢献したこと、およびリファクタリングとテストファースト開発によって技術的長所を強調したことである。XPは全体的な単位としての完全性が証明された動的プラクティスの体系を提供する。XPはアジャイル開発の中で最も関心を集めている。Beck、Cunningham、Jeffries、Fowlerは、アジャイル開発宣言の作成に参加した。

ASD（Adaptive Software Development）

アジャイル運動に対する筆者（Jim Highsmith）の貢献である。ASDはアジャイル方法論の哲学的な背景を提供し、ソフトウェア開発組織が、変化を避けるのではなく利用することで、返上のビジネス環境の激動に対応する方法を示す。ASDはイテレーティブな開発、フィーチャベースの計画、ユーザフォーカスグループレビューといったプラクティスと、リーダーシップ協調管理と呼ばれる「アジャイルな」管理哲学を含む。Highsmithもアジャイル開発宣言の作成に参加した。

その他、気になった点のメモ

ASDEとRSMの違い

ASDEとRSMの違いは、拡張的な文書化や、文書化がないのではなく、理解を伝達するための文書化と協調の混合である。アジャイルの実践者は、相互作用に傾倒する。厳密な方法論は、文書化に傾倒する。

BrownとDuguid2000

BrownとDuguidは、Xerox社のコピー機修理エンジニアの間での知識共有の研究について述べる。形式手な文書があるにも関わらず、難しい問題は、エンジニアが呼び出される前の朝食時の会話で解決されることが多いとわかった。

プロセスへの過剰な期待

すべてのツール、技術、好みのプロセスを配置せよ。しかし、最終的には成功と失敗の最大の違いは人である。プロセスのアイデアを作り出すためにどんなに一生懸命作業しても、期待できる最良のことは、プロジェクトにおける二次的な効果であるとわかった。したがって、一次的な人の要因を最大化することが重要である。

プロセスは、人が共同作業するのを支援する。共通のフレームワーク、共通の言語、問題を理解するのに役立つチェックポイントを提供することができる。しかし、コンピタンスや協調の問題を補うことはできない。

Bollesの指摘

手法がXPやCMMに関わらず、プロセスはスキルの代用物ではないということである。プロセスが重量でも軽量でも、アジャイルでも厳密でも、プロセスに従うだけでは優れたコード（または優れたテストケースなど）を作成できない。スキルが優れたコードを作成する。

プラクティス（または技法）

プラクティス（または技法）は方法論の活力源である。ペアプログラミング、スクラムのミーティング、ユーザフォーカスグループ、自動テストのいずれであっても、ASDEのプラクティスは才能とスキルがある個人によって実行され、成果を生む。

計画について

計画とはテストされる仮説であり、実現される予測ではない。

それぞれの中心主義者

プロセス中心主義者は人を後回しにする。プラクティス中心主義者は人を最優先する。プロセス中心主義者は（記述された）形式知を重視する。プラクティス中心主義者は（内部の）暗黙知を重視する。

ソフトサイエンス

人間工学、コミュニケーション、協調は「ソフトサイエンス」として知られているが、習得するのは難しい。

→soft science：科学そのものではなく、科学の利用の仕方を扱う科学を指すらしい

「方法論」という語はアジャイル開発の焦点（人、関係、不確定性）に適さない

「方法論」という語はアジャイル開発の焦点である「人、関係、不確定性」に適さないからである。…（中略）…方法論（methodology）という用語は、アクティビティ、プロセス、ツールといった物事のビジョンを連想させる。

はじめに

試行環境

初期状態

FW設定変更

TCP接続を許可する

接続を許可する

特定IPからの接続を許可する

FW有効化

FW実行／停止

手動で実行する

手動で停止する

参考

Kubernetes認定資格について

■ 試験対策について

１．Udemy（※有償：¥4800 → ¥2400）★50%OFF！

２．参考書籍

３．KodeKloud（※有償：$25/月）★サブスク契約サービス

４．Kubernetes Exam Simulator（CKS Simulator）

■ 試験本番の注意点

１．PSI Secure Browser（仮想接続を介して安全に試験配信する専用Webブラウザ）

２．禁止された常駐アプリ（※これは、前回試験時もあったかも、、）

３．試験中のWebカメラの画角（※但し、試験監督によって差がある）

■ 最後に

やりたいこと

やったこと（★失敗）

やったこと（☆成功）

ハマった原因

さいごに

本の構成

印象に残った点

はじめに

本書を読むべき理由

本書の対象読者

１．働き方の選択

チームが働き方を自ら選ぶべき理由

２．規律の実現

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

わたしたちは以下の原則を信条とする

原則：選択肢があるのは素晴らしいこと

おわりに

はじめに

本の構成

印象に残った点

第３章「第３ アジャイル開発に関する裁判例」

おわりに

おまけ

はじめに

本の構成

印象に残った点

アジャイルとは何か

ASDEとは何か

カオーディックな観点

主なASDEとその開発者

スクラム（Scrum）

DSDM（Dynamic Systems Development Method）

クリスタル方法論（Crystal Methodologies）

FDD（Feature Driven Development）

LD（Lean Development）

XP（Extreme Programming）

ASD（Adaptive Software Development）

その他、気になった点のメモ

ASDEとRSMの違い

BrownとDuguid2000

プロセスへの過剰な期待

Bollesの指摘

プラクティス（または技法）

計画について

それぞれの中心主義者

ソフトサイエンス

「方法論」という語はアジャイル開発の焦点（人、関係、不確定性）に適さない

第３章「第３　アジャイル開発に関する裁判例」