A Day In The Boy's Life -139ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

社内の要員を効率的に育て上げる一つの手段としては、必要なレベルを満たすための知識を体系化したドキュメントを用意して、それに沿って育て上げるというものがあります。

多分、どこの企業も入社したときはそんな感じで教育がスタートするのではないでしょうか。


基本的な研修が終わって現場に出されてもOJTという形で教育は続きます。

この辺で大きく研修プランが変わってきたりします。


1. 業務マニュアル渡すから、これ見て覚えてその通りにやってねパターン

2. マニュアルなんてないから先輩のマネをしながら体で覚えろパターン



マニュアル人間化計画


1.の教育パターンは、効率的といえば効率的な育て方です。

基本的な仕事の知識を入社後すぐに叩き込んで、後はその知識をベースとして業務に必要な知識を同じようにマニュアルに沿って育て上げていくことになります。

一つの業務が問題なくできるようになれば、次のステップに移りますが、そこでも業務のレベルが変わったとは言え、マニュアルが用意されているわけです。


これは大量の要員を育て上げたい場合には有効な手段になると思います。

いちいち個別に対応していては、教育する側も大量の人数が必要になります。

やって欲しいことはマニュアルに書いてあるから、君の仕事はそのマニュアルを理解することだ、というわけです。


ただ、この計画に沿って育て上げられる人材は、そのマニュアル外のことをやることを許されなかったりします。

その通りにやればよいという風に教え込まれるわけです。

教育するほうもそのほうが都合がいいわけです。

例外はないから、その通りにやってといったほうがみんな同じ道を通ってくれますから。

なので、どんなに優秀な人材も同じ道をたどらせてしまうことにもなってしまいます。


ただ、最初の1年目、2年目ぐらいは業務への慣れなんかもあって、そういう教育方法でも問題が出ないかもしれませんが、次第にこの方法ではボロが出てきます。

それは、マニュアルがないとできない要員へとなってしまうからです。

最初優秀だった人もそのような人材へと変貌を遂げてしまう可能性もあったりします。



非マニュアル人間化計画


一方で2.の教育パターンは、現場で覚えろという育て方です。

いきなり現場に投入され、先輩社員のやっていることをマネしながら仕事を覚えていきます。

これは、能率のよい人であれば短期間で戦力になるレベルまで能力を一気に引き上げることが可能になります。

マニュアルを使ったステップアップ方式ではないので、現場で使えればより高い仕事をさせることができますし、そうではない人はいきなり冷たくあしらわれたりします。


ただ、これは人それぞれの適用能力があるので、順番に教育していけば優秀に育つ人をいきなり殺しかねない教育方法だとも思います。

それは、理解力がないからというわけではないでしょう。

レベル1をすっ飛ばしてレベル5から教えだすから多くの人は混乱するわけです。

でも、現場の先輩社員はレベル10のことをやってたりするので、「レベル5もわからないの?」という風になります。

そして、「レベル1から教える時間なんてないよ」というのが口癖だったりもします。


この教育方法は、場合によっては「現場で覚えろ」ということが格好よく聞こえるかもしれませんが、マニュアルを作る暇がなかったり手間を嫌ったりしていた結果である場合もあったりします。

そしてそのうち組織の規模が大きくなると、現場で教え込むことに無理が生じ、効率的に教育するためにマニュアル人間化計画が発動することになったりします。


現場に業務するレベルに達していない人が大量に来ると、それをコントロールすることが難しくなりますので、より効率的に人を育て上げなければならないとなるわけです。



脱マニュアル人間化計画


紆余曲折を経てマニュアル人間がいっぱい出来上がりました。

ただ、それをそのままにしておくと多くの弊害が出ます。

先ほども書いたように「マニュアルがないと仕事できない人間」ができてしまうからです。


マニュアルがないと仕事できない人間のどこが問題かというと、一つは例外に対応する能力が低いと言うことだと感じます。

やることはマニュアルに書かれていて、それを疑問を持たずやりだすと、それ以外の方法ということを考えないようになります。

教えるほうも「その通りにやれ」と言ってるわけですから、やる方も「その通りにやる」となります。

なんでそんなこともわからないんだと怒っても、マニュアルに書かれていないことなので、どういう対応を取ったらよいかわからないという状況に陥ります。


ですので、マニュアルで効率よく育て上げた人材は、そのマニュアルを取り除く教育と言うものが新たに必要になってきます。

効率よく育てるための方法が、後々弊害になって今度はその逆の教育方法に注力しなければならない皮肉となるわけです。



私は、業務の全てをマニュアル化するのは不可能なことだと感じています。

基本形を教えるのには適していると思いますが、それが済んだらさっさとマニュアルを捨てて応用力を鍛える教育プランに切り替える必要があるのだろうなと。


人材の育成と言うのはどこの企業でも力を入れてはいるものの、悩みも尽きない領域だと思います。

大量の優秀な人材を育てたいという考えはどこもあるかと思いますが、結局は人を育て上げるのには長い年月がかかることだと感じています。

そのための一つの方法は、自社になるべく長い期間つなぎとめておくと言うこともいえるかもしれません。

教育にかけるコスト以上に、そのことにもコストをかけるべきじゃないかなと思ったりします。






平成20年度秋期情報処理技術者試験: プロジェクトマネージャを受けてきた 」の続編。


ということで、前回見事に滑ったので再チャレンジしてきました。

率直な感想は、前回よりは手ごたえありって感じです。

まぁ、制度も変わっているのでどういう採点になるかわかりませんがね・・・。

2度目ということもあり、しかも同じ場所だったので前回の反省点を色々活かせたので、当日ばたばたするようなこともありませんでした。

(例: 場所がどこにあるか不明、前日の夜に腕時計がないことが発覚して大慌て、会場の近くのコンビニはお昼激混みなどなど)


その制度が変わった試験内容ですが、午前からの試験別にまとめてみたいと思います。


プロジェクトマネージャ 午前問題


平成20年度までは午前は一つの問題になっており、100分で55問の問題を回答させる内容でした。

しかし、今回からは午前問題は2つに分割され、午前1が50分で30問、午後2が40分で25問という形式に変更になっています。

合計の問題数は変わらないものの回答時間は合計で1時間20分となっており、若干余裕が持てる内容になっています。


午前1の問題は、プロジェクトマネージャ以外にも、データベーススペシャリスト、エンベデッドシステムスペシャリスト、情報セキュリティスペシャリスト、システム監査技術者の試験と共通になっています。

試験の出題範囲は、テクノロジ系、マネジメント系、ストラテジ系と幅広い分野から出題されていました。

計算問題も出ますので、プロジェクトマネージャで求められる知識範囲だけを勉強してると痛い目にあうかもしれません。


一方で、午後2の問題はプロジェクトマネージャ専用の試験になっており(他の高度試験も同様)、プロジェクトマネージャに求められるマネジメント系が中心に出題されています。


何れも過去に出題された問題が結構な割合で出ていますので、過去問で対策していることが有効かと思いました。



プロジェクトマネージャ 午後1問題


こちらは出題形式と試験時間は変わっていませんが、回答する問題数が2問に変わっています。(前回は、3問)

おかげでずいぶんと時間的に余裕を持って回答することができました。

前回は、2問と少ししか解けませんでしたから、この時点でアウト(結果を見るとその通り、午後1で合格基準を満たしていませんでした)

逆に言うと、前までの試験形式で合格した人は、本当すごいと思う。(あれだけの短時間で問題文を読むとほぼ同時に回答を導かないと合格は無理だったと思います)


前回と同様の試験形式なので、プロジェクトのある状況についての説明があり、その中でプロジェクトマネージャとして取るべき行動や、プロジェクトにあるリスクなどを分析する問題になっています。


こちらも過去の問題を中心にやっておくことが重要になると思います。

ただ、全4問あるうち2問を回答する選択方式なので、過去問を繰り返し解きながら自分の得意な分野を見つけておいたほうが良いと思います。

例えば、EVMを使った問題も過去に出題されていますが、それは捨てるとかもありかもしれません。



プロジェクトマネージャ 午後2問題


最後の難関ですね。

こちらは出題形式は変わっていませんが、回答形式が若干変わっています。

前までの回答方法


設問ア

プロジェクトの概要とプロジェクトの問題の理由・範囲・内容・体制などを800字以内で論ずる


設問イ

設問アのプロジェクトで対応した具体的活動内容・問題点の確認方法・対応方法を具体的に論ずる


設問ウ

設問イの活動への評価と今後の改善点を論ずる


設問アに関しては800字以内と明記されていますが、設問イと設問ウには何文字でとは書いていませんでした。

ですが、大体設問イには1600字ぐらい、設問ウは400字程度で、合計2800字~3200字あたりが文字としては合格の目安になるようなことが参考書に書かれています。


今回受けた新制度では、具体的な文字数が指定されるようになっています。


設問ア

プロジェクトの特徴とプロジェクトの構成・目標・目的などを800字以内で回答する


設問イ

設問アのプロジェクトの問題に対する対応方法・活動内容・対応を行った理由などを800字以上1600字以内で具体的に回答する


設問ウ

設問イでの対応・問題に対する改善策・工夫点などを成果および今後の残された成果とともに600字以上1200字以内で具体的に回答する


このように設問イと設問ウにおいて文字数が明確になっています。

基準が明確になっていることにより、論文が書きやすくなっていましたが、いかんせん始めての出題形式になっていたため、なかなか答えるのに戸惑いました。


まぁ、全体としては最低限書く論文の文字数は減っているかもしれません。(題意に沿うと最低2200文字で条件は満たしますから)

ただし、文字数を短くするにはその内容を濃いものにしないといけないかと思いますので、その分難易度が上がるかもしれません。

何れにせよ2時間で2000文字強の文字を書くと肘が壊れたように痛くなることは確かです。


こちらも過去の問題を中心に論文を繰り返し書いてみることが対策になるかと思います。

ただし、実際に紙に書いて対応することが大切だな、と感じました。

Wordなんかで対応すると、さくさく書けるのですが、実際に書くスピードはもっと遅いですし、文章の構成を直すことも簡単にできません。

最初のほうで大きく間違うと致命的になってしまいます。

あと、普段から紙に書くということをやっていないと、漢字を忘れてる・・・。



以上、そんな事を思った試験の感想でした。






Tracを動かしていたサーバーでもろもろ不都合がでてきたので、新しいサーバーへ移行することにしました。

稼動中のプロジェクトもあるため、チケットやWikiもそのまま新しいサーバーへ移行できるよう、手順をまとめてみました。


移行した環境は、「バグトラッキングシステム「Trac」インストール 」の中で書いたもので、DBにはPostgreSQLを使っています。


1. 現在のTracのバージョンを調べ、必要に応じてバージョンアップする


現在動かしているTracのバージョンが最新ではない場合、その古いバージョンのソースを見つけられないというようなことが考えられます。

また、TracのバージョンによってはDBのスキーマ構造が異なるため、異なるバージョンでデータを移行させると、うまく移行できない可能性もあったりします。


こういった場合、一旦現在の環境にてTracのバージョンアップを行い、その後で新しいサーバーへ移行するというような手順も考えたほうがよいでしょう。


参考記事: Tracの使い方 - Trac0.10からTrac0.11へのバージョンアップ -


現在と同じTracの環境を整えるためのソースが一式揃っているのであれば、それを新しいサーバー上で設定し、現行バージョンのままで移行させることも可能かもしれません。

この辺りは、状況に応じての判断が必要になります。


※ バージョン間の変更点は、Changelog にて確認できます。



2. 新サーバーでTracをインストールする


新しいサーバー上でTracをインストールします。


参考記事: バグトラッキングシステム「Trac」インストール


【補足】
上記の記事に書いている作業のうち、「2.1 DB作成」と「2.2 Subversionのリポジトリ作成」は、現在の環境と同様のDB名、リポジトリ名を作っておきます。

また、複数のプロジェクトを移行する場合、移行対象のDBやリポジトリはその数分だけ作成しておきます。


ここまでの作業で、新サーバー上でもTracが動く状態になったかと思います。

ということで、次に本格的にデータの移行を開始します。



3. DBの移行


次に、DB(PostgreSQL)を移行します。

現在Tracを動かしているサーバーにログインし、pg_dumpコマンドを使ってDBの内容をバックアップします。


参考記事: PostgreSQLバックアップ3分クッキング


$ pg_dump tracdb > tracdb.dmp

上記のバックアップしたファイルを新サーバー上に転送しておきます。

次に、新サーバー上で先ほどバックアップしたデータをインポートしますが、2.のTracインストール時にDBを作成し、スキーマが作られているため、一旦DBを削除し中のスキーマを全てクリアにしておきます。


$ dropdb tracdb

※ dropdb時にエラーが出る場合は、一度Apacheを停止させてDBへのコネクションをクローズした上で実行してみると

  うまくいくかもしれません。


$ createdb tracdb

$ psql tracdb < tracdb.dmp


4. アップロードしたファイルや設定ファイルの移行


TracのチケットやWikiに添付しているファイルは、ローカルのディレクトリ内に保存されているため、そのディレクトリを丸ごと移行する必要があります。

添付ファイルは、下記のパスに保存されています。


/path/to/tracpj/attachments

※ 「/path/to/tracpj/」は移行対象のTracプロジェクトのディレクトリなので適宜読み替えてください。


上記のattachmentsディレクトリをtarなどで固めて、新サーバー上の同ディレクトリへ移します。


また、設定ファイルについても移行する必要があるので、同様に新サーバーに移行します。

設定ファイルのパスは、下記になっています。


/path/to/tracpj/conf


5. SVNの移行


リポジトリブラウザで使われる、SVNの移行を行います。
現在Tracを動かしているサーバーにログインし、SVNのリポジトリをバックアップします。


# svnadmin dump /path/to/svn/tracproject/ > tracproject.dmp

次に、上記ファイルを新サーバー上に転送し、リポジトリをインポートします。


# svnadmin load /path/to/svn/tracproject/ < tracproject.dmp


これでTracのサーバー移行は、一通り完了です。

複数のプロジェクトを運用している場合は、「3. DBの移行」から「5. SVNの移行」までをプロジェクトの数だけ作業する必要があります。
最後にApacheを再起動かけて、新しいサーバーの方にアクセスしてみましょう。



おまけ - サーバー移行時のエラー対処法 -


Trac detected an internal error:
SubversionException: ("Can't open file '/home/svn/tracproject/db/uuid': Permission denied", 13)

5.のSVNの移行をrootユーザーで実行したため、上記ファイルの所有者がrootユーザーになっていました。
本来の適切なパーミッションと所有者(インストール時に設定したユーザー)に変更することで解決できました。