チームのコミュニケーションの問題はモブで解決するよ
プロジェクトが終わって完了報告会やふりかえりの場を持つと、プロジェクトの目的を達成しているかQCDのいずれかでプロジェクトの目的を達成できないかったに関わらず、もっと上手にやればよかった、やりたかったと出てくるコメントが
「コミュニケーションをもっととればよかった」
というものです。
聞いている方としては、そんなことは必要かどうかその場でないと判断できないのだから、
「その場で判断して自らコニュニケーション＝意思伝達をすればいいじゃない」
、と思うわけです。こういったコメントは裏を返せば、意思決定の能力が低いですといっているのと同じなんだよ、と思っているんですよ。（ニッコリ
コミュニケーションをもっと取りたいはどうして？
ふりかえりでエンジニアはどうしてもっとコミュニケーションをとればよかったと思っているのでしょうか。
コミュニケーションは意思伝達の手段を丸っと表している表現ですから、コミュニケーションを取ること＝意思伝達することで実現したことがあった、と捉えることができます。
では何を実現したかったか。
自らコミュニケーションをとっていれば、自分の作業をもっと間違いなく、効率的に終わらせることができた、ということでしょう。
・質問をするのを躊躇った
・疑問に感じた技術的な質問を先送りした
・自分しか持っていない情報を共有しなかった
こうした自分に指を向けたふりかえりでの気持ちは、その逆も間接的に求めているものです。
こうしたふりかえりの気持ちは、その場で解決してほしいものです。欲しいという表現にしているのは、当事者でなければ解決できないから。しなさい、といってできるものでもないのです。これ、大事です。
どうしたら気軽にコミュニケーション取れる？
聞くこと、教えることのハードルを下げることが一番効果的です。それもチーム全員の。
チームの中で一人だけハードルを下げてもそれはチームの中でのコミュニケーション＝意思伝達が一人だけ下がるのであって、全員が同じレベルにならなければハードルが高いままのメンバに同じ気持ちが回るだけです。
モブろう
プロジェクトの一番最初のWBSをチーム、ープロジェクトの人数が多ければサブチームと数人程度がおすすめですー、全員で作業をしてしまいましょう。
用意するもの
・プロジェクタ１台
・PC１台・人数分の小さな作業
ルール
・作業を担当する人がPCを操作する
・作業時間を決める
・周りのメンバは必ず助言する
人数分の作業を順繰りに終わらせる。
たったこれだけ。
ルールに揚げ足取りのような指摘にならないように、と追加してもいいです。まあ、どうせ自分の順番に同じことをされるので自分が気持ちよく助けて欲しければ気持ちよく助けてあげましょう。
これの良いところはコミュニケーションが問題だったという点を解決できるのです。ほら。
・質問をするのを躊躇った → その場で尋ねられる
・疑問に感じた技術的な質問を先送りした → その場で解決できる
・自分しか持っていない情報を共有しなかった → その場で共有できる
これやるととっても疲れますが、得るものが多いです。
「36協定」の見直しで生産性の低いエンジニアは駆逐される
36協定。「さぶろくきょうてい」と読みますがどうして「さぶろくきょうてい」と読むかというと労働基準法36条に関する事項だから、です。
ではその第36条を確認してみましょう。
（時間外及び休日の労働）
第三十六条 使用者は、当該事業場に、労働者の過半数で組織する労働組合がある場合においてはその労働組合、労働者の過半数で組織する労働組合がない場合においては労働者の過半数を代表する者との書面による協定をし、これを行政官庁に届け出た場合においては、第三十二条から第三十二条の五まで若しくは第四十条の労働時間（以下この条において「労働時間」という。）又は前条の休日（以下この項において「休日」という。）に関する規定にかかわらず、その協定で定めるところによつて労働時間を延長し、又は休日に労働させることができる。ただし、坑内労働その他厚生労働省令で定める健康上特に有害な業務の労働時間の延長は、一日について二時間を超えてはならない。引用 労働基準法
条項の標題に気づいたでしょうか。（時間外及び休日の労働）とあるように所謂、残業に関する法律なのですね。
ここで問題です。この法律は誰のための法律なのでしょうか。次の選択肢から選んでください。
36条は誰のための条項か選びなさい
・労働者
・使用者
どちらかわかりましたか。簡単だったでしょうか。労働基本法だから労働者を守るための法律だから労働者のための条項でしょうか。それとも使用者（経営者）のための条項でしょうか。
確認する前に次の条項を確認してみましょう。第32条です。
（労働時間）
第三十二条 使用者は、労働者に、休憩時間を除き一週間について四十時間を超えて、労働させてはならない。
○２ 使用者は、一週間の各日については、労働者に、休憩時間を除き一日について八時間を超えて、労働させてはならない。
一日8時間、週に40時間を超えて労働させてはならない、のです。
プロジェクトをやっているとついつい残業することが当然だと思い込んでいたりすると
「週40時間！！何言っているの？」
と思わず脊髄反射しませんでしたか。
思った人は手をあげてください。 あー、全員ですね。エンジニアはビョーキです。
労働基準法では、労働者を週40時間を超えては働かせてはいけないのです。ところが
（時間外及び休日の労働）
第三十六条 使用者は、当該事業場に、労働者の過半数で組織する労働組合がある場合においてはその労働組合、労働者の過半数で組織する労働組合がない場合においては労働者の過半数を代表する者との書面による協定をし、これを行政官庁に届け出た場合においては、第三十二条から第三十二条の五まで若しくは第四十条の労働時間（以下この条において「労働時間」という。）又は前条の休日（以下この項において「休日」という。）に関する規定にかかわらず、その協定で定めるところによつて労働時間を延長し、又は休日に労働させることができる。ただし、坑内労働その他厚生労働省令で定める健康上特に有害な業務の労働時間の延長は、一日について二時間を超えてはならない。引用 労働基準法
とあるように、協定を結ぶのであれば労働時間を延長、又は休日に労働させることができる、とあるのです。
だから週40時間しか労働できないエンジニアも残業ができるわけです。ワーイ！
それでは先の質問の答え合せをしましょう。
36条は誰のための条項か選びなさい
×労働者
○使用者
なぜ使用者のための条項となるかは、その条項に答えがあります。
に関する規定にかかわらず、その協定で定めるところによつて労働時間を延長し、又は休日に労働させることができる。ただし、坑内労働その他厚生労働省令で定める健康上特に有害な業務の労働時間の延長は、一日について二時間を超えてはならない。
引用 労働基準法
そうなんです、労働させることができるのは使用者（経営者）です。
そして使用者とは部下を持っている管理職以上を指しますから、管理職以外の労働者は本来指示がなければ残業はできないのです。
ところで、政府は働き方改革を進める中で長時間労働を抑制する方向に進んでいます。
そうするとエンジニアのプロジェクトにどのような影響が出てくるでしょうか。
現状、野放図なプロジェクトでの労働時間は週40時間＋36協定で結ばれる延長の範囲に収めるように世の中の常識が変わっていく方向に進むでしょう。
間に合わなければ残業時間で、休日出勤でというマインドは通用しなくなるのです。法律的にも世間の常識的にも。
それに対応するためには労働者であるエンジニアは限られた労働時間というタイムボックスの中で成果を出さなければならない、ということになります。
それを実現するためには、それができるスキルも必要になりますし、今の無駄な作業を洗い出し、成果の得られる仕事のやり方に変える変化が法律からも求められるということになるのです。
変化できないエンジニアは淘汰されるでしょう。
SI開発のレビュー文化を変えよう
ジョイ・インクを読んでいるんですが…ちょうどこの辺り。
これまで経験してきた中でこれは参考になるかもしれないと思って書いているエントリの中のプラクティスがこの本に散りばめられている感じがしないでもないのです。
ジョイ・インクでは組織として回しているところもあるので洗練度合いは濃淡があるのは当然としても、プロジェクトマネージャやマネージャをそれなりに経験しているとエンジニアはだいたい同じようなことを考えるのだなぁ、と思うのです。
SI開発でレビューをする理由（PMの立場で）
SI開発のかったるさの一つにアウトプットの品質検証があると思うのです。でも、プロジェクトマネージャの立場だと工程毎にプロジェクトの品質要求レベルを満たしていることが次工程に突入できるクライテリアになるから現場に任せたとは言えないし、リリース後に明らかに工程毎に出さなければならない不良はその工程で出しておかないと契約形態によっては横並び点検などしなくてはならなくなった時に絶望するのでそうした容易く想定ができることは工程毎にカタをつけておきたいのです。得てして、注意が行き届かない、でもちょっと気になっていることがリリース後に不良として発現するので。
そういったこともあって、工程毎の品質を確保する、違うな、機能検証するためにレビューを全ての工程で行うのです。
SI開発のレビューがイケてない（エンジニアの立場で）
とは言え、SI開発でのレビューは「これいいやり方だぜ」というものに出会えた記憶がない…ない…。
プロジェクトの規模が大きくなればなるほど、レビューはフォーマルになるし、フォーマルになればなるほど形式ぽくなるので本来設定するレビュー観点が曖昧になるのですよね。
じゃあ、規模の小さいプロジェクトで効果的、つまり、レビュー観点に沿った指摘ができているレビューはどのくらいあるかと言えば、これもだいぶ怪しくなってくるのです。なぜならレビューができるレビューアがチームの中で限られるから。
SI開発でやりたいレビューとは
立場的にやりたいレビューは、そうそう、対象は設計書はもちろん、コードも。コードは機械に任せられるもの、例えば静的なチェックは機械に任せるとしてそれ以外の、ですが、要件をもれなくカバーしているか、実現したい機能仕様は存在するか、制約事項、前提事項は考慮されているか、そうした要件をコードに変換できているか、とやりたいことはリリース時に実現したいプロジェクトの目的がレビューを通して検証したい、のです。
レビューアの技量が足らないと、そこがすっぽりと抜けてしまって本来二の次の「てにをは」や体裁に走ってしまって本来レビューで得たい成果が得られない、と。
ライブレビューがイケてた
そう言えば、すっごく大変なプロジェクトで制約が多く、めんどくさいテーマがあって、そのときにやったレビューがライブレビュー（名前は今つけた）がイケてたことを思い出したのはジョイ・インクのペアプロが心のどこかに残っていたからかもしれません。
最近でも、セルフレビューを新規参画メンバにスキトラする際に、いかに効果的にレビューの観点を技術移転するにはどうしたらいいかを２分だけ考えてやったのがやっぱりこのライブレビューを頭で考えていることを言語化して見せるというやり方です。
■環境
外付けディスプレイとPC
■参加者
レビュースキトラしたい人、受ける人
■やり方
・ディスプレイにセルフレビューする資料を映す
・レビュー対象のコンテンツにレビュー観点でツッコミを書いていく
・書きながら、どうしてそう判断したのか観点、判断基準を示す
こんな感じです。
前のすっごく大変なプロジェクトで制約が多く、めんどくさいテーマがあって、そのときにやったレビューがライブレビューの場合は、レビューのたたき台をスライドに作っておいて、参加メンバがそれぞれ知っていること、例えば、それを実現するならこうした制約があるから考慮が必要、とか、技術的に確立できていないから検証が必要、とかとか全員が持っている経験と知識を総動員してスライドに書き込んでいくのです。
上記のいずれのケースもレビューで検証したい目的を実現できているのです。対象が仕様書なら後者の方法（人数は必要最小限）でやればいいし、コードなら二人でやったらいいのです。
もちろん、少人数、特に二人でやる場合は、一人は経験していないと二人でダメレビューになりかねないので、先行するペアを作って何度かチームの中で経験をして、経験者を散らす工夫が必要ですけど。
- 作者: リチャード・シェリダン,原田騎郎,安井力,吉羽龍太郎,永瀬美穂,川口恭伸
- 出版社/メーカー: 翔泳社
- 発売日: 2016/12/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
素早く働くことで得る成果とずれていく評価軸
エンジニアになってから、ーいや、エンジニアになれているかどうかはわからないけれどー一番変わってきた仕事のメジャメントは時間です。月次単位での予実の管理から週次に、日次での計測から、ついには作業単位を時間単位で見積り、朝会で計測するところまで変わってきています。
○次の○の時間の単位が小さくなってきていることは、時間に対する価値感が変化しているということができます。小さな時間に対してリソースを投入し、期待する成果を得ることに価値を見出すビジネスニーズが出てきた、ということです。
失われつつある仕事での時間の使い方
これまで、組織においてはまだ生き残っているかもしれない仕事での時間の使い方は、確信が持てるまで時間を使い、情報を集め、計画を作り、アウトプットするというような、より安定した、確実な進め方で、単純化して、物事をはっきりさせてから手をつけるようにしていたのです。
旧態の組織、それも間接部門や本社機能では未だにそうしたやり方に疑問を持たずに仕事をしているところもあるでしょう。
でも、これでは投下するリソースのリターンを得るまでが遅く、ましてや期待する成果を得られる確証の見通しも立たないのが今の時代です。
小さな時間で成果を出すということ
とにかく、小さな時間の単位でエンジニアも仕事の成果を出すビジネスニーズに変化してきたということは、エンジニアの評価軸も変える必要があります。
エンジニアが小さな時間の単位で仕事の成果を求められるようになったということで、これまでの安定した中での仕事とは違う環境要素を許容しなければならないということです。
これまでの時間を掛けて進めてきたやり方とは真逆の「これどうするの」と今までは投げ出していた状況下で成果を出さなければならなくなってきました。
・確実でない情報で進める
・不安定な状態で進める
・複雑な環境で進める
・曖昧なまま進める
でもビジネスニーズが変化し、評価軸も変わってきているのでエンジニアもやり方を変えなければならないというマインドセットの入れ替えから求められるのです。
そうしたことの積み重ねが、小さいタスクに分け、毎日進度を確認し、どうしようもなくなる前にピボットするプロセスを採用するに至るわけです。
成果とずれていく評価軸
従来の目標管理制度では、目標に対し、優先順位をつけ、それを合意して活動するのですが、ビジネスニーズと求められる成果を出す環境の要素が変わってきたことから、評価も変えないとエンジニアの成果と評価がずれていってしまうのです。
現行の活動の成果から、活動をとおして成果を出すためのスキルレベルをあげたり、スキルの幅を広げるというところに評価を移す必要が出てきているのです。
目標設定の際に、マネージャもエンジニアもその点にシフトしておくことを留意しておきましょう。
金融・COBOL・保守要員でエンジニアの成長は積むのか
新卒で入社したITベンダーでCOBOLを教え込まれ、金融機関にシステムの保守運用要員として送り込まれたら、一巻の終わり。「失敗は犯罪的行為」という金融機関のIT部門の文化にどっぷりつかり、要求された通りに保守作業などを続けていれば、ビジネスパーソンとして、技術者としての成長はおぼつかない。
「 一巻の終わり」なんだそうだ。一巻の終わりとはエンジニアとしての成長がおぼつかないのだそうだ。まあ、そういうエンジニアもいるのでしょうね。
この記事では、エンジニアの成長には失敗をすることで成長するのが前提らしいけれど、失敗をしなくていいならしない方がいいじゃない、と思うのだけれど。
それは挑戦をしないということではなくて、用意周到に準備をするとか、進むステップを刻んでピボットするとか、やり方を工夫して、という意味で。
なんとはなく、記事の背景には、
それなりの失敗を重ねること＝エンジニアの成長
という図式があるのではないかしら。
例に突っ込んでも記事で言いたいだろうと思われることと外れるかもしれないけれど、「失敗は犯罪的行為」の犯罪的という表現はともかく、金融、例えば銀行の勘定系で失敗、計算が間違っていたら犯罪というより、一預金者として預けておいたら気が気じゃないのではないか、と思うんですが。少なくとも嫌ですよ、そんな勘定系システムは。
失敗＝エンジニアの成長ではない
これまで「失敗をしよう」というテーマでエントリを書いてきているけれど、失敗の前に「小さな」としているのです。
あえて「小さな」としているのは、小さな失敗なら軌道修正してリカバリをできるようにするためです。
金融・COBOL・保守要員であれば行内NWに閉じられた閉鎖空間だから、新しい技術やツールを気軽に導入することはできないけれど、エンジニア自身の仕事の仕方の工夫などテクニック的なものやマインドセットのようなものまではいくら金融だとしても制御できないです。
小さな失敗と二度と繰り返したくない失敗と取り違えてはいけない
小さな失敗をしよう。なぜなら、エンジニアとしての改善を続けることに繋がるからだし、プロセスを見直す習慣にもなるからです。さらに、小さく進めることで期待する結果と期待していた結果を測定する習慣も身につくのです。
一方、二度と繰り返したくない失敗というのもあります。その経験で得られるものはリスクを識別する能力を学習することです。
まあ、トラウマになる経験ですね。
そんな経験はしなくでいいです。ほんと。身の危険を感じますよ。進退も。
失敗する機会、タイミング、程度があるのです。
金融・COBOL・保守要員は積むか
金融は技術的な閉鎖空間の意味合いがあるのでしょう。分散系であってもIE6とかjavaの古いバージョンが重荷になっていた時期があったものです。枯れている技術を採用する傾向が強いので、プロジェクト開始時点で安定しているバージョンを選びますから。
COBOLは古い言語だからシンボル的に挙げられていますけど、じゃあCはとかアセンブラとかはどうなんでしょう。分散系の言語の更新の方が早くないでしょうか。廃れてしまう言語を学ぶのもいいですが、使い切る前に新しい言語を学ぶようでは、使いこなすという習熟をどこで学べば良いのかしら。
保守要員ほど他人が書いたコードを読み取って新たな要件を追加することで影響を見切るのはそれなりの技量が必要だと思うのです。
金融・COBOL・保守要員で積まないエンジニア
経験から言えば、金融ほど標準化が進んでいる業種はないと思うのです。ある時期はどのベンダーも金融に一番優秀なエンジニアを配置していました。今は違うのでしょうか。
学ぶ情報、プラクティスは金融がいいのではないか、と。色々と継ぎ接ぎだらけなのかもしれませんが、そうしたプラクティスから自分なりに体系を抽象化することで得られるものは他のインダストリーにはないと思います。
言語も学習方法を学ぶことで対応力の幅が付いてきます。
多重請負であるとアクセスできる情報できる裁量は限られますが、それは他のインダストリーに行っても同じことです。
少しパラメータは違えど、超大型案件の中の時間が確保できるプロジェクトでプロジェクトマネジメントの体系的な学習と実務で使うツールを身につけた経験から言えば、このまま埋もれたくないとエンジニアが行動するだけで結果は付いてくるのです。
人月商売の裏でエンジニアが悶々と感じていることとアフターフォロー
一昨日のエントリに対してコメントが思っていた以上についたので珍しく読んでみたらアフターフォローというか、エントリでカバーできていなかったあたりの補足説明になるといいな、と思ったので、今日はこれで行きます。
こういったコメントは直接勉強会的な場でやり取りできると学びがあるんですよねぇ。
さて、
人月商売がエンジニアをすり潰す - 室長のひとりごち
- [SIer]
人月商売つらいなあ。有償稼働下げるとあかんというのは分かるんだけどそのせいで自分が成長できないと感じ辞めていく人を何人見たことか...
2017/04/08 18:15
自分がリーダ役であれば、仕事を分担する際にその仕事を通して何を経験できるか目標を設定することができます。多重下請けの場合、参画できるプロジェクトの適用技術、工程でしか目標を設定できないところに制約が出てしまいますが。
人月商売がエンジニアをすり潰す - 室長のひとりごち
世の中一括請負で出来る仕事だけではないし、松竹梅でもスキルを正しく評価できてるなら何ら問題ないだろ。人月商売は多重派遣で低スキル要員集めがちなのが問題なだけ。
2017/04/08 16:26
揚げ足を取りではありませんが、多重派遣というより二重派遣は法律で禁止されているので、多分、多重下請け（請負契約で）を指摘されているのだと思います。
多重下請け構造でも、契約の履行で必要な技術要素を他社から買うことで実現できるなら自社で育成する時間を買うという観点や技術特化している場合はありだと思います。問題は、過去のエントリでも書きましたが調達する側も売る側もプロジェクトの要素として必要なスキルセット、レベルを要求、供給できないマネージャ、営業、エンジニアが関わっていることかと思います。
プロジェクトの目的達成のためにプロジェクトチームとして必要なスキルセット、スキルレベルを棚上げした上で、需要側は請負契約にすることで供給側に履行責任を丸投げしたり、供給サイドも現場でよろしくやってくれと必要なスキルレベルに達していないエンジニアをドナドナするから現場が不幸になるんですよね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
人月商売なんてそんなに技術更新いらないところの話じゃないの？コボルできる人募集〜〜とか、JAVAとデータベース使える人募集とか、そんな感じな気がする。
2017/04/08 14:47
技術更新が要らないところでも、供給されるjavaエンジニアがjavaをちゃんとしたjavaで書けるのかと突き詰めればどれだけいるかはご存知なのでは。
技術更新ではないと思っているのですが、製品のバージョンアップがマイナーだとしてもガラッと変わっているエンプラパッケージを時々見かけます。こうしたバージョンアップ対応プロジェクトもそうしたパッケージの差分を現行システムに影響を与えずに適用するの手間がかかりますよね。そうしたことを考えられるエンジニアがそこそこ必要なのですが、そうした考慮しなければならないことを考慮しつつ仕事に落とすことができるエンジニアがとにかく少ないのです。
まあ、そうしたことを考慮してプロジェクトの中に落としていくことができるエンジニアはアーキテクトの素質がある人かアーキテクトそのものかパッケージに特化したスペシャリスト（特化型アーキテクト）なんですけどね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
人月商売は本当にダメだと思う。成果じゃなくて時間で稼ぐ形になるから、効率化や新技術とは無縁になる。
2017/04/08 13:16
人月商売はダメだ、については同意します。発注側がダメな点を挙げると、成果で見る技術を持っていないから、唯一判断できる時間だけで評価をするわけです。それしかメジャーメント持っていないから席に１人月座っていることを評価するのです。
受注側は、技術評価されないことを知っているから人月商売をすることがあります。毎日、プロジェクトルームに行きさえすれば、契約上の債務を履行していることになるのです。だから、その辺に歩いている人ならエンジニアの経験があってもなくてもドナドナするのです。で、現場で育ててくださいとか言い始める。
そこそこ経験をエンジニアが積むと時間で縛られていることを学習するので、プロジェクトで求められる成果をアウトプットしようとはせずに、指示された仕事の成果だけをアウトプットするオペレーションをするようになります。指示されたものしか作らないのは、時間に縛られているので効率を上げると余計に仕事をしなければならないのに給与などのリターンは変わらない（160時間内であれば）ので効率的に仕事をする必要が見出せないのですよね。
ましてや新技術なんてプロジェクトに関係ないですもの。心底、そのプロジェクトから抜け出したい、同じ言語は飽きたみたいな場合、抜けられる道具として新しい技術を習得して「新技術できるよ」と営業やマネージャにアピールする、と。
多くのエンジニアはそれさえもしませんけど。
人月商売がエンジニアをすり潰す - 室長のひとりごち
いつでも転職できるように入社当初から貪欲に勉強し続けてたら、今や無双状態で快適よ。業界の構造なだけで誰かが悪い訳ではないので、それを逆手に取らないと。
2017/04/08 10:26
転職する、しないに関わらず、転職するつもりで市場に自分の技術をレーティングしておくことはとても大事です。技術の成長を比較するのは今日と明日の自分ですが、外でどれだけで売れるエンジニアとしての価値を知っていることはとても情報を知っているだけでもアドバンテージがあります。
どんな環境下にあるとしても学習することを継続し続けるかどうかはエンジニア本人のマターです。自分で何ができるようになるかは対自分との絶対評価ですが、世の中に出れば相対評価です。技術的優位点が多ければ多いほど、市場価値は上がりますし、それは日々の技術習得で成長しているから実現できることです。
で、それを武器にしよう、と。
人月商売がエンジニアをすり潰す - 室長のひとりごち
孫請けより下のSIerは間違いなくそうなる。元請けや親密企業は新技術の教育に熱心だよ。
2017/04/08 06:32
おっしゃるとおり、一部の二次受けくらいまではその可能性はあります。ただ、いくら熱心に教育に力を入れているといっても、エンジニアが受けたい教育かどうかは、また別の話になってしまう…か。話が逸れました。
人月商売がエンジニアをすり潰す - 室長のひとりごち
"顧客からは今持っている技術で実現したいことがシステム化できてしまうなら、使う予定もない新しい技術の習得に対して魅力を感じるでしょうか。" わかってるじゃん。
2017/04/08 02:04
ありがとうございます。
人月商売がエンジニアをすり潰す - 室長のひとりごち
うーん。普通では？エンジニアに替えが効く（としたら）SIerはエンジニアを勉強させる必要がない。だって勉強させてすぐ辞められたら損じゃん。
2017/04/08 00:03
はい、普通の日常的に起きていることです。
ところで、エンジニアに変えが効くかどうか、は、プロジェクト側がプロジェクトに必要な技術要素、技術レベルをきちんと把握していて、あと業務知識も必要ならそれもですが、調達する社内外のエンジニアと紐付けしていれば、それが実現できます。
というか、それができていないプロジェクトは最初から積んでいます。だって、把握できていない時点で属人的にプロジェクトが遂行することが決まっちゃうんですから。
勉強させて辞められたら損だという点はエンジニアのマネージャの立場でしたらそのとおりです。良い観点です。仮に3ヶ月新人研修をするとして、4ヶ月目に辞められたら、新人エンジニアの給与※３倍くらいの費用をドブに捨てていることになります。20万が給与であるとしたら、180万くらいですね。180万の給与は将来現場に出て回収するための投資として行なっているので、投資先である新人エンジニアが辞めてしまったら投資した資金は回収できなくなるんですね。なので、教育に行かせることは将来の商売のためなんですね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
エンジニアの技術更新を組織がやってもいいけど、認めるだけでも全然違うかな
2017/04/07 23:14
組織が技術更新をする場合、組織の都合（事業計画的な意味合い）が強くなりますね。今だとIoTとかAIとかでしょうか。それとエンジニアの関心は別ですけれど、それも話が逸れてしまいますね。
何にフォーカスするかは別として、稼働を下げてまで時間を割り当てるという経営判断ができる組織は人月商売だとしても延命するでしょうね。
人月商売がエンジニアをすり潰す - 室長のひとりごち
優秀なエンジニアなら、そんな働き方しないでしょう。エンジニアに見向きされてない中小企業で働きなさい。エンジニアが自分一人だから、神様のように振る舞えますよ。
2017/04/07 23:11
優秀なエンジニアは優秀なのでマネージャに引き上げられて売る側に回るのですよね。以下ループ、と。ただ、マネージャが嫌なエンジニアは、逃げ回って現場に居続けるか転職してしまうのですけど。
ところで、
エンジニアに見向きされてない中小企業で働きなさい。
が理解できなかったのですが、中小企業ならエンジニアは事業組織の中では間接部門だし本業ではないこともあるのと情報技術は誰もわからないから治外法権になるよ、ということかしら。
実際そうだと思うのですが、200人以下の中小企業を100社くらい回ったことがありますが、そういった企業のIT担当者は1人や2人が精一杯でほとんどが総務や営業と兼務のケースがほとんどでした。知っている限りでは専任は珍しいです。
それで神様になれますが、神様に些細ないこと全て問い合わせが来ますし、事業優先で現場が強いことも多くトラブルとものすごいクレームなんだそうです。そのあたりの運用を捌ければ神様も良いかもしれません。
人月商売がエンジニアをすり潰す - 室長のひとりごち
成果物を小出しにしておちんぎん貰いながらダラダラしてる奴もいるんで一方的には言えねえなあと思う
2017/04/07 14:20
ほんこれ。こういう仕事をするエンジニアに限って文句はいうし、品質はひどいし、納期は守らないし、言い訳ばかり。速攻で退場いただきたいものです。
人月商売がエンジニアをすり潰す - 室長のひとりごち
ロストテクノロジーの意味が微妙に違いそう。内容については同意
2017/04/07 23:41
あーすみません、気付いちゃいましたか。
書きながら「違うな」思いつつもタイムボックスの時間切れと確信犯でやらかしたのでした。
だってなのはが頭をよぎってしまったんですもの。
