１．問題の内容

• 実質的な管理技術者・主任技術者あるいは主担当者としての専門分野の業務経験と技術（専門技術・管理技術）水準が問われます。
• 問題2とともに試験Aの130分（試験Aの中で問題1に至り問題2に行ったりすることはできる）です。従来は問題1だけで120分だったことを考えると、著しく時間が短くなったといえます。
• 2,400字以内の記述問題　（入力練習用のフォームはこちら、2019年度までの答案用紙はWord版がこちら、PDF版がこちら）
• ウェイト：推定30〜40％

２．出題内容

問題1は、以下のような問題文になっています。
CBT試験になって「冒頭の［　　］内には業務実績証明書記載欄の番号を記入しなさい。」という部分は少し変わりましたが、設問本体は変わっていません。

あなたが受験しようとする部門について、業務実績証明書に記載した技術的責任者あるいは担当者として実際に行った業務の中から3つ選び、このなかの2つは次の4項目についてそれぞれ400字以内で記述しなさい。解答用紙の中では、【経験業務その1】と【経験業務その2】に記述し、冒頭の［　　］内には業務実績証明書記載欄の番号を記入しなさい。 (1) 業務の名称、発注者名、履行期間 (2) 業務の目的 (3) 業務の内容 (4) あなたの果たした役割 前問の3つの業務のうち、残り1つは次の7項目について、1600字以内で記述しなさい。解答用紙の中では、【経験業務その3】に記述し、冒頭の［　　］内には業務実績証明書記載欄の番号を記入しなさい。 (1) 業務の名称、発注者名、履行期間 (2) 業務の目的 (3) 業務の内容 (4) あなたの果たした役割 (5) 技術上の問題点とその対応 (6) 業務の実施上の問題点とその対応 (7) 上記(5)(6)の対応について、現時点での評価 他の解答例をそのまま利用するなど技術者倫理に抵触するような場合には採点されません。 発注者の方は、担当した発注業務について発注者の立場から記述してください。

●3例がいずれも業務実績証明書に記載の事例で、業務の名称や発注者、履行期間、業務上の役職、実施内容等が整合している。
●RCCMとしてふさわしい規模・内容・重要度・役割分担の仕事が3例記述されている。
●技術上の問題点がRCCMにふさわしいレベルの問題で、解決策が専門技術によるものである。
●業務実施上の問題点が管理上の問題で、解決策が管理技術によるものである。
●技術士のような創意工夫はいらないが、着実で、試行錯誤・対処療法的な解決ではない。
といったことがクリアできていれば大丈夫です。
その場でテーマから全部アドリブで考えるのは論外、大筋や章立てだけ決めておいてその場で詳述というのもまず不可です。十分練った文章を作っておくことが確実です。

手書きからCBT試験への変更に伴う変化は、以下のとおりです。

• キーボード入力になるが、いつも仕事で使っているキーボードではないからミスタッチしやすく、いつも使っている日本語入力辞書ではないから誤変換しやすい。そのことを頭に置いて入力すること。
• 2019年度までの各項目（設問）の文字数制限は変わらない。項目ごとに入力エリアがあって、それぞれに文字数制限があると。ただし「Enter/改行」が1文字としてカウントされる仕様のようなので注意
  

  文字数 業務１ 業務２ 業務3 業務の名称 50 ● ● ● 発注者名 25 ● ● ● 履行期間 25 ● ● ● 業務の目的 100 ● ● ● 業務の内容 125 ● ● ● あなたの果たした役割 75 ● ● ● 技術上の問題点対応 425 − − ● 業務実施上の問題点対応 425 − − ● 現時点評価 350 − − ●

• 130分の時間枠の中で問題�Uと行ったり来たりもできる。
• 下書き用のノートボードとペンがあるので、それを使うことができる。ただし持ち帰れない。
  
  

３．答案の書き方

1. 必ず業務実績証明書記載業務から事例を選ぶ
   問題文で指定されていることなのですから、必ず守りましょう。「こういった指示を守れないような人は、実際の業務でも発注者からの指示事項を無視したり勝手に解釈してしまったりしかねないので、管理技術者の資格であるRCCMにはふさわしくない」と考えられて一発不合格になっても文句はいえません。
   

   過去の事例では、番号を間違えた（番号と内容の対応が、業務実績証明書とまったく整合していなかった）ために、問題1だけでなく全問採点してもらえなかった、つまり失格扱いになった人がいます。業務実績証明書との整合性をあまく見てはいけません。

   
   
2. 受験部門に合わせた内容＆コンサルタント業務の内容を書く
   受験部門から外れた内容の経験論文を書いた人、施工計画部門以外で工事監督などコンサルタント業務以外の業務内容を書いた人は0点になったという例が少なからずあります。
   このことを十分踏まえて、受験部門のできるだけ王道に近い内容の、また調査・設計などコンサルタント業務に絞って（施工計画部門に限り工事監督でもよい）事例を選びましょう。
   
3. 論文は十分に練りこんでおく
   　問題はまずもって変わらないでしょうから、あらかじめ作って練り上げた文章を丸暗記して機械的に書きまくることができます。
   　その場でテーマからアドリブで考えても書ける人、大筋や章立てだけ決めておいて文章はその場で組み立てることができる人はそうすればいいでしょうが、そういう自身がなければ十分練った文章を作っておくことが確実です。
   　なお、項目ごとの文字数が決まっているので、暗記しておく場合には文字数を間違えないようにしましょう。入力練習用のフォーム（こちら）で文字数を確認しながら練り上げてください。
   
   
4. 業務の名称、発注者、履行期間（50文字、25文字、25文字以内）
   　業務の名称は、必ずしも契約業務名と同じである必要はありません。契約内容をいちいち確認したりしませんし、何よりも業務内容がわかりやすい業務名が一番です。「道路改良工事その1工事　設計委託業務」などという業務名よりも、「一般県道○○線　道路改良設計委託業務」のほうがよほどいいです。
   　発注者名は直接の発注者名を書きます。もし下請けの場合は元請けを書きましょう。ただそれだと公共事業かどうかがわからないので、たとえば「発注者名：○○株式会社（元発注：○○県△△事務所）」というようにしてもいいでしょう。
   　履行期間は業務実績証明書との整合を考えると、和暦で書いたほうがいいでしょう。日までは書く必要はありませんが、たとえば4月15日〜8月15日だと期間は4ヶ月ですが、これを「4月〜8月」と書くと5ヶ月になってしまい、月数が業務実績証明書と整合しなくなることがあります。そういった場合は日まで書いたほうがいいでしょう。
   　以上ですが、これらの事項は出願時に提出した業務実績と照合される可能性がありますから、一言一句までしっかり整合させておきましょう。
   
   
5. 業務の目的（100文字以内）
   　業務の目的を事業目的まで含めて記述することで、事業全体を見渡す俯瞰的視野から業務に取り組むという管理技術者に求められる資質がアピールできます。
   「こういう事業に伴い、こういう成果を上げることを目的とする」というように、事業の中での自分が担当する業務の位置づけ、そして業務成果として求められているものをしっかり書くということです。
   　事業目的と業務目的を時に混同して、事業目的を業務目的として書いてしまう方がおられます。事業は複数の業務から成っており、それぞれの業務が事業目的達成のために担っていることがあります。それが業務目的です。
   　業務目的は発注者ニーズです。業務目的はコンサルタントが自分勝手に決めたりしてはいけません。業務目的とは発注者がこうしてほしいと思っていることで、「発注者ニーズは何だろう」と考え、設計書や仕様書、打合せ等を通じてそれを把握することが重要です。そして、その業務目的を業務の中で実現することを考えるのがコンサルタント業務です。
   　業務の目的というより、業務概要を書いてしまっている例が多くあります。
   　なぜ業務の目的を書くかというと、建設コンサルタント業務が、どんな目的で発注されたか、顧客要求やその背景にある社会的要求などをしっかり把握しておくことが非常に重要だからです。
   　業務の目的を把握していないと業務を遂行することが目的になってしまいます。たとえば地質調査業務において、橋梁基礎調査としてボーリングを2本行った場合、その目的は「橋梁基礎地盤状況を把握する」ことですよね。決して「ボーリングを2本やる」ことが目的ではないですね。それは目的達成のために必要なこと、つまり手段です。手段と目的を取り違えないようにしましょう。
   　結局、「○○が目的である」か「○○を目的として△△を実施したものである」といったような書き方になるのではないでしょうか。
   

   固有名詞の情報価値は極めて小さい

   たとえば「○○県○○市○○地区を通過する一般県道○○線」という記述には、ほとんど何の情報もないと思っておきましょう。その市なり道路がすごく有名であったり採点者がたまたま知っていたりすれば現場がイメージできるでしょうが、そうでなければ何もイメージできません。 そういった記述よりも「人口20万人の三大都市圏近郊都市を通過する、日交通量2万台の県道」というほうが、よほど現場がイメージできますよね。 業務の名称に固有名詞が入っているのはしかたがありませんが、「こういう現場です」という説明に固有名詞を使うのは得策ではありません。

   
   
6. 業務の内容（125文字以内）
   　3例のうち略記のみ記述する2例については、業務の内容を書くのはここだけですから、RCCMとしてふさわしい技術力をできるだけ盛り込むようにしましょう。ただそうすると課題解決部分に絞り込んだ記述になってしまいがちですが、その一方でここでは業務内容全般を網羅することも重要です。全体をざっくりまとめたら、その中での工夫点や問題解決はあれもこれもと欲張らず、受験部門のRCCMにふさわしいと思うことを1つだけ書くようにしましょう。
   　少なくとも設計書に書いてあるようなこと、つまり業務項目や数量を列挙しただけの内容にはしないようにしましょう。あくまで「こういうことをやった」という内容でいいのですが、そこで何らかの技術力をアピールできるようにするのです。
   なお、ここはダラダラ文にせず、箇条書きや段落番号を使った時系列記載などがお勧めです。
   　委託業務においては、業務の大きな方向性を決めていくという役割（発注者）と、その方向性を実現するための最適で具体的な設計等をするという役割（受注者）があり、さらには発注者・受注者双方に、実務に実際に携わる担当者とそれを指導・統括・監督する立場の人がいます。業務はそれらの人達が異なった役割分担を持って連携して遂行するものです。業務内容はこういった役割分担と整合する内容を書きましょう。
   
   
7. 私の果たした役割（75文字以内）
   　業務の中で果たした役割を書くのですが、ここはRCCMに求められる役割を強く意識しましょう。すなわち、RCCMは専門技術者ではなく管理技術者だということです。専門技術的な役割分担を持つことはもちろんですが、管理上の役割分担も持っていないと管理技術者とはいえません。さらに管理上の役割分担はできれば業務全般の工程管理などをやっていたほうがいいでしょう。また関係機関等との連絡調整も管理技術者に求められることです。
   　つまり、�@専門技術的な役割担当、�A管理上の役割担当（たとえば工程管理や品質管理）、�B発注者や関係機関、地元等との協議・連絡調整という3つを盛り込むことが望ましいといえます。さらに、業務上の役職（管理技術者とか主任技術者、主担当者、あるいは設計担当など）も明記するといいと思います。
   　以上、ずいぶんたくさん盛り込まなければなりませんが、たとえば
   

   私は○○（業務上の役職。「主担当者」とか「管理技術者」など）として、業務全般の工程管理を担当するとともに（業務全般を管理したことをアピール）、○○・△△・□□（いずれも専門技術的役割分担）を担当した。また発注者側担当者との協議・地元関係者との連絡調整を行った（発注者との協議はもちろんだが、地元や関係機関等との連絡調整も重要な役割）。

   というような内容にするといいのではないかと思います。
   
8. 技術的問題点（425文字以内）
   いろいろな書き方がありますが、もっとも得点しやすいのは、次のいずれかだと考えます。
   
   (1) 一般的な技術的問題
   　当該専門分野における一般的な技術的問題をあげ、その解決内容を記述するのが、やはり一般的です。
   　ただ重要なのは、技術的問題点を最初から予見して対策を講じているということです。業務の実施計画をたてるときに既往データ検討や現地調査をしっかりやって、問題点を察知・予見し、これに対処したというストーリーがよいでしょう。
   　くれぐれも予想外の事象に行き当たって、あわてて勉強したとかアドバイスもらったということのないようにします。試行錯誤・対処療法は最も減点されやすい書き方です。
   
   (2) トレードオフの技術的解消
   　工期がないのに高度な解析を求められたとか、データが不足しているのに的確な判断を求められた、利便性と自然環境保全の両立を求められたというような、トレードオフ（二律相反）を、専門技術力で解消したというケースです。
   　解決策としては様々なものがあると思いますが、ここで大切なのは、あくまで専門技術力による解決でないといけないということです。工程の取り回し、人員配置、長時間労働その他で時間的問題を解決したというようになってしまうと、「それは業務実施上の問題でしょ」という評価になってしまいます。
   
   
9. 業務実施上の問題（425文字以内）
   　業務をスムーズに遂行するためには、たとえばミスを出さないとか工期に遅れないとか、事故を起こさないなど、様々な管理上の対応が必要になります。業務の実施上の問題とは、こういった管理上の問題をいいます。
   　業務管理の要諦はQCDといわれます。つまり品質（Quality）、コスト（Cost）、工期（Delivery）ですね。ざっくりいえば、品質管理はミスを出さないことです。コスト管理は原価管理です。そして工程管理は工期遅延にならないことです。いっぽうRCCMは管理技術者として発注者ニーズに応えることが責務です。コンサル業務の場合、発注者の要求はたいていの場合品質確保と工期厳守です。コストについて要求されることはありません（廉価なインフラを設計するなどはコスト管理ではなく品質管理です）。
   　ということで、業務実施上の問題対応は、品質管理に関すること（つまりミスを出さない、発注者要求品質を確保する）と工程管理に関すること（工期厳守）のどちらかにしておけば間違いないでしょう。
   　また、地質調査や環境調査等現場がある業務では事故を起こさないこと、つまり労働安全衛生管理上の管理や、濁水流出等の環境負荷を最小化すること、つまり環境保全管理もあり得ますし、個人情報を扱う業務ではこの漏洩によるトラブルもあるでしょう。いずれにしても、それにより業務が中断したり滞ってしまったりしないための管理になります。
   　工期遵守は、たとえば、
   ○技術上の問題点に対処できるような業務計画を提案したが、通常と異なる手法などを使っていたため、発注者が上部機関と相談していたりして着工が遅れた。
   ○しかし、これを補う管理（調査なら現場、設計なら図面処理や解析処理に係る人員・作業班を増やし、それでは管理がおろそかになりやすいので専属管理者をたてて管理したという形などがよい）を行ったので、工期にもちゃんと間に合った。
   というようなストーリーがよいと思われます。くれぐれも、「技術的に大変なんだということを力説して工期を延長してもらった」というようなことを書くことのないようにしましょう。
   体系的に工程管理を理解していることをアピールできるキーワードは、バックワードスケジューリング、クリティカルパス、PERT、アローダイヤグラム、バーチャートあるいはガントチャート、CPMなどです。これらの用語はネットで簡単に調べられますから、理解して使いこなすようにしてください。たとえば「バックワードスケジューリングの結果、工期厳守が難しいことが判明した。そこでアローダイヤグラム（バーチャートでもいい）上でクリティカルパスを抽出し、この経路上にある○○作業に対して作業員を追加投入して工程短縮した」というような問題点対策が工程管理上は妥当な内容になります。
   　工期に余裕がない場合、すなわち工程短縮まではしなくてもいいけれど、工程遅延はなんとしても避けなければならない場合、手戻りの発生が最大の問題点となります。
   　手戻り発生原因には事故などもありますが、現場作業が主ではないコンサルタント業務では、なんといってもミスが最大の手戻り原因になります。つまり品質確保としてミスを防止する必要が出てくるわけですね。ミス防止は以下の方法で対処します。ポイントは検査ばかりを大事にするのではなく、そもそもミスを発生させないような対処をすることです。ミス発生防止策を講じずに検査ばかりがんばっても、次々に出てくるミスを潰しまくっているというモグラ叩きゲームのような状態になってしまいます。
   

   ミス防止の方法	ミス防止方法の解説	具体的管理手法
   ミス発生防止	そもそもミスを発生させない	�@ルーチンワークは標準化する �Aブレインワークは教育でスキルアップする
   ミス見逃し防止	ミスを見つけ外に出さない	検査の高度化・多重化

   　なお、設計の各段階での検査、チェック＆レビュー、統計的手法その他いろいろな書き方があると思いますが、「ISO9001認証されており、そのシステムで検査した」というようなストーリーは、「あなた自身の工夫がない」「あなたの業績とはいえない」と評価されるので駄目です。
   　総じて品質確保をテーマにすると、RCCM論文は書きにくいといえます。できれば工程管理のほうがいいでしょう。
   　安全管理は、現場作業における労働安全衛生管理や、内業における過重労働やメンタルヘルスといった事故・健康阻害を防ぐことになりますが、過重労働・メンタルヘルスは労基法違反と受け取られたりして、あまりいい結果を招かないことが多いので、前述の工程管理等に関する題材がよほどないとき以外は避けたほうがいいでしょう。
   　地元住民への説明・コミュニケーション・住民参加といった合意形成プロデュースは、今後建設コンサルタントに強く求められる能力です。書く内容としては、住民説明の重要性・早期実施などを発注者へ説明し実施してもらう、わかりやすい説明などドキュメンテーション能力、一歩進んで住民参加関連作業の実施といったことが妥当ではないかと思います。ただし合意形成プロデュース的なものは専門技術的ともいえるので、これを業務実施上の問題点対応とするのはちょっとむずかしい事例も多くなってきました。
   　以上、業務実施上の問題点対応について様々なパターンを紹介してきましたが、とどのつまり、「業務のスムーズな遂行上、障壁となるような問題点」の話になりますから、読み手（＝採点者）が、「この業務だったら、確かにそれが最大の障壁になるだろうな」と思うようなものを選んでください。順当に考えれば、工期遅延リスクを問題点とし、時間＝工数÷リソースですからリソース追加投入が最も無難な題材といえるでしょう。
   
   
10. 現時点での評価（350文字以内）
    　技術上の問題点対応と業務実施上の問題点対応の両方について現時点評価をします。「(5)についての現時点評価」と「(6)についての現時点評価」の2章構成にするといいでしょう。
    　まず現時点での評価は、反省や後悔ではなく「今ならこうする」という形にします。すなわち、「現時点では世の中の技術水準も上がっているし、自分自身も成長している」という認識のもとに、「おおむねうまくやったのだが、あれはもっとこうすればよかった」ということであれば、「おおむねうまくやった。今ならさらにここをこうする」というように書くと得点が期待できます。
    　失敗だけでなく、「これはすごくいい方法だった。こんなことにも応用している」というように発展型にしてもよいでしょう。
    　技術上の問題点対応については、「提案は最適だったけれど、制限等条件がこのように変わればこういう方法もある」というようなことを書いて、「今後も現場条件に合わせた最適な提案ができるように技術研鑽する」みたいなことを書くのもひとつの書き方です。
    　いずれにしても、その業務を経験してから今まで成長していないという印象を与えないようにすることが大切で、まちがえても工期管理や地元対策で下手をうったというような低レベルなことは書かないようにしましょう。特に詳述事例の実施時期から5年以上がたっているような場合は、その後の技術的進歩や社会経済情勢の変化等を踏まえて、「今ならこうする」ということを書くようにしましょう。
    
    

４．記述上の注意・留意点

1. 文章はとにかく読みやすくする必要があります。採点は通読でなされるので、読みにくいと即アウトになります。
   起承転結、箇条書き、長文の回避など、とにかく読みやすい文章を心がけましょう。ただし図表は使えません。
   
   
2. 漢字の誤字・脱字が起こりやすいので注意しましょう。いつもパソコンで文章を書いていると漢字の記憶があやふやになります。ましてCBT試験ではいつも使っているものとは違うパソコン・キーボードを使うので、ミスタッチしやすいし、辞書もいつもの辞書とは違いますからいつもと違う変換をしたりしますので誤変換にも気がつきにくくなります。建設コンサル業界ならでは単語（たとえば「礫」とか「天端」「法尻」など）はなかなか出てこないかもしれません。論文中の重要なポイントの漢字変換は十分注意して最後の見直しを忘れないようにしましょう。
   
   
3. 箇条書きリストアップなどの書き方で読みやすくしてもよいと思います。行数制限は基本的にありません（何行で無限に書けるというわけではありませんが、従来よりよほど多く改行できます）
   
   
4. 長文は読みやすければかまいませんが、主語と述語のねじれなどの構文エラーや読みにくさにつながりやすいので、文章力のある人以外は避けたほうがよいと思われます。