こんにちは。やまさんです！
やまさんは
プログラマー
→システムエンジニア
→プロジェクトリーダー（PL）
とキャリアアップしてきました。
今でもシステムエンジニアとして
設計や試験などもやったりしてますが、
実はちょっとだけPMの作業を
手伝ったり、
ITコンサルタントのようなことも
やっています。
そんなやまさんが若手の頃、
つまり、
プログラマーや設計などをメインに
やっていた頃、
いろんな人からこの作業やってほしいと
依頼を受けました。
その作業を受けたときのことを
思い出してみると
今でもそう感じていることが
いくつかあります。
ということで
この記事では仕事を受けるとき
意識しておくと役立つことを
紹介してみたいと思います。
この記事に書いていることを
実践するとこんなことがおきます。
- システムエンジニアやプログラマーとして仕事している人はリーダー職の人からデキるSEと思われる
- これからPM、PL、チームリーダーをやる人は作業をお願いするときに意識しておくべきポイントをあらかじめ知っておくことで失敗を回避できる
- PM、PL、チームリーダーの人でうまく配下のメンバーが動いてくれないと悩んでいる人はこの記事で紹介する情報を伝えられているかチェック。悩み解決のヒントになる
ぜひ読んでみてくださいね！
アプトプットのイメージを確認する
お願いされた作業で作るもの
アウトプットのイメージを
依頼元と共有することは
とても大切です。
この間見かけたのは
上司からプロジェクトの見積り根拠を
教えてー
と、依頼されたPLが
メールに見積り根拠を書いて
おくったところ
表に作り変えて
と言われていました…
PLの人もメールから表に変えるのも
二度手間でちょっと不機嫌になったり、
依頼した上司もなかなか情報がこなくて
イライラしていたり…
作業のやり直しを発生させないためにも
お願いされた作業の
アウトプットイメージを
共有することは重要です。
チャットや口頭で共有するできるのが
一番早いですが、
表現が難しい場合は
試しにちょっとだけ作ってみて
共有する方法が有効です。
表なら縦軸と横軸だけ作ってみるとか
設計書なら目次だけ作ってみる
などですね。
これをやるだけで
かなり二度手間は防げます。
アプトプットイメージを作業手順で共有するというのも有効です。
やまさんはこの間、システムの利用状況を調査する仕事をお願いされました。
このとき、「DBからSQLでこういうデータを抜き月単位時系列の表でまとめればいいですかね？」といった流れでアウトプットのイメージを確認しました。
アウトプットを誰に対して何を目的に使うか確認する
誰が何の目的で使う資料かで
情報の粒度やまとめ方が
かなり変わってきます。
例えば、次の２つの資料は
まったく違う資料になるでしょう。
- 部長などの上位層が見るシステム概要を理解するための資料
- 新システム設計のためにチーム間で既存システムの設計情報を共有するための資料
部長向け資料の場合は
細かな情報よりもシステム全体増が
分かる資料が求められます。
アウトプットの形式もパワポで、
ユーザの利用シーンと関連させた資料だと
ベストでしょう。
一方、後者のチーム間の情報共有のための
資料の場合、
既存システムのインターフェイスや
処理内容など、
細かな情報が求められます。
アウトプット形式も
詳細内容が分かりづらいパワポよりも
エクセルなどで表形式した方が
好まれるでしょう。
誰が何の目的で使うアウトプットなのかを
把握しておかないと、
利用用途に合わないものが
できてしまいます。
お願いされた後でも遅くないので、
作業を始める前に必ず確認しましょう。
作業期限を確認する
こんなことありませんか？^^;
仕事をする上でとても重要なんですが、
これも忘れがちですよね…
確認すれば、だいていの場合
教えてくれるんですが、
慣れてきた頃が一番危険です。
さらに期限に関することで
やっかないなトラップが
あるんですよね…
みなさんも一度は以下のような期限で
お願いされたことはないでしょうか。
”なるはや”
つまりは”なるべく早く”なんですが、
これはお願いする側の感覚で
期限が変化するのでだいぶ危険です。
一度OKしてしまって自分が思っていた
期限より早かった場合、
特急で対応しないといけなかったります。
”なるはや”で頼まれたとき
やまさんが使っていた確認方法は
こんな感じです。
”なるはや”ってことなので”ｘｘ月ｘｘ日”までに完成させますね。
お願いされた作業を”なるはや”で
対応した場合の完成日を伝えます。
実は、このとき伝える完成日は
実際の”なるはや”の日である
必要はありません。
たっぷり余裕と持った日を
伝えましょう（笑）
こっちの”なるはや”の日が
お願いしてくる側にとって都合が悪い場合、
期限の調整をしてくるので
気にしなくてOKです。
”なるはや”と言ってくる人の中には期限を早めたくてこちらの出方（でかた）をうかがっている人もいます。
提案した完成日から期限を短くする交渉が入るので、あらかじめ余裕を持った日を伝えておくと交渉がスムーズに進みます。
分からないことは”やり方や調べ方”を質問する
仕事を進める上で自分で調べても
分からないことは
必ず出てくるものですよね^^;
そんなときは詳しい人、先輩、上司などに
質問して解決していくと思います。
このとき、分からないことの”答え”を
直接聞いていないでしょうか。
分からないことがあって質問する場合
”答え”を直接聞くのではなく
”やり方や調べ方”を質問するように
しましょう。
”答え”を聞いていると、
今の問題は解決するかもしれませんが、
似たような問題にあたったときに
もう1度質問しなければなりません。
応用がきかないんですよね^^;
せっかく自分より優れた知識を持つ人に
質問する機会です。
自分の成長になるように
やり方や考え方を身につけて
スキルアップしていくのを
おすすめします。
また、IT業界特有かもしれませんが、
質問されることを
嫌う人いませんか？^^;
やまさんはそうでもないんですが、
自分の時間を取られた感覚と
感じてしまう人もいるようです…
どうやって調べたんですか？
どう考えたらいいですかね？
こんな感じで質問すると、
教えるのが嫌いな人も
半笑いで教えてくれます（笑）
この手法、
Twitterでも紹介してみたところ
フォロワーさんからこんな感じの
反響もありました。
・尊敬されている気がして悪い気はしない
結構有効なので
ぜひ使ってみてくださいね！
まとめ
いかがでしたでしょうか。
この記事ではやまさんが若手の頃
意識してやっていたことで
やっていてよかったなー
と思うことを紹介しました。
っていうことも含まれていたと
思います。
ただ、こういうことって資格の勉強では
勉強したり問題に出てきたり
しないんじゃないでしょうか^^;
やまさんはPMやPLとして仕事する上で
この記事で解説したことの
重要性を痛感しました…
基本的なことかも知れませんが、
基本だからこそ
しっかり押さえる必要があります。
なので、今回、記事にして
紹介させていただきました^^
この記事が何かの役に立てば
とてもうれしいです！
なお、資格の話が少し出てきましたが、
資格とSEの年収の関係を以下の記事で
解説しています。
ぜひ読んでみてくださいね！
それでは！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
