Hatena::ブログ(Diary)

Basic このページをアンテナに追加 RSSフィード

2017-07-31

PMP受験体験記〜受験動機編

| 23:11 | PMP受験体験記〜受験動機編を含むブックマーク PMP受験体験記〜受験動機編のブックマークコメント

技術士情報工学)を取得した際の話は、以前に書いた。あれから9年が経過し、職場の環境も仕事の内容もすっかり変わってしまったけど、自己研鑽は地道に少しずつ進めている。今回は、その一環としてPMPを取得した際の経験を紹介したい。

主な受験動機は下記の通りだ。

  1. 技術だけでは仕事できないプロジェクト管理の立場になった
  2. 海外のプロジェクト管理者とスムーズに話が出来るようになりたかった
  3. PMP保持者と対等に話が出来るようになりたかった

1.に関して多くを語る必要は無いと思うけど、要するにそれだけ歳を取り、目の前の技術だけではなく、メンバが抱える課題もまとめて面倒を見る立場になったという訳だ(意味するところは分かりますね?)。自分ひとりの世界で満足するだけではなく、プロジェクトを率いて成功に導くというミッションが与えられた以上、それに相応しい知識を習得して一流の管理を行わねばならない。PMBOKのテキストを最初に開いたのは遥か昔のことだけど、その知識獲得と実務経験の証として、PMPを取得しておくのも悪くないと思ったのがそもそものきっかけである。

2.については説明が必要かも知れない。昔から海外の顧客を相手に仕事をする機会が多いのだが、その中で日本国内では(あるいは社内では)決して要求されない資料を要求されたり、データを求められることが有り、長年の謎だった。理由を周囲の人に聞いても誰も分からないとの返事。海外と日本の文化の差異という見解を聞いたことが有ったけど、国も会社も異なる顧客が同じ類の質問をしてくるのだから、何か理由が有るはずだ。その答えに辿り着いたのは、PMBOKのテキストを読んで理解した時のことだ。

そう、海外のパートナーは「プロジェクト管理」という視点で物事を把握してくるから、そこには「会社のルール」「個人の経験に基づく判断」の背後に、PMBOK知識が存在しているのだ。自分の周囲にPMP所有者はもちろんのこと、PMBOKすら真面目に読んだことのない「自称」プロジェクト管理者ばかりだったので、その質問の意図を理解できないのは当然だった訳だ。

そんな訳でPMBOK知識を一通り学んだ後のプロジェクト管理では、海外のパートナーと驚くほど話が通じるようになった。PMBOKの考え方をベースにすれば、先方が望むものは分かっているし、こちらも同じレベルの視点で回答すれば相手は直ぐに納得するし、話は簡単に片付いてしまう。「質問の意図が分からない」と首をひねる隣のプロジェクト管理者と少しだけ差をつけることが出来たのはPMBOK知識のおかげだろう。

最後に3.に関しては、技術士取得の時と似ている。PMBOK知識があれば仕事はスムーズに進むようになったのだけど、「PMBOKで言うところの...」なんていう説明をしていると、相手は当然のごとく私がPMP保持者だと誤解してくるようになる。「いやPMPは持っていない」という回答には、「以前は所有していたが、更新を放棄したのか?」と聞いてくる。「いやいやPMBOKを勉強しただけでPMPは最初から持っていないし、試験を受けたことすら無いのだ」と回答すると、仕事の話はそっちのけでPMP取得を勧めてくるようになってしまった。このプロジェクトが終わったら取得するよ、という言い訳も徐々に苦しくなってきたので、仕事の合間を見て学習に励み、ようやくPMPを取得したという訳だ。

もっとも、PMPの人気も一時期ほどではないようで、「今頃、PMP?」という辛辣なコメントを貰ったのも事実である(但し、PMP非保持者)。変化の激しい時代に、一昔前のPMBOK知識だけで太刀打ちできるとも思えない。これは事実だろう。しかし、PMPの名称が入った名刺を貰えば、相手の力量が直ぐに把握できるし、共通知識ベースで話を進められるという直接的なメリットも大きい。プロジェクトを成功に導くための条件として、PMPはあまり関係しないと思うけれど、プロジェクトを推し進めるのは結局のところ人間なのだ。その人と人との間の信頼関係の構築に役立つのであれば、PMPという資格も悪くないと思っている。

わたしPMP試験について一番問題に感じているのは、じつはそれが知識を問う試験にすぎないことだ。以前から書いていることだが、能力とは知識や資質だけで決まるものではないと、わたしは考えている。個人の能力を構成する要素としては、知識・感覚(センス)・身体的スキル・創造性などがあり、これらをきちんとバランスし、かつ整合的・臨機応変に、組み合わせて活用できなければならない。だから、誰かの能力を評価するのはとても手間のかかる、難しい仕事なのである。これを、わずか数時間程度の、パソコンの前の応答だけで測ろうというのが、もともと無理なのだ。PMやPM補佐を10年近くやってきた者は、こうした矛盾点にそもそも違和感を感じるのだろう。

PMPの資格はほんとうに仕事の役に立つのか : タイム・コンサルタントの日誌から


トラックバック - http://d.hatena.ne.jp/rabbit2go/20170731

2017-07-11

PMI日本フォーラム2017に参加した

| 23:00 | PMI日本フォーラム2017に参加したを含むブックマーク PMI日本フォーラム2017に参加したのブックマークコメント

2017/7/8-9は、PMI日本フォーラム2017へ行ってきた。初めて参加するイベントだったので、事前に講演プログラムを見てもなかなか分からず、結局、聴講する講演を各分野から選択して全体的な傾向を掴むようにした。発表資料は、もちろん後日ほとんど全てが参加者には公開されたけど、(この手の講演の常として)資料を読んだだけではあまり理解できないことが多い。週末の2日間に話を聞き続けるのは大変だったけど、それ以上に値打ちのあるイベントだった。

講演全般の所感として、次の点が印象に残った。

  • PM界の大御所や会社社長、研究会の成果発表など、プロジェクトマネジメントに関わる内容が幅広く網羅されていた。私のように様々な分野の講演をはしごする人もいれば、一つの会場に留まり特定の分野の内容をとことん聞き続けるという人も少なくなかったようだ。
  • PMBOKガイド第6版は、2017年9月に発刊される。世界各国の人が1箇所に集まり、翻訳の集中的な討議を行ってきた成果として、日本語版も同時に出るとのこと。これは素晴らしい。PMPの試験は2018年早々から更新されるようなので、それに間に合わせる必要も有ったのだろう。
  • PMBOKは古くて硬いもの、と認識はもはや時代遅れ。アジャイル的な文言、考え方が次々と出て来ているし、その方針に沿った資料も数多く発刊されているという事実を初めて知った。PMBOKガイドを読んで満足しているとしたら、それは少々まずい兆候かも知れない。
  • プロジェクトというよりは、プロジェクトの上位であるプログラムポートフォリオを含めた、ビジネス的な視点での話には、これ程までにマネジメントの対象が広がっているのかと唸ってしまった。もはやプロジェクト云々のレベルではなく、経営に近いレベルの話だと思う。
  • リスク管理に関心が有ったので、関連するセッションを幾つか聴講し、この中では「A-4 プロジェクトリスク評価、機械学習適用して成否の予測」が興味深かった。プロジェクト初期のデータを元に、その成否を予測させるという仕組みと実際の結果が紹介されており、予測の精度はともかく、こんな指標が参考レベルでも良いから欲しいと願うPMは多いのではないだろうか。

ところで今回はPMI会員として、PMP資格のPDU獲得という目的も兼ねて受講した。お前は一体いつPMPを取ったのか?という質問への回答は、次回のエントリで紹介したい。

トラックバック - http://d.hatena.ne.jp/rabbit2go/20170711

2017-06-19

Jetty 9.4.6への更新にはまる

| 23:24 | Jetty 9.4.6への更新にはまるを含むブックマーク Jetty 9.4.6への更新にはまるのブックマークコメント

Jettyのバージョンを更新したら、アプリケーションの設定にはまってしまったので記録として残す。

動作環境

  • macOS 10.12.5 (Sierra)
  • Java SE 8 Update 131
  • Jetty v9.1.5 (更新前)
  • Jetty v9.4.6 (更新後)

問題

2017-06-19 21:00:06.070:INFO:oejs.ServletHolder:main: unavailable
java.lang.NullPointerException
	at org.eclipse.jetty.servlet.ServletHolder.initJspServlet(ServletHolder.java:700)
	at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:630)
	at org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:422)
	at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:892)
	at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:349)

原因

  • ログ出力の設定方法が途中のバージョンで変わっていたのが原因。設定を修正したところ、デプロイに成功し、正常に起動するようになった。

詳細

  • Jetty本体に添付されているサンプルアプリや、公式ドキュメントを見る限り、Jetty 9.3.0まででのログ設定は下記が正しい。(実際、v9.1.5では、この設定で動作していた)

<Configure class="org.eclipse.jetty.webapp.WebAppContext">

...

<Set name="handler">

<New id="RequestLog" class="org.eclipse.jetty.server.handler.RequestLogHandler">

http://www.eclipse.org/jetty/documentation/9.3.0.v20150612/configuring-jetty-request-logs.html
  • ところが、Jetty 9.3.xまでの何処かのバージョンでログ設定が変わったようだ。

<Configure class="org.eclipse.jetty.webapp.WebAppContext">

...

<Call name="insertHandler">

<Arg>

<New id="RequestLog" class="org.eclipse.jetty.server.handler.RequestLogHandler">

http://www.eclipse.org/jetty/documentation/9.3.x/configuring-jetty-request-logs.html


関連

トラックバック - http://d.hatena.ne.jp/rabbit2go/20170619

2017-06-06

時間が足りないという言い訳は残念

| 22:42 | 時間が足りないという言い訳は残念を含むブックマーク 時間が足りないという言い訳は残念のブックマークコメント

システム開発の納期は短くなる一方だ。充分な時間が確保出来ているのなら、正規の開発プロセスに従い、然るべき成果物が出てくるはずだが、工数が不足するということは、必然的にそのしわ寄せが何処かに出てくる。残業や休出で頑張るとは言え、限度がある訳だし、幾ら頑張ったところで「最終的に時間が余った」なんていうプロジェクトは未だかつて見たことが無い。結果的に、プロジェクト終了後のふり返りの場では、反省点のオンパレードとなってしまう。

  • 工数が不足していたので、要求仕様の検証が不十分でした」
  • 「時間が足りなかったので、インターフェースの整合をとっていませんでした」
  • 「納期が近かったので、充分な検証が出来ていませんでした」

だが、ちょっと待って欲しい。時間が足りないという状況は、そもそもプロジェクトの開始時から分かっていたはずだ。その前提条件を無視して、作業ワークフローを見直さず、いつもと同じやり方をいつもと同じように実行するなら、時間が足りなくなるのは当然のことだ。充分な作業工数が確保できないという前提条件なら、その対策を事前に取るべきなのだ。

  • 工数が限られるので、xxxのレビュー会議を取り止める」
  • 「開発期間が短いので、優先度の低いxxx機能の検証を省略する」
  • 「時間不足の可能性があるので、xxx処理の実装を後回しにする」

開発プロセスの適切なテーラリングを行い、ステークホルダー間で合意を取れば、「後出しジャンケン」の様な指摘は出てこないはずだ。プロジェクトの反省として「時間が足りなかった」という総括が出てくる度に、その言い訳を残念に思う。時間不足という状況に対して、絶対的な解決策はもちろん無いけれど、それなりに賢く対処する手段は有るはずだろう。少なくとも、言い訳を減らす為の工夫が全く出て来ないのは、変な話だと思う。問題の発生を見抜き、対策を事前に考え抜くのがプロジェクト計画の基本だと思っている。


トラックバック - http://d.hatena.ne.jp/rabbit2go/20170606

2017-05-29

関西Ruby会議2017に参加した

| 22:50 | 関西Ruby会議2017に参加したを含むブックマーク 関西Ruby会議2017に参加したのブックマークコメント

2017/05/27は、関西Ruby会議2017へ行ってきた。RubyはJenkinsのジョブや簡単なツールに使う程度だし、Railsは全然習得できていないし、チンプンカンプンな話が続いたら困ると思っていたのだけど、こんな私でも理解できる内容が多くてなかなか楽しめるイベントだった。

2016年京都でRubyKaigiが開催されて大盛況でした。

そして、2017年は地域Ruby会議大阪で開催します。

関西Ruby会議2017

聞いた講演の中では特に下記が印象に残った。

エンタープライズRubyOnRails:エンプラでぶち当たった2つの壁と突破法

10名のチーム体制で開発を始めたものの、ソースのコンフリクトが多発し、様々な書き方のコードが存在したため、レビュー時間の増加という問題が発生。その対策として、Excelでモデルを作成してコードを自動生成させたという話。アジャイル派から見たら卒倒しそうな内容だったけど、人数が多くなる程、スキルのばらつきは大きく、その対策として作業効率化の仕組みが導入されるのは他のプラットフォームと変わらず、Railsでも同じだと知った。開発技術はシステム開発必要条件では有るけれど、十分条件ではないので、開発プロセス抜きには開発組織は成り立たないと思う。その意味では、そもそも何の開発プロセスに従い、どのような作業ワークフローが準備されていたのかという点が気になる内容だった。

子どものためのプログラミング道場「CoderDojo」を支えるRails CMSの活用事例

子供にプログラミングを教えるCoderDojoのサイト構築の話。RailsCMSを作る話かと思っていたけどそうではなくて、RailsのプロジェクトをScrivitoというサービスに取り込み、ブラウザ上でデータ編集を可能にしてしまうという仕組みだった。結果的にはCMSなのだけど、その裏方ではRailsが稼働しているので、Railsが生成するコンテンツを利用できるのが特徴らしい。通常のCMSでは「利用者が全てを記載する」か、あるいは「予め用意されているウィジェットを利用する」しか無いけど、今回のシステムでは両者のいいとこ取りが出来る構成になるようだ。初めて知ったサービスだけど、これはなかなか便利そうで、自分でも使ってみたくなった。

Rubygem開発の流儀

今まで多数のGemを作成、公開してきた経験の中で、Gemを作るに至った理由は何なのか、どのようなGemが必要とされるのかという開発の裏事情を解説してくれる話だった。日々の作業の不満を解消すべく、開発支援系のツール類を多数考案し、その為に頭の中に沢山の引き出しを用意しておく、という姿勢は、Gem作成に限らず他のソフト開発全般にも役立つ考え方だと思う。言われるがままの作業手順に従う開発者よりも、このように自分の頭で物事を考えて自ら改善できる人が求められる時代になってきているのだろう。著書としてパーフェクトRuby改訂2版が紹介されたので、帰り道に書店で購入した。Gemパッケージの作り方が詳しく説明されているとのことだけど、多分私には不要な内容だろう。でも、この講演のような考え方をする方の書籍なら、きっと有益な内容が多いだろうと思いつつ読んでいる。

改訂2版 パーフェクトRuby

改訂2版 パーフェクトRuby

トラックバック - http://d.hatena.ne.jp/rabbit2go/20170529