マネージャに集められても自律的なチームにするために
はじめに
システム開発ではプロジェクトチームとか、開発チームなどチームをよく使いますね。班はほとんど使わないですね。製造業だと使うようですけど。
元よりチームの意味はどんなのでしたっけと辞書を引きます。今度はグループときたもんだ。
チーム【team】 の意味
ある目的のために協力して行動するグループ。組。スポーツや共同作業についていわれる。
グループの意味を引きます。人を集めた感しかないですね。束ねた、みたいな。
グループ【group】 の意味
出典：デジタル大辞泉
１ 仲間。集団。「グループ旅行」
２ 共通の性質で分類した、人や物の一団。群。
３ 同系列に属する組織。「企業グループ」
製造業で使う班は小学校以来な気がします。これも辞書を引いてみます。班のほうが良さげですが、目的を持って行動するという意味合いがチームより弱い気がします。
はん【班】 の意味
出典：デジタル大辞泉
［名］
１ 一つの集団を数人ずつに組み分けして、行動・作業を共にする小単位としたもの。「三つの班に分かれて討議する」「救護班」
２ 仲間。
システム開発のように目的を持って行動するのはやはりチームが用語の意味的には良いのかもしれません。組織の中の担当部署としての集団には班でも適当そうです。
チームは勝手に集められる
組織の中では人事権を持つマネージャやプロジェクトのミッションを担い手がデレゲートされ、必要と想定するリソースを集めてチームを作ります。エンジニアがプロジェクトに参画するとき、ほぼこのパターンです。多くはないですが自薦だったり、プロジェクト自体のリーダになればリソースの人選に関わることもあります。多少については組織の文化に依存するのですけれど。
何れにしても機能的構造を持つ組織ではリソースの権限を持つマネージャがエンジニアを集めるわけです。そこに、志を持ったエンジニアが勝手に集まってくるということは存在しないのです。
ちょっと悲観的ぽく書きましたが、エンジニアが自組織の新しい動きについてどのくらい関心を持っているかといえば、隣のチームですら何をやっているかわからないというか情報を取りに行かないのに自ら参画したいと思っているのかと。
チームと多様性
一人のいちエンジニアの立場ではチームを作るにあたって集められるのであれば、多様性を云々というよりは、勝手に多様性のあるメンバでチームが作られるのです。どうして多様性を持つのかといえば、チームがチームの存在意義である目的を達成するために必要とするチームとしてのスキルセットを確保するためです。
多様性、ダイバシティ確保のために〜ではなく、一人ひとりキャリアも保有技術も価値観も違うメンバを勝手に集めているのですから、お互いできることを知り、お互い補完しながら仕事をしよう、という合意がなければチームが持つ目的のために行動を一緒にすることはできません。
多様性やダイバなんとかという前に、お互いにどのような性質を持っているかを理解しましょう、ということなのです。
チームと自律
チームが機能するためにはチームの中でのアクティビティやそのアウトプットをするために作業品質をある一定の水準で確保する必要があります。
それを確保するためにチームのルールが必要で、そのルールを無意識に、自律的に守る状態を醸成することが当面の課題になります。チームがルールを自律的に守るためにはそれができるまでお互いにルールを意識しながらアクティビティをこなさなければなりません。目指すゴールはそうしたルールを暗黙で振る舞えるようになることです。
エンジニアの転職でリセットされるもの
「（こんな仕事やめたい…）」
「（この会社のやり方についていけない…）」
などと思ったことがないエンジニアはいるのだろうか。この2つはないけれど、
「（この上司とはやっていけない…）」
「（この仕事から逃げたい…）」
の方が思い当たることがあるかもしれないですね。それで実際に転職するエンジニアはどのくらいいるかといえば、それほどいないのだと思うのです。転職するエンジニアが多ければ転職エージェントは宣伝が減らせるので。おおいいですよね、電車の中の広告。
どちらのタイプか
転職するにも自分から転職を探すケースとヘッドハンティングから声がかかるケースと2つあります。詳細には、ヘッドハンティングも声をかける側が闇雲に声をかけているケースと一本釣りのケースに分類できます。ヘッドハンティングで闇雲に声かけているケースはろくなもんじゃないので逃げましょう。
自分から転職したい場合は、どうして転職するのかを明らかにしておいたほうが意思決定を間違えを減らす方向に向けられるでしょう。
保有技術を生かすのか新しい挑戦なのか
やめたい理由とじゃあ、移った先でなにをしたいのかはよく考えておかないと移る前のやめたい事案を再現することになります。
自ら転職したい場合で新しい技術に挑戦したい場合は、採用条件や配属先まで注意しておかないと保有技術で配属を判断されるので注意が必要です。
ヘッドハンティングの後者の場合は、引き抜く側から担当して欲しいポジションが明確に用意されているので話は早いのですけれど。
転職でリセットされるもの
自ら転職を選ぶケースでもヘッドハンティングで引き抜かれるケースでも、必ず起きるのが転職することでリセットされるものがあるということです。
それは、会社の中でのコミュニケーションパス、ヒューマンネットワークがリセットされるということです。
転職しているので試用期間は期待される成果に応える必要がありますが、仕事をする上で人的ネットワークも構築していかないと仕事にならないのです。
ほとんど、知り合いのない中で一からコミュニケーションパスをゼロから構築しなければならないのです。これ、相当コストがかかりますしバカにできないのですよね。
個人的には、このコミュニケーションパスの再構築をするのが面倒だなと思う派なのです。
エンジニアの間違った稼ぎ方
エンジニアがどうやって稼ぐかネタとして振ると良くも悪くも、いや、よくないのだけれどトラブルプロジェクトに入るのが稼げると答えが返ってくるのです。
「お、おぅ…そうだね」とレスポンスしますけれど、それ一時的な臨時収入のようなもので続かないので。
なぜトラブルプロジェクトに入ることがエンジニアの稼ぎに繋がらないかというと、1つは、エンジニア自身や体力的、精神的に参ってしまうことがあるからです。300時間越えの労働なんて数ヶ月やるだけで立派です。立て直しでそこそこやりましたけど稼げるからとやるもんじゃないです。だって、エンドが見えない過酷な状況ほど、負担が大きいのですよ。
2つ目は、トラブルプロジェクトの方が先に力尽きてしまうのです。10年前に比べたら、プロジェクトマネジメントやプロジェクトの定量的監視は程度はあるにしてもコストの観点でモニタリングされ、ストップが掛かり易くなっていると思います。経営者だって監視されているわけです、株主に。説明責任を果たすとなるとトラブルプロジェクトは放置できるものではないということです。まあ、メンツでやり切る方が相変わらずなのでしょうが。
トラブルプロジェクトはリソースの切り売り
毎度まいど同じことを言っているような気がしますが、トラブルプロジェクトに参画しているということは1日のうちのほとんどを仕事のアウトプットするために使っているのです。ね、アウトプットだけに時間を使うんですよ。
インプットとなるリソースは、エンジニアの知力、体力、時間です。それを10時間超毎日やるわけです。それでいつまでリソースの供給を続けられるのか、ということです。
トラブルプロジェクトで元気なのは、ベテランエンジニア勢で、彼らは教養課程としてトラブルプロジェクトを何度か経験していますから、どうなるかとかどうすればいいかが彼らなりに見極めできているんですね。それに長丁場になることも想定していればどこでリソースの投下と緩和をすればいいかもわかるんですね。ウイークポイントは体力ですw。
一方、経験の少ない若手は全力で行くタイプはすっからかんになるまで突っ走ってしまうんです。で空っぽになってから倒れちゃう。
どっちにしてもトラブルプロジェクトはリソースを使い切ってしまったら退場するしかないし、使い切らないようにしないとあかんのです。
トラブルプロジェクトはリソース供給できない
これも何度も書いていますが、エンジニアは技術を売るので技術の供給を自分でしなけえればならないし、それを需要家であるプロジェクトに売らないといけないのです。
トラブルプロジェクトで需要に応えてばかりいると技術のストックはなくなる一方だし、自分自身に技術を供給しないと売る技術がコモディティ化して商品価値が目減りするんですね。
それでトラブルプロジェクトにずっと参画して稼ぐよと言っているとどうなるかといえば、エンジニアの価値的にはどうにもならなくてというか使い物にならなく自分からしているんですよ。技術的にジリ貧になってしまうんですから。
60歳を超えて働くという長期的なスパンで考えたとき、トラブルプロジェクトなんて1/20くらいなものです。それでそれ以外を棒に振るのか、ってことです。
仮にトラブルプロジェクトに入ってしまったら、何かを得ないとやっていられませんけど。
現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
SEサバイバル手帖 通勤
はじめに
どこに住居を構えようが、仕事と住居が同一でない限り通勤は生じます。首都圏で戸建ならドアツードアで片道1時間30分なんて可愛い方です。この低成長期に入り、地価が下がったこともありかなり都心回帰となっていますが、それでも1時間くらいはかかる人が多いのでしょう。
最近は働き方の多様化を促す働き方改革を政府が推進していることもあり、懐かしいテレワーク、つまり、在宅勤務など通勤せずに働くケースもあります。一部の会社では、オフィス自体を無くす取り組みをしているところもありますが、それってますます労働の対価に対するロイヤリティが高まるのではないかと心配せずにいられません。
手段
通勤手段には、次のものが挙げられます。
・電車（新幹線通勤含む）
・バス
・自転車
・自動車
・徒歩
電車やバスなどの公共交通機関は、徒歩や自転車との組み合わせのケースも多いです。最近の自転車は、所謂、ロードバイクを使った通勤風景もだいぶ見られるようになり、そうしたケースですは、オフィスの中に駐輪用のスペースを設ける会社もあるようです。
自動車については。公共交通機関が発達していない地域においての代替手段として、若しくは、便利さにおいて選択されます。
時間
通勤時間は乗り換えを含めドアツードアで計測します。決まった時間で行くためには、徒歩＋バス＋電車などのように運行が不安定なバスを入れるのは余裕しろが必要です。また、公共交通機関や自転車、徒歩は天候に左右されるために、始業時間前のどのくらいに到着するかはそのエンジニアの時間と約束に対する価値観で幅が違います。
通勤時間の過ごし方
自分で運転する手段以外は、経由地若しくは目的地までは乗車するだけになるので乗車中は隙間時間となります。この時間の使い方はエンジニアの日常的な時間の潰し方の価値観が可視化されます。
スマホやタブレットが普及した以降、電車の車内で新聞を読む風景はすっかり見かけなくなりました。読書も書籍からスマホや電子書籍リーダに置き換わるようになりました。
出会い
ドラマや映画などでは相変わらず、通勤途上で気になる異性に出会ったり、アクシデントから認識することがありますが、現実の世界ではそうそう多くはないようです。
トラブル
通勤時間のラッシュに関わらず、早朝から深夜まで何が不満なのか、無関係な人に因縁をつけて喧嘩をふっかけたり、痴漢をして電車を止めたりと迷惑千万な輩が相変わらず一定量います。
君子危うきに近寄らずで、そうした時間帯を避けたり、混雑する車両を回避することはリスクを識別して確実に移動する目的を果たすために必要なことです。
最適な通勤
これは考え方や価値観に左右されますが、少しでも勤務地に近い方が、通勤による時間を抑えるためには一つの解だと思います。読書の時間を電車の乗っている時間で確保したいというケースでは乗り換えのない経路となるように住まいを選ぶという価値判断もあります。
SEサバイバル手帖 技術習得
はじめに
エンジニアが技術を身につけるには、身に付けなければならない技術の特定から考えなければなりません。エンジニアが身につける技術は幅が広く、技術の難易度も深く組み合わされているのでいきなりピンポイントで学ぶことはエンジニアの性質、得手不得手のマッチンングするとも限りません。エンジニアが振るう技術にはどのような技術の種類があるかを知るためにも概論的な知識が必要です。
エンジニアと技術のエンゲージ
技術領域の幅が広いために専門性を持ったエンジニアを育成したくなるところですが、そのエンジニアの性質がアサインした技術領域とエンゲージするかどうかは別次元の話です。
一方、エンジニアは好感を持っていなくても特性上から出来が良いケースもあります。この場合は、エンジニアは仕事に興味を持つまでに時間がかかりますし、興味を見つけられる前に離れてしまうこともあります。
エンジニアと技術のマッチングは長期的な成果の観点では重要な要素です。それを見極めるためにも技術のローテションは考慮しなければなりません。
技術を身につける手段
エンジニアが技術を身につける方法は、集合教育によるOFFJTと業務の中で実践しながら技術を身につけるOJTがあります。OFFJTはさらに組織内での教育と外部委託による教育、及び、エンジニア自身が組織外で取り組む自己研鑽とに分かれます。
組織がエンジニアに対して技術を習得させるのは、業務上必要なことで事業の達成に必要なコストです。これは、エンジニアに一定の教育を行うことが事業の発展に繋がる投資であることを物語っています。組織がエンジニアに対して教育を行わないということは、事業の発展に必要な投資を行わなわないということです。
OJによる技術習得
OJTによる技術習得は、アサインする業務で必要な技術が身に付けられる期待ができます。逆の見方をすれば、アサインされる業務で使われない技術は身に付けられることができない、ということです。長期にわたり特定の業務にアサインすることは、エンジニアが適用できる技術が固定化されるということになります。
組織がエンジニアに対してマルチスキルを望むのであれば、ローテーションなどの配置転換により、強制的に技術習得の機会を設ける必要があります。
組織内及び業務委託による技術習得
組織内若しくは業務委託によるOFFJTでの技術習得は、組織が事業計画を具体化した際に注力する次期ビジネスの技術をエンジニアに習得させるために行います。これは組織が行うOFFJTは、事業計画と連動して先を見据えた育成計画がなければならないということです。
エンジニア自身による自己研鑽
理想は、OJT若しくはOFFJTでエンジニアに必要な技術習得の機会を設け、技術移転を行える仕組みを用意することです。実際には、企業内及び業務委託による教育のコンテンツではエンジニアが関心を示す先端的な技術などは体系化される以前のことが多く、提供されません。エンジニア自身が関心を示す先端的な技術や手法については、任意の団体で運営される場で習得したり、自己の技術的欲求を満たす知識や技術を満たすために自己研鑽の形式で行われます。
