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

A Day In The Boy's Life

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

仕事がしやすい環境というのは人それぞれ持っている感覚が異なると思います。

静かな部屋で一人黙々と打ち込みたいという人もいれば、ワイワイガヤガヤしている部屋のほうが活気を感じられていいという人もいます。


私は一人黙々と仕事をしたいタイプです。

イヤホンをつけて音楽を聴きながら、「話しかけるなオーラ」を発散しながら仕事をしてたりします。

エンジニアという仕事柄であるからそういうことが許されるのかもしれません。


※ どんな職種であれ、その人が最大限のパフォーマンスをはっきりできる環境で仕事をすべき(させるべき)だと思いますが。


どちらにしろ仕事には集中する時間と環境が必要です。

周りが忙しそうにせかせかと働いている活気あふれる環境のほうが集中できるという人もいます。

私は、静かな環境で仕事をしたい派なので、何故そういう環境のほうが集中できるのかはわかりませんが、周りの活気に後押しされ自分もがんばろうという気持ちが出てくるのかもしれません。

または、周りが働いている姿を見て一定の緊張感(自分だけが取り残されないようにしようと)が出てくるのがよいのかもしれません。


ただ、困り者なのはワイワイガヤガヤして活気にあふれている職場のほうがいいといいつつ、いざそういう環境で仕事をすると、仕事と関係のないところでワイワイやりだす人たちです。

確かに仕事をする上で無駄話の1つや2つは全然あるでしょう。

誰かがちょっとしたミスをしたことに対して、冗談の1つも言いたくなるのはよくわかります。

もし、その場が少しギスギスした雰囲気になり、険悪なムードになっているときにそれを和ませる一言を言ってみるのは「あると思います」が、周りが仕事をしているときにその中の数人と関係ない話でワイワイ盛り上がられるのは少し困りものです。


そういう人は、なんとなく周りが楽しそうな雰囲気を見て、自分もその輪に加わりたいという思いだけなのだと感じます。

楽しく話しているところを見ると疎外感を感じてしまうとか、自分の環境とその楽しげな環境のギャップからうらやましいという感情がこみ上げてくるとか。

ただ、それはみんなで仕事をするんだということの捕らえ方が少しずれている気がするんですよね。

楽しく仕事をすることはいいことですけど、1日喋っていて終わる仕事なんてほとんどありません。


私も、チームで仕事をするというのは好きです。

みんなが同じ目的を持って仕事しているという雰囲気が自分もがんばろうというモチベーションにつながりますし、終わったときに1人で達成感を味わうよりは、多くの人と喜びを分かち合いたいと思います。

なのでなお更、その場の雰囲気というものを大事にしたいと思っています。


少なくともその場を打ち砕く会話というものが、少し先の「みんな」にとっていいものであるかどうかを考えるべきだとは思います。





擬似個人情報、はじめました。


なるほどね、という感じ。

実データなんてテストで使えないわけですから、それにかなり近いデータが簡単に手に入るのであれば、欲しいというニーズがあるのはわかります。


リアルな情報を扱うほうが、より実運用に近い状況でテストができたりします。

「テスト太郎1」「テスト太郎2」「テスト太郎3」・・・

というようなデータでテストしたところで、実際にはその微妙なテスト結果を見ないこともあります。

テスト太郎1で申請したから、申請者の欄には「テスト太郎1」が表示されているはずで・・・、とテストケースをこなしてみても、最後の数字が違うなどの微妙な違いというのは、テストする上で返って判断しづらくなります。


最大の問題はリアルすぎて実データとテストデータの区別がつき難くなることかな。

データがダミーであるかどうかを判断するには、住所が実在しないということぐらいでしょうか。


ただ、このサンプルデータはいくつかのサービスを組み合わせたらできそうな気もします。


名前(苗字だけですが)のサンプルを作りたい場合


日本の姓の全国順位データベース @ 静岡大学


※ IEのみで閲覧可能 & 激重


住所であれば、ここ。


郵便番号データダウンロード @ 日本郵便


実際の住所なので、データを適当に組みかえれば同じようなことができます。


テストデータのお供にいかがでしょうか。





プロジェクトの中を覗いてみると、様々な人が参画しそれぞれの役割に沿った業務をこなしていくことがわかります。

縦の役割を見てみると、プロジェクトマネージャ、プロジェクトリーダー、アプリケーションエンジニア、テクニカルエンジニアと呼び名はいろいろあるにしても、縦の階層でも役割が細かく分かれます。


一方横の役割というと、テクニカルエンジニアという呼び名にしても、専門分野ごとに分かれています。

ネットワーク、データベースやアプリケーション、またプロジェクトリリース後の保守や運用といった切り口でもそれを担当する人が、それを作り上げていくプロジェクトの段階で早期に参加していたりします。


こういったピラミッドの階層の中で、自分の担当はここだというのがはっきり示されており、またその他の領域の役割分担がカチッと決まっているなら、さほど問題はありません。


が、そこまで大きなプロジェクトではない場合、多くの領域を兼任する羽目になることがあります。


「君、チームリーダね」


って言われて周りを見渡したら誰もいない・・・何てこともあるわけで、自分でタスクやスケジュールも管理しつつ、エンジニアがやるべき実作業もあわせてこなすなんてことはよくあります。


先月に、IPAのプロジェクトマネージャ試験を受けてきました が、その中でうたわれているのは、プロジェクトマネージャがすべき業務というのは、プロジェクトの中での制作工程における実作業などではなく、全体のタスクやスケジュール、個々の作業領域における要員や課題の管理だったりします。

氷山の一角なんて言葉がありますけど、その一角だけでも十分に大きいわけで、プロジェクトを氷山にたとえたときにプロマネがやることは、それでも十分に巨大なわけです。


が、先ほどのお話同様に


「君、今回プロマネね。あとは後ろの子と体制組んでプロジェクトを推進してね」


なんていわれて振り返ると、一人だけ新人がポツンと立っていたなんてこともあったりします。

もちろんその子に製造工程の全てのタスクを割り振るなんてことは無理な話です。

中堅クラスの人であればなんとか効率よく業務を遂行する方法を考えうるかもしれませんが、何もわからない新人であれば割り振った瞬間に空中分解するのがオチなわけです。

ということで、プロマネという名のワーカーがそこに誕生を迎えます。


結局のところプロジェクトの理想と現実には激しいギャップがつき物です。

それでも何とかしようと努力してみたりします。

(まともに取り掛かると火を噴くのは明らかなので、始めるにあたって「どうなってもしらねぇからな」ぐらいの捨て台詞は吐いておくことをお勧めします)


で、それでも何とかやりきって終えてみて、報告の際に文句のひとつでも言ってやろうかと思っていたら、


「幅広い分野でとてもよく活躍してくれた。今後も期待している」


なんてほめ言葉をもらったりして、なんか悪い気がしないでもない、でもなんかもやもやとした気持ちになったりします。

が、結局のところその後のプロジェクトも同じ道をたどる訳で、苦労するのは自分+少数のαとなります。


まわせないことをわからせないといけない、でもまわさないと評価につながらないという負のスパイラルが実際の現場では存在します。


縦でも横でも幅広い分野をカバーできるということはその人の能力の敷居をあらわしています。

ネットワークの構築はできるは、ミドルウェアの設定もでき、その上で要件に沿ったアプリケーションも作って動かすことができる、というのは確かにその人が広い分野で活躍でき、優秀な人という評価にはつながります。

そして、そういう多岐にわたる領域を兼任させることで、広い知識と技能を吸収できることもわかります。


が、本人からすれば、プロジェクトという限られたスケジュールの中ではどこかに専念させろという気持ちが沸いて出てきます。

こう考えると理想のプロジェクト推進ってなんだろう、という気持ちに現場の一兵卒としてこみ上げてくるものがあります。


教科書どおりに進められたプロジェクトというほうが数が少ないのではないでしょうか。

まぁ、教科書どおりに進められたとしても「ここは僕の担当ではありません」なんて人が出てきて、それはそれで大変な目にもあったりもするのでしょうが・・・。


※ 自分の中で、少し矛盾したことを書いたかな、と感じたりもしています。

  ただ、プロジェクトを離れて冷静に考えた場合の考えと、その中で必死にやっているところとでは、こみ上げてくる感情が

  大きく違うものだなと。

  納期に余裕がある状況であれば、色々な経験をしたい(させたい)という思いが出てくるんですけどね。