計画づくりにおいて「バッファ」をどう取るか
はじめに
MIKE COHN著書の「アジャイルな見積りと計画づくり」を読んでみました。 本書はアジャイル開発における見積りや計画づくりを行う際のハウツー本であり、実践的な手法がいくつも紹介されていました。 なかでも特に興味深かった、いや私が実際に苦戦したポイントである、第4部17章「不確実性に備えるバッファの計画」について理解を深めたいと思い、これまで苦戦したポイントなどを振り返りながら本記事で深堀りしてみたいと思います。
バッファって？
本書では、計画づくりにおいてバッファは以下の2種類に分かれると紹介されていました。
フィーチャバッファ
フィーチャバッファって何か？
これはプロダクトに対する要求が優先順位付けされていて、その全てが必ず提供されるわけではないと合意できている場合に用意するバッファを指します。 このフィーチャバッファを設けることで到達点に幅を持たすことができ、スケジュールを柔軟に調整することが出来ます。
また、MoSCoWルールに従って、フィーチャを必須、重要、有用、不要の4つに分類することも有効とされています。
で、振り返ってみると
私が担当したプロジェクトでは、まず事業部の方たちと何を作るか？の認識合わせのためにユーザーストーリーマッピングを行い、プロダクトに必要となるフィーチャの洗い出したうえで、1stリリースで必須か、必須以外かで分類しました。必須以外のフィーチャーは時間的に余裕があればやると事業部の方にも一応申し伝えてはいたので、それ自体がフィーチャバッファになっていたのかもしれません。
しかし、そもそも必須と分類したフィーチャには、重要や有用に分類されるフィーチャもたくさん含まれてしまっており、必須と分類したフィーチャを見積もってみると、事業部が希望するリリース時期にギリギリとなってしまっていました。なので、実際にはフィーチャバッファを持つことは出来ていなかったと思います。
フィーチャバッファを実践する上で、フィーチャを分類するだけではなく、その分類の取扱いについて事業部の方の合意が必要であり、そこの部分を理解して貰い認識を合わせることが結局は一番難しいポイントだなぁと感じています。
スケジュールバッファ
スケジュールバッファって何か？
一方で、スケジュールバッファは名前の通り、スケジュールに適用するバッファを指します。 スケジュールバッファの見積りには、ユーザーストーリーそれぞれに50%見積りと90%見積りを行い、適切なバッファの量を見積もる手法が紹介されていました。 これは、50%以上の確率で、タスクの完了までには見積りよりも長く時間がかかるという事実を踏まえて、ユーザーストーリーごとのリスクを含んだ見積りをすることが可能とされています。
また、スケジュールバッファの持たせ方として、ユーザーストーリー毎にバッファを管理するのではなく、プロジェクトバッファとして合計量で管理することが推奨していました。 理由としては、パーキンソンの法則や学生症候群といった観点から利点が大きいからとされています。
で、振り返ってみると
私が担当したプロジェクトでは、計画づくりを行うにあたり、開発チームと一緒にユーザーストーリー毎の開発規模を見積もりました。 やり方としては、プランニングポーカーとほぼ同じ要領ですが、見積単位はS/M/L/XLを用いて、50%見積りのみを実施しました。
もちろん50%見積りは開発者によって異なりますので、場に出た一番小さい見積りをMin、一番大きい見積りをMaxとして扱い、ユーザーストーリー毎の見積りに幅を持たせて管理しました。 最終的には、MinとMaxそれぞれの見積り合計量を出したうえで、それぞれ20%程度をバッファとして追加することにしました。
おそらく、これが本書で紹介されているスケジュールバッファであったと思いますが、50%見積りでの開発者間の見積りのバラつきをバッファとしたため、見積りにリスクを完全に包含できていなかったことになります。
実際に、見積りよりも時間を要したユーザーストーリーが多くあり、また追加要件やユーザーストーリーやタスクの漏れなどもあり、Max見積り合計量に20%バッファを加味したスケジュールぎりぎりになってしまいました。
てか、そもそもバッファって水増しなのか
スケジュールバッファを設けていることは事業部の方には伝えていませんでした。理由はもちろん、水増しと思われてしまう＆説明しても理解して貰えなさそうだからでした。
しかし、本書では、バッファの存在を隠したり、使い方を秘密にするべきではなく、ステークホルダ含めて全員がスケジュールに自信を持てるようにするために、見積りとバッファをどうやって導き出したかを伝えることが重要とされていました。
確かに根拠なく20%をバッファとしていたので説明できなかっただけかもしれません。そういう意味でもこの本で紹介されているバッファの見積り手法は有効だと強く感じました。
さいごに
プロジェクトを機能面での不確実性から守るにはフィーチャバッファを用意し、スケジュール面での不確実性から守るにはスケジュールバッファを設ける。さらにこの２つのバッファを組み合わせることでさらに柔軟性をもたせることができ、それぞれのバッファを小さくすることができる。と最後に纏められていました。
この章を初めて読んだときはものすごく納得感があり、私が担当したプロジェクトを振り返りながら、もっとこうすれば良かったのか、と終始読み進めていました。過去は反省したら忘れて、次回の計画づくりで早速実践していきたいと思います。
プロダクトオーナー関連の個人的なおすすめ記事を纏めてみた_20210929更新
はじめに
プロダクトオーナーに関連する記事のなかで、個人的に読んで勉強になった、面白かった記事を適当にPickupして本記事で共有します。はじめてプロダクトオーナーを担当する方がロールや役割を理解するのにも役立つのではと思います。
おすすめ記事
プロダクトオーナー系
-
- POについての定義、役割、特性、すべきことがわかりやすく説明されているスライド資料です。あ、いきなりジョニーさんの資料でしたね。笑
はじめてのプロダクトオーナーが心にとめるべきたった一つのこと
- 「疑問を口にすること」がPOにとって一番大事、と市谷さんが書かれた記事です。私自身、初めてのPO、初めてのシステム開発と日々分からないことだらけでしたが、個人的にもこれが本当に大事だったなぁと実感しています。
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なこと
- PO祭り2016（2016年11月26日）での基調講演のスライド資料です。
【翻訳】プロダクトオーナーになりたい人が知っておくとよいこと
- どういう人がプロダクトオーナーに向いているか、成功するために必要な特性が纏められています。翻訳記事ですがすごくわかりやすいです。
【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき10のこと
- スクラムチームのパフォーマンスを最大限にするためにPOがすべきことが纏められています。こちらも翻訳記事ですが良記事です。
優れたプロダクトマネージャーのなり方・役割・スキルをプロPdMが考えてみた
- POもPdMもほぼ同じだと思います。
見積・計画づくり系
-
- アジャイルな活動でよく出てくる相対見積と経験主義についてわかりやすく書いています
プロダクトバックログ系
-
- バックログリファインメントの考え方やテクニックについて書かれています(翻訳記事です)
ロードマップ系
- ロードマップに機能を書くべからず｜小城久美子 / ozyozyo｜note
- ロードマップの表し方やPBLとの関係、そしてOutcomeについてがいい感じにまとまってます。私はこの図解の仕方をパクりまくってます。
仮説検証型アジャイル系
正しいものを正しくつくる / Do the Right things Right
- 市谷さんのスライド資料です。「正しいものを正しくつくる」の書籍が要約された感じでものすごく分かりやすいです。
MVP系
- MVP の作り方 :ハンマー: とにかく雑に作る「手作業型 MVP」のススメ
- 馬田さんのスライド資料です。「とにかく雑に作る」の必要性が繰り返し説明されています。
その他
初回リリースを最短距離で開発できなかったことについて振り返ってみる
はじめに
昨日、私がプロダクトオーナーとして担当しているプロダクトの開発が完了し、無事に1.0.0のリリースをすることができました。
今回の開発期間は、今年の4月末から始まり9月中旬と約5ヶ月間でしたが、もし私の不手際がなく最短距離で開発を進められていれば（開発者が金の卵を生むことだけに注力できていれば）1ヶ月間くらいは短縮できたかもしれないと個人的には思ってます。
個人的に思う、POがボトルネックになってしまった主な要因や、難しかったポイントを自身の振り返りも兼ねて緩い感じで以下に書いてみようと思います。
手戻りや無駄な作業の発生系
事業部との詳細仕様決め・調整
ユーザーストーリーマッピング及びプロトタイプ制作で粒度の粗い要件/仕様は決まっていたのですが、粒度を細かくしていくにつれ要件定義が難しくなり、事業部側との認識齟齬など新たな課題も多く見つかったり、手戻りなど開発工程に少なからず影響がでてしまったので、事業部側とはできる限り前広に調整すべきだったなぁと思っています。
事業部側にやってもらう作業の管理
今回のプロダクト開発では基幹システムとのデータ連携の実装や、データ紐付け・追加登録など、事業部側に対応していただかないと開発工程に影響が出てしまうタスクがたくさんありました。この事業部側のタスクの進捗管理もかなり苦戦したポイントだったと思っています。
私が所属するDX組織として初めてのことの対応
脆弱性検査やプライバシーポリシー策定など私が所属するDX組織として初経験のことが多く、見通しをうまく立てることができないタスクが多かったこともひとつの要因と考えています。ここに関しては今回一度経験してえば、次回からはかなりスケジュールや方針も立てやすくなると思っています。
事業部側とDX組織のカルチャーの違い
上記と重複する部分が多いですが、ここが一番苦戦したポイントです。単純に事業部側のPJメンバは本業の片手間で対応いただいていることもあり仕事のスピード感の違いもあると思いますが、システム開発に対する事業部側の受け身の姿勢をいかに取り除いて、作るもの（詳細仕様）を一緒に考えることが大事だと思いました。（開発チーム側だけで考えて、作成して、レビューしてもらい、修正するという悪循環になったケースも有りました）
必要最小限のプロダクトを作れなかった系
MVP実現の難しさ
お客様へ提供するものだから最初にリリースする段階から、より良いもの、機能が充実したものを作りたい、と事業部側は基本的に強く思っています。事業部側との関係性もあり、PJ最初の段階でここを抑えられずに要件が想定より多くなり、機能を作り込みすぎてしまったと感じる部分も正直にいうとかなりあります。最短でリリースまで持っていくにはここが一番大事なポイントと思いますが、事業部側にもMVPの必要性を理解・納得してもらった上で必要最小限の機能だけにすることはものすごく難しいなぁとこのPJを通じて実感しました。
現状維持バイアスへの対処
あと、事業部の方は現状維持バイアスが強い傾向にあり、現運用方法を変えるのではなく、システム側を現運用プロセスに合わせたいとの希望が強かったこともあり、追加的な要件も多く発生しました。
おわりに
事業部側のメンバにもスプリントレビューに出席してもらい常に動くものを見せたり、一緒にふりかえり（レトロスペクティブ）を行ったり、事業部と開発チームの距離を縮めて一体感を醸成するために様々なことにチャレンジしてきましたが、こうやって振り返ってみると改善点や課題がたくさんあることに気付かされました。
私自身、今回が初めてのプロダクトオーナー、初めての要件定義、初めてシステム開発に携わったりと、なにもかもが初体験で仕方ない部分も多いのかもしれませんが、今回の結果をしっかりと反省して次の機会に備えたいと思います。
ITIL®4ファンデーション速習二日間の研修を受講しました
はじめに
ITIL®4ファンデーション速習二日間＜含認定試験＞を受講しましたので、どんな研修だったか？、受けてみてどうだっか？を書こうと思います。
ITILとは？
ITIL (Information Technology Infrastructure Library)は、ITSM（ITサービスマネジメント）の成功事例（ベストプラクティス）を体系化したITシステムのライフサイクルマネジメントに関するガイドラインです。
ネットで調べてみると上記のように難しく説明されていますが、要は「ITを本当の意味でビジネスに活かすための世界中のノウハウをまとめたもの」です。 ただ、最近はIT以外の分野でも注目されており、サービス業や製造業、教育など、あらゆる業界でも適応可能であり、業務改善に活かすことができると言われています。
ITIL®4ファンデーションとは？
ITILの最新バージョンであるITIL®4の体系を基礎として必要な知識をまとめた学習コンテンツであり、それらの内容について、知識があるか？理解しているか？が問われる認定資格になっています。
下図の通り、ITIL認定資格の中で入門・基礎レベルに位置する資格になります。
詳細はリンクを参照ください。
どんな研修か？
ITILの最新バージョンであるITIL 4の基礎を習得する認定コースで、オンラインで二日間でした。
認定試験の受験も研修の中に含まれていたようですが、オンライン研修の場合は研修後に個別で予約して受講する形になっています。
参考：https://h50146.www5.hpe.com/services/education/teiki/seihin/HU0C1S.html
本研修の目的としては以下とされています。
サービスマネジメントの4つの側面を理解し、それらをバランスよく使用して価値を創造するための方法を説明する
サービスバリューシステム（SVS）を理解し、SVSがどのようにビジネスと共同して価値を創造するかを説明する
サービスバリューチェーンを理解し、実装する
ITIL® 4ファンデーション認定試験の準備と受験に必要な知識を習得する
で、受けてみてどうだったか？
良かったところ
本研修を受講前に、公式テキストは読まずにファンデーション認定試験の複数回分の模擬問題を事前に解いて勉強していましたが、ITILのなかで出てくる言葉の定義、日本語訳がとても読みにくく頭にすんなり入らず、独学だけでは理解できない部分が多かったです。しかし、本研修では言葉の解釈とそれぞれの関係性を具体例に沿ってひとつひとつ説明してくれ、点で線になった感じで理解が深まりました。
ITIL4のバージョンと、以前のバージョンの違いについてはテキストや参考書には詳しく記載されていなかったですが、そこの部分は講師が熟知されており、変更点や変更の経緯を聞けたのは個人的に興味深かったです。
ITIL4のバージョンから、リーン、アジャイル、DevOpsなどの新しい概念が追加され、ITILのフレームワークにかなり取り込まれていたので、その辺りの考え方や概念の理解が深まったと思います。
電子テキストや模擬試験、e-Learnigなど、必要十分な学習用のコンテンツを受講者に提供してくれて、またファンデーション試験に合格するまで支援して貰えるみたいで、もはや認定試験の合格証まで含まれているような感じです。
あまり良くなかったところ
研修は7時間半/日×2日間で、ところどころ演習もありましたが基本的には講師の説明をずっと聞いだけで、残念ながら私は集中力が続かなかったです、、笑
ITILファンデーション自体がサービスやそのマネジメントの基礎的な範囲になるのでそこまで難しくなく初歩的な内容でした。IT中級者やサービスマネジメント経験者には退屈な講義かもです。
ITILファンデーションの試験対策にかなり特化している印象でした。試験に合格するための説明の仕方の部分がちょいちょいありました。まぁ、主催者側の研修の目的がそれなので仕方ないですが。
おわりに
本研修ではほとんどITに関する話は出てこず、"サービス”とはなにか？、価値に着目した上で"プラクティス（成功事例集）”としてどんなノウハウがあるか？についてを改めて学ぶ良い機会でした。
アジャイル開発のフレームワークであるスクラムと同じですが、ITILのフレームワークやプラクティスをそのまま現場に適用しようとしても、手段が目的になってしまうと思うので、いかにその現場に適応させるかが重要かつ一番難しいポイントだと思います。ちなみに講師の方は適応のことをずっとテーラリングと言ってて、個人的なNewワードでした。
これまで業務効率化のツールとして活用されてきたITが、これからはビジネスの一部に組み込まれていく時代になると思うので、そういう意味でもITILの活用はこれからのビジネスには必須になってくるのだろうと強く感じました。
とりあえず、近いうちに認定資格の試験を受験してみようと思います。
非ITエンジニアの私ですが、G検定（2021#2）に合格しました。
はじめに
非ITエンジニアの私ですが、昨年の12月に畑違いの部署からDX部門に異動してから、5つ目のIT系資格としてG検定を取得することができました。
G検定のご紹介含め、どう勉強してどんなテストだったかを書いてみたいと思います。
G検定とは？
G検定とは、公式名はジェネラリスト検定らしく、一般財団法人日本ディープラーニング協会（JDLA）が実施している“ディープラーニングを事業に活かすための知識を有しているかを確認するための試験”です。2017年12月に第1回目が実施され、かなり新しい検定資格ですが、現在の第3次AIブームも相まって注目を浴びている資格のようです。
もう一つ「E検定」というものもあり、こちらは“ディープラーニングの理論を理解し、適切な手法を選択して実装する能力を有しているか確認するための試験”みたいです。なので、G検定はビジネスパーソン向け、E検定はエンジニア向けの検定として、2段階のレベルに分かれているようです。
その他
- 年3回の頻度で開催されている。受験費用は1万3200円（税込み）とちょっと高め
- 合格率は60-70%あたりで難易度は低め
- 試験はオンライン受験のみで、ピアソンの自宅受験とは異なり試験中のビデオ監視もなく、なんと試験中にカンニングしてもOK
どう取得したか
経緯や動機
デジタルについて、特にテクノロジーについての知識・経験が少ないので、まずはを“深く”より”幅広く”学びたかった。デジタルの世界にはどんな山があるのだろうか、いきなり登るのではなく、まずは山を見つけるところからスタートしている最中で、IT関連の比較的簡単な資格を取り漁っていた。
最近AIという言葉をよく聞くようになり、一度AIについてを勉強してみたかった
事前知識
- AIとは、人間の脳と同じで、五感＝データでINPUTを集めて、脳＝アルゴリズムでに解決してOUTPUTにするイメージ
- ディープラーニング・機械学習・AIの違いを全く説明できない
- 応用情報技術者試験の勉強で少しだけAIを学んだ気がする
勉強時間（試験対策）
- 15時間くらい
勉強方法
公式テキスト（通称：白本）を一周読んだ （深層学習教科書ディープラーニングG検定（ジェネラリスト）公式テキスト第2版）
問題集（通称：黒本）を2周解いた （徹底攻略ディープラーニングG検定ジェネラリスト問題集 第2版 徹底攻略シリーズ）
ネットでG検定カンペ記事を乱読（試験中に使えそうな記事を3つ選定）
試験本番
- 試験本番はPC2台で挑みました（試験用、ググる用）
- 試験の問題数は200問弱で、時間切れにならないよう最初の100問は調べたりせず、わからない問題&ググったりすれば解けそうな問題だけをフラグ（多分20問くらい）
- 100問が解き終わった時点でだいたい40分が経過しており、残りの100問はググりながら解いていく戦法に変更
- 残り100問を解くのに調べる時間が長くなってしまい、すべての解答が終わった時点で残り15分弱
- 残りの時間で前半100問のフラグを付けた問題をググりながら解答を修正
- ただ全て終わらず時間切れ、、
受験結果
- 分野別正解率を平均すると約75%で、結果は合格でした
- おそらく60%〜65%あたりが合格ラインだと思います
感想
- とにかく時間との戦いでした
- ググる時間はほとんど無かったですが、ググっていなかったら不合格だったかもしれないです、、笑
- 白本と黒本の勉強だけでは30〜40%程度しか自信を持って解答できる問題はなかったと思います
- 噂通り、黒本と本番の問題レベルはかなり違う印象でした
- ググっても正解がわからない問題、時間がかかる問題もかなり多かったので、諦めることもかなり重要そうです
- 試験前にカンペ用記事を準備しておくとかなり時間削減になりました
- AIについての基礎知識はこの資格の勉強を通じて必要十分量は習得できたと思います
- ただこれ以上AIを深く勉強したいとは全く思いませんでした、、笑
“プロジェクトマネージャー”と”プロダクトオーナー ”はなにが違うか？を考えてみた
はじめに
こんにちは。
昨年までの約5年間、発電設備メーカーでモノづくりの開発・製造に携わる業務をしておりましたが、そんな私は現在、ある事業部向けのECサイト構築プロジェクトに参画しており、そのなかでスクラム開発における“プロダクトオーナー（PO）”という職種を担当しています。
今年の1月から約半年間、知識ゼロからプロダクトオーナーを担当し、試行錯誤を重てきた私の目線から、プロダクトオーナーとは何か？を主にプロジェクトマネージャーとの違いについて触れながら本記事で書いてみようと思います。
そもそもスクラムってなに？
アジャイル開発のなかで代表的な手法の一つであり、一言でいえば「チームで仕事を進めるための枠組み（フレームワーク）」です。ラグビーで両陣が、8名ずつ肩を組んで一つの集団を作り、ぶつかり合う際のフォーメーションである「スクラム」が語源になっているみたいです。
もともとはシステム開発などのITプロジェクトを成功させる仕組みに特化したものだったそうですが、現在は業種を問わずチーム作業に共通して適用できる要素だけが残り、様々な業種やプロジェクトのチームにも活用されているようです。
プロダクトオーナー（PO）とは？
プロダクトオーナー（PO）とは、スクラムで定義されている3つのロールのうちの一つです。ちなみに他の2つはスクラムマスター（SM）と開発チームのロールになります。
（抜粋：https://www.ipa.go.jp/files/000065606.pdf）
プロダクトオーナーは、『チームが生み出すプロダクト（製品）の方向性を決める「舵取り役」』です。プロダクト（製品）のリーダーシップの権限を与えられているため、プロダクトの方向を定め、開発チームを率いてプロダクト（製品）の価値の最大化に責任を持ちます。
プロダクトオーナーの具体的な役割はたくさんありますが、主に以下の二つに纏められると思います。
ステークホルダー（利害関係者）と協調しながら開発チームとの架け橋となりつつ、プロダクトの最終意思決定を行う
プロダクトの機能や要件を優先順に記述した「プロダクトバックログ」を作成・管理し、開発チームへ提示する
プロジェクトマネージャーとなにが違うか？
上述の説明だけでは、プロジェクトマネージャー（PM）と同じでは？と思われる方が多いかと思いますので、主な違いを説明したいと思います。ただ、私自身プロジェクトマネージャーを経験したことがないので、ここがこう違うんじゃないか？とちょっぴり想像で書かせていただきます。
そもそも“プロジェクト”と“プロダクト（製品）”の概念が違う
- ”プロジェクト”とは、ある目的のもと、品質・予算・納期のQCDを管理しながら開始時期と終了時期が定義されています。一方、”プロダクト（製品）”は”プロジェクト”を内包する概念になり、”プロダクト（製品）”にはプロジェクトで必須になる終了時期があらかじめ定められておりません。複数の”プロジェクト”を繰り返しながら”プロダクト（製品）の成功”のために価値を提案し続ける、終わりのない活動であることが前提になります。
- それゆえ、プロジェクトマネージャーは品質・予算・納期に関連する“プロジェクト”の成功または失敗に責任を負うことに対し、プロダクトオーナーは“プロダクト（製品）”に責任を負います。
- 従って、プロジェクトマネージャーは品質・予算・納期の管理に重点を置き、プロダクトオーナーはプロダクト（製品）価値の提供に重点を置くことになります。
“マネージャー”ではなく”オーナー”であり、チームや開発者との関係性が違う
- プロダクトオーナーはマネージャーではないため、常に開発チームとの交渉が必要になります。開発者へ要件やタスクを一方的に割り当てるのではなく、チームで話し合いや交渉をしながら作業の計画を進めていきます。
- なぜかというと、スクラムでは「チーム」を重視するため、開発チーム内で「上司と部下」の関係や、「命令や指揮」などの指揮系統は存在しないからです。
- それゆえ、事業部門や顧客のみがステークホルダーではなく、開発者もステークホルダーとして扱うことが重要になります。
- 従って、なぜその機能が必要か？どういった価値を生み出すか？など、開発者含めたステークホルダーに対して常に説明・交渉しながら、芯のある意思決定が必要とされます。
終わりに
“プロジェクトマネージャー”と“プロダクトオーナー ”の違いについて、正解なのかは全く分かりませんが、これまでの経験を踏まえて自分なりに考えを整理しながら書かせて頂きました。もし、それは間違っているのでは？などコメントをいただけるととても嬉しいです。
実は、8月頭にオンラインで認定プロダクトオーナー（CSPO）研修を受講してみましたので、どういった研修か、なぜ受講したか、受講してみてどうだったか、についてを今後記事にしていきたいと思っています。
非ITエンジニアの私ですが、基本情報技術者試験をスキップして応用情報技術者試験に合格しました。
はじめに
非ITエンジニアの私ですが、昨年の12月に畑違いの部署からDX部門に異動してから約7ヶ月間で、ITエンジニアリング資格を4つ取得することができましたので、なにを取得したか、どう取得したかについてを書いていきたいと思います。
今回は最後の4つ目で、“応用情報技術者試験”についての合格体験記編になります。
どんな資格か
ITエンジニアリング系の資格の中で一番有名な、独立行政法人・情報処理推進機構（IPA）が主催している国家試験の一つで、ITパスポート試験、基本情報技術者試験の上位、レベル３に位置する資格です。
どう取得したか
経緯や動機
昨年、DX部門への異動が決まった後、ITの基礎知識を少しは勉強せねばと、IT系の資格でポピュラーなIPAの基本情報技術者試験の勉強を始めました。昨年度の秋に基本情報技術者試験を受験する予定でしたが、残念ながらコロナの影響で試験が中止となってしまいました。
IT初心者だった私としては基本情報技術者試験をまず合格することを目標にしていましたが、DX部門の同僚から、応用情報技術者試験を将来的に合格したいのであれば基本情報技術者試験はスキップして応用情報技術者試験に挑戦した方が効率が良い、とアドバイスがあり、応用情報技術者試験を挑戦してみることにしました。
事前知識
- 大学は情報系の学部ではない（物理工学科でした）
- IT経験といえば、前職場でOAキーマンを1年担当していたくらい
- DX部門へ異動前に基本情報技術者試験の勉強をしていた
勉強時間
- 150時間くらい
勉強方法
基本情報技術者試験の過去問5年分で2〜3周した（2ヶ月くらい）
コロナの影響で基本情報者試験が中止（→応用情報技術者試験の勉強に切り替えた）
"キタミ式イラストIT塾 応用情報時術者 令和02年"を1周した（15時間）
応用情報技術者試験の過去問3年分を2周した（約60時間）
受験結果
合格基準は午前午後60%以上で、結果は、午前60%、午後64%で超効率よく合格できました（笑）
感想
この資格に関しては、まさか一発で合格できるとは思っていませんでした。午後の問題は分野選択式であり、かなり運の要素が強い試験だと感じました。 基本情報技術者試験とこの資格の勉強を通して、IT技術やIT業界の幅広い知識を習得することができましたが、まだまだ理解できていない領域もたくさんあるので、今後も引き続き勉強していきたいと思っています。
終わりに
今回、非ITエンジニアの私が取得することができた4つのITエンジニアリング資格と、それぞれどう取得したかについてを記事に分けて書かせていただきました。 "デジタル人材"に少しでも近づけるよう、今後も様々な資格の取得にチャレンジしながらデジタルの山を登っていきたいと思っています。
ちなみに、4つの資格の合格体験記記事を書いている途中に5つ目の資格を取得することができましたので、近日、乞うご期待ください（笑）
