エンジニアは孤独か

HBR6月号のメイン記事である。サブタイトルに

WORK AND
THE LONELINESS
EPIDEMIC

成人の4割が自覚し、寿命を縮める病

「職場の孤独」という伝染病

 とある。

ダイヤモンドハーバードビジネスレビュー 2018年 06 月号 [雑誌] (職場の孤独 企業に広がる“病"にどう対処するか)

リードの文章では、即刻この状況をに対して対策を取らなければならないらしい。

孤独については「はっ、何言っているの」と頭を過ったのがファーストインプレッションである。大人って一人遊びができるから大人なんでしょ、と思っていたから。

もちろん、仕事においても意思決定して仕事を終わらすのは一人でではないのか。

個人的な考えは一旦棚に上げて、エンジニアの仕事と孤独はどうだろう、と。ちょっと、そんなことを思った。

ひとり作業

 そう言えば、エンジニアが一人でやる作業はどうして存在するのか。

専門性を持ったエンジニアと専門性を持ったから故の分業体制が起因となっている。こうした形態は、システム開発だけの特有の事象ではなく、工芸や建築でも同じように専門性を持った職業となっている場合に見られる。

システム開発で言えば、成果物を作成する作業を専門性をもつエンジニアにアサイメントする仕事の仕方がひとり作業を形作ることになる。

一人の作業

 そうするとエンジニアに作業分担する作業が全てかというとそうでもない。設計書を書く仕事は書く、修正するは一人で行うが、作業自体の完了の定義や進捗の共有、仕様の調整、設計書のレビューは共同作業である。

孤独を感じる作業

 エンジニアの作業でいえば、成果物を作成する作業がひとり作業なので、外形的には一人の作業として挙げた作業をする場合に孤独を感じると考えられる。

ただ、あくまでも外形的に、である。

成果物を作成する際にはエンジニアが持つ技術や理解力及び思考を総動員することになる。ここで自分のエンジニアとしての力量に向き合うことになる。

難易度の低い作業であれば持つ合わせる力量で賄えるため心理的な不安を覚えることはない。ところが、未経験の技術レベルを要する作業では試行錯誤をしつつ、自己の能力を伸ばしながら作業を進めなければならない。

ここで自己と向き合うことになり、孤独を感じるのだろう。

孤独にしない作業方法

 複数のエンジニアが同時に1つの作業を行う形態で仕事をすればエンジニアが孤独を感じる機会を減らすことが可能なはずだ。

そうした方法を挙げるとすればペアプロかモブだろう。

ペアプロは二人で行うからペアとなるエンジニアとの相性が影響を及ぼす。比較対象としてしまうと自分の力量に跳ね返り、孤独を感じてしまうかもしれない。

その点、モブの方が入れ替わり立ち替わり作業を行うため、多くのエンジニアから学ぶ方が多くなり、比較する対象が薄れる。

どちらの場合でも自分と比較するのは自分であることがわかっていないと技術レベルの較差を孤独に結びつけやすい。

システム開発は無形であるがためにエンジニアの作業を孤独にさせにくい方法をとる手段があることは幸いなのかもしれない。

エクストリームプログラミング

ペアプログラミング―エンジニアとしての指南書

小さなチームは新しいことに挑戦しやすく、大きなチームでは新しい試みに手がつかない理由

小さなチームでは新しい技術や生産性向上ツールの置き換えの検討などを挑戦しやすく、大きなチームではリソースの観点で言えば潤沢にありそうなイメージを持つので小さなチームよりはより多く機会があるように思えるが、現実はそうならない。

返って、小さなチームの方が新しいことに挑戦していた経験がある。

その小さなチームとは、4−5人のチームをイメージしてくれれば良く、大きなチームは10人以上のチームをイメージしてくれれば良いが、一層のこと、極端に300人くらいのチームを想像してくれた方がイメージしやすいかもしれない（経験していないと返って300人のエンジニアのチームは難しいか）。

小さいなチームの特徴

小さなチームなのでプロジェクトマネージャは、エンジニアを兼ねているプレイングマネージャの方が多い。

小さなチームばかりプロマネをしていると、体系的なプロジェクトマネジメントを経験的に学ぶ機会はゼロに等しい。経験ベースだと経験したこと以外を身につけられない。身についていないことは視界に入らないし、視界に入らないことは関心を持たないので形式知の対象とならない。

エンジニアの数が少ない（小さいチームだからね）のでエンジニアの性能（能力）がチームへ与えるインパクトが半端ない。5人のチームで1名の能力がチーム平均を１としたときに0.5だとチーム全体の性能は10％ダウンを前提に全てを計画しなければならない。言い換えれば、作業計画時から計画工数の10％の残業が前提としなければならなくなる。

小さなチームであるため、生産性向上のチームへ与えるインパクトは絶大になる。そうした背景から新しい試みに挑戦する文化が作りやすい。ただし、適用できるかどうかの見切りは早い段階でできないと納期を守れなくなることから従来の方法へピボットするタイミングが早い。

人数が少ないので専門技術だけではチームの作業が賄えないことから、（必要に迫られて） マルチスキル化しやすい。そのため、エンジニアの価値が（技術の幅として）上がりやすい。

同じように、人数が少ないのでロールとしての階層構造はほぼフラットになる。そのため、プロマネの仕事が視界に入りやすく、見様見真似で覚えられるし、プロマネによってはプロマネ業を委譲するタイプだと経験が少ないエンジニアでも早くから体験できる機会が得られる。

大きなチームの特徴

10人もいればプロジェクトマネージャは専任でなければやっていけない。そのくらいプロマネ業の作業ボリュームはある。

10人のチームともなれば、プロジェクトマネジメント を顧客が要求する案件であることが多く、体系的なプロジェクトの運営のスキルを必要とする。

人数が多いとチーム全体での作業の統一化、作業品質の確保にパワーがシフトしてしまうため、成功体験をチームの中にインプリする傾向となる。

結果的に統制を取るための活動に注力することになるため、新しい試み、例えば生産性向上のためのツールの置き換えは起きにくくなる。

10人以上ともなればメンバの平均的な性能は1に近く。近くが、低性能のエンジニアの混入率も上がる。

人数が増えると意思伝達の経路の組み合わせが多くなり、チーム内での情報共有に格差が生じやすい。

総じて、受け身のエンジニアが混在する率が高まり、他のメンバからの情報提供に寄生するエンジニアを産みやすいため、チーム文化としての対策（発進と自分から取りに行く）を強要する文化に陥りやすい。

 ロールの階層化、技術の分業化が進む（プロマネが一人二役を推進しなければ）ため、単機能工としての担当エンジニアでいることが可能となる。

しかし、そこで楽をしていると他で使えないエンジニアになる。

劇場版「Fate/stay night [Heaven's Feel] I.presage flower」(完全生産限定版) [Blu-ray]

技術発表のスライドの構成の意図がやっと理解された話

エンジニアをしていると、技術成果を発表する機会があると思う。組織内でもいくつかの成果発表の場があり、そうした場への発表がエンジニアのキャリアデザイン上の加点になっている。

エンジニアがスライドを作る機会自体は多い。提案書、仕様検討、報告資料などプロジェクトで資料を作った数なんて数えてられないくらいに。

ではそうした資料の作り方をどこかで教わる機会があるかと言えば、実はない。論文を書いていれば指導教官や上司に赤ペン先生をしてもらうので指導された、と言えるのかもしれない。

ところがツールがWordからpowerpointに変わる途端、資料づくりは自由になる。最低限のフォーマットは（既存の資料のスライドデザインを踏襲するという意味合いで）似た構成になる。

例えば、表紙、目次、自己紹介、スライドテーマ、endページで構成されていることが多い。

メンバが成果発表をする機会があり、上記のような構成でスライドを作ってしまってからダメ出しにならないようにしようと思って摺り合わせの場を持ったのに、メンバに伝わらず回避しようとした構成でスライドの作成を進めてたことがわかった。

なぜわかったかというと、摺り合わせ後に、摺り合わせで合意した（はず）の構成で書けているか、全体の構成を確認するスケジュールを入れていたからだ。

まあ、見せてもらったら前回のすり合わせは何だったのかと思うくらいに上図の構成まんまだった。

スライドにありがちな問題

やってしまったことは仕方がない。構成をなぜ変えないといけないかを理解してもらうことが２回目の摺り合わせの目的となってしまったとしても。

上図の問題点は、3つある。

1. テーマ１から最後のテーマ５までを全部聞かないと何を言いたいのかメッセージが理解できない
2. 最後まで聞いているうちに最初のテーマを忘れてしまう
3. 一番いけないのはどこまで頑張って聞けばいいのか見通しがわからない

どれも話す側の立場に立つと拙い。スライドを理解してもらえないと発表の評価に響くし、肝心なことを覚えてもらわなければ発表する側の苦労も水の泡になるし、いつまで続くかわからないスライドを見せされることほど辛いものはない。

自己紹介

フォーマットとして自己紹介のページを入れていることが多いが、無意識で入れていないだろうか。

自己紹介はこれから発表するテーマについて専門性をアピールする最初の掴みである。専門性をアピールすることで発表に対する聴講者に期待を持たせることができる。さらに、ここで笑いを取れれば緊張感から解放されて発表しやすくなるだろう。

自己紹介と乾杯の挨拶は短く、要約しよう。

伝える相手は誰か

 聞いてもらう対象のセグメントを設定することは大事なことだ。想定する聴講者に響くように、つまり、聴いてもらい伝えたかったことを伝えなければならないからだ。

スライドを作っている目的がそれであるのだから。

同じエンジニアに聴いてもらうのか、年代はどうするのか。技術レベルはどのレベルか。それをスライドを作る前に決める必要がある。これをせずにスライド作りを進めてしまうと総花的になってしまうのだ。

何を伝えるのか

このスライドで何を伝えたいか。このページがないままスライドを作ってはいけない（発表時に落としても構わない）。

なぜこのページが必要か。それはスライドを作るエンジニアがスライドを作っている間に自分が書きたいことを書き始めてしまうからだ。

案の定、２回目の摺り合わせで見せてもらったスライドはスライドを作って聞いてほしいことではなく、メンバが作りたいことばかりになっていた…。そうしないために摺り合わせをしたのだが、結局、理解されていなかった。

２回目の摺り合わせで最初に何度も尋ねたことがある。それは、このスライドで何を伝えるか、だ。「何を伝えたいのか」「今作っていたテーマはそれに合っているか」と何度も尋ねやっていることを理解させなければならない。

モデル

さて、聴講者のセグメントと伝えたいことを明確にしたのでスライド作りを始めていいかと言えばそうは問屋が卸さない。

この後、いくら伝えたいスライドを作るにしてもエンドのページまでずっと同じ調子でスライドが続いてしまうことはダメだ。

伝えたいことを概念化して体系化した形式知にしなければいけない。概念化することでモデルに置き換わる。

モデルは発表しようとするエンジニアが考えているエッセンスである。スライドの価値は、実はこのページだけ見れば良い。後に続くページは詳細の解説になるからだ。

端的に言えば、モデルのページ以降のサマリである。

ではなぜここの場所に必要なのか。それは聴講者を飽きさせず、迷子にさせないためである。言い換えればスライドに集中させるためのガイドの役割をするからだ。

アウトラインを使う

こうしたスライドの作り方は難しいと思うかもしれないが、ついついスライドを作っていると楽しくなって詳細なテーマばかりに手をかけてしまわないようにする方法がある。

それはアウトライン表示を使い、アウトラインから作れば良い。もし、アウトラインを書いているときに具体的にサンプルを見せたいとかキャプチャを入れたいと思いついたら、ノートに書き込んでおく。

とにかく、アウトラインを完成させよう。

 この２回目の摺り合わせの場でやっと１回目の摺り合わせの意図が理解された。あとはメンバに任せよう。

Microsoft Office 365 Solo (最新 1年更新版)|オンラインコード版|Win/Mac/iPad対応

調達 Princess Limited CD+DVD

Princess Limited

調達 20th Anniversary 田村ゆかり Love Live

20th Anniversary 田村ゆかり Love Live *Crescendo Carol* [Blu-ray]

 

あなたなら誰をトラブルプロジェクトへ推薦するか

仕事やソーシャルネットワークで人を紹介出来る、推薦されるという話題がほぼ同じタイミングで起きたのは自分としては面白いものだと思う。

紹介されることも推薦されることもどちらも意味合いでは同じことで、紹介しようとする対象の人を紹介される側から見ているか、紹介しようとしている側から見ているかの立場の違いでしかない。

知り合いのある方は自分から見ればとても交友関係が広く、エンジニアとして仕事も出来る方だと認識している。実際に同じ仕事をしたわけではないが、考え方やときどき公開するスライドは平易でシンプルな表現なのに要所を適切に解説しているのだ。

先だって、その方を含めて会合があったときにポツポツと近況を話し始めて、ある案件に知り合い中でその案件に合う凄腕のエンジニアを数人紹介した、と言っていた。一層のこと、手数料貰えばいいのになんて言ったら、あなたも紹介したよ、と。さらにその案件は割と界隈では有名で、トラブっているのであなた（自分のこと）が適任でしょう、と。

上述したとおり、この知り合いの方から見て自分の仕事ぶりはわからないはずだが、これまでの付き合いの中でのスライドやポートフォリオ的な作品からプロジェクトへの思想やチームビルディング、プロジェクトの立て直しなどのアプローチを聞いて判断しているのだろう。

本人にどういった観点で紹介したのかは聞いていないので推測の域を出るものではないが、自分がその方なら一緒に仕事をしてもいいと思うくらいだから、あるところでは同じ価値観を持っていると判断したのかと思う。

話は変わって。

あるときに推薦状をいただく必要となって誰に頼もうかと思案したことがあった。勿論、碌に知らない方へ推薦状をお願いする訳にはいかない。第一、推薦をする方だってそんなことは出来やしない。

こうしたことは割と悩むものだ。何を悩むかと言えば、推薦状をお願いする人選とそれを断られたら、というもの。

特に後者については断られたらと思い始めるとどうも不安になって仕方がない。そんなことを不安に思っても誰かに推薦状を書いてもらわないといけないことは変わらないし、さっさとお願いをしてしまうことでそのあとの対応をあらかじめ考えていた方が良いのはわかっているのことなのだが。

そのときは好意的に推薦状を頂けることになったので次善の策を考える必要は無くなったのだが、こうしたことも

「最悪の事態を想定しつつ、楽観的に構える」

という西住みほの言葉は理に叶っているのだ。

まあ、彼女のセリフの10年も前からプロマネをしているときは同じ心境でプロジェクトを見ていたし、多分に性格に依存しているところもあるので変わるものでもなさそうだが。

しかしあれだ、トラブルプロジェクトよりは綺麗なプロジェクトを綺麗なまま（水面下では足を漕ぐにせよ）したいものだ。

ガールズ＆パンツァー 最終章 第1話（レンタル版）

最高でないマネージャの習慣

この、googleの最高のマネージャの8つの習慣ってネタのエントリを見たの、何度目だろうという気がするのだが。

じゃあ、放置すればいいじゃないと思わないこともないのだが、あーこれ自分は成れんなと思ったので最高でない、アンチパターン的なマネージャとしての自分を分析してみよう。自分は素材だからな。

lightworks-blog.com

習慣1　よいコーチであれ。

具体的で、建設的なフィードバックをする。
ネガティブフィードバックとポジティブフィードバックをバランスよく行う。
定期的に1対1の対話をし、部下の強みに合わせた問題の解決方法を示す。

引用　全て上記サイトから。

 良いコーチの良いとはなんだ。詳細を読まなければわからんな。曖昧で非建設的な指摘をするマネージャだと最高でないのだろう。

確かに。

でもな、具体的過ぎるとマイクロマネジメントぽくならないか。具体的過ぎるとメンバの仕事を実質やっていることにならないか。

曖昧であることはダメなのはわかる。多分、基準を示せばいいのもわかるが。

ネガティブフィードバックをバランスよくする必要はあるのか。特徴なんだろう、その性質はメンバの。ネガティブフィードバックをするとしたら、業務に支障する勤怠上の問題とか他のメンバへの接し方とかそういったところか。後は、業績評価につながるところだな。

習慣2　部下に権限を委譲せよ。マイクロマネジメントはするな。

部下に自由を与える。同時に、よき相談相手になる。
チャレンジできるようにストレッチした課題を与える。

権限委譲するのは当然としても、メンバの立場になれば「いいですか」と聞いているだろう。なぜなら、やってから後でひっくり返されたくないからだ。

これは習慣1の具体的にと関連するのだろう。

身の回りのメンバを見ていると、具体的を持ってないのがメンバの方で、曖昧なまま進めようとするからあれこれ予防的に自分だったらこうするというのだが、それをやり過ぎるとやはりマイクロマネジメントに繋がるのだ。

良き相談相手とはなんだ。これをやりたいと思ったらやればいいじゃないか。どうせやるんだろう。だから、いいよと言うよ。ただ、あれこれ段取りとか関係者とかへの手配的なところまで気が回っていないから言うのだ。

チャレンジできるような課題。

それは目標設定のときに1年後に成長しているだろうメンバが自分で設定するものだ。それをやりたいと言わなければいけない。仕事は作るものだよ。

習慣3　部下の成功と幸せに関心を持て。

仕事以外も含めて部下を人間として知るようにする。
新人を温かく迎え入れて変化のストレスを減らす。

部下が成功して昇進していくのをサポートするのがマネージャの仕事だ。ただ、仕事だぞ。やりたい仕事を（結果的にはそうじゃなかったとしても）やりたいと言ってくれたらそれは幸せに繋がるのだろうからアサイメントや動機付けで配慮するのは当たり前だ。

ただ、仕事以外で部下を人間的に知る必要があるかといえば、それほどでもないだろう。仕事に影響するようなことはプライベートでも機微になり過ぎない程度で教えてくれないとアサイメントの配慮ができないから必要だが。

温かく迎え入れるのは新人ばかりではないだろう。居続けたいと思う場でなければ。

ただこれも、仕事の成果をしている限りという前提がつく。成果を出せない場は本人の性質がフィットして居ないのだから。

習慣4　くよくよするな。生産的で結果志向であれ。

チームに達成して欲しいこと、及び、どうすれば部下が達成できるかに集中する。
チームが優先順位を付けて働けるようにし、障害を取り除く意思決定をする。

くよくよする。自分のことは。想定している通りにならなかったらとかさ。わかっているのだ。持っている球は投げないと、と。

チームの目標達成は組織への貢献だから、それを全力でやらないとメンバの評価に繋がらない。だからこそのチームの目標でもある。

習慣5　よいコミュニケーターであれ。そしてチームの声を聞け。

コミュニケーションは双方向。聞くことと共有すること。
全員参加の会議と具体的なチームのゴール。
オープンな対話を督励し、部下の質問と関心に耳を傾ける。

コミュニケーションという言葉は、社会性を持ち過ぎていると思うし、言葉の意味以上にあれこれと吸収し過ぎている。都合で使うが、結局、チームの目標達成のためにやってほしいことをやっているかを知るためのコミュニケーションを取っていることに気づかなければならない。

習慣6　部下のキャリアについてサポートせよ。

メンバを昇進させるのが仕事だ。

自分より昇進したら、俺が育てたと内心思っているだけにする。

習慣7　明確なチームのビジョンと戦略を持て。

不安と動揺の中でもチームのゴールと戦略にフォーカスする。
ビジョン、ゴール、進め方の策定にチームを巻き込む。

これ習慣４にループしてるじゃないか。

習慣8　チームにアドバイスができるように技術的なスキルを磨け。

必要なときはチームと一緒になって働く。
仕事に関わる具体的なチャレンジを理解する。

マネージャは一人だ。メンバはN人だ。１対Nの関係でどこまで技術を追えってか。

概念はわからないと技術を適用するビジネスの良し悪しの判断ができないからな。それは必要だ。そこからビジネスに繋がるかどうかを見極めるのが仕事だから。

説明は習慣2に戻ってるな。リファクタリングが足らない。

果たして、こんなマネージャの下で働きたいエンジニアは今の部下もそうだけど、これをたまたま読んだエンジニアでいるのだろうか。

How Google Works(ハウ・グーグル・ワークス) 私たちの働き方とマネジメント (日経ビジネス人文庫)