プロジェクトもFUNが駆動する

プロジェクトマネージャをやっていると楽しい。楽しくなければ続かないしさっさと撤収していたに違いない。人生の多くの時間を費やす仕事で楽しくないことは身体に無理をさせるし、変調を起こすだろう。アラサーの頃のプロジェクトで激やせしたのは参画していたプロジェクトが辛かったからだ。

だから自分でプロジェクトをキャリーする案件は、自分が楽しくなるようにする。プロマネ自身が担当するプロジェクトを辛いと思って仕事をしていたら、メンバも迷惑千万だしパフォーマンスなんて上がる訳が無い。

楽しめれば笑顔になれる。何より余裕を持てる。

楽しむために計画を考え、計画どおりに進むように事前準備をする。事前準備は大変だ。特に、プロジェクト立ち上げ時期は、プロジェクト計画自体を書かなければならないし、直近の作業計画も具体化し詳細化しなければならない。調達したメンバにプロジェクトのポリシーを刷り込まなければならないし、顧客とキックオフするスライドも作らなければいけない。組織のレビュープロセスを通さなければならないし、プロジェクト完了まで見通せてなければならない。もちろん、先々は変わっていくから着地点のアンカーを打つのと着地の姿勢（完了条件）をそっと置いておくことくらいだ。

プロジェクトは様々な制約を受ける。外的な制約を受けることもあるし、プロジェクトの見積もりや計画で前提とする条件を自らつける。こうした条件から外れないようにしなければならないし、手間も多々かかる。これらの条件は、外れると厄介ごとになったり、アンコントローラブルな状態に突入してしまうのでやらないとはできない。でも予め知ってやっていれば大したことではない。思い描くように条件をコントロールできればそこにもFUNはある。

プロジェクトでFUNが無くなるときは、やらなければならないことを気付きながらやらないで自らトラブルを引き起こしたときである。放置し、手に負えなくなり、外野からあれこれ干渉され、リソースを勝手に使われるような横槍をいれざるを得ない状態にするのだ。主体性を取られ、管理されれば余裕はなくなり、その対応だけで精一杯になる。そこにはFUNはない。

だからそうならないように、FUNであり続けられるためにプロジェクトをコントロールするのである。プロジェクトがFUNの状態かどうか。とても大事なことだと思う。

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

調達 クリストファー・アレグザンダーの思考の軌跡

クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う

マネージャとしてエンジニアに伝えたいたった1つのこと

昨晩、このツイートがTLに流れてきて必然のように視覚に入り、深く頷いた。

ツイートでキャプチャされている元の動画のURLはこちら。

youtu.be

以下に、YouTubeから画像をキャプチャし直して引用する。時系列で言えば、キャプチャして掲載した画像は3→4→1→2の順になる。

メンバには、自分の部下でいるうちは守ってあげられるがいつ自分がクビになるかもしれないし、不慮の事故にあうかもしれないし、自分から組織を離れるかもしれない。そうなったとき、部下であるエンジニアは自分で生き抜かなければならない。

大げさかもしれないが、自分の部下であるうちはできることはしてあげたい。

こうした自分の考え方はメンバとのミーティング、目標設定の面談などで何度も伝えている。伝える相手は、自分より年上であろうが、年下であろうが同じである。

メンバの年齢、経験は自分から見れば個々のエンジニアのアトリビュートに過ぎない。だから経験の多少により差をつけない。皆、同じように扱う。

これは別に公平に、なんていう馬鹿げたまるで正義のような考え方からではない。メンバであるうちは、年齢に関係なく成長して欲しい。それが1ミリ、１ミクロンだったとしても、だ。

シンプルな考えに基づいているだけだ。

そのために与えられている裁量できることは、時間というリソースの使い方と教育の機会と実務へのアサイメントである。

それがエンジニアの成長のための環境づくりでできることだ。

たった、これだけしかマネージャはできることがないのである。

だから、目標設定ではこと細く、具体的にイメージアップできるまで問いかける。エンジニア自身が１年間というタイムボックスの中で価値をどうやって付加していくか。そのストーリをきく。

エンジニアがストーリテラーに成れなければ、伴走しながら一緒に考える。少しずつ。

• エンジニアの目標を一緒になって作ること。
• それを実現できるリソースを確保すること。
• 機会を作ること。 

マネージャができる環境づくりとはこの3つだと思っている。

こう言った話をすると何故そこまでやるのかと逆に尋ねられることもある。不思議でならない。

高度で高価な教育を選抜でもしたいというと、戻ってきてから辞めてしまうからやりたくないというエグゼクティブやマネージャがいる。

そうならない業務、ビジネスをするのがマネジメントの仕事ではないか。

自分にできることは、自分がマネージャの間、メンバの育成、目標設定、キャリア、プロジェクトへのアサイメントのポリシーとして、自分の外、他の組織、他の企業、エンジニアという業界に出たときに活躍できるエンジニアに育つ支援だけしかない。

エンジニアにとって成長だけがエンジニアとしての価値を増やす手段である。だから、そういう機会、リソースを確保するのであって、それを活用するのはエンジニア自身である。

しなくても誰も困らない。後になってやっておけばよかったと繰り返し思い、結果、自らはなにもせず、与えられた業務の範囲の中で得られる経験を拠り所にしているエンジニアも皆無ではない。逆に8割くらいは他のことを優先する。

そうしたことも踏まえ、自分の価値をどうするかエンジニア自身で考えて欲しい。

マネージャができることは裁量の中でリソースを確保し、使ってと指示するだけである。執行するかどうかはエンジニア自身に委ねられている。

マネージャとしてエンジニアに伝えたいことは、外に出て生き抜けるよう部下でいるうちに価値を付加して欲しい。

たったこれでだけである。

動画のような考え方を伝えられる経営者と働きたい。トヨタ車は買わないけど。

ドライバーズシート 豊田章男の日々

トヨタ物語 (強さとは「自分で考え、動く現場」を育てることだ)

結婚するときに最初から買った方が良いもの、買うのは待った方が良いもの

結婚してあと数年したら25年になるので銀婚式か。子どもさんたちも成人になっているだろうから、子育てお疲れ様で久しぶりに海外旅行に連れて行きたい。自分は仕事で何度か海外に行っているがワイフは行っていない（行きたいところがあるかどうかはわからないけどね）ので。

25年近く暮らしていると結婚した当初から持っていた方が良かったなと思うものとよく考えてから買った方が良いと思うもの（婚礼家具）がある。

結婚するときに最初から買った方が良いもの。どちらも生活家電。とりあえず2つある。1つは、食器洗い機。もう1つは除湿乾燥機。

• 食器洗い機
  なぜ必要か。食事をすれば洗い物が出る。３食食べれば3回分の洗い物が出る。中食で買ったとしてもコップや箸や取り皿を使う。とにかく、食べれば洗い物が出る。風邪をひいても食事をする人がいれば洗い物が出る。小さな子どもができたら洗い物だらけになる。体調が悪くても食べれば洗い物が出る。手で洗えばいいと言い切るなら、言い切った自分で全部、毎回洗うんだよ。
  
  子どもを授かったら、子どもの対応で時間を吸い取られる。洗い物をしていようが関係なく、無慈悲に召喚してくる。子どもの泣き声に気を取られて食器を割ってしまったら、自分の不甲斐なさに凹んでしまう。洗い物は機械に任せよう。
  
  年齢を重ねるごとに身体を動かすのは億劫になる。億劫になるから作らなくなってと悪循環になる。食事は忙しいときには出来合いを上手に選びたいが、いつもはどうかと思う。その面倒の原因を除けばいい。食器洗いがそれ。
  
  食器洗い機選びのポイントは、短時間で終わること。5分くらいがいい。30分もかかるような食洗機は使っていて楽しくない。セットする、5分後に洗い終わる。布巾で拭くか、時間がなければ扉をあけて放置して自然乾燥。
  
  汚れを落としてセットするような代物は単にすすぎを機械がやっているだけだ。洗うところからやってくれる食洗機を選ぶ。値段は二の次。1日3回、食器の量によっては食事ごとに何度も使うのだから十分元は取れる。

• 除湿乾燥機。洗濯物も毎回でる。雨が降ろうが洗濯物は出る。家の中が広く干す場所があったとしても除湿乾燥機があれば素早く乾く。子どもさんが出すのを忘れた体操着とかとか。洗濯乾燥機でもいいが我が家では除湿乾燥機で風を当てて乾かす。晴れればベランダに干すが乾ききらないときに、除湿乾燥機が働く。
  屋内も除湿するのでジメジメすることもなく、快適だ。
  
  

  パナソニック 衣類乾燥除湿機 ナノイー搭載 デシカント方式 ~14畳 シルバー F-YZRX60-S

結婚するときに買うのは考えた方が（先送りした方がいい）ものの筆頭は、婚礼家具。あと、ソファ。

• 婚礼家具
  我が家にあるのは府中の家具でとても立派で収納力があり、品もある。だけど、場所をとるし、住む場所が変われば内装に合わなくなってしまうこともある。住む場所に合うように選ぶ、場合によっては廃棄して、という選択肢もある。でも、立派な婚礼家具ではそうはいかない。
  
  
• ソファ
  これは引越しして家を構えてから買った。カリモク製の良いものだが、やはり場所をとる。２人掛けと1人掛けが2つあると広いリビングが分断されてしまう。
  とは言え、こたつは嫌なので、椅子とテーブルは（ダイニングテーブルとは別に）必要だが、形状を考えたい。
  今だったら、２人掛けとオットマンとテーブルだけにするだろう。1人掛けはいらない。
  立派な府中の家具ではなく、無印あたりで選ぶだろうし。

ダメ出しされない資料作り

あまり他人のことを言える立場では無いのだが、企画兼コンサルティングのプロジェクトに参画している他所の年配エンジニアの資料作りはとてもユニーク（オブラートに包んだ表現）である。

プロジェクト立ち上げの初期は、こちらも前のめりというか担当範囲以上に色々とやらなければとそんな気持ちでやっていたので、他所の年配エンジニアに対してもああしろ、こうしろと散々ツッコミし続けていた。

アプローチも思想も全く並行線の世界で交差するのは極まれだった。しばらくして、距離を保った方がお互いのためと気づいて役割分担も綺麗に分かれるようにするとその分のしわ寄せはプロジェクトオーナ側に押し付けることになるのだが、全体的にはそうした方がお小言的な指摘をする必要がなくなったので他所の年配エンジニアに取っても平和だったかもしれない。

こうした企画兼コンサルティングの資料作りであまりにもユニークな資料を作り、周りから総ツッコミをされないためのコツは、実はエンジニアが要件整理や仕様を詰める検討資料作りの参考になるのでは無いかと思った。

• 必要最小限で十分な情報収集、課題の中の本質、仮説とストーリ
  資料作りでは、作成する資料のテーマに応じた結果を実現するための準備を行う。要件を確定したいのであれば、要件を確定するための準備をしなければならない。そのようなテーマであっても標題の3つのステップで進めれば良い。
  
  必要最小限で十分な情報収集とは、目的はあるマイルストーンの期日までに実現しなければならないものである、という前提がある。要件が後続工程のインプットになる場合、要件は後続工程の開始日前に決着している必要がある。更に言えば、要件を整理する側の都合に良い状態になっている必要がある。
  
  期日、都合の良い状態は制約になる。以上から、資料作りでは締め切りを設け、それに収まるように作業を完了させるためにタイムボックスの考え方を取り入れる。端的に言えば、作業前に終了時間を決めておき、その中で収まるように作業を調整する。ただし、次工程のインプットになることから中途半端ではいけない。
  
  課題の中の本質とは、見えるキーワード、ステークホルダが発するキーワードに囚われずに課題の根っこを必要最小限で十分収集した情報から自分のフィルタをかけ探さなければならない、とうことである。
  
  得てして、与えられるキーワードが課題であると鵜呑みにし、それを解決するためのアクティビティを設定しがちであるが、それでは期待されている課題解決には至らない。なぜなら、キーワード自体がそれを発した人の仮説であり、仮説の背景にある『なぜそれが必要か』に辿り着けないためである。
  
  仮説とストーリとは、タイムボックスの中で得た情報の分析から自分で設定した真因を解決する骨格となる台本を組み立てるということである。この台本がいい加減であると課題設定自体を疑われることもある。

• 資料の構成、曖昧さを排除する、伝えたいことを伝える
  資料の構成はいわゆる章節項という目次のことである。たとえ目次を作らないとしても、標題を設け、親子関係を取らなければならない。構成を取るということは、親となる目次で全体を表し、その範囲の中でのみ記載するテーマを設定する。前方もしくは上位の目次で述べられていないことをいきなり書くと読み手が混乱し、資料の目的である要件の整理はストップしてしまう。
  
  曖昧さを排除するとは、章節項の構成の上位もしくは前方で示す記述の範囲について述べる範囲をさし示すことと示した範囲の中で重複や漏れをしないようにコンテンツとしてのムラを排除するという観点がある。更に、主張することについての表現でいくつもの受け取られ方をするような言葉は選ばないようにするということである。
  
  伝えたいことを伝えるということは、標題と内容が一致しているか、それを必ず確認しなければならないということである。資料の標題、とくにスライドなどで資料を作る場合、標題から手をつけることが多い割に本文を書いていると次第に標題と内容がずれ始め、全体の構成からとも違う資料を作っていることがままある。

もっといくらでも出てきそうであるが、資料作りの根幹は資料作りの骨格と資料自体の明快さにより資料作りの目的が達成できる。年配エンジニアの資料を見ていてそう思ったのだからそれほど外してはいないと信じたい。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

こんな仕事にアサイメントされるのを知っていたら断った

エンジニアになる前の学生の頃の専門でエンジニアになったときの優秀さは見極めることはできないとつくづく思う。農学部出身の同僚は優秀だし、以前プロジェクトで一緒になった理工学部のおじさんはそんな風に考えるか（褒めてない）と突っ込みたくなるような思考回路を持っていた。

実際、仕事をしていると課題を見つけるのが上手なエンジニアもいれば、課題に気づかないエンジニアもいる。多くのエンジニアは課題の本質に辿り着けず、表面的に見える資料や会話のキーワードを引用してそれを課題だという。それは解消しなければならない課題の本質ではないよと思うことが多すぎる。それはまた違う話ではある。

自分の初めての仕事は専門の学科から言えば、全くフィット感もへったくれもないような職場だった。どう考えても工学部出身者の方が合っている（それもまた専門が分かれているので違うと言われそうだが）と思える仕事である。

おかげで、一時期は改造したプログラムが全国にばら撒かれたり、ダウンさせたらめっちゃ怒られそうなシステムに携わらせてもらった。当時はあまり考えていなかった（余裕がないというか日々乗り越えるだけで精一杯だった）がその割には勉強していなかった。

想定していた仕事は金融か何かだろうと思っていたので、全くもって低レベル言語を扱うプロジェクトにアサイメントされたことを同期の飲み会でよくネタにしていた。

若手エンジニアを見ていると、自分でやりたい仕事のイメージを持っているメンバは楽である。やりたい仕事を知っているから少しでも擦りそうな案件であればアサイメントできるように配慮をする。でも、自分でやりたい仕事の希望を持っていないと持っている技術を中心に適用範囲を広げたり、ロールを恣意的にあげたりする（これ自体は部下一律でやることなので希望を持っていないエンジニアだけということはない）しかやることがない。

新規テーマがあり、アサイメントのタイミングで興味があるかを尋ねることはあるがそれもタイミングドリブンとなってしまう。率先して見つけてこようという感じにはならないのは希望としてリマインドがないためである。そうは言ってもメンバ全員が希望を持っていると叶えられるのは全員にならないだろうし、そうそううまくはいかないだろう。

話を自分に戻して、初めての仕事から所属する組織を変わる方便として2回、プロマネをやるために1回、都合3回ほど自分の希望を組織に伝え、仕事の担当を変えた。それ以外は、アサイメントされたプロジェクトで仕事をしてきた。

それ以外のほとんどの仕事は、こんなプロジェクトをやるのか、やってられないと思うような仕事ばかりだった。最初からわかっていれば断った（そんな権限はない）と言いたい仕事ばかりだった。客バカ度が高い、メンバがひどい、プロマネがマネジメントしていない。

何より自分の技術がひどい。当時は相当迷惑をかけていただろう。

こんな仕事にアサイメントされるのを知っていたら断りたいと思っていたのは、自分の技量なさを内心自覚していたからだ。その上、新しいことには手を引っ込めていたのだ。全くもって使えない。

まあ、仕事も地雷案件はいくらでもあるのでそうした案件を察知できるならわざわざ自分から地雷を踏み抜きに行く必要はない。ただ、自分の技量の問題を棚に上げてどうこう言おうとしている自分に気づいたら、それは技術力をあげるチャンスかもしれない。

学ぶ機会は溢れている。ただそれに気づくか、手を出すかは自分次第である。

実践 自分の小さな「箱」から脱出する方法

シンプルなチームへの権限委譲

プロジェクトでも定常的な業務でも『組織・チーム』という人の集まりを作り、各人に役割を負わせるとき、権限を分担する。最近では、管理職のいない組織づくりで上手くやっているというケースも一部ではあるようだが、これは、権限を持つロールに属する人を複数にしているだけの話で、従来の形態の亜種だと理解すると上手な制度設計の1つのパターンだと受け止められる。

古式ゆかしい、旧態的で伝統的な組織であれば、権限を持つ役割は通常１名で不在には代理設定するように設計しているものだ。権限を持つ人を複数置かず１名としておくのは権限＝責任の所在を明示的にするためであって、そうした要求に基づくか単になんとなくそうしているだけの理由に過ぎない。他の要件、例えば意思決定を昼夜行う必要があるのであれば複数体制を取るか切れ目なくできるように制度を設計するだろう。

身近なチーム内での権限委譲はどう考えればいいのだろうか。最近、権限委譲を７つのレイヤーで表現したスライドを見かけたような気がするのだが、そこまで細分化が必要なのだろうかという印象しか残っていない。自分としては（先の７段階の権限委譲のような）細分化し過ぎる考え方は、運用に耐えないと経験的というか自分の性格的に判断している。今は2番目の段階だから、次は3番目に…などやってられない。権限は委譲するか委譲しないかの2択で十分だ。

ではどのように委譲するかしないかを決めれば良いか。それはright personに権限を持たせると決めておけば良い。プロジェクトチームなら、チーム内で一番専門性を発揮するメンバにそのメンバが担う権限を委譲するということである。システムデザインはアーキテクトに意思決定する権限を付与すれば良い（明示的にする必要があるのかは差し置いて）し、実装はメンバに判断してもらえばいい（レビューはあるとしても）。

通常の業務での役職の意思決定で違和感を覚えるのは、案件の判断を行う役割の管理職がその案件の専門性を持っていないのに（ろくに勉強もせず）自力で判断するときである。専門家を引っ張り込んだ上で（専門家の意見を尊重して）判断するのであれば、right personが意思決定に十分な影響を与えていることになるので問題がないが、知識もないのに判断されてはたまったものではない。

エンジニアが権限から違和感を覚えるのは、こうしたケースもあるし、プロジェクトでももちろん起きる。でも、権限における違和感、不条理の原因の構造は組織の構造で起きる原因と同じである。であるから、ストレスのないチームでの権限委譲は、

• right personであるか
• right personを適切なロールに置いているか
• right personはロールにふさわしい資質を持っているか

で行えばいい。

あとは、そうした役割を一部でも経験年数が少ないうちからそれこそ委譲し、慣れさせる機会を作ることも大事である。

The Right Person

甘々と稲妻（１２） (アフタヌーンコミックス)