私が入社したときは、3ヶ月間の集合研修がありました。
基本情報やソフ開など情報処理技術者試験の勉強をしたり、
データベースやネットワークやシステム開発技術などの勉強をしました。
スタイルも自習からEラーニングから講師を招くものまで色々で、
あっと言う間に3ヶ月が過ぎたように感じた事を覚えています。

そして更に3ヶ月は配属される予定の職場での研修でした。
集合研修で全員に共通するようなことを学んでいましのたで、
部署が扱う業務に関する内容などを何年か上の先輩に教えてもらいました。
電話の取り方や議事録の書き方などを実践で学んだのもこの時期でした。

そして明日から私が先輩社員として後輩を指導育成する立場です。
まだ顔も見ていませんし、どんな人かもわかりません。
ひとまず私自身が席を準備しておくことになったのですが、
その最中に手配した机の引き出しが壊れている事に気付き、重たいスチール机を
別のフロアから運んできて入れ替えるという力仕事になりました。前途多難です。
そんな事をしつつも、どのような事を教えてあげるのが良いだろうか、と考えたりしていました。

ひとまずオルタナティブブログを探してみると、
教育に関してのエントリなどもあっさり見つかりました。

教育と訓練は違う・・・【人的資源管理入門】

Whatを教える訓練、Whyを教える教育

などなど。ITの「次」が読めるビジネスブログ・メディアと言う名の通りに
ビジネスに関するエントリは充実していてありがたいです。
私も後輩の指導をしてく中でブログに還元していけるものがありましたら
積極的にやっていきたいです。（後輩本人にも了解をとらないといけないかな？）

本ブログには、普段のシステム開発の現場で学んだ事を
もっとたくさん書けるといいなという思いはあるのですが、なかなか難しいです。
普通の開発を進めるにあたってプロジェクトが炎上したりですとか、
極めて難解な技術を使わないといけないということはあまり多くないです。
どちらかというとそういうケースが多発すると困ってしまいます。

そうならないために、プロジェクトを円滑に進行させよう等の努力をします。
そのあたりのことは基本的なことの積み重ねが効果を発揮する部分です。例えば、

プロジェクトメンバにスケジュールの進捗度合いを確認したら、2週間前から
完成度が50%のまま進んでいないプログラムがありました。そこで進捗管理の粒度を下げたら
100%のサブプログラムと10%のサブプログラムから構成されることが判明しました。
10%のほうが遅い理由を探ったところ、別のプログラマさんが自分の作業を減らすために
内々で無茶な仕様を押し付けたということが発覚しました。
（これは情報処理技術者試験のプロジェクトマネージャ区分の勉強をしたときに
学んだ参考書の練習問題でして、私の身の回りの話ではありません。）

など。このようにして地道に進捗管理をしていくことのひとつひとつは決して難しいことではありません。
しかし「これであなたも！！」的な書籍を1冊や2冊読んだら急にできるようになることでもありません。
たくさんのプロジェクトを推進した経験により、プロジェクト遅延の予兆となる現象を
把握する実力をつけた結果としてこういうことが遺漏なくできるようになるのだと思います。
偉そうに例とか出してますが私もうまくできません。プロジェクトマネージャという資格は持ってますが、
経験が圧倒的に不足しております。そこのところを補うべく、上司や先輩から色々と教えていただく毎日です。

身の回りで顔を出す、プロジェクト遅延の予兆というのは些細なものが多いように思われます。
何度も訂正をお願いしている誤字がなかなか直らない、とか、
ミーティング中に集中力を切らして空中を見つめている人がいるとか、です。
そういう地味なことをひとつひとつブログで紹介するということはなかなか難しいです。
書き手のモチベーションも維持していけないような気がします。

では、何かおもしろいことが書けそうなところはあるかと思って探してみると、
おもしろい部分はお客様の業務の核心に触れていることが多いです。
そうなるとほとんど「禁則事項です」となってしまいまして表に出す事ができません。みっくるんるん。

そのような事情があって当ブログはシステムエンジニアの視点を少し拡張した
「良いものを作るにはどうしたらいいだろう？」という内容が多いです。

最近ですと渋谷のガス爆発事故やジェットコースター事故などについて
考えたエントリがありました。他人の失敗というのは、
本人にとって見れば重大な損失を招いた忌まわしいものであると思いますが、
他の人間にとっては同じ轍を踏まないための貴重な教訓になります。
これからもまた、大きなインパクトを与える事故が起きた時には
本ブログで取り上げ、どんなことを学ぶ事ができるか考えていきたいと思っています。

いずれはそういったことまで新入社員の方とも話し合うことができると良いのですが、
そこは3ヶ月前まで学生さんだったわけですのですぐには無理でしょう。
しばらくはこのブログのタイトル通り「一般システムエンジニア」として
日々の業務で大切だけれども地味な事、ということを教えて行くことになりそうです。
その中でユーザインターフェースの設計について考える機会があったら、
「こんにゃくゼリーを誤飲しないためのデザインを考えてみよう」
などと言うと翌日から会社に来なくなってしまうかもしれません。
そのあたりは私も昼の顔と夜の顔を区別していきたいと思います。

最後に、1つ心配に思っていることがあります。SEの仕事に過大な期待を抱いていないか、です。
課題が山積して経営が傾いたお客様に自分のスーパーアイデアを美しいプレゼンで提案。
その姿に感激したお客様が即日発注。プロマネはもちろん自分を指名。
パパっとプログラマさんに開発を依頼したら、「完璧に動くシステム」が納品される。
それをお客様に納品して、効果は絶大。株価上昇で社長も大喜び。
業界誌にインタビューが載ったり、フォーラムで講演を依頼されたりして。自分も給料アップでうっしっし。
という未来予想図を思い描いていない事を祈ります。