採用活動で学生を採用するかは父性本能で判断すると良い

2018年度の採用活動では既に内々定は出始めているのだろう。相変わらずの売り手市場のようで、貴重な人的リソースが無駄に買い叩かれなくて良いことだと思う。新卒社員の給与も何十年も前から変わっていないような感じがする(思いの外、上がっていない)が、実際そうなんだろうし、だからyahooなどは条件付きで待遇すると言っているのだろう。

特に企業が欲しいと思っているデータサイエンティストは奪い合いなのだろう。ただ、そうした学生はごく一部で、多くの学生はそれ以外だから、従来の聞いたことがある大企業や研究室や就職課の斡旋で候補企業を選ぶというやり方は多分、80年代と変わっていないだろう。

ただ、知っている企業の知っている、が変わってきている。大手のメーカではなく、メルカリやアカツキなどのWebサービスの企業がそうした企業のサービスを介して知る機会が増えているからだ。

SIerの定員割れ

従来のSIビジネスやSESや常駐型のシステム開発や維持管理をしている企業の採用はより難しく(=募集予定枠の未達、定員割れ)ばかりなのではないか。

自社サービスなどを持たなければ、そのSIerはサービスを提供する企業の裏方に徹することになるわけだから、学生に知られようがないのである。

根こそぎ、優秀な学生はWebサービスの会社に持っていかれる。その選定で篩から落ちた学生がSIerの規模順でまた篩にかけられるのだ。

人の能力を知ることの難しさ

普段からチーミングを考え、実践していると、人の能力を見極めることは難しい。プロジェクトの規模がそれなりにあると、ついつい頭数だけ揃えているマネージャがいるが、そうしたプロジェクトでは概ねトラブる。

プロジェクの目的達成のためにチームとしてのスキルセットを把握することが必要だとなんども書いたのと同じように人が持っているスキルを知ることもまた難しい。

エンジニアは普段からプロジェクトでそうした経験を積んでいるにも関わらず、そうしたチーミングでのメンバ候補を選ぶプロセスにおいてサイエンスやエンジニアリングが生かされることはまだないのだ。

一体いつになったらそうしたことが可視化されるのだろう。

候補として採用を判断する上で

採用したいと決めれば(学生がその気になってくれるかどうか次第だが)、ほぼほぼ配属されることが多い。

これはこちら側に人を見る目がなければ、担当する事業にフィットしないエンジニアを抱え込んでしまうことになる。そうなってしまっては、職場のエンジニアも配属された新人エンジニアも不幸になるだけだ。

そうしたことを避けるために、学生を採用候補とするかどうか1点だけ気にしていることがある。

面談をしていて、学生が会社を辞めるまで面倒を見られるかどうか、だ。

それもあって、学生に年齢が近い若手と話をさせて、ぶっちゃけた会話を二人でしてもらうようにしている。これはこちら側も若手を通して学生が後輩になったら一緒に仕事をやりきれそうかを見ているし、学生側もつい数年前まで学生だった先輩(予定)の仕事を見て自分でもやれそうかを考えて欲しいからだ。

まあ、そうして学生を見ると父性(母性か)本能が働くというか、あまり若手のエンジニアに高すぎる要求をするのは馬鹿げたことだと思ったりもする。

 

 

 

よつばと!(14) (電撃コミックス)

よつばと!(14) (電撃コミックス)

 

 

 

 

 

SESは消滅すべきか

SES(システムエンジニアリングサービス契約)の意味を一度確認してみよう。

SES契約は労働法規などでは業務請負の一種とみなされる。このため、労務管理や指揮命令系統などが発注元企業から独立している必要がある点が、発注元企業による指揮命令の下で業務を行う派遣契約との大きな違いである。賃金は技術者の労働力に対して支払われ、システムの完成は支払い要件には含まれない。 民法での典型契約が委任であっても、下請法における取引が「情報成果物作成委託」や「役務提供委託」であっても、労働者派遣法や職業安定法の区分基準では「業務請負」であり[1]、違法派遣や偽装請負に該当しないように注意が必要である。

システムエンジニアリングサービス契約 - Wikipedia 

 要約すると「自社の指揮命令の下で労働力を提供する」ということだ。興味深いのは民法と労働者派遣法及び職業安定法の区分基準が違う点である。

さて、なぜSESを読み返したのかというと、SESは消滅すべきだ、と主張するエントリがある。

 

axia.co.jp

 

色々と書かれているが消滅しなければならないほど悪なのだろうか。まず、誰かが何かを主張したら、疑って掛かることにしている。それでホントらしければそうなんだーだし、怪しいままであればそれも「お前の頭の中ではな」ということだ。

多分にもれず、このエントリも同じである。嘘はないが書き手の思いでバイアスが掛かっているのは当たり前であるから、そうしたこころ持ちで読み進められると良いだろう。

引用したエントでの標題を拾うと7つある。一部、冗長的な項目がある(項番3−4)が項番4は項番3のサブセットにしておくほうがいい。4の原因が3だからだ。

  1. 価値がない
  2. 偽装請負
  3. 労働管理ができない
  4. 長時間労働になりやすい
  5. 構造的に生産性を下げる
  6. エンジニアをダメにする
  7. 日本のIT業界をダメにする

価値がない

些細なこと(もしくは解釈の違い)はいいとして、価値がないというのは、多重構造の中で二次受け以降のSES会社が価値を提供しているのか、ということを問うているのだろう。

Wikipediaの定義によれば労働力を提供するのだから、提供された労働力に対価が支払われているのであれば、価値は提供されると看做して良いのではないか、と思うのだがどうだろうか。

偽装請負

上記の項番3と4については、記述の通りの問題を孕んでいるし、実際、労基はそれが事実と判断すれば改善指導をするようだ(ようだ、としたのは実際指導されたことがないため)。

労働管理ができない

では、全く回避できないか=遵法するためにはどうあれば良いか。それは、何重であっても、SEとSEに指揮命令する役割の管理職が、プロジェクトの計画を立てる場に出席することだ。具体的には、進捗会議などの場で作業計画を委託元と協議し、委託元から受託会社のSEには作業子をしないことを徹底すれば良い(出来なければ違法)。

構造的に生産性を下げる

これはSESに関わらず、中規模以上の、いや10人を超えたあたりからコミュニケーションパスが増えすぎ、コミュニケーションコストがバカ高くなることを知っていれば、こう行った書き方にはならないのではないか、と思うのだが。

更に言えば、ウォーターフォール形式のプロジェクトでは、局面を分断することが前提となっているので、局面ごとに情報の受け渡しが行われる。この局面を変わるタイミングで人員の増減を合わせるため、コミュニケーションコストは更に悪化する。

もともとのプロジェクトで採用するシステム開発手法に構造的な生産性を下げる要素が含まれており、それをSESが原因であるというのは些か違うのではないかと疑念が生じるがいかがだろうか。

エンジニアをダメにする

ここは評価が分かれるところだろう。ワタシのようにサブコンでの経験がプライム案件で必要となったプロジェクトマネジメント やウォーターフォール型でのシステム開発の体系的な復習の場になったケースもある。

一方、工程の繁忙で労働集約の局面だけ召集されるエンジニアに取っては、属する組織のビジネスにプライム案件がなければ要件定義や基本設計などの上流工程やシステムテストや移行など、システムリリースの経験がすっぽりと抜けてしまっているケースもあるだろう。そうしたビジネスを主体とするSESに属するエンジニアがダメになるという点においては同意する。

日本のIT業界をダメにする

これは責任を押し付けるつもりではないが、顧客の要望からそうしたビジネスが成り立っているということを棚上げしていないだろうか。需要があるから供給が生まれるという理屈だ。であれば、IT業界をダメにしているのはユーザ企業であるということになる。

この点については、ユーザ企業のIT部門の弱体化で問題視されているのでそちらの記事を日経BPででも探して欲しい。

そうした意味合いでは、SESは必要悪なのかもしれない。ただ、欧米でアウトソーシングから内製化に回帰しているように生産能力をユーザ企業が取り込もうとしているのはここ最近のアジャイル界隈の事例でも出てきているのでそうした必要悪による副作用に気づいている組織(例えばデンソーなど)は対策し始めている。

個人的な見解

SESも一つの手段、道具であるとみなせば良いのではないか。それをどう使うかは使うユーザが判断すればいい。エンジニアの立場では、労働集約的なクローズドな局面だけのビジネスをしている組織が不満ならはなから避ければいいし、万が一、属してしまったらとっととやめるのが良いのだろう。

ただ、そうした労働集約的な作業を好むエンジニアの存在もあることを忘れてはいけない。そうしたエンジニアに自己研鑽や成長を語っても響かない。

パレートの法則はここでも生きているのだ。

 

 

 多重構造のアニメと言えば…

 

相談させない「相談して」

プロジェクトでプロジェクトマネージャが困るのが、担当のエンジニアが進捗上の問題を抱えたままタスクの期限になってしまったことをその日や前日に知らさせれることだ。

 

「実はこのタスクでこんな事象で困っています…」
「それ今日完了予定日だったよね」
「みんなも忙しそうだったし、自分の担当なので自分でやらないと…」
「相談してっていつもいってるじゃないか」
「すみません」

 

あれ、これ昨日職場で見たぞ、とデジャブ感を感じた方もいるかもしれない。そのくらいテンプレの光景だ。

ここでプロマネの気持ちではなく、報告したエンジニアの気持ちになってみよう。

 

  • 担当している作業でやったことがない技術があった
  • 自分の担当だから自分でやり始めたが知らないこともありなかなか進まなかった
  • このくらいのことを一人で出来ないと思われたくなかった
  • 手こずっている間に作業予定完了日になってしまった
  • 未完了だとわかって怒られるのは嫌だ

 

昔の自分を思い出しながら気持ちを書き出してみたが、こんなことが日常茶飯事だったに違いない。すまんかった、当時のプロマネさん。

知らないことは恥ずかしくない

知っている手法、仕組み、形式知、経験知でしかエンジニアは課題を解決できない。知らないところに解決方法があったとしても、知らないのだからその解決方法に辿り着けないのは当然だ。

知ろうとしないことは知的産業に携わっている専門家としては恥ずかしいことだが、経験する機会や専門違いなどでなければ知らないことは恥ずかしいことではない。

逆に、やっとここで知る機会が得られたと喜ぶ事案だ。

1人プロジェクトじゃない

 チームを編成してプロジェクトにしているのだ。だったら、誰か知らないか聞いてみよう。聞き辛いなら、聞かれることから始めてみよう。

 聞かれることができれば、逆に聞きやすい環境になってきているということだ。そうなるためには、自分の得意技をチームにアピールしよう。

ピボットするタイミングは前におこう

 自力で進めることは良いことだ。やってみなければ、それが独力でできるのか、できないのかは判断がつかないのだから。

でも、出来そう、つまり、完了する見込みの見通しがつけられなければならない。3日の作業ならどこで相談するか。実装の方法が複数あるならどれで進めて、うまくいかないときはどこで転換するか、ピボットの位置(日にち、時刻)を決めておこう。

業務課題を解決できないことがわかったらそれだけでも価値はある。それを見極めるタイミングは開始してすぐに判断しよう。

相談させない「相談して」

 最大の問題は、プロマネが困ったことがあったら相談してという言い方だ。

その「相談して」は「相談するのは問題を可決する方法を選ばせろ」だったりする。

それは相談とは言わない。課題も解決できる見通しがついているし、あとはメリットデメリットまで整理してチョイスするだけだ。そこに辿り着くまで複数案を考えているし、できるだろうという見切れるまでのコストを使っている。

それが「相談して」なのだろうか。

もっと手前に相談して欲しいのではないか。選ぶまでコストを使わせていいのか。もっと手前で相談して欲しいのではないか。

「相談」は「解決手段の提示」ではダメなのだ。「困った」状態で「困った」と言ってもらわないといけないのだ。

なぜ、スタンドアップミーティングで、実績と予定と「困っていること」の3点を聞くのかを考えてみよう。

相談させない「相談して」より「困っている」状態を教えてもらおう。その時に教えてもらった方がプロマネとして一番安く上がるのだ。

 

 

いきもの人生相談室 動物たちに学ぶ47の生き方哲学

いきもの人生相談室 動物たちに学ぶ47の生き方哲学

 

 

 

 

あなたのリーダも、ぼっちでストレスを抱えて泣いている

いくつか主宰しているコミュニティの会合前から数人の方が仕事関連でかなりのストレスを受けていて、メッセージグループで内心を露呈していたことがあった。

どの方も重要なプロジェクトのマネージャを担われていて、規模感的に言えば相応のプレッシャーなんだろうなと思っていた。

会合の議題が片付いたあと軽く飲む流れになって、飲み始めたら、まー出てくる出てくる。聞き役に回ってみると、どうやら組織内でマネジメントと摩擦があったようだ。もうひと方は、担当する業務での考え方の違いのようだった。

エンジニアの仕事は、作業的なところもまだ多く残っているが発注者側がはっきりと何をしたいかをつかめていない状態から概念化し、言語化し、コードに変換するという機械的な作業に置き換えられない手続きが多いのはご存知のとおりだ。

そうした手続きの中での伝える側と受け取り返す側の理解の違いを埋めるために相応の時間を使っているのが現場で日々行われていることだ。

プロジェクトでもそうだが、ビジネスを回すマネジメントとエンジニアの間でもビジネスについては同じように相互の理解の差があり、それを埋めるためにリソースを費やしているのだ。

カンファレンスのスライドなどで、エンジニアの心理的安全に言及される機会が増えたが、エンジニアの心理的安全は何もチームの中のエンジニアばかりではなく、チームの対外的な役割を担うプロジェクトマネージャやスクラムマスタだって同じように心理的安全を確保しなければストレスで擂り潰されてしまいかねない。

PMやSMはチームを守るという気持ちがある分、そうした問題には少しばかり耐性を持っていることが多いが、その強さが強いストレスを抱えたままにしてしまい、閾値を超えたときの崩壊は早いのだ。

できればストレスの原因を吐き出すことが仕事のコミュニケーションの中でできれば良いのだろうが、そうした当てを持っていないリーダもままいるのは、エンジニアより一つ飛び抜けたロールであるという背景も少なからずある。

リーダは割とぼっちなのだ。

そして辛いと言えず、心の中で泣いているのだ。

ぼっちのリーダは自分で全部ストレスを抱え続ける他ないのだろうか。

ぼっちのリーダこそ、外部のコミュニティで心のNDAを結べる仲間とざっくばらんに腹に溜まっていることを露呈したり、仕事とは違う別の活動を介した居場所を確保することで心理的安全を確保するのも一つの救済手段なのかもしれない。

もともと仕事ができる人たちだから、組織の利害もしがらみもない場で、自主的に手を挙げたくなる活動を用意し、そうしたところで業務とは違ったテーマで集中することはおかしな話だが、気分転換になるのだ。

会合の後、ソーシャルで会合で会う人たちとの活動がストレスを緩和になっていると書き込みがあったとき、続けなければな、と。

 

 

 

 

チームが期待されている貢献を何かしらの形にするために何をするか

チームには様々なミッションが設定されている。プロジェクト(業務)の目的を達成することは勿論、それ以外にも技術力向上や後進育成、ビジネスの創出などそのチームごとでのミッションこそ、チームが組織の中で存在する理由でもある。

この、チームが組織の中で存在する理由の大切さ、意味を理解していないエンジニアが多い。アサインメントされたからそのチームのメンバになったくらいにしか思っているのが普通なのかもしれないが。

そういった背景もあって、年度始めの目標設定の際には、

「なぜ、私たちのチームはここに存在するのか」

を改めてチーム全員で再認識することにしている。そのうち忘れてしまうかもしれないけれど、マネージャとしては繰り返し存在意義は刷り込むことは必要だし、これはある意味、プロジェクト憲章の読み合わせのようなものだ。

全ての活動はチームの存在理由に帰結する。繰り返すがチームの存在理由は、そのチームに属するコストを掛けてもビジネスとしての貢献を期待されているからだ。

チームの活動はチームメンバに考えさせる

 考えさせる、と書いている時点でまだ道半ばだと思う。メンバに投げかければ、口ではわかった風な答えが返ってくるが、マネージャが考え期待していることとは程遠いのは、伝える側の期待するイメージとメンバの確固たるアウトプットを完成させることに訓練されているエンジニアの性かもしれない。

プロジェクトや事務処理的なことであればそれでいい。しかし、それでも困ることもある。例えば、ビジネス創出など、ゴールを設定できない目標に対しては。

それであっても、最初はチームのメンバに1年間の活動の中で何をしていくかを考えてもらう。

 

チームが期待されている貢献を何かしらの形にするために、何をするか。

 

貢献に結びつかない活動の場合

 チームに期待する活動を一旦は制約をかけないで何をするかを話し合ってもらうと始めるのが決まり切ったようにブレストを始める。

ブレスト、まーブレストの形態を取るよねと思うが、始めたかが悪い。思いつくことをあげるのはいいが、スライドやホワイトボードのペンを持っている人が思いつくことを書き始めてしまうから始末が悪い。

チームに期待されていることを何かしらの形にするのであれば、ブレストをスタートする前に、チームに期待されていることは何かを確認した上で始めなければ単なる思いつきレベルでしかないし、仕切っているメンバが自分で書き始めては、周りのメンバは仕切っている人が書き出すことだけを見ているだけ、になってしまう。

そういったところは、指摘しながら、全員が実質的な意味合いで参加して、チームの存在理由の軸から外れないように軌道修正させつつ、貢献の仮説のアイデアを1つでも見つけて欲しいと思っているが、なかなかスピード感が合わないことろは、日頃、どれだけチームを考えているか、そのリソースの分だけ違うのだろう。

 

 

2人から100人でもできる! 15分でチームワークを高めるゲーム39

2人から100人でもできる! 15分でチームワークを高めるゲーム39

 

 

飲み屋で武勇伝は聞きたくないけれどデスマを生き抜く方法は知りたいじゃないですか

一時期、60歳近い役員やそこあたりのおじさん達と何度となく飲みの誘いに付いていって、(飲み代は払ったけど)話を色々聞いていた時期があった。組織の上の方の人たちだったから、出てくる話がエグくて、こりゃ適当に合わせておかないとと思ったことも実際あったけど、それでも毎回の誘いに付いていって少なくない飲み代の自腹を切るのも、エグい話や武勇伝ばかりを一方的に聞いているのでは割りが合わないよな、と思って始めたのがインタビューぽく話を聴きだすという手口。

一方的に偉いおじさん達(いつもだいたい2−3人いる)が会話すると組織の誰それがあーだ、こーだとかいう人の評価ポイ話とかトラブっているプロジェクトでのプロマネがとかアーキテクトがとか、昔話とか、誰それの学歴とかの話になる。

つまり、自分がそこにいなくて、何かやらかしていたら、そうした場で酒の肴にされていたんだろうなと察しはつくわけだ。だからと言って、そういったおじさん達と一緒にその場の肴に誰かを引っ張り出して飲むなんてことは趣味ではない。

全くもってそうした他人の評価や評判に関心も興味も持っていないし、わかない。

飲んでいる間の時間という価値と支払っている対価の元をリターンしたい。そう考えたときに思いついたのは、インタビューしてこのおじさん達が40年も会社員として、役職として生き抜いてこられた何かを聞いてみようと。

いやいや、そんなのに付き合わなければいいじゃんと思うかもしれないけれど、結果から言えば、インタビューもどきの訓練相手としてはある意味よかったんですよ。一癖もふた癖もある役員級ですから、練習相手としては不足はないし、何より、気持ちよく喋らせるというスキルも身につけられる(た)ので。

それも飽きたら、スーッとそうした飲み会からフェードアウトしたけれど。

話の流れを使ってネタを振る

「へー、じゃあ、こういった時はどうしたんですか」

こんな感じで話の流れを捕まえて、自分が聴きたいことの方向に方向転換をさせ始める。期待する方に向かない場合は、その場にいる別のおじさんにネタを振る。話を振られて嫌がるおじさんは皆無だ。

なぜなら、仕事場では声をかけるのは上の役員くらいで、あとは話を一方的に聞くばかりだからだ。だってそうだろう、部下がたくさんいれば報告や相談を聞いて判断するのが仕事なんだから。

家に帰れば、奥さんが構ってくれればいいけれど、まー、そういうことだ。おじさん達はもっぱら寂しいので、撒き餌を撒けばすぐにぱくつくのだ。

デスマは話たい

 ひどかったプロジェクトを生き抜いてきたおじさん達は、そうした経験が結果的にキャリアに結びついていることが少なくないからとても話したくてしょうがない生き物だ。

でもそこで好き勝手に話させるのではなく、聞き手が関心を持っていること、例えば、デスマで最初にすることは何か、とか、デスマの交渉は、とか、そういった自分の置かれている立場で知っていればあとあと参考になるかもしれないことを聞く。

どうせ何かを聞くならね。

なので、話したいおじさんと今じゃないかもしれないけれどいつか役にたつかもしれないと思っている聞き手は、実はマッチングするのだ。

一方的に武勇伝や俺すげぇ系の話になるから、合いの手もいい加減だし、お互いつまらないのだ。

だから、逆手にとって喋りたい欲を擽るのだ。

 

 

これは別に飲み屋でしか使えない術ではないのだよ。普段の、ちょっとした場でとても役にたつ。

気持ちよく喋らせる方法を一つ知っているだけで、聾せす、好感度まで得られる。だって、相手は気持ちよく喋ったのだからね。

 

 

 

 

話すより10倍ラク!  聞く会話術

話すより10倍ラク! 聞く会話術

 

 

 

 

調達 AUKEY 20000mAh モバイルバッテリー

これかな。