２年ぶりに資格を受験をしてきた話
はじめに
約２年ぶりくらいに ITベンダの資格を取得したのでその備忘録を残しておきます。
新人の頃は 業務も資格取得もがむしゃらにやっていましたが 3年目を過ぎたころから燃えさかる熱が冷めて、受験する回数がめっきりなくなっていました。
今回久しぶりに受験した資格は Certified Kubernetes Application Developer (CKAD)というもので、CNCFとLinux Foundation が運営しています。
CKAD は アプリ開発者を想定し、k8s を 利用したアプリ開発をするうえで必要になってくるスキルを習得するという目的みたいです。
受験に至った経緯
今までは主にAWS の ECS に アプリ を デプロイすることが多かったのですが、最近 はプラットフォームが変ってきており、 EKS が台頭し始めたことで ECSから EKSへマイグレーションするケースがちらほら来ていると感じます。
実際私も EKS の on-boarding のタスクを直近実施して 悪戦苦闘しました。
そういった中で、CNCFは k8s を中心としたエコシステムを築いていることを知り、 とたんに興味関心がわきました。
最近ベンダ資格を受けるモチベーションが出てませんでしたが久々に わくわくするものを見つけたためCKADを 受験しようと思いました。
私の エンジニアリングスペック
本題に入る前に 勉強開始前の私のスペックを書いておきます。
- サーバサイドの開発にはある程度精通している
- k8sの全体的な仕組みは 公式の絵本を読んで「へぇ～」と思っている程度
- kubectl での操作は get 系のコマンドしかよくわからないwww.youtube.com
勉強方法
まずは公式の絵本を読む
まず無知だった私は上述したk8sの絵本をを再度読み直しました。
個人的にはこの絵本がk8sと k8s に対して難しいイメージを抱いていたわたしの距離を縮めてくれたかなと思います。（心の距離は意外とモチベに影響してくる）
受験後に振り返ると、CKADで出題された問題群のほとんどは この絵本で登場していたリソースに関するものでした。
Udemy便利
絵本を読み終わったのちにUdemy で Mumshadさんの講座を受講しました。
やり方の方針は下記
- すべての講義を一周し、リソースの目的や使い方について理解を深める
- 付属の mock test を合格するまで反復する
CKADの試験はすべてにおいて コマンド操作が伴うため、ドキュメントを読んで知識だけ蓄えるだけだと不十分です。ある程度手を動かせるかどうかがカギになってきます。
その点、上述の講座の 練習問題は ブラウザから Kode Kloud で用意している 練習用の instance にアクセスでき、実際にコマンドを打ちながら学ぶことができます。
なので、リソースをいろいろいじって練習する場としては最適なのでおすすめです。
Udemyはよくセールをしているので、安くなったタイミングで購入しておくとよいと思います。
当日のお話
コロナ禍もあってか、最近の資格は自宅でも受験ができるシステムになっていってるみたいです。
CKADも自宅受験が可能だったので今回は自宅で受験しました。(テストセンターに行ってた日々が懐かしい)
試験日は余裕を持ったスケジュール確保をしておいたほうがいい
試験自体は2h なのですが、 試験前にリモート先の試験官による checkが入ります。
例えば下記のようなことをやりました。
- web カメラで部屋全体をゆっくり見せる
- 余計な電子機器は部屋から排除する
- スマホと顔が常時カメラから見えるよう調整する
こんな感じで、いろいろcheck することが多く私は 約 30 min かかりました。
また、webの他の方の記事だと当日トラブルが発生して、つながらなくなる事象もいくつか見ました。
なので、 当日試験時間の直前と直後には別の予定をスケジュールしないほうが良いと思います。
身分証明書の確認はパスポートが早い
試験官に 身分証明書をカメラ越しにcheckしてもらうのですが、
最初私が運転免許証を見せた後に 問答無用で パスポートはあるかどうか聞かれました。
私は自宅で受験したので手元に有り、すぐ出せたのでそれを見せると すぐ確認が終了しました。
webでCKADを受けた方の記事では, 身分証明書を２つ(exp. 運転免許証とクレジットカード)見せなければいけなかったパターンもあるそうです。
私の場合、パスポートならそれ1枚見せただけですぐ終わったので、これから受験する方はそのほうがスムーズなのかなと思います。
さいごに
結果は 合格点 が66 点のところ、70点の scoreでした。
結構ギリギリ。。。
CKADは 時間が足りなくなる系の試験だったので
全部の問題に必ず目を通して自分が解けそうな問題を優先して解きに行くことがポイントかなと思いました。
下期も何か受けないと。。。
次はこれかな 受けるかわからんけど
agile「守・破・離」の「破」くらいまではできてきたんじゃないかなという話
ブログ開設一発目には日々携わっているagileの話についてつらつら書いていく。
わたしについて
- 中堅規模のSIerに所属
- サーバサイドの開発に従事
最初はagileな現場に入ると聞いて意気揚々と参画した。
しかし、参画したての頃は以前まで所属していたウォーターフォールPJと比較して劇的な変化を感じることはできなかった。
ただ、時間を経て直面している課題やチームの現状を認識できてくるとそれらに対する自発的な行動をメンバがある程度自由にできる風土、文化が当たり前に存在していることに気づいた。これはウォーターフォールPJではなかったことだったため、そこから少しずつ社会人としてチームのために自律した行動をするという意識が芽生え始めたと振り返る。
agileなFWに基づいてただやることがagileな働き方に直結するとは限らない
scrumといっても、実は自分の参画しているチームの特徴は以下のような感じである。
- プランニングは最小限(2week sprintで1h)
- タスク分解はassigneeにほぼ任せている。
- story pointの付与もplanningの時間でできるものだけやる
- user story、story point の消化数の推移などのtrackingも非積極的
これ自体は一件無計画に運用していると思いきや
チームである程度合意したいわば戦略的な措置なのである。
- planning時に計画したものでsprintが進まないことがわかりきっている（突発でくるsupport対応など）
- POCや調査系taskがほぼほぼを占めており、相対見積もりができない
- プロダクトの特性上、開発メンバが作業しているものが技術的に独立している（メンバの作業状況が互いのクリティカルパスにならない）
こういった特徴からplanningでチームメンバ全員の時間をとって、user story一つ一つに対して、やりかたや勝ち筋を丁寧に見出す作業は行っていない。
ふわっとした内容でも作業者に任せて、全体の調査をしてもらい後追いでどの程度のscopeか判断していくようにしている。
(もちろんdaily scrumではメンバの状況のsyncは常に行っている。)
大事なのはチームの抱えている状況や特徴を見極め、仲間と話し合うこと
scrum guideはいわば必修の教科書であり、全てのPJに共通的に実施して失敗しないだろう方向性を見出してくれていると思っている。
これは有用であり、まずは教科書通りに実践してみることから始めるべきなのは至極当然である。これがいわゆるagileの「守」である。
ただ、それだけをひたすらやっていくことだけで全員が満足して開発を進めていけるとは限らない。
やり方や手段には必ずメリットとデメリットが存在している。
そんな中で、メンバ内で薄々感じている
- 「これってちょっとモヤっとポイントだよな」
- 「このやり方ってうちのチームには合ってないような」
- 「やってても何も恩恵ないな」
などの声が出てくるはずである。
これらの潜在意識を表面化させていき、チームの体質改善につなげていくことが
agileの「破」になっていくのかなと思う。
私の所属するチームは厳密にscrum guideには則っていないかもしれないが、
在籍しているメンバで良いものを作り続けるためにはどのように変化、進化していくべきかは模索し、実行できているなとは思う。
最後に
東北楽天ゴールデンイーグルスの石井監督の言葉に対して、agileなチーム開発に通ずるところを感じたため引用する。
オフが野球界では大事になってきている。自分なりのオリジナル野球観、教科書を作って、大人な選手になってほしい
自分なりのagileな働き方がどういうものか、オリジナルのagile教科書をそれぞれが作りあげていくことで、素晴らしいproductを生み出していけると思う。
まあ、私は鴎党ですがね。
