エンジニア向けワークショップのコンセプト作り入門

独自のワークショップを持っていると、カンファレンスでワークショップを受けられた別のコミュニティの幹部の方が所属するコミュニティのカンファレンス向けにアレンジしてやって欲しいとリクエストをいただくことがある。ありがたい話なのでホイホイと話を進めるのであるが、その進め方自体もまた面白いと感想をいただく。折角なので、そのアプローチを文字に起こしてみる。

コンセプト

• きっかけになる大元のワークショップのコンセプトがある。派生したワークショップを作るか、その大元のワークショップを一部改造（カンファレンス向けに調整）するとしても、ベースのコンセプトからずれたり壊したりしない。コンセプトを変えるならワークショップは別仕立てにする。
• その上で、アレンジして作る新しいワークショップのコンセプトを設定する。このコンセプトは、ワークショップの受講者が体験後に何を得て欲しいかを言葉で表現する。ワークショップであるからhow toや受講者を変えるきっかけ、気づきになっていなければならない。
• コンセプトを作り上げるとき、対象とする受講セグメントや背景を考えるが、受講者全員を救うことはしない。タイムボックスで進めるセッションをやっていれば否が応でも次のセッションのワークに移動させるので問題ない。ただし、手が止まるセッションは予め想定しておき、受講者の手が止まっているセッションでは講演者が巡回してヒントを出すのか、手が動いている他の受講者を見学に行かせるなどのフォローを用意しておく。

セッション構造

• セッション構造では、ワークショップを構成するワークを具体的にイメージアップする。いくつかのセッションを体験し終わるとワークショップも終わり、何かしらの知識、経験、を得られる構造をとる。前説、ワーク1、2…ふりかえり（内省）にすることが多い。
• ワーク1、2といくつかのワークを続ける際に、流れてしまわないように場面転換、引っ掛かりのワークを間に挟むと良い。例えば、エンジニアの価値観について書き出した後、価値観を他者のものと入れ替えたらどうなるか、などを考えてもらう。
• セッション構造ではそのセッションごとに頭をひねって得られるものが必要で、それはセッションのワークになってはいけない。それでは単に作業をしただけになってしまう。
• セッションごとに何をするかをイメージアップする。ワークショップなのでファシリテーションも必要になるから、ワークショップの台本を半ば作りながら具体的にしていく。ここでモヤモヤしたままにするとあとでやり直しになるので理解しきること。

ウォークスルー

• セッション構造をプロットできたら、このワークショップの目的を達成できているかウォークスルーする。構造が流れてしまわないように引っかかり、場面転換性を持っているかも検査する。
• 全体を通して、大元になっているワークショップのコンセプトからずれていないかも確認する。
• 想定する受講者が狙い通りにお土産を持って帰れなければワークショップを作っている講演者も受講者も時間を無駄にするだけである。

ポストイット イーゼルパッド 方眼入り 762×634mm 30枚x2冊セット EASEL 560

ポスト・イット 強粘着ノート キャビネットパック リオデジャネイロコレクション 76×76mm 70枚×24個 654-24SSAU-CP

ぺんてる サインペン 5本パック XS520AD5 黒

やがて稼働率は開発部門を弱体化する

昔話になるがある部門のマネージャをしていたとき、引き合いが旺盛でプロジェクトを安心して任せられるだけのリソースを使い切っているつもりだったことがあった。とは言え、管理部門から見ればプロジェクトにアサインされていないメンバがいたのでなんとかしろと言ってくる。そんな都合よく案件がくるわけがないのだが、（後になっては地雷だった）案件がやってきた。この案件は、二度と繰り返したくない経験になるのだがここでは割愛する。

業務を行う上で組織には、組織という単位になるからだが、slack、つまり伸び代を持っておかなければ新しいビジネスを考えることもできないし、技術を追うこともできない。何せない袖はふれないのだから、恒常的にリソースをひねり出すことが出来ない。

それを加速するのが稼働率である。

一度稼働率を導入してしまうとエンジニアの持つ技術と案件の必要とするスキルセットの適合を鑑みることなく無理に投入しようとする。数値管理をしている側はそんな個別案件の事情は関心がない。稼働率という数字だけに関心を持つ。御構い無しに上から掛かる圧にリスクを識別し、リスクテイクをできるかどうか見極められないマネージャは流されるかリスクを見誤って手を出してしまう。上から見れば挑戦しているように見えるから受けはいい。ただ、現場の足元はバチバチと火の粉が上がり始める。

個人的には稼働率は宜しくないと思っているが、ビジネス感覚、つまりエンジニアを抱えていられるだけの案件をやらなければそのエンジニア自身を他所の本来専門でないスキルで働くことになることを気づかせるためには必要な数字ではある。

稼働率を放置、つまり管理部門に制限なしで手渡してしまうと際限なく上げようとするのは昨対での売り上げ、利益を積むことが仕事になるからである。稼働率は率だから、何らかの意思決定をサポートする指標でしかないはずなところを稼働率をあげることを仕事にしてしまうのである。

稼働率を悪魔の道具として使うのは本来の使い方を知らないからだ。考えれば、案件への直接作業と間接作業（教育、年休、組織活動など）があるから稼働率はどう計算しても70−80％などのあたりの数字が上限になるはずである。場合によってはもう少し低いかもしれない。つまり、組織全体の上限はやる前から決まっているわけだ。

目的と手段を取り違えていると誰かがバッサリと切らなければならないが、当事者である開発部門のマネージャは右肩上がりで成長を要求されるプレッシャや引き合いから鼻から考えないのである。

何が起きるかと言えば、短期的な収益改善には寄与するが長期の観点では高い稼働率を維持すると開発部門は静かに蝕まれる。余裕を自ら削るのだからじわじわと技術力は消耗し、新しいおもちゃの技術を扱えないエンジニアは離れていくのである。

それが今のあなたがいる組織である。

やがて君になる(6) (電撃コミックスNEXT)

成長が停滞している中堅エンジニアに手を差し出せるマネージャになるために

目標管理での業績評価を伝えたり、目標設定でのスキルの育成計画の元となる評価を話すとき、キャリアが滞留しているエンジニアに一つの特徴がある。

エンジニアに必要なスキルは2つに分けられる。1つは基礎スキルで業務を推進する能力やリーダシップのようなエンジニアの行動様式を構成するスキルだ。もう1つは技術スキルで方法論や適用する技術そのものを習得したり適用するスキルになる。

目標管理でもOKRでもエンジニアのスキルの成長のための目標を設定する際に大事なことの1つに現状を客観的に観察できるか、というポイントがある。現状認識をあるがままに捉えられるかどうか、これを過小でも過大でも甘く捉えてしまうと設定する目標の位置を間違えてしまう。

目標設定を低くしてしまえば容易に目標達成となるため、成長ののりしろはほとんど得られない。目標を達成するために掛けた期間が無駄になってしまう。方やとても高く目標を設定してしまうと未達となり、自信を失うきっかけになる。

キャリアが停滞、例えば40代くらいの中堅エンジニアで管理職の職位に上がれず止まっている場合の1つの理由に持ち合わせているスキルを客観的に評価できていない事象をまま見かける。

会話をしてその理由を探ってみると、その原因がなんとなくわかってくる。スキルの評価で説明を求めると『私、できますよ』と言うのである。でもエビデンスを求めると出てこない。例えば、『論理的思考スキルを業務で活用し業務課題を設定した』と言う目標を設定すると『本を読んだ』『論理的思考を活用した』くらいしか申告しない上、エビデンスはないのである。

これは自己肯定感ではなく、現状認識、あるがままの自分を受けれる能力が弱いのかもしれないと思うようになった。今の状態を今の自分として『そんなものだ』と受け入れられず、現状のスキルをありたいスキルにバイアスを掛けて自己評価をしているように見える。

これは自己肯定感というよりは、それ以前のあるがままの自分を受け入れられるかどうかと言う『自己受容力（自己受容という言葉があることにこのエントリを書いている途中で調べて知った）』の成長が未熟なのだろう。

マネージャをしているとエンジニアは成長するものだと無意識に思い込みをしてしまうが、成長が停滞しているエンジニアに対して一律で目標設定をしても期待する成長は得られないことを知っておくと、別のアプローチを見つけられるかもしれない。

セノビック 成長期応援飲料 ミルクココア味 224g(約28杯分) ロート製薬公式

成長痛 (moment)

世界線を見誤るとアジャイル開発は上手くいかない

エンジニアになった（就職したの意）ときから、唯一メンタルモデルの元上司のプロジェクトにjoinするまではプロジェクトマネジメントという概念、知識は持っていなかった。プロジェクトマネジメントの知識（当時はPMBOK初版）は翻訳本を手に入れられたが、システム開発手法については案件ごとのPMのやり方についていくだけで知識としては持ち合わせていなかった。

システム開発手法、つまりウォーターフォールをまとまった知識として得られたのは大規模な金融システムのプロジェクトに参画し、プロジェクト内の今で言うPMOにアサイメントされたときだった。その経験により割ときっちりしたウォーターフォールでのシステム開発の形式知と実践知を手に入れた。

マネージャになり、ウォーターフォールでのシステム開発を任せていたプロジェクトで担当PMの推進に問題があり、立て直しにあまり介入することなく（介入をゼロにはできない。立て直しで手を出すので）、つまり、主体性は担当PMに残したまま立て直す手段を探していて見つけたのがスクラムやカンバンのアジャイル開発であった。このプロジェクトはかれこれ10年くらい前のことである。

ここまでは前振りというか背景的な前説である。

プロジェクト、それはSIerとしてのシステム開発でも良いし、サービサーのプロダクト開発でも構わない。そのプロジェクトは基本的にプロジェクトとして別々の世界線を持っている。PMBOKのプロジェクトの定義を記憶していればわかるだろう。わからない人はPMBOKを読むか、過去のエントリでの説明を読んで欲しい。

要は、プロジェクトは唯一無二である。

である（PMIもPMBOKでそう定義している）から、世界線が交わることはない。独立した世界を持ち、いつか、その世界は終わる（プロジェクトの成否に関わらず終わる）。維持管理フェーズはプロジェクトと呼ばない（期限性の性質を持つのがプロジェクトであるため）。

そうした違うものたちを敢えて分けるとすると、

1. 開発物を契約に基づいてシステム開発をシステムオーナとシステム開発をするチームに役割を厳密に分離してシステムを作る
2. 開発物をシステムオーナとシステム開発チームが一緒になって作り上げる

の２つに分けるとする。言い換えれば、システム開発チームがシステムオーナ部門内か外かの種類に分ける考え方をする、ということであり、そこで線引きするかしないかということでもある。

これはプロジェクトの世界線は唯一無二というばかりではなく、それ以前にプロジェクトに厳密な役割分担の線引きをするしないという性質を持たせる。

ここまでを（自分のために）整理すると

• プロジェクトに線引きの性質を持っている
• プロジェクトは、唯一無二の性質を持っている

という前提を持つ。

その前提の上で、個々のプロジェクトでシステム開発手法は、プロジェクトの特性（リリースに対するビジネス要求、QCDへの要求などビジネスサイドで実現したい業務課題）を判断する。

見方を変えれば、別世界のプロジェクト（事案）は個々の都合で開発のお作法を選択しているであるから、個々の道具だけを並べて議論することに意味はない。

プロジェクトマネジメントの形式知の導入（実践知は除く）から入り、システム開発手法に関する知識を後に導入したPMの知見で言えば、トッププライオリティは役割であるシステムを実現したい方法で終わらせるということだけである。これは、道具は何でも良いから、ビジネスオーナのやりたいことを実現しよう、ということだ。

同じようにビジネスオーナサイドの立場で言えば、なんでもいいから業務課題を解決する方法で実現してくれ、である。

この両者には手段であるシステム開発手法についてはプライオリティは低い。フォーカスしているのは業務課題の解決（かそれを代行して実現すること）である。

アジャイル開発の知識を取り入れ、カンファレンスで講演が議論を聞いたときに思ったことは、それで自分の解決したいことが実現できるかどうかを知りたい（それはやってみないとわからないのでやり方の見通しに必要な道具と使い方の知識をどこでどれだけ手に入れればいいのか）のであって、道具の優劣の話なんて興味がないんだよ、ということであった。

そのときの感覚は、プロジェクトの世界線が違うことに由来しているからだ、と自分なりに紐づけられると割とすんなり受け入れらるのであった。

もしウォーターフォールで上手くいかない、アジャイルを組織に導入できないという事象に落ち入ったら、それはその前のプロジェクトの性質を見誤り、世界線を間違えているということかもしれない、と今の世界線を疑わなければいけない。

終わりと始まりのプロローグ

先輩と見積とシフォンケーキ

私の担当しているプロジェクトチームでメンバにさせた工数見積もりが思っていた以上の規模で頭を抱えていた。思っていた以上といっても２倍にもなったら頑張ってやってと言うようなレベルじゃない。少しぐらいなら何かのために取っておいた予備の工数で吸収すればいいかと目論んでいたが２倍は無理だ。

そう思いながらリニューアルされたフロアを横切ってソファに座ったら横にいたのが先輩だった。最近は先輩のプロジェクトに呼ばれることが少なくなった。最近話していないな、思ったのが通じたのかどうか、先輩が私に話しかけてきた。そんな私の心情を避けるように当たり障りのない話でお茶を濁そうとした。

「先輩、最近はまっていることなんですか」
「うーん、そうだな。スイーツ作りかな」
「え、先輩料理作れるんですか」
「スイーツ作りは料理か。まあ、料理か。製菓だからいいか」
「それでどんなスイーツ作るんですか。って言うか、食べたいですっ」
「シフォンケーキとかクリームあんみつとか。あとベルギーワッフルとか」
「しふぉんけいぇきぃー…わっふるぅってどんだけ女子ですか。女子だって作らないですよ。来週はバレンタインでチョコどうしようか、どこのチョコレート専門店で奮発して買おうかって悩んでいる女子に向かってしふぉんけいぇきぃですって」
「声でがいな。面白んだよ。お菓子作りはさ。パラメータをいじってチューニングする感じ。シフォンケーキってさ。西洋菓子で計量をきちんとやらないとダメなのはみんなそうなんだけどさ」

なんだこの先輩は。こんな一面を持っていたなんて。ただ一緒にプロジェクトで仕事を何回かしただけじゃ仕事の面しか知ることはできないんだ。もっと一緒に仕事をして色々と教えて欲しいな。

いやいや、今はお菓子作りの話。

楽しそうに話してる。好きなんだね、ものづくり。さすがプロマネだもんね、先輩は。

PCの画面を見始めた。仕事するのかな。邪魔しちゃったかなと思って自分のPCを開いたタイミングで『まあ大丈夫か』と先輩が独り言なのか話しかけてきたのか判別のつかない大きなつぶやきをした後、私の方を向いている視線を感じる。

はっとして『ど、どうかしたんですか』と声を吃らせながらリアクションをすると『ご飯を食べに行こう』と強引に誘ってきた。一応、女性なんですよ、予定が空いているかを確かめてから誘って欲しいものです。この辺は相変わらずだ。

「それで」
「何がですか、先輩」
「悩んでいるんだろう」
「う…なんでわかったんですか。悩みがあるって」
「顔を見ればわかるよ。知らない子じゃないからさ」

意識のない罪とはこう言うものなのかもしれない。つい悩みを話し始めてしまう私がいる。

「見積をさせたんです。そうしたら」
「３倍になった、そうか２倍か。そうなんだろう」
「なんでわかるんですか。覗いていたんですか」
「メンバに丸投げしたんだろう、見積。だいたいそうなるよ」

何か法則でもあるのだろうか。それで見積をどうしたいのかと質問をされる。見積をどうしたいかって、それは半分になったらいいと思うけど、今が2倍だからそう簡単にいく話じゃないこともわかっている。わかっていますよ。だって自分がメンバだったら危なっかしくてバッファを持っておかないと。工数よりは作業日の方が大事かな。あれ、私は何を考えているだ。

運ばれてくるアラカルトの料理を目の前にして無意識にかぼちゃとクリームチーズとベリーのコロッケを口に運びながら午後のミーティングのことから彼方此方と頭の中をヘラで混ぜていた。

「叶わないですね、先輩には。そうなんです。メンバに見積をさせたら2倍になったんですよ。メンバによっては3倍です。それを思っていた予算に収めるのは無理で」
「よかったじゃん。2倍じゃないかとか3倍掛かるだろうってメンバは『自分の』考えを言ってくれているんだろう。いいチームになっているじゃん」
「あ、そうですか。そんなことを言われるとは思っていなかったから不意をつかれたと言うか嬉しいと言うか。え、いいチームですか。見積2倍になっちゃったんですよ」
「それは後輩ちゃんに見えている事象じゃん。メンバは後輩ちゃんから頼まれたことをちゃんとやっているじゃないか。メンバそれぞれの持っている情報を背景に」
「でも」
「メンバがさ、後輩ちゃんはどう見積もったのかとか、それでいいとか言われたらどうする。見積もれませんと言ってきたらどうする。いい加減な、適当に見積もってきたらどうする」
「え、流石にそんなことはないかと」
「長くこの業界にいるとさ、キミが思いもしない経験をすることもあるんだよ。

それよりこのストロベリーティのシフォンケーキ、美味しい。そうか、アールグレイティの茶葉を変えればいいのか分量も同じでいいだろうな。ホイップクリームもほとんど甘さがないけどシフォンケーキを甘さで邪魔しないようにしているんだな」

先輩のスイーツ作りはどうやら本物のようだ。ストロベリーティのシフォンケーキを作るつもりでいるのか、ブツブツとレシピめいた呪文を言い始めた。しかし、先輩の感想と同じにこのシフォンケーキは美味しい。少ししっとり目で、でもちゃんと弾力があり若干モチモチ感も備えている。ホイップクリームはよく見ると柔らかめかもしれない。甘さは控えめで甘めのシフォンケーキによく合う。

美味しい。

いや、このシフォンケーキを食べて再現しようとしている先輩もおかしい。

「ところでさ、どうして3倍なのか、2倍なのか聞いてみたかい」
「いえ、まだです。」
「じゃあ、聞いてごらん。勉強になるから」
「それはそうかもしれませんが」
「多分、後輩ちゃんが思っている勉強とは違うかな。立場で見積もるときの粒度と範囲が違うことを勉強できるんだよ」
「立場でとは」
「メンバは後輩ちゃんのお願いを健気に、でも実現可能とするための工数見積をしてくれてるんだよ。後輩ちゃんの依頼から考えられることを見えている範囲で。現時点で見えていないところは経験知上から紐付けて補って。仕様を実現する方法はいくらでもあるけど、そのプロジェクトに組み合わせて実現できる方法を選んでいる筈だと思うけどさ。後輩ちゃんは、メンバがどう実現しようとしているかを聞かなくちゃいけない」

先輩はフォークで切り分けながら、シフォンケーキを焼くための素材やその配分（リソース）、手順（工程）や作るときの条件で出来上がりに違いが出ることを懇々と語り始めた。

相当、シフォンケーキ作りにはまっているようだ。

わかったことは、シフォンケーキ作りも私のプロジェクトの見積もその組み和合わせでやってみないとどんな仕上がりになるかは熟練するまでは確信が持てないと言う共通項があると言うことだ。

シフォンケーキをしっとりとさせるのは油（多分、エクストラバージンのオリーブオイルだろうと言っていた）の分量で変わるらしい。それを何dlにするかは作り手の好みだが、その好みを実現するためにもどのような分量をどうのような組み合わせでチューニングしていくかそこを明確に計量して記録しておかないと見積もりにならないのだと。

パール金属 テフロンセレクト加工 シフォン・デコ ケーキ 焼型 18cm 兼用タイプ 【日本製】 D-1500

タニタ はかり スケール 料理 洗える 2kg 0.1g レッド KJ-212 RD

IZUMI ハンドミキサー ピンク HM-410P

タイガークラウン ケーキフード 〈深型〉 カバーのみ メタクリル樹脂 日本 PKC19100

貝印 Kai House Select 耐熱プラスティック製で使いやすい 計量カップ 200ml DL-6316

Ejoyous計量カップ＆スプーンセット 計量カップ 計量スプーン 大さじ 小さじ ステンレス製 10点セット 台所液体/顆粒適用 シリコーンハンドル

パール金属 ステンレス ボール 3点 セット 16 18 22cm ララシャイン H-5371

ダメ評価をされていた若手エンジニアを引き取った話

結果的には、件の若手エンジニアは自分の進む道を自分で見つけ、旅立った。送り出したマネージャの立場でいえば、もう少し技術を身につけてからと思わなくもないが、今のプロジェクトだと制約があるので若手エンジニアの判断はよかったと思っている。

ある年の年度始めに増員のリクエストを出したらスキルの合うエンジニアはいないと言う。需要の旺盛な時期で（今もそうだが）気長に待つしかないな、と腹は括っていた。プロジェクトの特性上、プロジェクトで知り得た情報を漏らすことはできないし、プロジェクトのステークホルダになる関係者の役職レベルもあり、採用する要員の席は制限された（と言うよりはこちらから条件として出していた）。

こちらからは顔を思い出す要員を適当にあげてリクエストするも、ことごとく却下される。そんなことはわかっていても要求はしなければ要求にならない。

少し経って、若手エンジニアがいると吉報が入った。

『若手エンジニアがいるんだけど、ちょっと…』

とネガティブな文章が続いていた。

これまで何十人もの部下を持ってきた経験から言えば、部下（か年下のエンジニア）をネガティブに評価している時は、その評価自体に注意が必要だと思っている。

何かと言えば、マネージャがエンジニアの特性を把握できておらず、フィットする仕事にアサイメントできていないケースがまま見られることだ。目の前にやらないといけない（とそのマネージャは思っている）案件に適用する技術、必要とする技術レベルにフットしないエンジニアを当てはめ、フォローもせずにできないやつだと悪評をつける。

そういったケースを知っていると、お前の評価はどこまでフォローした上での評価なのかと疑ってかかる。実際、エンジニアが『できない』エンジニアと言うケースもあるだろうし、エンジニアに向いていないケースもある。であれば、エンジニアの職種から別の職種に移すことを考えればいいはずである。リソースを使えないと言うマネージャはマネージャが使えないのである。

条件は、プロジェクトの特性の一部でも適合する技術を持っていることと所属の席の制限である。後者はクリアするが前者がかなり物足らない。

デリバリのプロジェクトでメンバが多ければチームとしてのスキルセットを満たすことを見切れれば引き取っただろう。

では当時の判断は。

そのダメ評価の若手エンジニアを引き取ることにした。かなり、忠告めいたことを言われた。アイツはどうのこうのという。親切心で情報提供をしているつもりなのだろうが、こちらとしてはそのダメ評価のエンジニアを『１から育てる』つもりで引き取っているのである。

少なくとも自分の部下でいる限り、放置したり、無下に扱うことはしない。リソースとして活かすのが仕事なのだから。

実際、仕事をしてみると若手エンジニアから中堅に差し掛かる経験年数には見合わない技術レベル（低い方という意味）であることを実感した。

多分、これまでアルバイトのように、細切れに、都合よく、急かして、やっつけで仕事をしてきたのだろう。そう思わないと理解しづらい技術レベルであった。

どうしたか。

プロジェクトの仕事は自分が付きっ切りでサポートすることにした。この他に、基礎的な技術スキルを身に着けるためにプロ級のエンジニアに指示して、マンツーマンのハンズオン的な技術習得をさせた。中堅のプロマネ資格をもつエンジニアにプロジェクトでの自分の作業管理の基礎を身につけられるように時間を確保させた。

少しずつ、できる仕事が増えてくると自信を持つようになった。やることを自分から説明できるようになってきた。ゆっくりだが歩き始めたのである。

まあ、あと1年もすればそこそこのエンジニアとして基礎の基礎くらいはキャッチアップできただろう。

そう思っていた頃、若手エンジニア自身の事情で休みを取ることになり、最終的には去ることを本人の希望として決めた、と連絡があった。

その連絡を受けたとき、若手エンジニア自身の事情と付き合っていける新しい道を探せたのだな、と思った。

一緒に働いた年月は新しい道を探すためのサポートになっていたのだったとしたら、マネージャとしての役割を果たせたのかもしれない。

それは若手エンジニアが選んだ新しい道での活躍が証明してくれるだろう。

エンジニアになりたい君へ 理工系学生のためのキャリア形成ガイドブック

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

調達 東芝 LED電球 一般電球形 485lm（電球色相当）TOSHIBA T形 全方向タイプ LDT5L-G/S/40W-TC

 トイレの電球が切れたので交換。T型を試してみよう。

東芝 LED電球 一般電球形 485lm（電球色相当）TOSHIBA T形 全方向タイプ LDT5L-G/S/40W-TC