説得が先か、納得が先か
（2022年頃に思いついたネタをまだ投稿していなかったことに気づき、公開しないのも勿体無いと思いたったので夜中に微修正して出しました）
今回の話はいままで他者とのコミュニケーションでうまくいかないなぁともやもやしていたことを吐き出してみました。
- 概略：相手に行動の変化を求めるようなコミュニケーションでは、説得しようとする前に納得してもらうことを考えるべき
- 背景・状況（どうなっていたか・どんな問題を抱えていたか）
- ここ１年くらい自分の成果物に関する設計上の工夫点や処理の流れをメンバに話してもなんか腹落ちしている様子がない
- 自分のなかでは十分な情報を提示しているつもりでも相手の反応が薄かったり、解消したのかが不明のまま終わる
- チーム内で自分の発言の影響力が上がってこない
- レビュアーのテンションが落ちてるなぁと感じる（リマインドしてもすぐみてもらえなかったり。。）
- 気づき
- 自分の意見が正しいことに自信があり、それをわからせれば問題解消につながると暗黙的に思ってしまっていた。
- 実際考慮すべき点などが抜けていたりしており、要件や設計の議論が足りていないことを認識できていなかった。
- 無理に説得しようとしていた姿勢が相手からするとすごい圧でめっちゃ言ってくる人に見えていた。
- 自分の主張、意見、気持ち100%を相手が欲していることはない。
- 今後の行動：相手を説得するのではなく、納得してもらうためのアクションをとる
-
- チームの課題として捉え、憂慮点・考慮点を互いに共有する
- 論点を絞れた上で、それを満たす材料を提示する
- 提示したものに対して、相手が理解を示してくれた点を確認する
- 逆に指摘事項が出た点については、その指摘の意図を確認する
- やりとりを通じて、確実に進捗が出ていることを互いが実感する
-
MCPC IoTシステム技術検定［上級］ 合格レポート
ビジネス関係の資格試験を受験して合格できたのでそのレポートを書きます。
私自身IoTシステムに関する業務経験はなかったのですが、対策次第で十分合格できると感じています。私と状況が近い方にとって参考になる内容となれば幸いです。
試験について
概要
私が受験した試験はMCPCという通信やネットワーク関係の団体が運営している
IoTシステム技術検定は基礎、中級、上級が存在しており、それぞれのレベルで問われる内容が異なります。今回受験した上級はIoTシステムを構築するためのエンジニアリングスキルは一定のレベルまで保持していることを前提とし、それを世の中の課題解決に適用したり、顧客と価値を明確化して事業化することまで含めて問われます。システムの企画の部分がメインですので一般的なITベンダ資格とは問われる内容も学習の方向も異なるなと個人的には感じています。
受験条件
まず、上級の受験には前提条件がありますので注意が必要です。多くの方は”中級の合格者であること”という条件で受講すると思います。そのため、まずは中級の合格を目指してください。中級試験に関することはWebに先人たちのありがたい受験レポートがあるためそちらを参考にしてください。私は2023年度に早稲田大学のリカレント教育プログラムであるスマートエスイーを修了していたため、その条件で上級試験を受験しています。
受験前の状況
前提として受験前の私のスペックを書いておきます。
SI業務に約６年間従事しており、主にWebのバックエンドやモバイルアプリの開発などをしてきました。通信やIoT関係の業務経験はないので、そのエンジニアリングスキルはスマートエスイーで学びました。
どんな学習をしたか
学習スケジュール
今回は長めの学習期間を費やすことができませんでした。
2月2,3日が試験日で、学習を開始したのが１月の正月休み明けくらいからです。そして、切羽詰まって本腰入れたのが試験日の１週間前くらいでした。
まともな試験対策ができていたかというと、微妙なところではあります。
また、本試験のためにIoTに関するスキルを補完するような学習は特にしておりません。
以下実施したことを参考程度に書いておきます。
- IoTシステムの事例収集(2day)
- ビジネスモデルキャンバスの作成(2day)
- 手書き予行練習(3day)
IoTシステムの事例収集
試験で課されるテーマが自分の精通している領域とは限らないため、ざっくりと業界ごとにIoTシステムの適用事例を調査をしました。
とはいえ、闇雲に調査しても時間がかかるため私は農業、製造業、社内DXの３つに絞って事例を調査していました。この事例収集の際に、私が意識していた点をいくつか挙げておきます。
- 誰のためのシステムか？（誰からお金をもらうのか）
- 具体的な課題は何か？
- どんな価値があるか？
- ステークホルダーは誰か？
- どのような技術で価値をもたらしているか？
私は農業や製造の現場経験がないため、ステークホルダーを整理して誰がどんな課題を抱いており、それがどのように組織や経営に影響を及ぼしているかを理解しようと調べていきました。
ただ、現場を知らない立場からするとWebの事例調査だけでは当事者目線を得にくかったため、調査した内容を製造業関係の友人に共有した上で現場ならではの声をヒアリングしてみたりしました。
ビジネスモデルキャンバスの作成
事例調査を踏まえた上で、自分で課題を設定し、IoTシステムを考案してみました。
私は試験日までの残り日数が少なく、2つだけ案を作成しました。
前のセクションで調査した内容をまとめる段階では、課題・解決策・価値の３点をテキストに整理してていきました。整理する中で、どの立場から誰に(who)に対してどんな価値(what)を届けるのかを明確化するよう意識していました。
ある程度具体化が進んだ後に、自分のアイデアをビジネスとして形にするためにビジネスモデルキャンバスを作成しました。ビジネスモデルキャンバスに関することは、私の説明なんかより素晴らしい記事がWebにたくさん転がっていますのでそちらをご確認ください。
私なりのコツとしては、初めから美しいビジネスモデルキャンバスを作ろうとするのではなく、何回も修正していくことを前提として徐々に作成するのが良いと思います。
まずは、顧客セグメントと価値提案だけ埋めるくらいのテンションで進めて良いと思います。
実際に手書きで予行練習
ビジネスモデルキャンバスが埋まってきたら、実際に本番を想定して論述の練習をしました。
試験は手書き論文のため、この対策をしておかないと本番で思うように書けないだろうと感じ、自分が考案したIoTシステムについて手書で論述する練習をしました。正直この練習は一度は必ずやっておいた方が良いと思います。
ホームページの実施要項に基づいて、下記の４つの論点に対してそれぞれ論述しました。
- 本当の顧客は誰か（A社など、仮名にて具体的な業種と業務内容等）
- 顧客が抱えている課題
- 技術的な訴求点（技術活用は課題解決にどのように貢献するのか）
- ビジネス上の創出価値は何か
また、ポイントを抑えるためにも回答に関するFAQについて目を通しておくことをお勧めします。
試験当日について
初日と２日目午前は講義受講
実はこの試験は２日間実施して、初日と２日目の午前は講義受講、２日目の午後に論述試験があります。そのため、初日は試験がなく講義受講のみになります。講義内容から昨今の技術動向や事例について学ぶことができてとても興味深かったです。個人的には、昨今のベンダ資格の受験料が高額になっている中で、講義とお昼のお弁当も出るのはとても親切だなと感じました。
腕時計と消しゴム持参必須
試験は手書き論述です。普段手書きで長い文章を書くことはほとんどないと思いますので、時間配分が難しいです。会場に時計はあるものの、常に残り時間があとどのくらい残っているのかすぐ確認できるように腕時計は持参しておいた方が良いでしょう。実際に私はギリギリで、試験終了５分前に書き終わりました。。。
また、当たり前ですが鉛筆やシャープペンシルはあっても消しゴムがないと詰みます。
一応試験会場の近くにコンビニがあるので、万が一ペンケースに入ってなかったら当日のお昼などに買いに行くことはできます。
論述する前にビジネスモデルキャンバスでアイデアを整理
試験で与えられるテーマは当日にならないとわかりません。そのため、論述し始める前に与えられたテーマに沿ってIoTシステムを検討する必要があります。私は学習期間中に自分で考えたアイデアをベースとして、試験テーマに合うよう補正してビジネスモデルキャンバスで形にしてから論述を開始しました。自分が提案するサービスが全て見えてから論述した方が首尾一貫した主張を述べられますし、途中で大幅な方向修正をすることなく最後まで書き切ることができると思います。
終わりに
IoTシステム技術検定上級を受験し、合格しました。
手書きで論述しなければならないという点が受験をお勧めしにくいポイントではありますが、自分で考案したアイデアをビジネスとして立ち上げる上で考えなければならないポイントを学習する契機にはなると思います。
今まで業務で培ってきたエンジニアリングを新規ビジネスに活かせるような人材となるべく、今後もがむしゃらに頑張っていこうと思います。
２年ぶりに資格を受験をしてきた話
※別記事により詳細なレポートを書きました！
こちらの方が参考になるかもです。
はじめに
約２年ぶりくらいに 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を生み出していけると思う。
まあ、私は鴎党ですがね。
