転職面接の面接官が応募者に語ってほしいこと

最近、別々の方から転職面接の面接官として同じ悩みを聞きました。そして、それは私も面接を担当する時に感じていたことでした。悩みとは応募者が教科書通りの回答しかしてくれない、ということです。

例えば、プロジェクトマネージャー候補として考えている方に対し、困難なプロジェクトを成功に導くために何をすべきでしょうか？と聞くと、「コミュニケーションをとることだと思います」と答えが返ってきます。では、具体的にはどのようなアクションを取りますか？と聞くと、ちょっと困った顔をしながら「ミーティングをこまめにするとかですかね…」と続きます。
その度に、どうして質問されることが想定されるのに準備しておいてくれなかったのだろう、ととても残念に感じます。

この質問をするとき、面接官側は応募してくださった方に仕事を任せられるか見極めたいと思っています。実のところ、面接官側だって先の質問に完璧な答えがないことを知っています。面接官側も日々の仕事の中で答えを求めて毎日悩み、挑戦しています。応募者にも仲間として一緒に取り組んでほしいと思っています。その思いに応えてくれる方かを見極めようとしているのです。

そのために話してほしいことは、ご自身のエピソードです。極端な話、失敗談だっていいのです。そこから何を学び、次をどうしたいのか。そのために今、何をしているのか。それが面接官として知りたいことです。
例えば、こんな話ができるかもしれません。要件の提示を遅れがちな担当者がいた。いつもそれが繰り返されるので、担当者へ催促や要件調整の協力を申し出つつ、早めにPMへもアラートをあげた。それでも滞るので自分から担当者の上司へも状況の説明と調整を依頼した。こうしたアプローチを繰り返した結果、毎日夕方に担当者との定例会が開催されるようになり、その後の仕様決定がスピーディになった。メールベースだと担当者に返信の負担がかかるが、対面の打ち合わせにしてこちらが議事のまとめを引き受けることで、担当者の負担も軽減することができた。次回はもっと早い段階から対面での打ち合わせを提案したい…。
このエピソードはPMBOK（いわば教科書）で言えば、コミュニケーション／リスク／ステークホルダー分野のマネジメントです。教科書の知識をベースにどのような具体的なアクションへとつなげたかを説明しています。

今回のエントリは面接を切り口に書き出しましたが、その予定がなくとも、今一度、自身の仕事を振り返り、面接官としての自分だったらどんな質問をするか、そして応募者としての自分はどんな回答をするか、考えてみることは実務につながるのではないかと思います。

例えば、こんなテーマも面白いかもしれません。

これまでずっと専門分野を深掘りしてきた中堅エンジニアが、「全体像を見る」ためには、どうしたら良いだろうか？

わたしがおすすめするのは、二種類の『見方の練習』である。最初の練習はまず、「上司の上司の立場になって仕事のあり方を考えてみる」ことである。あなたが課長だったら、本部長の立場で、どう仕事の仕組みをつくるか、考える。これは簡単ではない。かなり視点を背伸びして、高い位置から関連する仕事の全体を見なければならないからだ。

そしてもう一つの練習は、「顧客の顧客の要求を考えてみる」である。あなたは「顧客が要求して言ってくること」の背後に、顧客自身が悩んでいる「隠れたペイン」を見通すべきなのである。それはいいかえると、「サプライチェーンの中で、自社の位置を理解する」ことにも通じる。そういう視点を獲得できれば、あなたが日々直面している問題に対しても、別の見方、別の解決策が見えてくるかもしれない。

※引用元から一部省略して抜粋しています。

全体像を見るために 〜 インテグレートされた工場の作り方 : タイム・コンサルタントの日誌から

日々の課題に対して日頃から考え抜き、取り組むことが、将来のキャリアパスへとつながると信じています。

【ご参考】

今回のエントリをまとめるにあたり、リクルートエージェントの細井さんの本を読み返しました。応募者が語るべきこと、面接官が問いかけるべきことがまとめられており、双方にとってお互いの思いを十分に伝えるための参考になると考えています。もし、よろしければご一読ください。

「使える人材」を見抜く 採用面接

転職面接突破法―10万人が受講した究極メソッド

カリスマエージェント直伝! 履歴書・職務経歴書の書き方

プロジェクト・マネジメントのためのスケジューリング理論の基礎を学ぶ

はじめに

プロジェクト・マネジメント・ソフトウェア（例えば Microsoft Project）を使いこなすにはスケジューリング理論の基礎を理解していることが必要です。
現場ではプロジェクト・マネジメント・ソフトウェアが勝手に日程をずらす！とか、組みたい日程で設定させてくれない…というぼやきをよく聞きます。ですが、これらの挙動はプロジェクト・マネジメント・ソフトウェアが設定されたタスク・リソース・順序関係・制約からスケジュール理論を基に最適解を導き出そうとした結果であることがほとんどです（まれにバグやソフトウェアの制約のこともありますが）。つまり、プロジェクト・マネジメント・ソフトウェアの基礎をなすスケジューリング理論を学ぶことで、それらの挙動の理由を知り、真価を発揮することができるのです。
本エントリではプロジェクト・マネジメントのためのスケジューリング理論の基礎を学ぶことに役立つ資料を紹介します。

書籍

建設エンジニアのためのPMSによるプロジェクト計画入門―基礎からリスクスケジューリングまで

建設エンジニアのためのPMSによるプロジェクト計画入門―基礎からリスクスケジューリングまで

この本のタイトルは2つの点で損をしています。それは、建築エンジニア向けをうたっていること、そしてPMSという耳慣れない略語を使っていることです。

まず、この本の対象読者は建設エンジニアに限定しません。スケジュール管理に関わる全てのマネージャそしてエンジニアが対象となります。説明例は主に建設にかかわるものですが、スケジュール管理に関する基本的な部分は業種を問わず適用できます。

また、PMSという略語は"Project Management Software"のことです。具体的には以下のようなソフトウェアのことです。

• Microsoft Project
• ProjectLibre
• Artemis Schedule Publisher
• Primavera

この本ではスケジューリング理論の基礎から実際のプロジェクト管理の方法まで幅広くカバーしています。また、説明例は建設にかかわるものですが、専門的な用語は少なく、他業種の方でも内容を十分に理解することができます。
また、日本語でスケジューリング理論の基礎に関して説明した数少ない本です（本屋、Amazon、Googleで探しましたが他に見つかりませんでした）。スケジュール理論を勉強するための入門書としてお勧めします。

本の目次から主だったトピックを挙げます。

• プロジェクト計画の立て方
• リソースを考慮した計画
• ネットワーク工程計画法
• クリティカル・パス法 (CPM)
• 実施フェーズにおける進捗管理
• リスクを考慮したプロジェクト計画

また、後述する mosaic の Core Scheduling Papers の一部を含んだ内容となっています。この本で概略をつかんだうえで、Core Scheduling Papers を読み進めると理解しやすいです。例えば、以下のような内容が含まれています。

• アロー型モデルとプレシーデンス型モデルの違い
• 順序関係(FS, FF, SS, SF)
• フロートの種類（トータル・フロート、フリー・フロートなど）
• タスクの中断

Mosaic Core Scheduling Papers

オーストラリアの Mosaic Project Services Pty Ltd は自社のウェブサイトでプロジェクトの計画とスケジュールに関する資料を公開しています。
Planning and Scheduling

その中に Core Papers として公開された資料があります。この中から特に有用と思われる資料とそこで説明されているトピックを以下に挙げます。
全て英語ですが、ここで挙げた資料は図が豊富に使われており比較的理解しやすいです。英語が苦手な方も理解できるところからつまみ読みしてはいかがでしょうか。
資料によってはトピックが重複していることもありますが、異なった視点から議論しているため、併せて読むことをお勧め増します。

Links, Lags and Ladders - the subtleties of overlapping tasks -

http://www.mosaicprojects.com.au/PDF/Links_Lags_Ladders.pdf

• 順序関係 (FS, FF, SS, SF)
• リードとラグ
• オーバーラッピング・アクティビティの管理
  • 順序関係の論理的矛盾
  • ラダー
• ハンモック・アクティビティ

Calculating and Using Float

http://www.mosaicprojects.com.au/PDF/Schedule_Float.pdf

• ADMとPDMにおけるフロートの扱い
• フロート計算
• カレンダーとフロートの関係
• ネガティブ・フロート
• ハンモック・アクティビティ（サマリー・アクティビティ）

Basic CPM Calculations

http://www.mosaicprojects.com.au/PDF/Schedule_Calculations.pdf

• アクティビティの要素と定義
• PDMのスケジュール計算
  • 順序関係 (FS, FF, SS, SF)
  • 制約
  • 複数の先行／後続アクティビティ
  • オーバーラッピング・アクティビティ
• フロート計算
• カレンダーとスケジュール計算

記事・ブログ

DRAGとCostの解説

納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か : タイム・コンサルタントの日誌から
Drag Cost - 納期を加味した真のコストを考える : タイム・コンサルタントの日誌から

DRAGとはあるアクティビティがクリティカル・パスに対してどれだけ影響しているかを計るための指標です。また、これにCostを加味することで、クリティカル・パス短縮のために攻めるべきアクティビティをコストの観点から検討することができます。

英語版Wikipediaで"Critical path method"の解説を見ると、"Critical path drag"が度々登場しています。対して、日本語版Wikipediaの"クリティカルパス法"の解説ではDRAGについて触れられていません。DRAGの日本での普及はまだまだのようですが、今後に向けて知っておくべき手法と思われます。

本ブログのエントリ紹介

本ブログではここまで紹介してきた資料をベースにしたエントリを公開しています。以下に紹介させていただきます。

ADM（アロー・ダイアグラム法）、PDM（プレシデンス・ダイアグラム法）、AON（アクティビティ・オン・ノード）の違い - ぱと隊長日誌
ADM / PDM / AON は表現の違いに着目されがちですが、順序関係の扱いや歴史的経緯まで含めて比較を行いました。

ADM(アロー・ダイアグラム法)及びPDM (プレシデンス・ダイアグラム法)におけるタイミングとフロートの計算方法 - ぱと隊長日誌
ADM / PDM を明確に区別した上で用語の定義と計算式を説明しています。また、同じことを指す場合でも資料によって異なる名前を使う場合があるため、よく使われる別名も併せて記載しています。

PDM （プレシデンス・ダイアグラム法）のスケジュール計算における制約の影響 - ぱと隊長日誌
PDMにおいてはアクティビティに対する制約を考慮したスケジュール計算をする必要があります。また、それによってネガティブ・フロートを発生する場合があることを示しています。

PDMにおいてSS/FF関係を持つアクティビティのトータル・フロートのパラドックスを解消する - ぱと隊長日誌
PDMで前後のアクティビティとSS/FF関係を持つアクティビティにてトータル・フロートにパラドックスが生じるケースを説明し、その解決策を提示しています。

スケジュール計算とラグとカレンダーの関係 - ぱと隊長日誌
スケジュール理論を議論する際にカレンダーはしばしば無視されます。ですが、実際のプロジェクトでカレンダーを適用したときに考慮すべき点をまとめています。

おわりに

ここで紹介した資料以外にも役に立つもの、参考になるものがまだまだあると思います。ご存知の方はぜひ本エントリのコメントやTwitter(@pato_taityo)などでご教示いただければ幸いです。

知らないことを知り、知る過程の大切さ

知(し)らざるを知らずと為(な)す是(これ)知るなり
《「論語」為政から》知らない事は、知らないと自覚すること、これが本当の知るということである。

知らざるを知らずと為す是知るなり(シラザルヲシラズトナスコレシルナリ)とは - コトバンク

疑問・問題には解決・答えに至るまでの過程（プロセス）があります。そして、その過程は結論とともに残すべきです。

まず、「知らない」ということを知ったこと自体に価値があります。そして、それはきっと世界のどこかで誰かが悩んでいることでもあります。
それが解決、もしくは道半ばだとしても、文章や映像、言葉として残せば、知識と経験の共有となります。もしかしたら、さらに議論が発展するかもしれません。

知らない⇒知るに至った過程はとても大切です。
何がきっかけで知らないことを知ったのか。どうやって調べたのか。その過程でどんなことに躓き、解消したのか。結果何を得たのか。

知らないことに対して誰かが出した結論だけ知りたいと思うこともあるでしょう。
でも、その誰かが結論を出すに至った過程は自分が問題を理解するための過程でもあるのです。もしその過程を知らなければ、過程を自分で再発見するか、表面的な理解にとどまることになります。

そして、調べた本人もまた、過程の記憶は時間とともに薄れていきます。だからこそ、その過程を記録に残しておく価値があるのです。
その記録は別の課題を調べる際のヒントになるかもしれません。

繰り返しとなりますが、あなたが知らなかったことはきっと誰かが悩んでいる、もしくはこの先悩むことです。そして、結論だけでなくその過程を示すことはその疑問・問題だけでなく、他の疑問・問題に立ち向かうヒントとなるかもしれません。それは共有すべき価値ある情報です。
私にとってブログは共有のツールの一つですが、どんなやり方であってもいいと思います。

あなたのひと手間が、公開する勇気が、世界の誰かの助けとなります。