dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

ITサービスマネージャへ 終着点と果てなき旅路(3)

本試験

 よくもまぁ、こんなに受け続けてきたなぁ、と思いながら。

会場

 千葉県の某大学です。いつもの大学で受験するのかと思いきや、初めての大学でした。

 大きなフィールドがあって、サッカー少年たちが練習に勤しんでいました。

午前II

 もはや何を言わんや、という感じですが。

 基本的には過去問をしっかりやっておけば余裕でパス1できますが、

  • ITサービスマネージャらしくJIS Q 20000系とプロジェクトマネジメント系が少し多め。
  • 簡単な計算問題がやや多めだった印象。

 という感じでした。

午後I

 午後Iの問題選択は結構悩んだのですが、

  • 生産系システムは他区分も含め過去問でよく見ていた(問1)
  • セキュリティは得意な方(問2)
  • DX系は比較的変化球が来やすく博打要素がある(問3)

 という印象から問1と問2を選択しました。

 ただ、結果論ですが、改めて答案を見てみると問1を選択したのは失敗だったかもしれません。結構IPAが提示した解答とズレていました。

 一方で問2はほぼ表現と合わせてIPAの回答例と合致していました。

 これを合わせた結果、頭書のスコアになったのでしょうが、私自身は記述した解答が間違っているとは思っていなくて、IPAの解答例の表現を変えた(逆向きの言い方をした)程度なので、正直な所この採点には若干異論があって、採点者を呼びつけてお説教したい感はあります。

 この午後I問1で発生した『IPAが書いてほしい解答に問題文からたどり着きづらい』というのが、他の試験区分にはなかったITサービスマネージャ特有の特性で、おそらく日本語記述と誘導が他区分に比べて下手なのではないか、と私は思っています。

午後II

 今年の午後IIは2問。

  • サービスレベル(SLA)について語るか(問1)
  • リリース計画について語るか(問2)

 いずれかです。

 SLAはどうしても数値の話が出てしまうので、実サービス上SLAをやり取りしたことが乏しい私には苦手な問題です。

 また、午後IIの答練で題材にしてきた社内システム運用から言及しづらいテーマでもあります。大規模なシステムならさておき、せいぜい部署内の社内システムを厳密なSLAで運用することはあまりないですから。

 というわけで、私は問2について話をすることにしました。

IPA試験 最後の試練

 ただ、今回は最後のIPA試験だけあって、私に与えられた課題はそれなりに難問です。

 何たって、製品開発側では数え切れないほどリリース計画を立ててきた私ですが、運用側では一度としてリリース計画を立てたことがないのですから。

 しかも私の出自は組み込み系

 エンプラ系であれば、たとえ開発系であっても、情報システムのリリースにおいて運用時の対応施策を想定したリリース計画を立てる機会は多いでしょう。

 一方で組み込み系の場合、今日ではアップデート可能な製品も増えてきたものの、基本的にはリリース範囲を限定したり、DevOpsで頻繁な更新…などという手を打つことはそう簡単には出来ないのです。たとえ問題文でいくら言及されていたとしても。

 というわけで、私はこの問題の解答の多くを想定によって組み立てなければならないわけです。『あなたの経験と考えに基づいて』と書いてある問題に対して。

 もっとも、私の本にも書いたのですが、IPA試験では記述した経験の品質については問われますが、真実性については本質的に問うことが出来ません。

 いかにして自分の経験を下敷きに、真実性の高い体験と見識を展開できるかというのが、今回の午後IIで私に大きく問われたテーマでした。

 ここまであらゆるIPA論文試験を受け、パスした後で思ったのは、IPAの論文試験の本質は問題文にあるような『受験者の経験と知識を問う』のではなく、『受験者の知見を基礎としたロールプレイの結果を問う』所にあるのではないだろうか2、と。

 ならば、経験の有無は問題ではなく、あくまでも試験区分のロールで取るべき適切な行動を記述できれば良い。それが現実の自身の行動にも通底するのだから。

 私はそう割り切って、最後の論文を書き始めることにしました。


  • 1.私が携わったITサービスについて
    • 1.1 ITサービスの概要
    • 1.2 リリースの内容
      • UIの刷新(HTML5対応)
      • 機能面での変更(独自形式に加えてpdfを新たに追加)
    • 1.3 特定したリスク
      • アクセシビリティの低下(ユーザの期待とのズレ)
      • 機能の不具合による動作不全
      • セキュリティの低下(特にフロントエンドの脆弱性を懸念)
  • 2.リスクへの対応について
    • 2.1 回避軽減策
      • アクセシビリティ
        • ユーザ限定公開→一般公開
        • まず限られたユーザから反応を得る
      • 動作不全
        • ステージング環境の増設と継続的デリバリの依頼
        • 不具合即応体制構築の依頼
      • セキュリティ低下
        • DAST(Dynamic Application Security Test)、ペンテストの依頼
        • 現環境へのセキュリティアセスメント
          • 新環境への評価基準化を図る
    • 2.2 展開計画
      • セキュリティ→動作不全→アクセシビリティの順で対応を実施
        • 先行して現環境のアセスメントを実施し、評価基準書を作成
        • ステージング環境を作って開発側に提供
        • ステージング環境上で各種テストとセキュリティチェックを実施
        • テスト完了したページを限定ユーザに公開
        • 不具合を集中的に拾って開発側にフィードバック
  • 3.方策、展開計画の評価
    • 3.1 レビュー結果を踏まえた評価
      • UIに対する苦情はあったが数は少なめだった
        • 前回の更改時よりも少ない
        • GA(全体公開)後も苦情は少なく、限定公開による改善は奏功
      • リリース後の動作不全は特になく、ステージング環境でほぼ不具合を検出
      • 評価基準化によりセキュリティ要件を早めにインプット
        • 要件定義に間に合い、Security By Designを実現できた
    • 3.2 課題
      • 運用部門の枠を超えた活動
        • 自部門の負荷増大が課題
        • 開発部門との分担決めが急務
      • 全社的に開発、リリース手順の取り決めが不十分
        • 全社レベルでのリリース手順化を目指す予定

 概ねこういう話をしました。

 よく見てみると、運用側のマネージャのくせにかなり開発側の知識、作法について言及しています。これは私の開発側からの経験を活かしているのですが、一つ本文で工夫をしています。

 "私は運用部隊のリーダだが、以前開発部隊に所属していた経験を踏まえ、以下のように方策と展開計画を立案した"

 と、設問アの回答末尾に書いてあるのです。

 このように言及することによって、試験問題で求められるロールから外れることなく、区分外のロールの知見を自然に組込み、設問の要求である『あなたの経験に基づいて』を満たすことができるのです。

 この手は以前システム監査技術者試験でも使ったのですが、おそらく未経験の区分に挑むときには結構使いでのある手だと思いますので、改めてご紹介しておきます。

dimeiza.hatenablog.com

とはいえ

 見ての通り、技術的にも論文ネタ的にも、大した話はしてないんですよ。一つ一つはごくありふれた話だと思います。

 その『ごくありふれた話を、自身の知見を元に活動として具現化し、順序立てて人に伝えられるか』がIPA論文試験で求められていることで、別に特別な、立派な論文である必要はないのです。この内容でパスしているのが何よりの証拠です。

 ITサービスマネージャはシステムアーキテクト共に論文試験の登竜門なわけですが、特に運用部門で活動している方は、論文試験という体裁に尻込みすることなく、自身の活動の棚卸しと言語化をちょっとだけ頑張った上で、この試験に臨んでみてください。決して難しいことではありません。

 もしどうしても難しい、参考書を読んでも論文がうまく書けない、という方は、私の本がお役に立つかもしれないので、一度見てみると良いと思います。

zenn.dev

 運用は開発より立場が低く見られたり、華々しい活躍とは縁遠い存在になることもありますが、ITサービスマネージャは開発部門のリーダ、マネージャと対等に立つべき存在です。この資格の取得はその矜持の支えとなってくれるでしょう。

おわりに

 こんな感じで試験に挑み、頭書の結果を得ました。

 合格自体はまぁ予定通りだったんですが、今回はちょっと特別でしてね。

IPAグランドスラム

 このITサービスマネージャ試験の合格をもって、私は高度情報処理技術試験"9種"を制覇しました。

 現在、高度情報処理技術者のタイトルは8個なんですが、私は支援士試験の前身である情報セキュリティスペシャリストを取得しているので、この通り9枚の高度合格証書が揃うわけです。

 巷では高度全冠、運転免許に例えるならフルビットなわけですが、ちょっと呼び名が今ひとつだったので、私は "IPAグランドスラム" という称号を発明して名乗ってみることにしました。

 セキュリティスペシャリストから始まった高度情報処理技術者試験への挑戦も、技術士(情報工学部門)取得を経て、ついに終わりとなる日が来ました3

 まぁ正直、私も最初から全部取るつもりだったわけではなく。実際、ITストラテジスト取得時に『一旦卒業』を宣言していたんですよ。

dimeiza.hatenablog.com

 『日本のIT系国家認定、せっかくだから全部取ってしまわないか? 』と思ったのが、エンドコンテンツと位置づけていた残りの高度試験を受ける直接的なきっかけではありました。

 が、その裏側には、技術士の責務である資質向上を意識した上で、世間一般のIT技術を一通り押さえてしまおう、という学びの意識があったことは言うまでもありません。

 実際、残りの資格は私の業務から遠い所にあった分、取得によって私自身がアクセスし得る技術領域が広がったことも事実です。

 ここから先は資格に関係のない自己研鑽も含めてフリーハンドでできるようになったので、自身の興味と仕事上の要請を加味しつつ、思うままにIT関連技術を研鑽していく予定です。私のITエンジニアとしての果てなき技術探求と研鑽の旅は、まだまだ続いていきます。

 ここまで残した資格試験合格体験記が、皆様が資格試験において勝利の栄冠を勝ち取り、キャリアを先へ進める手助けとなれば、筆者としては何よりの幸いでございます。


  1. 余計なお世話と思いつつ一言付け加えておくと、IPA試験を一発で勝利するための最も基本的な条件は、午前問題を余裕で突破できるだけの盤石な基礎知識をつけることです。『100%通過しているのだから事後採点など不要』と言い切れるレベルで。
  2. これは技術士(情報工学部門)試験との制度上の最大の差と言って良いでしょう。IPA試験は未経験者でも、紙面上で経験を表現できればパスできますが、技術士試験では実務経験の真実性を勤務先証明付き業務経歴書と、口頭試験による直接確認の2点で問われることになります。
  3. 論文試験、技術士(情報工学部門)試験含め、全て一発でストレート突破してきましたが、正直出来すぎな結果でしたね。

ITサービスマネージャへ 終着点と果てなき旅路(2)

 さて。ここから先は演習の具体的な話に入るのですが…。

午前II

 午前Iはいつもの通り免除なので、午前IIさえ突破できればいいのですが。

 今回の学習で面倒だったのは、『信頼できる過去問訓練場がない』ってことでした。

 いつもはここのサイトにお世話になっていました。

www.pm-siken.com

 これはプロジェクトマネージャの過去問サイトなんですが、このサイトには過去問道場というWeb問題集が用意されています。このWeb問題集はブラウザ上で回答でき、正解と解説を読みながら演習をオンライン上で行うことが出来ます。その上回答数や誤答問題の記録までしてくれます。

 プロジェクトマネージャやネットワークスペシャリスト等ではここを使って午前IIの答練をしていました。

 参考書は参考書で買っているんですが、

  • 4択問題をわざわざ紙で解く意味なんてない
  • 全ての過去問をフォローしているわけではない

 ので、ここ最近の演習は全て電子上で行っているのです。

 ところが、ITサービスマネージャに関しては、この手の信頼できる過去問サイトがなかったのが厄介なところでした。

 …いや、サイト自体はあるにはあるんですよ。ただし、

  • そのサイトの正答がIPA公式の正答と異なり、シンプルに誤りを含んでいる。
  • 解説内容が乏しく、単なる暗記に終止してしまう。
  • 文章自体に誤りを含んでいたりと品質が低い。
  • 解答率や誤答問題の記録機能がない。

 と、非常に使い勝手が悪いのです。

 この辺りはマイナー区分の呪いとも言うべき点で、受験者数が少ないことによる弊害と言うべきでしょう。

 結局私はどうしたかというと、

  • Excelで解答用紙を準備しつつ、
  • IPA公式から問題と正答のpdfをダウンロードして答えつつ、
  • 誤答問題に対しては参考書をペラペラめくりながら確認する

 という古典的な方法を使うことにしました。

 よく考えると、この手のオンライン問題集サイトがなかった頃はこうやって勉強していたわけなんですが、便利なものに慣れると人間怠惰になってしまうものです。

 しかし、一つだけ昔とは違って、私には強力な味方がいました。

  • 参考書に解説がない問題については、ChatGPT(GPT4)に解説を求める

 これはなかなか強力でしたね。過信は禁物とは言え、IPA試験で求められるような一般的な技術については、たとえ運用系の知識であってもChatGPTから引き出すことが出来ます。

午後I

 午後Iは特に代わり映えしません。いつもどおり淡々と問題を解き、淡々と参考書の解説と照合するだけです。

 ただ、ITサービスマネージャの午後I試験問題は、何と言うか日本語の文章の出来が悪い印象がありました。

 なかなか言語化がしづらいんですが、他区分と違って答えを確定させるための情報が曖昧と言うか。システム監査技術者ほどではないですが、メジャーな他区分(PM、DB等)と比較すると少し解きにくかったです。

 この辺りは私自身の運用経験不足に起因している可能性もあります。

 午後1の問題は、仮に未経験者であっても、知識があれば基本的に問題文から論理的に解けるのですが、当該分野の経験があると、ある程度推論プロセスをバイパスして(すっ飛ばして)解けるのが特徴です。

 その手の経験が不足していたがゆえに、文章の裏にある論理を追いかけきれていなかった可能性もあります。

 が、似たような条件のDBやNWではそういった感覚を感じなかったので、受験者数の少ないマイナー区分故に、日本語が十分に洗練されていない出題や問題作成者が残っているのでは、という疑惑も覚えました。

午後II

 今回一番の関門はここです。なんたって私には商用サービスの長期運用経験がないのです。

 とはいえ、区分に対する経験がないながらも、私はいくつもの論文試験を一発で通ってきたわけです。

 これとか、

dimeiza.hatenablog.com

 これのように。

dimeiza.hatenablog.com

 そういうわけで今回も想像力をフル活用して答練をしていくことになります。

 この本にも書きましたが、

zenn.dev

 論文試験において想像力を使う場合、全く未知の状態、経験0の状態から想像力だけを使って論文を書いてはいけません。 何らかの足がかりとなる自身の経験が、土台として必要になるわけです。

 一方で今回はその土台となる経験も乏しい。

 そこで今回意識したのが、『自身の周囲や自社で実施している運用業務の深堀り』でした。

自身の周囲で実施している運用業務の深堀り

 仮に、受験者が開発側の部隊の人間で、運用業務経験がなかったとしても、実際のところは様々な領域で運用業務のお世話になっているわけじゃないですか。

  • 開発時に使用するインフラの運用
    • 開発者のPC調達
    • 開発NWの構成管理、インフラ敷設
    • 社内サーバの稼働監視、メンテナンス

 などなど。

 運用部隊との接点がない開発者ですら、自分たちのインフラを運用してくれる誰かの尽力があって、初めて成果を出すことができるわけです。

 『自分たち開発部隊のインフラを管理、運用する人々のアクティビティを、午後Iまでで習得した知識から逆に類推、想定していく』というのが、私の1つ目の戦術でした。

 『社内開発部隊向けインフラ提供サービス』というのが、私の答練一発目の論文ネタだったんですが、これは開発者ならば必ず書くことができるITサービスマネージャ向けの論文テーマかと思います。

 実際の所、私の執務環境の運用を行っている人々は私の知り合いで、運用のための活動も私から結構よく見えていたので、関心事もある程度わかっていました。そこに実務書や午後Iで出てくるような運用のプラクティスを付け足していくと、仮想事例としては十分な裏付けを伴った論文ネタになるわけです。

自社で実施している運用業務の深堀り

 もう一つは自社で実施している事業が、どのような運用に支えられているかを確認したり、想定したりするアプローチです。

 自社が開発と運用の機能を持っていて、自分自身が運用との接点があると、一番書きやすいはずです。

  • 開発したシステムの運用環境での運用
    • 運用担当者との対話、協働
    • 運用環境デプロイ時の考慮事項、懸念事項

 こういうことが思い当たりますからね。

 ただ、論文に適したシステムの運用との接点がないこともあるので、その場合は実務書や午後Iで出てくるようなプラクティスをかけ合わせ、建付けとして無理のない説明を組み立てていくことになります。

 他社事例でもいいんですが、自社で実施しているビジネスのほうが論文答練の取っ掛かりとしてはやりやすいかと思います。

 これ以外の事項については、全て前述の論文攻略本に書いてあるプラクティスを使っています。気になる方は是非手にお取りください。

というわけで

 いつもどおり午前II、午後Iは過去4年分ぐらい、午後IIは10本ぐらい論文を書いておきました。

 では、決戦のバトルフィールドへ。

ITサービスマネージャへ 終着点と果てなき旅路(1)

はじめに

 もう何度目か忘れましたが、いつものとおりです。

 この度ITサービスマネージャ試験に合格しました。

ITサービスマネージャ試験とは?

 一応定義はここに書いてあるんですが…。

www.ipa.go.jp

 『ITサービスマネジメント』と言ってもなかなか分かりづらいかもしれません。

 一言で言うと、

サービス運用チームのリーダーとして、安全性と信頼性の高いサービスを顧客に提供する。

 とあるように『システム、サービスの運用部門のリーダ級』を想定した試験です。

 基本的にIPA試験のロールの多くは、システムを『開発する』ロールであることがほとんどです。

 等、論文試験の過半や、テクニカルスペシャリストの多くもこの範疇に入ります。

 しかし、システム監査技術者や、本稿で触れるITサービスマネージャは開発からは独立した立場として設けられているロールで、他の区分とは一線を画します。

 長らくプログラマ、SEの登竜門であったIPA試験において、開発と一線を画す試験はあまり人気がなく、高度試験の中ではシステム監査技術者やエンベデッドシステムスペシャリストと並んで受験者数が少ないマイナー区分です。

 なんたって今年の受験者数は2886人、合格者は294人と300人を切るレベルですからね。

 一方で、このITサービスマネージャは『運用のスペシャリスト1としては唯一の区分でもあり、逆に合格者が少ない分レアリティは極めて高いと言えます。

 論文試験区分ではありますが、レベルとしては三大難関程ではなく、システムアーキテクトと並んで論文試験の最初の関門と言われています。

事前状態(なぜ受けようと思ったのか)

 いや…まぁ…ここまで来てしまったから…というのが最初の動機ではあるんですけども。

 この区分ただ一つを残し、めぼしいIT系国家試験、国家資格は取得しており、もはや足の裏の米粒、取らないと気持ち悪い所まで来てしまったのです。

 ただまぁ、それはそれとして、私の所属する組織の事情もあるにはあったのですよ。

 自組織は割と開発系には力を入れるんですが、運用系にはリソースが割かれない傾向があって、運用方面に明るかったり、積極的に手を挙げる人が少ない、という風土になっていました。

 私自身も運用についてはかなり知識が乏しかったのです。

  • システム、サービスを長期間商用運用した経験には乏しい。
    • デモシステム等、(直接お金には絡まない)サービスの維持経験はある。

 折しも社内で運用絡みで問題がちらほら起こることも多く、技術士(情報工学部門)であるからには、運用についても最低限の知識をもって隙なくあるべきでは、と思ったのが、おそらくここで言明しておくべきであろう、まっとうな動機です。

教材について

 今回は未経験の分野ということもあって、なかなか悩んだんですけども。

参考書

 結局参考書は2種類使いました。

 まずはこれを読んだんですが、なんとなく物足りなくてですね。

 知識よりも試験問題対策に重点が置かれており、前回のプロジェクトマネージャで使用した情報処理教科書に慣れた感覚では、若干鍛えたりない感があったのです。

 そこでもう1冊買って読むことにしました。

 この本も知識編と演習編に分かれているのですが、知識編の分量が過不足なく、ちょうど良い塩梅でした。

 なるべく1冊で済ませたかったところですが、私の知識レベルからするとこれぐらいやって正解だったかもしれません。

実務書

 実務書は2冊読み込みました。

 この本はITサービスマネジメントそのものというよりも、『ITサービスマネジメントを開発側としてどう設計するか』という開発者側視点から入っていくのですが、逆に開発者としてのバックグラウンドが強い私にとっては非常に学びのある本でした。

 『先に運用について考えておく』とは一体どういうことなのかを教えてくれる本なので、運用設計に関わったことのない方は一度読んでおくことをお勧めします。

 後半は実際の管理フローを想定した設計考慮事項が細かく書かれていますが、今にして読み返してみると、この中身と考え方は午後2論文で投入可能な論文ネタの宝庫です。

 試験対策としても実務書としても有用な一冊です。

 ITサービスマネージャ試験で見え隠れするキーワードとして、『ITIL』というものがあります。

www.ntt.com

 英国でまとめられた、ITサービスマネジメントにおけるベストプラクティスガイドブックのことです。

 一応、ITサービスマネージャ試験はこのITILを参照していて、ITIL 2011、またはこれを国内標準化したJIS Q 20000シリーズを参照しているのですが、最近のITIL4についても一応押さえておいたほうがいいかな、と思いまして。

 実際に読んでいくと、ITILv4はPMBOK第7版のようにアジャイル的な考え方の影響を受けた改訂がなされているようでした。サービス事業者による一方的なサービス提供から、顧客を含めて価値を共創していくというパラダイムシフトが起きており、考え方としてモダンなものになっています。

 今年の試験ではITIL4が特段効く、ということはなかったのですが、今後の試験への対策や実務上の考え方として、学んでおく価値は高まってきているかもしれません。

武器は揃ったが…

 道具立ては揃いましたが、今回はシステム監査技術者同様、経験が浅い中での戦いになります。経験不足をどう演習で補っていったか、の話をしていこうかなと。

 以下次号。


  1. 実はITサービスマネージャのかつての区分名は、"テクニカルエンジニア(システム管理)"。論文試験が課されていたとは言え、以前はテクニカルスペシャリスト区分だったのです。

『本プロジェクトの目的は、プロジェクトマネージャ試験に合格することである』(3)

本試験

 IPA試験の受験、果たしてもう何度目でしょうね。

会場

 千葉県の某大学です。システム監査技術者、ITストラテジストデータベーススペシャリストの各試験で訪問しているので、ここに来るのはもう4回目。

午前2

 ここはもはや、特に言うべきこともないですね。

 過去問で頻出のRACIチャートとかEVMとか、PMに新たに組み込まれたアジャイルの文脈でも、アジャイルマニフェストとかXPとか、過去問やってればだいたいわかるよね、という感じです。

 ここまで来たら、いっそ全区分で午前2を免除してほしいぐらいです。

午後1

 私が選択したのは問2と問3でしたが、この辺りは今般試験の変更点が浮き彫りになっている問題です。

試験情報 | IPA 独立行政法人 情報処理推進機構

令和4年度 秋期 プロジェクトマネージャ試験 午後1 問2より抜粋

メンバーの多様な考えを活用して早期に対応し、変化に適応

令和4年度 秋期 プロジェクトマネージャ試験 午後1 問3より抜粋

メンバーの成長とチームの自律的なマネジメントに向けた継続的な改善

 それぞれ、試験要項の改訂事項と真っ向対比できるレベルで、明確に反映されています。

 統制型のプロジェクト運営だけで、いわゆる剛腕だけでプロジェクトを進めてきたPMには解きづらい問題と言えるでしょう。

 ただ、過去問の時点でも、自律的なマネジメントという文脈は結構出ていました。

令和3年度 秋期 プロジェクトマネージャ試験 午後1 問1より抜粋

令和2年度 秋期 プロジェクトマネージャ試験 午後1 問2より抜粋

 試験要項に変更があったと言っても、実際の所、試験問題の傾向としては連続しているのがよく分かると思います。過去問への演習は嘘をつかないということの証左で、変更点に向けてあからさまに準備していなくても対応可能だった、というのが実際のところでした。

 まぁそういうわけで、私自身は午後1も快調に筆を進めていたのですが、返ってきたスコアを見ると予想より若干低くて。IPA発表の回答とそれほど乖離しているようにも思えず、ちょっと採点者に文句を言いたい気分にはなりました。

午後2

 技術士試験の峻厳さには程遠いものの、IPA三大難関の最大の壁は、なんだかんだ言って論文です。

 まず問1を見たんですが、

問1 システム開発プロジェクトにおける事業環境の変化への対応について

 と書かれていて、ここで若干悩みました。

 どちらかと言うと変化への対応性を強く持つべきプロダクト、具体的にはSoEのシステムやエンプラ系のシステムに対して親和性が高く、組込のような深層、低レイヤのシステムに対しては適用しづらいテーマです。

 そういう事例を書くこともできたんですが、私が得意としてきたのは組み込み系の話なので、問2のタイトルを確認し、

問2 プロジェクト目標の達成のためのステークホルダとのコミュニケーションについて

 これならいけそうだな、と思ったんですが、一つ、ある事に気付いて警戒のレベルを上げました。

 それは設問の書き方です。

令和4年度 秋期 プロジェクトマネージャ試験 午後2 問2より抜粋

 システム監査技術者以外の他区分について論文答練をしてきた人なら、この設問の書き方の違和感に気づくはずです。

 対比してみましょうか。前年度の問2とかどうでしょう。

令和3年度 秋期 プロジェクトマネージャ試験 午後2 問2より抜粋

 まだピンときませんかね? では令和3年度問1を、対比箇所を強調して見てみましょうか。

 そう。設問ウの書き方が異なっているのです。

 システム監査技術者試験を除き、IPA論文試験の設問の定石は、概ねこんな形になっています。

  • 設問ア: 与件(対象となるプロジェクト)の説明
  • 設問イ: 与件に対して受験者が行った施策、行動の(題意に基づいた)説明
  • 設問ウ: 設問イで受験者が行った施策、行動に対する評価、改善点

 ところが今年度の問2だけはそうではありません。設問ウにおいて、

”実行段階"において生じた認識の不一致とその原因、及び"実行段階"において認識の不一致を解消するために積極的に行ったコミュニケーション

 つまり、設問イと同様、与件に対して受験者が行った施策のさらなる説明を要求しています。

応用力と論理展開を求める設問の変化球

 プロジェクトマネージャ試験ほどのレベルの試験でも、論文を事前作成しておき、その論文を本番上で展開してしまう人は結構いるようですが、この手の変化球が来た場合、真っ先にふるい落とされるのはそういう人々です。

 そりゃぁそうですよね。定石に従って論文作成するなら、設問ウに相当する中身は評価や改善点であって、施策の第2段階ではないのですから。

 私の論文攻略本でも、IPA試験に対しては『論文の事前作成&展開は避けよ!』とはっきり言明しています。これは論文評価ランクを落とす最大の落とし穴なのですが、ここで調子を狂わされた人も結構いるのではないでしょうか。

経験と論文展開力を持つ者の余裕

 一方で私はこれを見て、逆に得たりと思いました。

 ステークホルダ間の認識齟齬は、私自身のプロジェクト管理経験における最大のテーマの一つで、書くべきことはたくさんあったからです。

 あまりにも言うべきことが多かったがゆえに、技術士口頭試験においてすら言及したほどでした。

zenn.dev

Q.チームの質問がお客様に伝わらない言葉だったので、それを書き直した、というお話でしたが、具体的な事例を挙げることはできますか?

A.昔のことなので大分忘れていますが…。

開発しているデバイスにはファイルシステムがあって、アプリケーションごとに階層が分かれているんですが、この状態で『カレントフォルダ』という言葉をメンバーが使うことがあって。

チームメンバーは自分の担当アプリケーションが念頭にあって、一意と思い込んでそう言ってしまうんですが、絶対パスで示さないとお客様にはわからないだろう、という話をしたことがありました。

 このように、論文試験では、試験に対する取り組みや姿勢によって、初手で決着がついてしまうことが普通にあります。

 論文試験において勝利を確実にするのは、事前に論文を書く行為ではなく、自身の経験をその場で形式知化し、文章として説明できる能力なのだということを押さえておきましょう。

論文設計

 せっかくなので論文設計も、差し障りがない範囲で残しておきましょうか。

  • 第1章 私が携わったプロジェクトについて
    • 1.1 概要
      • 大手企業向けICチップ形状製品
      • 2.5年、20人、約300人月、2億程度のPJ
      • 得意先要求仕様への配慮と、工場に量産品書込コードを送った上で、工場で量産させる点に注意が必要
    • 1.2 目標
      • 1.5年以内に得意先評価用サンプルを提出
      • 2.5年後に工場量産品の納品開始
    • 1.3 重要ステークホルダと影響
      • 得意先仕様管理部署
        • 仕様コミュニケーション上の手戻り→サンプルの納期に影響する
      • 工場
        • 量産品書込コードの遅延→量産遅れにつながる
  • 第2章 計画時の期待値コントロール
    • 2.1 期待の内容
      • 得意先:
        • フル仕様でサンプルが納品されると思っている
      • 工場:
        • 得意先へのサンプル納品と同時に量産品書込コードが完成すると思っている
    • 2.2 理由
      • 得意先:
        • 開発リソース上、1年間でフル仕様の実現は困難。
        • 仕様齟齬は過去開発でも発生しており、仕様Fixが間に合わないリスクがある
      • 工場:
        • 得意先側のサンプル評価によってはコード修正が必要→量産品書込コードの納期は変わりえる
    • 2.3 コミュニケーション
      • 得意先:
        • リリース計画と、各時点の搭載機能の対応表をキックオフ時に説明
        • 仕様、認識齟齬による遅延可能性を明言し、リスク認識させた
      • 工場
        • 予め、量産品書込コード提供時期が未定であると明言
        • 量産時の作業について初期段階で明確化し、前倒し実施
  • 第3章 実行段階での認識不一致について
    • 3.1 不一致の内容
      • 顧客の受け入れ試験における、自社仕様認識との不一致
    • 3.2 原因
      • 顧客が受け入れ試験を定めるに当たって、他ベンダーの仕様を流用した
      • 結果、自社製品と仕様が乖離していたが
      • 顧客の仕様理解は大雑把で、仕様乖離を認識していなかった
    • 3.3 コミュニケーション
      • 自社製品(顧客仕様)と受け入れ試験仕様の乖離をテーブル化するようリーダに指示
      • 他ベンダーの仕様とも整合するよう、自身が監修して受け入れ試験仕様を確定させた
      • 最終的に各社が共通の受け入れ試験仕様で量産化し、市場投入に成功

 だいたいこんな感じです。

 まぁ、書いた結果が全てといえば全てなのですが、一つ言っておいたほうが良いことがあるとすれば。

  • プロジェクトの規模に関する情報を除けば、数字は必ずしもMustではない。

 ということでしょうか。

 納期に関しては1.5年、2.5年などのざっくりとした数字を出してはいますが、やれ試験項目数が何項目あるかとか、コードの規模が何LoCだとか、量産品が何万個なのかとか、そういう細かい数字は一切使っていません。

 プロジェクトマネージャ試験の対策本によっては、こういう数値を出すことによってリアリティを出すんだよ、みたいな記述を見かけたりもするのですが、設問で必要な情報を論理立てて十分に説明することさえできれば、細かい数値の明示などは些末事に過ぎません。

  • 一般論ではなく自分独自の経験、知見に基づいて
  • 設問から要求される、プロジェクトの文脈と、受験者の行動を
  • 適切な粒度で、論理的に、ストーリーを立てて説明する

 これが論文試験で成すべきことの全てです。来年以降挑まれる方の健闘を祈ります。

さいごに

 従前で書いてきたように、私自身はプロジェクトマネージャとしての仕事をするつもりはあまりなくて。

 つまりこの試験で勝ち得たロールを実業務で実施することはあまり予定していないのですが、こうしてIPAからプロジェクトマネジメントの有識者である旨のお墨付きをもらったので、

  • 組織内でのプロジェクト運営体制に関するチェックやバックアップをしたり
  • プロジェクトマネジメントに関わる後進の育成に活かしたり

 することができるだろう、と思っています。

 また、自身が書いた論文対策本のプラクティスを試す絶好の機会でもあり、この通り効果を立証することもできました。

 キャリア途中の置き土産の回収を通して、こんな成果が得られたので、これをご覧の皆様も、プロジェクトマネージャ試験を通し、何らか勝ち取るものを得られれば幸いでございます。

『本プロジェクトの目的は、プロジェクトマネージャ試験に合格することである』(2)

 さて。

2022年度のプロジェクトマネージャ試験の変更点

 今年の5月に、こんな文書がIPA掲示されたんですよ。

www.jitec.ipa.go.jp

 情報処理技術者試験は、試験範囲を明示した『試験要項』と、各区分に対して要求される知識、技能を明確化した『シラバス』によって試験内容が規定されるわけですが、よりにもよって私が受験するタイミングで改訂してきたわけです1

変更内容は次のとおりです。

(1)アジャイル型開発プロジェクトの増加、プロジェクトマネジメントに携わる者の業務と役割の変化を踏まえた変更(プロジェクトマネジメントの業務を、特定のプロジェクトマネージャが任命されて担う、チームの一部のメンバーで分担する、又は全メンバーで分担するといった多様な形態を想定)

(2)その他、シラバス用語例などの整理

 IPAのプロジェクトマネジメントに関する認識は、基本的にSIerがやるようなウォータフォールモデルに基づく、どちらかというと古典的なプロジェクトマネジメントのそれだったんですが、今年からアジャイル的なマネジメントについても問うよ、と言い出したわけです。

 冒頭で説明したプロジェクトマネージャの対象者像や役割、技術水準も、この影響を受けて変わっています。

プロジェクトマネジメント業務を単独で又はチームの一員として担う

メンバーの成長とチームの自律的なマネジメントに向けた継続的な改善

メンバーの多様な考えを活用して早期に対応し、変化に適応

プロジェクトチームの自律的な成長を促進

多様な考えを理解して,変化に柔軟に適応

 この辺りは従来の統制を主とし、強いリーダーシップで牽引していくというプロジェクトマネージャ像とは大きく異なっています。むしろ協調、支援を主としたサーバントリーダーシップに近いと言えるでしょう。

 後述しますが、これは実際の問題傾向にも波及してきていて、この考え方にキャッチアップしていかないと、いくらプロジェクトマネージャの経験があったとしても、大きくビハインドを背負うことになってしまいます。

私の蓄積

アジャイルに対する蓄積

 これに対するに私としては、本を買って勉強するなどの対応なしに、『うん、分かった』の一言である程度済んでしまいました。

 というのも、実はこの手の本、自社でウォータフォールでプロジェクトを回していたくせに、結構読み込んでいたんですよ。

 おそらく普通のプロマネさんとはこの点が大きく異なると思うので、私が読んでいたアジャイル関連の本をピックアップして紹介しておきます。

 いずれもアジャイルの文脈におけるプロジェクト運営の方法について記述されており、日本の旧来の上意下達的なプロジェクトマネジメントとは全く異なっています。この辺りを私は割とよく読み込んでいて、アジャイルの空気感がどういうものかを概ね把握していました。

 それどころか、私自身はウォータフォールプロジェクトの中にアジャイルの技術やプラクティスの一部を持ち込んで、プロジェクトを安定化させるなどということを、これらの本が出るかどうかのタイミングで実施していた立場だったので、問われれば答えられる、ぐらいの自信はありました。

アジャイルに対する蓄積

 それだけではなく、非アジャイル、つまりウォータフォールを前提とした書籍の蓄積も、実は相当量あったわけです。

 これはあくまでも一例ですが、プロジェクトマネージャ試験に先立って、実はこんな感じで膨大な蓄積があって。この蓄積が、今般の受験で参考書がたったの1冊で済んだ最大の理由と言えます2

 なので、これを読んでいる方で来年以降プロジェクトマネージャを受験される方は、先程示した教科書類に加えて、アジャイルと非アジャイルの両側面において、面白そうだと思える書籍をそれぞれピックアップして読んでおくと良いでしょう。

 特に、自社で採用していない(有用性を認識していない)が、業界的、世界的には有用なプラクティスが示されている書籍が良いです。そういう書籍を読んでおくと、問題一つ解くときにも、自社の考えに凝り固まることなく、より広い視野で有用とされているプラクティスを参照してより良い正解を書くことができるようになります。

 プロジェクトマネージャ試験は特に自己の経験に自縄自縛されやすい試験なので、上手にアンラーニングしつつ、多様なプラクティス、考え方を選択肢に組み込んでから挑みましょう。

試験準備

午前と午後1

 午前と午後1に関しては特に言うべきことはなく、試験対策本と前述の書籍から知識を付けつつ、過去問を解き、結果を評価する、ただその繰り返しです。

 強いて言うならこの2点でしょうか。

1.午前2対策は、試験学習開始時と終了時に実施するのがオススメ。

 先に紹介した試験対策本だと、午後試験から学習を開始し、午前2は最後に取り組むように推奨していますが、それは当該区分にある程度習熟した下地のある受験者が取るべき戦略だと思っています。

 対象区分に対する理解度が低い場合、語彙が少なすぎて教科書や問題文の読解に支障が出ることも想定され得るので、

  • 学習を始める際、まず語彙を獲得するために午前2をざっと解いていく。
    • 問題文や教科書を読むための基礎知識をつける。
  • 学習の終盤で、最終仕上げとして午前2を解く。
    • 論文等の重い学習で終盤消耗することを避けつつ、単発知識を再度刷り込んでおく。

 私は(どの試験区分であっても)この手法で取り組むことにしています。

2.午後1を解く際には、論理的かつ客観的な解答解説が示されている試験対策本を選ぶ。

 これはどの区分でもそうですが、午後1の問題文から回答に至るまでに適用する論理こそが、論文試験系の午後1を解くために必要な唯一の武器だと言っても過言ではありません。この武器を磨くことができる書籍の選択だけは確実にしましょう。

 その観点で言うと、先に紹介した試験対策本は、私からも太鼓判を押せます。

午後2

 今回、午後2については、私は先に紹介した試験対策本については全く参照しておらず、完全に私のオリジナルのやり方で挑んでいます。

 例によってPCで5本、手書きで5本ぐらい書いたんですが、今回私が意識したのは、

  • プロジェクトという活動には、複数の側面がある。

 ということです。

 午後2対策の文脈で平易に言うと、こういう意味です。

  • ある一つの完結したプロジェクトは、各側面毎に複数の論文に書き下すことができる。

 ここでいう側面は、例えばPMBOKの知識エリアで切り分けたり、プロジェクトに対する関心事で切り出すことができます。

 PMBOKの知識エリアで切り出すなら、例えばこんな感じでプロジェクトを表現することができると思うんですが、

  • スコープ:
    • プロジェクト序盤の要件定義は準委任契約、アジャイルにスコープを探索。
    • 設計以降はスコープクリープを防止するため、変更委員会で保守的に管理。
  • 品質:
    • 設計工程ではレビューの指摘事項密度から設計品質を把握。
    • 一部設計では形式手法を用いて自動検証を実施。
    • 実装工程では単体テスト推進のためTDDを一部導入。
  • コミュニケーション:
    • プロジェクト計画段階でステークホルダ登録簿を作成、洗い出し。
    • 工程横断のステアリングコミッティと、各工程個別の会議体、連携フローを計画。
    • メンバーの意見を取り入れ柔軟にコミュニケーションパス変更に対応。

 これらが実は全て単一のプロジェクトの活動だったりするわけです。

 何が言いたいかと言うと、仮に受験者が1つのプロジェクト経験しか持ち合わせていなかったとしても、そのプロジェクトについてあらゆる側面で説明できれば、複数の論文を苦もなく記述可能なのだ、ということです。

 プロジェクト経験が豊富であれば良いに越したことはないのですが、それは論文中で引き合いに出せるプラクティスや実経験といった、いうなれば引き出しの数に関する話です。

 問題文中で特定の制約がない限りは、論文の題材にするプロジェクトは実は1つ2つあれば十分だったりします。そのプロジェクトについて、問題文中で問われた側面さえ論述できればそれで良いのです。

 実際、私自身は複数の論文を書いていますが、その半分をある単一のプロジェクトを元ネタにして書いていたりします。試験本番ですらこの単一のプロジェクトから書いているのです。

 問題文中で発生し得る制約としては、

  • 対象システムの特性(エンプラ系 or 組み込み系)
  • プロジェクトの攻め度合い(SoR: System of Records or SoE: System of Engagement)
  • プロジェクト体制(ウォータフォール的 or アジャイル)

 この辺りが想定されますが、過去問を見て、問題文中で縛りがありそうだなと思ったら、それに対応したプロジェクト事例を思い出すなり、調べて手元に持っておくとよいでしょう。プロジェクトのストックとしては2、3個あれば良いんじゃないでしょうか。

 一つの事例には複数の側面がある、ということを覚えておいて、単一のプロジェクトを複数の側面から説明、描写できるようにしておきましょう。おそらくそれがプロジェクトマネージャ試験の午後2で効率よく勝つ秘訣です。

 これ以外の事項は、私の論文攻略本に書かれているプラクティスをそのまま使っています。ガッツリ書いてありますので、よろしければ手にとって参照ください。

zenn.dev

 学習時間とかもいつもどおりです。週末の土日午前中に数時間、というのを3ヶ月ほど繰り返した程度です。

 では、本番に行きましょうか。


  1. そういえば、似たようなことがシステム監査技術者試験でもありましたねぇ…。何だろう、こういう試験制度改訂については、私は結構運が悪いようです。
  2. 『勝つべくして勝った』というのはこの辺りの事情もあります。

『本プロジェクトの目的は、プロジェクトマネージャ試験に合格することである』(1)

はじめに

 久しぶりに書くわけですが、冒頭は…まぁ…いつものとおりです。

 この度プロジェクトマネージャ試験に合格しました。

プロジェクトマネージャ試験とは?

 このページにたどり着く方であればご存知の方も多いと思いますが。

www.jitec.ipa.go.jp

ja.wikipedia.org

高度IT人材として確立した専門分野をもち、組織の戦略の実現に寄与することを目的とするシステム開発プロジェクトにおいて、プロジェクトの目的の実現に向けて責任をもってプロジェクトマネジメント業務を単独で又はチームの一員として担う者

 という人材モデルを意識した、高度情報処理技術者試験の一区分です。

 IPA試験の中では昔から実施されており、かつ昔から人気が高く、合格率も低い資格として有名です。

 IPA試験の中ではITサービスマネージャと並んでマネジメントに関する知見を問う試験であり、他の試験区分と比して、テクニカルな要素が問われづらいところから、非ITエンジニアが受験を企図することも多くあります。

 WikiPediaにも記載がありますが、プロジェクトマネージャ試験は、ITストラテジスト試験、システム監査技術者試験と並んでIPA論文試験の最難関級の試験としても知られています(私は勝手に三大難関と呼んでいます)。

 なぜこの試験を受けようと思ったのかについては、事前状態を説明しながら追々。

事前状態

 まぁ…正直なところを言うと、今回の私は勝つべくして勝つ状態で挑むことになったので、後に続く人にとってどれぐらい参考になるかはちょっと分からないのですが。

  • 高度情報処理技術者試験は7冠。
  • 技術士(情報工学部門)。
    • マネジメント、リーダーシップ、評価、コミュニケーション、問題解決等、プロジェクトマネジメントで問われるコンピテンシーを公式に認定されている立場。
    • 口頭試験中にマネジメント経験について説明したりしている。
  • プロジェクトマネジメント経験を数年単位で有している。
    • 小規模なテストマネジメントから、顧客に相対する億単位のプロジェクトまで。
    • 当事者としてマネジメント上の問題をいくつも抱えてきた。

なぜ受けようと思ったのか

 私の過去の論文試験合格のエントリ(↓)を見た後でこれを見ると、

dimeiza.hatenablog.com

dimeiza.hatenablog.com

 『他の試験は未経験気味でぶっ込んでるのに、何でお前今までこれ取ってなかったの?』と言われるぐらい、私自身のキャリアとは親和性がある資格に見えると思います。

 これは私自身の個人的な事情で、プロジェクトマネージャを担当してもあまり割の良い経験ができなかった(最終的に体を壊してしまった)ので、今の組織ではプロジェクトマネージャを卒業していて、『もうプロジェクトマネージャやりたくないなぁ』と、以前から思っていたからです。資格を取ってしまうと関連の仕事を回されかねないですからね。

 ただ、よくよく考えると、今の私は技術士(情報工学部門)になっていて。

 前述したとおり、技術士(情報工学部門)は、プロジェクトマネジメントに必要なコンピテンシーを明示的に問われ、その発揮を期待されている立場です。

 加えて、ここでも紹介したんですが、

zenn.dev

 政府調達の立場から見ると、プロジェクトマネジメントについては、技術士(情報工学部門)はプロジェクトマネージャ試験合格者と対等の立場として取り扱われています1

 私はかねてからこの事を知っていたので、技術士を取った時点で最早不要とも思ったんですが、逆に、

 『今となってはプロジェクトマネージャ、持ってても持ってなくても変わらなくね?』

 と思い直しまして。

 せっかくここまで来たんだったら行きがけの駄賃、

  • PMBOKを含めてプロジェクトマネジメント知識を一通り整理した上で
  • IT系論文試験本著者としての箔を付け、その効果を証明する2

 という意味でも、このタイトルを勝ち取ってしまおうと思ったので、あえて取ることにしました。

教材について

 私のIT系論文試験本の冒頭でも書きましたが、

zenn.dev

IPA試験に挑む際には対応する試験区分の攻略本を読んで、各区分の個別技術知識を付けることを勧めています。

試験対策本

 今回はこれを使いました。

 PMの攻略本といえばこの人、と言われるぐらい有名な方が書いている本です。

 実際見てみた感じ、この本を徹頭徹尾、真剣に読み通せば、かなり合格率を上げられるだろう、というのが私の感覚でした。要求される知識は一通り集まっており、午後問題の解説についても納得感のあるロジックで説明されています。

 また、試験受験のモチベーションを高めるためのコラムが随所にあったりするなど、攻略本としての工夫には私も参考にする所が多くありました。

 一方で、情報密度が非常に高い所から、読み通すには相応の根性か計画性を要します。自身の経験を持ち込みながら咀嚼する箇所も出てくるので、プロジェクトマネジメントについて全くの初心者である場合、読解自体も難しくなってくる側面があります。

 私のようなプロジェクトマネージャ経験者が読むのであれば隙のない本ですが、未経験者の場合はもう少し平易な書籍から始めても良いかもしれません。

参考書

 今回は実務を経験していますし、関連書籍も大分読んでいるので、PMBOKの体系さえ整理できてしまえばいい、という判断のもと、これだけを読んでいます。

 PMBOK上のプロジェクトの構造や用語、概念について図を多用した説明がされており、プロジェクトマネジメントとはどんなものなのかを解説しつつ、PMP試験への足がかりにもなる本になっていました。

実はこれだけでは足りていない…。

 通常、というか昨年までの試験であれば、おそらくこの2冊があれば問題なく攻略できただろうと思いますが、実は今年の試験から一つ変わった所があって。

 一方で、私はその変わった所に対する書籍を特に揃えませんでした。その辺りは過去に私自身がたくさん読んできていたからです。

 この、『プロジェクトマネージャ試験の今年度の変更点』と『私自身の過去の蓄積』から、次の話を始めるとしましょう。


  1. 政府調達上における技術士の真価は、ほぼ全ての高度試験のロールをこれ一つでこなせることで、プロジェクトマネジメントは技術士のロールの一つに過ぎません。
  2. 未踏破の論文区分が残っていると、論文攻略の解説をしても説得力に欠けるなぁと。

プログラマが第二種電気工事士を取ってみた(2.ソレダメ!〜あなたの施工は欠陥品!?〜)

技能試験

情報処理技術者試験の午前試験と同じく、基本的にちゃんと準備している人であれば、筆記試験はまず突破できるはずです。

そう、本番はこれから。

概要

事前に決められた13個の候補問題の中から1つが出題され、ケーブルと部品を使って40分以内に問題に記載された一般用電気工作物を施工せよ、という試験です。

出題される問題は試験地ごとに違い、事前に知ることはできません。

詳しいことは教科書や試験要領を参照した方がいいでしょう。

必ず覚えておくべきことは2つ。

  • 40分という極めてタイトな時間しかない。
  • 『欠陥』と呼ばれるミスを1つでも作品に含めてしまった場合、一発で不合格になる。

ということです。

工具

多分これが鉄板だと思います。

ホーザンの技能試験工具セット。試験会場でも多くの人が持参していました。

他に練習用部材セット付きのものや、後述する合格シリーズのアイテムが同梱されているものもあるので、必要に応じて好きなのをお選びください。

初めての人は対策DVD付きのやつを選んで、基本作業をDVDを見ながら習得するとよいです。非常に簡潔かつポイントを押さえています。人によってはこのDVDだけで合格を狙えるかもしれません。

個人的には腕力がないので、リングスリーブの圧着がきつかったんですが 1、何度もやってるとそのうちできるようになるので、腕力が弱めな人もご心配なく。

追加工具

ホーザンはこの工具セット以外にも『合格』シリーズと称した電工試験用工具を出しているんですが、この中で、『合格クリップ』と、『合格マルチツール』は工具袋に入れておく価値があります。

合格クリップ

圧着作業前に接続の事前確認ができ、誤接続を防ぐことができる

ってのが売りのようですが、私はどちらかというと、『リングスリーブ圧着時に電線の向きと長さをそろえるための固定具』として使用していました。

技能試験では、リングスリーブによる電線の圧着はどの候補問題でも必須の工程なんですが、この際、芯線がリングスリーブから一定の長さ以上むき出しになっていると欠陥を取られてしまい、一発不合格になります。

これを避けるためには芯線むき出し部分の長さを短く揃えた上で圧着する必要があるんですが、送電用の電線は電子工作で使うような細い線と違って、中の導線が太いのでそれなりにやんちゃで、手で固定して圧着しようとすると、すぐに明後日のほうを向いてしまったりします。

特に3本、4本を束ねる場合、リングスリーブに入れづらかったりするので、この辺で結構イライラ感が出ます。こうした際に手を使わず線を固定できるので、作業の円滑化が期待できます。

ただし、試験終了時に合格クリップをつけっぱなしだと、それ自体が欠陥扱いになり、これまた一発不合格になります。

合格クリップを使う場合、リングスリーブを圧着したら、すぐにクリップを外す習慣を演習中につけておきましょう。

合格マルチツール

  • レンチ
    • ロックナットを固定できる
  • ブレード
    • 器具の電線外し穴に差し込んで電線を外す
    • ゴムプッシングに穴をあける
  • リングスリーブ保持穴

 の3つの機能がありますが、特にロックナット用レンチとして使い勝手が良いです 2

 技能試験で求められるロックナット固定には、通常ウォーターポンププライヤーを使うのですが、ジョイントボックス内にウォーターポンププライヤーを入れようとすると結構作業しづらいんですよ。

 その点マルチツールは小さくてすっと入るので、短時間での作業が求められる技能試験ではこちらがおすすめです。

部材セット

最初、『準備万端』シリーズの1回分のやつを買いましたが、本記事執筆時点ですでに在庫切れでした。

2回目を回した際にはモズシリーズを買い足しています。

この辺りもお好きなのをどうぞ。

基本的にさほど変わり映えはしないはず…ですが、最初に使った準備万端シリーズとモズシリーズで、2.0[mm]ケーブル被覆の剥ぎやすさに違いがあった(準備万端シリーズのほうが剥ぎやすかった)ので、多少評判を見て選んでもよいかもしれません。

教科書

技能試験の教科書も『すいーっと合格』シリーズを見ています。

ただ、この教科書を見る前に、先ほど紹介したホーザンのDVDを見ておくのがおすすめです。

この教科書で1点だけ迷うところがあるとすると、

  • ケーブルストリッパとの付き合い方

かなと思います。

筆者は電気工事士の必須技能として電工ナイフの操作技能の習得を重視しており、基本的にケーブルストリッパなしですべての作業ができるように書いてあります。数センチ単位の配線長計測でも、ケーブルストリッパのゲージではなく、手(握りこぶしの大きさ等)や電工ナイフの長さで測定するように書いてあったりします。

合格者が電気工事士の実務に携わることを考慮した、非常に親身な配慮 3 なんですが、合格を狙うだけであれば、ケーブルストリッパをフル活用して、ケーブルストリッパでできない作業をほかの工具で実施するようにした方が良いでしょう。

2021/4/30更新: 2020年度からケーブルストリッパメインの書き方に変わっているようです。安心してオススメできそう。

逆に言うと、電工ナイフでしかできない作業には特に注意する必要があります(ゴムプッシングの穴あけと、VVRケーブルの被覆剝がし)。これらの作業は実施する問題も少ないので、意識して練習しましょう。

技能試験対策に当たってのポイント

1. ケーブルの太さからリングスリーブと刻印を求められるようにしておく。

この辺は筆記試験でも問われることなので、しっかり勉強してきた人にはそれほど苦ではないと思います。

技能試験で使う電線は1.6mmと2.0mmの2種類しかないので、この組み合わせと本数から、リングスリーブの種類と刻印を求められれば問題ありません。

  • 1.6[mm]2本=リングスリーブ『小』、刻印『〇』
  • 電線全部で8[mm]以下=リングスリーブ『小』、刻印『小』
  • 電線全部で8[mm]以上=リングスリーブ『中』、刻印『中』

だけわかっていれば、まぁ大体何とかなるでしょう。

ちなみに刻印間違いも欠陥なので、圧着する際には刻印間違いに十分気を付けましょう。私も練習中に何度かやらかしました。

2. 誤解しない複線図を書く。

複線図を2,3書くと分かると思うんですが、

  • 線が交差したとき、接続点なのかそうでないのかがわかりづらくなる
  • 隣り合った線の色が赤なのか黒なのか白なのかわからなくなる

汚く書いてしまうと、せっかくの複線図がこういう問題を抱えてしまい、施工ミスの原因になりかねません。

  • 線同士の間隔をある程度開けられる程度に大きく図を書く
  • 交差するときは大きく黒丸を書き、リングスリーブの刻印を記入しておく
  • マーカーを使って電線を色分けする

等、施工ミスを起こさないよう、明確に図を書いておくといいです。

あと、複線図を一度書いたからと言って、思考停止して作業に没頭しないようにすることも大事です。

先ほどリングスリーブのサイズの話をしましたが、特に接続、圧着施工をする際に『これで合ってるよな?』と確認を意識しておくといいでしょう。

圧着直前に複線図の記述ミスに気づいて、慌てて『複線図のほうを』直して正しい施工をした、なんてこともあったので。

3. 基本的には2周回す。

Qiitaの記事だと1周でも、って書いてありましたが、個人的には、

  • 合格率7割を目指すなら1周でもまぁ何とか。
  • 100%に近づけたいなら2周を推奨。

って感じです。

というのも、

  • 1周目の最初の数問の演習では、おそらく規定時間(40分)をオーバーする

だろうからです。

技能試験の候補問題は、どの問題をとっても基本作業の組み合わせなので、異なる問題に取り組む場合であっても、基本作業の習熟に伴って、施工に必要な時間は徐々に短くなっていきます。

最初は40分以上かかります

13問やればだいたいできるようになると思います。

って書いてあるのはそういう話です。

逆に言うと、1周だけでは、

  • 初期に取り組んだ問題は40分以内で完了することが保証されてない

ってことです。

1周目は習熟のため、2周目は確認と定着のため、と割り切って2周回すと、勝利条件をかなり固めることができると思います。

4. 必ず時間を測る。

技能試験の時間は40分しかないので、時間に余裕ができることはまずもってありません。余裕ができたとしても、確認のためにリザーブしておくのが賢明です。

このため、

  • 指定された作業を規定時間内で確実にこなせるか
  • 慣れた環境の場合、大体何分ぐらいで施工を完了できるか(何分リザーブできるか)

を知っておくことは非常に大事です。

あと、各問題の時間を計っておくと、

  • 自分が苦手なのはどの問題、どの作業なのか

如実に見えてきます。その問題は自分の弱点なので、その問題を構成している基本作業には特に注意しましょう。

ちなみに私は候補問題No.11が苦手だったらしく、いくつか作業やり直しが発生し、演習でも30分以上時間がかかっていました(ココ伏線)。

5. 完成後、各部品と配線の欠陥をチェックする。

電気工事士の技能試験の最も恐ろしいところは、実は時間ではありません。

  • 施工した電気工作物に、1個でも欠陥が存在した場合、有無を言わさず一発不合格になる。

という欠陥の存在です。

せっかくお金と時間をかけて技能試験までこぎつけたのに、くだらないミス一発で努力を水の泡にされてたまるか! と思ったら、施工終了後、各部品と接続に欠陥がないかどうか、教科書を見ながら1つ一つチェックしていきましょう。

大抵の教科書には(試験要領でもよいです)、各部品についてやってはならない欠陥が列挙してあります。例えばランプレセプタクルなら、

  • 正しく『輪作り』ができていない(巻きつき不足、巻きつきすぎ、左巻き等)
  • ネジが絶縁被覆を噛んでいる
  • 芯線が5[mm]以上はみ出ている
  • ケーブル外装が台座内に入ってない
  • ネジを締め忘れている
  • 極性を間違えている

こんな感じに欠陥が示されているはずなので、これらの欠陥が存在しているかどうかをすべてチェックし、やらかしていたら明確に認識し、きちんと施工しなおしておくことを勧めます。

6. 差し込み型コネクタは再利用しない。先に十分買っておく。

演習用に電線セットを買うと思うんですが、私が買った電線セットには、差し込み型コネクタの予備がなかったんですよ。小スリーブこそ100個ぐらい入ってたんですが、差し込み型コネクタは1周分の最小限個数しかありませんでした。

こりゃぁ使いまわすしかないのかなぁ、と思いつつWebで外し方を探し、実際に見つけて外したりもしたんですが、結構手間で時間もかかるんですよね。

そんな手間で時間を消費するぐらいなら、いっそまとめ買いして、使いまわさず捨てたほうが効率的じゃん、と。

これを買って、使いまわさずに捨ててました。失敗時の付け直しを考慮しても、50個づつあれば2周回しても十分余ります。

再利用の時間がもったいないですし、試験でも実務でも、施工失敗時の差し込み型コネクタは電線ごと切って新しいのを使うので、ケチケチせずに買ってしまった方が楽です。

7. 機器接続→ケーブル切断がおすすめ。

これは『すいーっと合格』シリーズの流儀でもあるんですが、ケーブルを先に切断して、切断したケーブルに機器をつなぐよりも、

  • 先にケーブルに機器を結線した後で、ケーブルを切断する

という手順で作業するのがおすすめです。

ケーブル切断は不可逆な作業なので、機器ごとに一つ一つ確認して切断した方が確実ですし、場合によっては結線済みのケーブルを入れ替えることでリカバリすることもできます。

大体この辺を意識して、10月下旬から12月初頭ぐらいまで、週末にひたすら演習していました。

以下、次号。


  1. 第二種電工では大スリーブは出題されないので、小中スリーブ程度で悲鳴を上げる私の腕力が弱すぎる、って話でもあるのですが。

  2. 個人的には電線外しはPanasonic純正のプレートはずし器、ゴムプッシングは電工ナイフのほうが確実だと思いましたが、この辺は好みの問題。

  3. ケーブルストリッパで取り扱えるのは一部の細い電線だけなので。