調達 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(ハウ・グーグル・ワークス) 私たちの働き方とマネジメント (日経ビジネス人文庫)

エンジニアは事業の夢を語る

こじんまりとした団体がある。特定のジャンルで割と知られているエンジニアと一緒になって活動している。先日もその会合を開いて色々と話をする。

話の議題は前日に共有してあって、多分、出席者はそれを見ていただろう。仕事ではないから、当日に、その場で見て、理解してくれても構わない。そんな場である。

続いている企画があり、その続編というか次回の事前確認を行う。その他にも数点の議題を用意していた。ポツリポツリと定刻前に集まってくる。雑談をしつつ、説明し直す労力は大したことがないのと待っているのも何なので、会合をゆるりと始める。

一旦、予定していた議題毎にやりたかったことで合意した内容を記録しつつ、議題になかった話をした。

実は、こんなことを考えている、と。

活動している中で話題になったことはあったが実現したときのゴールはもっと身近なものだった。それを割と高みのゴールを考えていることを話した。

譫言ではなく、企画として要点を押さえ、中身がイメージアップできるまでの情報を持っている。

別にメンバに話す必要もなく、淡々と企画ができたら企画をぶつける相手に持っていき、進めてもよかった。

ただ、その企画のコアの部分、コンセプトは自分が創り上げたものだが、それを形にしていったのはメンバの知見であることもわかっている。それに独り占めしたい訳ではない。協同とした方がより良いものができることはこれまでの活動の中で得られた経験である。

そんなことまでは話はしないが、要点は巻き込むつもりだぞ、という宣言である。まあ、今まで散々巻き込んでいるので今更感はあったかもしれない。

ノリがいいが、きちんと各自のペースを持っているのでブレーキはそれぞれ踏めるメンバだ。

実現するかどうかは誰にもわからないが、投げる相手の目星もあり、専門家として教えを請う良い機会でもある。

これが始まったら、色々と私生活にも影響が出るだろう。半年は死ぬ思いをするかもしれない。

しかし、夢があるのだ。その企画も一発で終わりではない。その後がある。ある意味、その後がメインで、メインで使うための企画の捉え方の方が正しいかもしれない。

エンジニアは事業を作らなければならないと思っている。本業で実現するのが一番良いのだろうが、仕事がそうした事業創出に関わっているかどうかは別な話だ。

本業でなくても、事業として成立するかどうかはさておき、企画し、夢を語るのはエンジニアの領分なのだ。

リーン・スタートアップ

連休に自分が空っぽであることを知る

連休中にやることをポストイットに書き出したらそこそこの項目があったので気の向くままに手をつけたり、先方の都合に合わせたりしながら片付けた。

連休を終わって改めてそのポストイットを眺めると思った以上に家に関連することがあって、去年までとは違うな、とそう思った。

そう言えば、一つ前から実現したいことがあってそれを安価に実現できたのはまあまあよかった。これで夏場の作業が楽になりそうだ。ちょいと改善が必要だが。

じゃあ、PCに向かう時間が減ったのかというとそうでもなく、何割かの自分の連休中にやっておこうということもあったので仕事のある日までではないけれど、それなりにPCの画面で何かしていることがあることも無くせないのだなと。

その中でも前の区切りから3年が経ったのでその間に仕込んだことの企画を体系的に整理を始めたら思ったより自分の中が空っぽだったことがわかった。

何がどう空っぽだったかというと構成を組んで全体のボリュームを考えたときに構成の中身の標題がなかなか埋まらないのだ。これはどうにもし難い。埋まらないから、PCの前から離れて別のどうしようもないことをして、気になってまたPCの前に座って唸る。

池波正太郎は書けなくても毎日数ページでも書くんだよという意図のことを言っていたが、まさにそれで、何か文字を埋めないと全くもって真っ白のままだ。

ただ、構成を埋めていくとあれをしよう、こうしようと思うようになるのも又不思議な事で、どうしようかとか相応しくないとかそんなことが頭をよぎったとしても、それでも埋めていくのがいいのだと実感する。

それとは別に連休の冒頭にスライドを作り始めて、途中で切り口を変えてみたり、後半に参考画像を入れ込もうと用意しておいた画像を貼りつけながら肝心の参考画像がなくてどこに入れたか随分探したが一向に見つからない。

なくてもいいかと諦めて（無くても差し障りがないように構成して）、別の資料を探していたらひょんなところにそのファイルがあったのを見つけて戸惑う。

こういう体験をするとポートフォリオというか個人のリポジトリはどこかにまとめておくことをしておかないと散逸してしまい、必要なときに探せない。

話を戻して、埋められないままにぽっかり空いた領域は未だその状態だ。未だ白い箇所があるのにも関わらず、さらにその詳細をこんな風に建てつけしたいと仔細に走るのもやっぱり空っぽであるから楽しい方に自分からすり寄っているのかもしれない。

それとは別にその企画を覆うもう１枚のスライドというかエレベーターピッチ的な物を作っておきたいという気になって、それは近々に片付けておかなければ。

こんな連休の使い方をしていると、連休中に何してたと聞かれても、家に引きこもっていた、くらいしか言いようがないのだよねぇ。

システム工学 知識システム II 知識の創造と意思決定 (東京大学工学教程)

デスマと穀潰しエンジニア

なんだろうと思って読んみでみたら随分前に読んだ物のような気がするのだが、果たして記憶違いだろうか。

デスマーチが起きる理由 - ３つの指標 · GitHub

ちょうど、過去に作成したスライドを探していて見つけられず、諦めた後、ひょんなことからスライドを見つけられたのでそれをまじまじと眺め直してみた。

そのスライドは、冒頭でリンクを貼ったデスマを書いたものではないのだが、スライドに書いたプロジェクトも立て直しに入らずに、あのまま進行していたらです待っていたのかもしれない。少なくともあのプロマネは持たなかっただろう。

リンクの先のエントリの最後に書いていあるのはこれからの抜粋だと思うのだが、そりゃ色々とリソースが半減だったらデスマになるのはほぼ確実だろう。ほぼと書いたのは、見積もりが甘くて1.5倍以上の予算が確保できていれば、まあどんなプロジェクトでも収まるからだ。

世の中にはQCDSと言う考え方がある。個人的にはSはQの母体であるから不要だと思っているが、単にQで捉えていることが多いし、固執することでもないので（要は面倒で）Sを加えて話すようにしている。

そのQCDSがブレれば見積もりのパラメータが変わるのだから尋常でない事態が起きたことになる。QCDSの調整ができないのであれば、あとはデスマとはならなくても異常事態に陥るのは必須だ。

よくよく見直すと、Qは備えていなければならない要素だし、Cは実現に必要な費用だし、Dは約束可能であるかだし、Sは前提のようなものだ。

その裏にある、それら4つを支えるのは実現するリソースだが8割はエンジニアである。それもエンジニアがいればいいと言う次元では意味をなさない。必要とされる技量を持ったエンジニアという条件が付く。

スライドを眺めているとそのプロジェクトでもエンジニアをほぼ総取っ替えしていたということは、QCDSの以前の話でエンジニアの調達が間違っていたということだ。

ここでサンクコストを忘れてはいけない。やっとの思いで調達したエンジニアを切るのかと必ず言われるだろう。

でもそこで怯んではいけない。機能しないエンジニアはそのプロジェクトでは無能と同じで更に予算を食いつぶすだけの穀潰しエンジニアである。

その上での選択肢は2つある。

1. 穀潰しエンジニアを切る。
2. （素養を見極めた上で）育て、将来機能させる。

さてどちらを選ぶか。そレより、プロジェクトで機能しないエンジニアを調達するようなマネージャを切る選択肢が絶大な効果を得られるのだが。

必要なことを足して構成するアプローチの良し悪し

過日、こんなことを呟いた。

減らすのと、足すのどちらが簡単か。減らすためには目的を理解できなければ減らしていいかの判断がつかないし、知識がなければ足すことはできないし。

— ふみさん (@finayama) 2018年5月4日

これは、こんなことを考えていた。

facebookで

開発プロセスのテーラリングは、オーバーオールに体系化された項目から不要な項目を削除するよりは、本質として外せない最小限の体系に必要な項目を足す方が楽だ。

と言う考えを見かけたからだ。

それを読んで、そうかな、と感覚的にそんなことないよ、と思った。感覚的に反応するのもアレ（自分の思慮の浅さ）となってしまうのも自分自身に対して如何と言う感じなのと自分の考えの正誤を確かめたく、表に整理した。

 表の項目を分ける条件は次の項目である。1つは体系化された項目から削る、足すと言う振る舞い。もう一つはそれらとの組み合わせとなる別の軸である。

その軸を削る、足すは「何に基づいて」行われるのかと言う事前条件で組み合わせることにした。

この表の組み合わせからfacebookに書かれたことは、達成条件を理解できていると言う前提条件があるように思える。そうでなければ、達成条件を理解できているから足す方が楽だ、が選択肢にならない。

これが正しいと考えるのは、最大限の体系から不要と判断した項目を削除することも最小限の体系に必要とする項目を足すことも同じ結果を得られるからだ。

そこで、「達成条件を理解できないと」と真逆の条件のケースを作り、検証する。達成条件を理解できなと削るときに「不必要な項目を削除することが出来ない」となる。削ってしまっていいかどうか判断基準を誤って理解しているために起きる結果は不必要な項目を削除することが出来ないのである。

同様に達成条件を理解できないまま最小の体系に項目を足そうとすると達成条件を理解できていないため「必要な項目を足すことが出来ない」のである。

この結果でおやっと気づいたのは、達成条件を理解できる、理解できない方の項目の方がより重要な観点ではないかと言うことだ。この気づきを得られただけでも表を作って整理した甲斐があるというものだ。

元々のfacebookへの書き込みは「最小限の体系に足す方が楽だ」である。でもそれは最小限の体系を理解していることが前提である。さらに、追加で体系に項目（要素でもいい）を足すための経験若しくは知識としての知的体系が必要となる。それらのためには達成条件自体を理解できなければならず、これが一番効いてくる。

ところで、知らないことは知りようがないため、意思決定の際に知らないことは反映できない。別の考え方で、知らない（＝理解できていない）場合、間違った判断をすることがあるかもしれないがその間違いが判断ができずに残す方に傾いた場合、結果的には（残す方が）正しい解答を得られるかもしれない。その際の副作用は、判断できずに残してしまったことで本来不要だった項目の対応コストを削減することができずに残してしまうと言うものがある。

それ（＝不要なものを残してしまう）が嫌なら、早く試し、早く軌道修正（＝ピボット）するほかない。

UXリサーチの道具箱 ―イノベーションのための質的調査・分析―