コストを意識した仕事の時間の使い方

ええ、40代半ばくらいまでは割と無限にあると思っていました。仕事の時間が。平日は夜もあるし、週末だって必要なら使えるし、と。

まあ、それもプロジェクトにマネジメントとして入っているかそれともただのマネジメントかでまた少し事情が違ってきます。エンジニアの方は前者のプロジェクトにマネジメントで入っている方の時間の制約が同じ条件かもしれません。

時間の制約

立場により時間の制約があることに不思議なイメージをもたれるかもしれませんが、単純な話をすれば、プロジェクトに参画しているときにはその活動に掛かる時間は全て申請しなさい、と考えを持っています。これは実際に掛かった時間を計上しておかないと次の類似案件を類推見積もりをする際に実績として使えなくなってしまうからです。 

と言う背景もあって、プロジェクトに参画する場合はどのロールであっても計画する工数の範囲かプロマネ(結局自分だけど)の事前合意を得た上で活動をする制約を受けます。

一方、単なるマネジメントのときは、必要ならやんなきゃなぁくらいの制約です。組織的には遵法が厳しく求められているので管理職としても活動した時間は計上せよと言われますし、まあ申請しておくか程度ですが活動自体の一次的(プロジェクトの計画工数の意味合いで)な時間的制約がないのでフリーに近いです。ただ、適当にやりすぎると人事部門から刺されるので…。

直接か間接か

 この時間の制約は裏を返せば、人件費が直接費用か間接必要かと言う意味が含まれています。プロジェクトに参画している場合はその活動に費やす時間はプロジェクトの人件費となるので直接費用となります。ITのプロジェクトであれば8割型が直接費でしょうから、ここのコストのポーションを適正にコントロールするところが一つのアレですが例外なくコスト計上は正しく行っておかなければ前述の類推見積もりで死ぬ原因を作ることになるので。

一方、間接費用はその活動をすることで対外的に対価を得られない場合の費用です。なので直接費のプロジェクトコストとは別にカウントして配賦するわけです。本社の人件費になると思えばいいです。プロジェクトでいくら稼いでも本社費が馬鹿高いと利幅がぐーっと減ります。

コスト意識を持って言われるけど

 エンジニアの活動はプロジェクトでの活動なら直接費用になります。でも、業務時間内での勉強会とか有給とか社内の研修とかは厳密に言えばプロジェクトの活動の一貫(情報収集とかプロジェクト内研修とか)でない、つまり直接関連がなければ間接費として扱います。

これは見方を変えれば、組織の中で活動するためには必ず予算が必要で、誰かがその予算を持っていると言うことを意味します。予算があるんだから期待する成果を出して欲しいのは、プロジェクトの活動ばかりじゃないよ、と言うことです。

社内の研修でもただぼーっと聴き流すのではなく、(たとえつまらなくても)研修目的があるんだから覚えておいて欲しい開催目的があるんだからそれは頼まれてあげて欲しいのですよ。

そこが、コスト意識を持つはじめ、じゃないかと思うんです。

どこかのエントリに書いたような気がしますが、社内の研修を受けている時間にプログラムの1本でも書きたい、資料を作っておきたい、と思ってもそれを内職でするのではなくて、社内の研修で1つ以上のお土産を持って帰らないとその研修の時間が何も成果のない死んだ時間になってしまうのです。で、場合によっては後でもう1回テキストを見る羽目になったら無駄が2倍ですし。

 

 

 

世界No.1の利益を生みだす トヨタの原価

世界No.1の利益を生みだす トヨタの原価

 

 

調達 色々

 

緑の魔女 全自動食器洗い機専用洗剤 800g

緑の魔女 全自動食器洗い機専用洗剤 800g

 
フロッシュ 食器洗い乾燥機専用粉末洗剤 ソーダ 750g
 
ソニー SONY アルカリボタン電池 水銀ゼロシリーズ LR43-ECO

ソニー SONY アルカリボタン電池 水銀ゼロシリーズ LR43-ECO

 

 

中堅エンジニアやシニア層のエンジニアを育成する

  

「エンジニアを育成する」と聞いて思い浮かべるのは新人や若手のエンジニアに方法論や技術スキル、仕事を終わらせるために必要なメンタルの領域に近い基礎スキルを業務を通じてインストールすることだと思うんですよ。

まあ、そうですよね。一人前になって欲しいので。

その発想だと置いていかれるのが中堅やシニア層のエンジニアです。中堅エンジニアにもなれば、仕事を任されて独り立ちしていてもらわないとどうしようもないわけですけど。ましてやシニア層のエンジニアにはサイズは別にしてプロジェクトチームでもリードしてもらわないとビジネスにならないのですけれど。

技術スキルを対象にした育成

冒頭の出だしのように、新人エンジニアや若手エンジニアはまだ仕事の仕方がそれぞれのエンジニアとして確立していないのであれこれとネタを提供して上げたいところです。

ITのエンジニアですから仕様を実装できるスキルを身につけていなければリソースにカウントしてもらえませんし、それをしてもらわなければマネジメントサイドも当てが外れて困るのでそこをなんとかしようとするわけです。

ITエンジニアの技術スキルは繰り返し同じ作業を覚えるのではありません。一品もののコードを仕様毎に実現しなければならないのでそれはそれで要求レベルが高いので、繰り返し作業を早くするという観点よりは、思考の導き方や意思決定の仕方を学ぶのが良いと思います。

まあ、新人エンジニアや若手エンジニアの育成はそれなりになるのでよしとして。

中堅エンジニアやシニア層の場合

 必要なのか、という疑問もなくはないですが立場が変われば中堅やシニア層であっても育ってもらわなければならないこともあります。

とかく、人は楽をしがちで学習して身につけこれでできるというやり方をやりたがります。つまり、必要性に迫られなければ新しい技術や手法は覚える必要性がないのでリソースを割くことはしません。

ただし、興味を持つテーマを見つければ飽きるまで調べたり、試したりすることもありますけど。

そのような中堅エンジニアやシニア層のエンジニアに対して勉強しなさいとか、こんな手法があるよと言ってもやった試しがほぼないのでやらないエンジニアは言ってもやららないです。

とはいえ、業務命令を出せる権限を持っていても、やれと言われてやる仕事は楽しくないですし。

環境に放置する

一つのやり方としてですが、やらざるを得ない環境を作ってそこに投げ込むというやり方があります。

エンジニアの業か、制約条件が多い方がエンジニアがその気になってくれるという性質を利用するわけです。Mが多いので。

例えば、これまでマネージャが仕切ってきた会議体のファシリテーションから会議体の結果までのロールを出席するメンバ全員に共同責任を負わせるというやり方です。

ただ全部やれとは言わず、権限までデレゲートをすることで裁量を持たせるところがポイントです。

マネージャはその会議に同席はしますが一切口を挟まないことがルールです。口頭では。

ここで使うのがチャットツールです。全員のグループを作り、そのグループに対して気づいたことだけを容赦無くメッセージを投げ込みます。

中堅エンジニアやシニア層のエンジニアはそれまでマネージャにある意味ぶら下がっていた環境にいたわけです。そのぶら下がるところを取っ払って、君たちで全部やってと当事者に強制的に役割を変えるのです。

これで意識が少しだけ変わります。あれ、やばいなと。あと、そのまま放置するとグダグダになるし、始末も面倒なので気づきを投げ込むことでフォローする体を作ります。

 

これやっておかないと暴走されても困るし、お通夜になっても困るので。

 

 

 

 

 

UNISON SQUARE GARDEN/春が来てぼくら(初回限定盤) セブンネット

調達 プラムネット ブッククリップ

 

プラムネット ブッククリップ

プラムネット ブッククリップ

 
ブッククリップ×2個セット

ブッククリップ×2個セット

 

 

20代前半のエンジニアがドラフトに掛けると年収が上がる1つの理由

なんとなく、子どもに「youtubeなんてみてはいけません!」とか「ゲームなんてやってはいけません」的に通ずる感じの印象を持ったのは先日、お友達のママさんが子どもさんに言葉遣いが悪くなるからyoutubeは見せていないというのを聞いたことがあったのが連鎖したからだと思うのですけど。

 

blog.inouetakuya.info

 

禁止することのムダさ

オープンなインターネットですし、お友達からも情報が入るでしょうから禁止するだけムダな労力だし、禁止されれてもアクセスする手段を持っているなら防ぎようがないわけです。子どもさんならペアレンタルコードでもかけておけばいいのかもしれませんがそれはあくまでも設定した端末かアカウントでですし。

ましてや成人した20代前半のエンジニアでイケてるでしょうから情報へのアクセスはお手の物でしょうし。なのでムダです。

あと、禁止するとされた側は当然ストレスが溜まるし、禁止した側も気になってストレスが溜まりますしいいことないです。逆にオープンにした方が健全です。

転職ドラフトに及ばない昇給

 当然ですよね。何が当然かというと、今いる組織の中にいるエンジニアは同じ事業内で業務分担をしているので事業内でそれぞれがそこそこの成果を出しているとするならば、評価は似たり寄ったりになります。

組織によっては業績の評価の幅を大きく設けているところも聞くところによるとあるようですが、転職ドラフトによる市場での評価までは行かないです。それができるくらいなら全体の給与テーブルをあげて採用自体に優位性を持たせる方に使うでしょうし。

それと社員の評価制度は職位のランクになっているとすると貢献度合いでどれだけ昇格させる華道家の評価になるので。

サイが出てくるのはどのロールをやっているかという差分にならないと極端には差異は大きく開きにくいです。それよりは事業がよければ全体の給与テーブルか一時金を支給するでしょうし。

つまり、同じ事業の中でやっていると同じメジャーで成果を計測するのでそれほどサイが出ないということです。

まだ昇進としての方が給与に反映されやすいです。

思い切った昇給をしてあげられないなら

どうするか、です。基本的に20代前半で(別に後半でも30代でも同じですが)本人が転職という属する会社を変えたいと決めたら気持ちよく送り出すことです。

少なくともエンジニアの育て方は間違っていなかったということを証明できたわけです。ただ、組織の給与テーブルなりキャリア制度なりが追いついていなかった、ということです。

喜んで送り出して、戻ってこれる環境を作っておくのが吉かと。

 

さて、若いエンジニアは悩みながらも色々とやってみたいことがあるでしょうから、同じポジションに滞留させておくのは得策ではありません。なので、マネジメントサイドの入り口に取り込んでおくのが良いです。

言い方を変えれば、ロールをエンジニアからリーダへとマネジメントサイドが持っている裁量の一部を委譲して技術以外のメンバの管理を少しずつさせてみましょう。優秀なエンジニアが優秀なマネジメントになれるかどうかは別次元なので次世代のマネジメント育成の観点からも篩は必要ですし。

 

 

 

 

 

 

 

就活中の学生さんに知っておいて欲しいシステムを作るお仕事

IT業界を考えている学生の多くは、稀に全く別の業界からの転職する人たちが思い浮かべるIT業界の会社に入ったらシステムエンジニアプログラマになりたいと思うかもしれません。

まあ、そうですよね。ITのシステムを作るのがSEかPGと呼ばれる仕事についている人たちですし。

でも、学生(別の業界からの中途採用を含めるけど以下略)はIT業界で働いたことがないから行こうと考えている会社の企業情報サイト(いわゆるホームページ)とか就活イベントなどの企業ブースとかエントリ後のリクルータからの情報とか、OBOG訪問とか大学が主催する就職企業のイベントなどの断片的な情報しか得られないということはよく認識しておいてください。

ここ数年は、インターンと称した学生中に一時期をアルバイトの位置付けで企業の職業体験をするマッチング制度が広まってきました。これは、学生から見れば抱いていた企業へのイメージと実際の会社がブラックでないかを識別するための一つの情報になると思っているでしょう。さらに最近はドラフトっぽい企業とのマッチングもあるようです。いづれにしても、どんな手段で情報を仕入れてもシステムを作っている会社の情報は断片的でしかありません。

気になる異性に会うたびに知ることができる情報は自分から聞き出したことか相手が教えてくれる情報しか得られないということだし、でも、実査に得られた情報が自分が理科下とおりかどうかは得た情報を一緒にいて経験するまではそれが本当かどうかはわからないのと同じで、就活やインターンで得られた情報がそのまま本当かどうかは自分がその中で聞いていた情報と同じかどうかが判別できる経験ができるまではわかりません。

システムエンジニアという職業に対する自分で持っている仕事のイメージと会社に対して持っていたイメージはどんなに情報を集めたとしてもスナップショットのツギハギでしかないのです。

結局、その仕事、システムエンジニアプログラマといったエンジニアの仕事が自分が思っていた仕事かどうかは「やってみないとわからない」のです。

仮に違ったとしたら次のことを思い出せると次のアクションの選択肢を増やすことができるので参考になるといいのですが。

システムを作る会社の中はどんな仕事でできているかというと、ざっくりと

の4つがあります。4つありますが2つ目の営業はシステムエンジニアかエンジニアの管理職が兼ねている企業もあります。そうかどうかは企業次第です。

4つ目は1つ目から3つ目の上位職なのでここでは棚に上げて、上から3つで考えると仕事としてエンジニアが合わないことがわかったとしても、その会社は合っているなら残りの2つが選択肢があります。もしかしたら、他社へ物を売る行為が合っているかもしれませんし、人事や経理業務が合っているかもしれません。

つまり、会社を変えるのではなく会社の中での職種を変えるという選択肢もあるよ、ということです。

ただ、会社の業務が合わないことはあり得ます。IT業界の会社といっても様々です。

  • 自社HW/SW/サービス提供
  • 自社HW/SW/サービスを代理店に卸す
  • ITコンサルティングを提供
  • HW/SW/サービスをインテグレーションして提供(アプリ←→インフラ)
  • エンジニアをリソースとして提供

こうしたサービスをB2BやB2Cで提供するかどうかでも違いはありますが、だいたいこの5つのどれか、です。企業がどのタイプの事業をメインとしてやっているかにもよりますし、業務プログラム、つまりアプリケーションかインフラ事業かでもエンジニアとして担当する仕事は全く違ってきます。5つの縦のどこが仕事になるかも仕事に違いが出てきますが、5項目も水平のどこになるかで仕事に違いがあります。

ということは、学生として手に入れられる情報は結局、5項目の1つかもしれないし1項目の水平の1つしか情報を得られていないかもしれないです。アプリエンジニアだと思っていたら、QA(品質管理部門)だったり、テストエンジニアかもしれません。

結局、やってみないと自分がやってみたいことかどうかはわからないし、やってみたい仕事ってなんだかわからないということだけがわかるかもしれません。

実際、そうなんですよね。漠然としてエンジニアになって、プログラムを書くことが合わなくて、それよりはチームを作って専門家のエンジニアに作る環境や仕組みを作る方が「楽しい」と思ってい仕事をしているので。

でも、もし仕事としてやってみようと興味を持てるキーワードを持っているなら、明示化しておきましょう。そのほうが流されてしまうことを留まって考えるアンカーになるかもしれないので。