プロマネやスクラムマスタが決めてはいけない

このツイートの気持ちを少しだけ補足すると、本エントリの方が9月で満60歳になられる（おめでとうございます）とのことで、同じようにあと数年（とは言え猶予は7年くらいある）もすると60歳になってしまう自分にゾッとするなぁ、と。

あと数年でその歳になるかと思うとゾッとする。 / 他9コメント https://t.co/9eqGgmIRGR “プログラマ60歳定年説、FA宣言 - 未来のいつか/hyoshiokの日記” https://t.co/h3hIJF6WKt

— ふみさん (@finayama) June 21, 2018

 今の仕事以外の活動は実はその60歳を超えたときの種まきで、一部は既に成果が出ているところもあるが、もう少し主たる業務に置き換えられるようにしたいと考えているが今のところ、はまだまだ試行錯誤中な状況なのだ。

特に、ソフトウェア開発のエンジニアの組織づくりに関わりたいと思っているのでVPoEやマネージャが必要な経営者の方はお声掛けいただければありがたい。

そうしたエンジニアのチームを構築するとき、特に有期限性を持つプロジェクトでのチーミングで気をつけておきたいのはプロマネやスクラムマスタがオーダをバンバンと出すようなチーム作りになってはいけないと思っているし、自分がプロマネのポジションになる場合は、そうならないように仕組みづくりをするように心掛けている。

プロマネ・スクラムマスタ（1人）　→　チーム（N人）

図　プロマネ・スクラムマスタが決める関係

ありたい姿はこうだ。

プロマネ・スクラムマスタ（1人）　←　チーム（N人）

図　チームが決める関係

 チームが決めるようになって欲しい理由

メリットしかないから。

チームが作業プロセスを決め、完了条件を合意し、チームで進捗させる。チームで進めているから誰かの進捗が滞れば気がつくし、負荷が低いメンバが自然と手助けする。

プロマネは先々の計画を考えること、チームの進捗上のリスクを識別することに専念できるのでリスク回避が半端ない。

もしプロマネがチームも識別していないリスクを識別したら、これはどうすればいいかを示せばいいだけだ。

プロジェクトでのチームづくりで気をつけたいと上述したが、継続的な開発を続けるプロダクト開発ではより重要になる。なぜなら、チームが属する組織の意思決定がチームの判断に影響するからだ。 

 一般的に組織が成長すると意思決定は多段に置かれるマネージャの分掌の範囲で決定するようなり、チームの裁量はプロマネやスクラムマスタの持つ裁量よりも小さくなってしまう。小さな裁量は、思考範囲を狭め、制約事項だらけの中だけで考えてしまうと従来の意思決定や慣習に沿おうとする力学が働く。

それを少しでも緩和するためにプロマネやスクラムマスタが持つ裁量をチームに移譲をするのだ。移譲を受けたチームは少しでも裁量が増えれば伸び代が増え、放置しても進められるようになる。成果として組織貢献が可視化されればさらに権限を付与することも可能になる。

プロマネやスクラムマスタからチームが決めるように促し、それが上手くいかなくても心配しなくて良い。何が起きようともプロマネやスクラムマスタが責任をとる構図は変わらない。だったら、チームが決める方で失敗した方が学びが多い。

まぁ、そうも言っていられなくなったら、ちょっとだけ関与を増やせば良い。もう、トップダウンではやっていられない。そっちの方がリスクが高い時代なのだから。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

ブログを続けるモチベーションが知りたい

ある方からそんなことを聞かれたのだが、モチベーション、つまり、動機付けがあるかというとあまり思いつかない。改めて聞かれると「えっと…なんだろう」というのが素手のリアクションになってしまう。

毎日書くことについて

朝起きて、平日、休日に関わらず毎日書く。時間はだいたい決めているが週末の方が書く時間が遅い。それとタイムボックス的なものが週末の方が緩いからというのもある。週末にも関わらず早い時間に書く場合は、何かイベントか用事があるときだ。

そういう意味では習慣になっていると言えばいいのかもしれない。年に数回、書く時間が確保できそうにないときがある。そういうときは、前の日の夜か、用事の移動中に書くこともある。とにかく、書く時間を見つける。うーん、中毒なのかもしれない。別に人気サイトということは無いし、アフィなんて雀の涙だし。

書くテーマについて

 プロフに書いているように、プロジェクトマネージメントやエンジニアの育成などをテーマエリアとしてしている。専門的のフィールドで書くことが一番自分のノウハウを（自分が考えたように）伝えられるからだ。

三題噺では無いがキーワードを拾う。割と車輪の再発明的なエントリがあると思うが、書いている中の人は同じだから仕方がない。ただ、少しずつ考え方もシフトしているのではないかと思う。それはアジャイル開発とかそうした今風の考え方に同意できるところがあり、そうした考えを取り込んでいるからということの現れでもある。

得られるものについて

 書くテーマについての元ネタを調べたり、理解したりすることが必要なので、情報を取りに行くという姿勢を続けられることは大きい。それにその情報を知ることができる。

ごく稀にバズるときがあってもなんでこのエントリだけがバズったのかがよくわからない。たぶん、タイトルが琴線に触れたのだろう。ここがわかるともう少し良いのかもしれないが。

話を戻して、あと得られるものは、書く習慣で書くことに対する心理的なハードルが全くなくなるということがある。あるコミュニティでの記事をかいてと依頼されてもホイホイと受ける。

あと、書く前よりはいくらか書き方がましになったかもしれない。まあ、個人の感想だが。

書いていなかったら

この時間を何に使うか。多分、ほぼソーシャルで時間を潰してしまっているのではないか。

そして、今よりはつまらないおじさんエンジニアになっているかもしれない。アウトプットが無くなるので、インプットの必要性が下がるだろうから。

アウトプットの麻薬的なところはあるのかもしれない。アウトプットするためにインプットするという感じか。

さてこれが尋ねられた知りたいことなのだろうか。

HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント

なんとなく作っているWBSのその作り方が間違っているとしたら

システム開発には様々な手法や方法論があり、現場で使われている。こうした意見に対して反論するエンジニアは皆無だろう。

例えばWBSがある。ウォーターフォール型のシステム開発では有無を言わさず採用されているのでウォーターフォールでのシステム開発を経験したエンジニアなら100％経験しているはずだ。もし、WBSを経験してないとしたらどんな方法で作業計画を立てていたか教えて欲しいのでコメント欄に書き込んで欲しい。

では、誰でもが知っているWBSはなんのために作るかを知っているエンジニアはどのくらいいるのだろうか。さらに、WBSの作り方の教科書的な書籍を読み手法として学んでいるエンジニアはどのくらいいるのだろうか。

ほぼほぼのエンジニアはWBSをOJTで、つまりプロジェクトの中で、それも周りの見様見真似で覚えてきたのではないか。

WBSは作業分解ではない

WBSの正式名称は、Work Breakdown Structuresである。直訳すれば、仕事を（複数の）構造に展開したもの、である。あれ、何か違うと気づいたら流石。一般的な理解は、仕事と訳さず作業と訳され、使われていることが多い。もう少し具体的に言えば、（ある目的を持ち、努力して行う）仕事を指す。

システム開発において、ある目的を持って努力して行う仕事とは何か。答えられるだろうか。

何れにしても、WBSは作業を「分解」したものではない。目的を達成するための行為である。

WBSとは何か（復習）

 WBSは、お仕事の目的を構造展開したものである。では、お仕事の目的とは何かを考えてみよう。

さて、思いついただろうか。これだ、とはっきりと即答できただろうか。答えは、成果物を作ることだ。

システム開発に置き換えれば、プロジェクトのスコープを成果物の観点から定め、成果物を構造的な部品に具体化したものが成果物だ。部品化した構造物がどれ一つ欠けてもプロジェクトのスコープを満たさないため、プロジェクトの目的が達成されることはない。

プロジェクトの目的→成果物→部品（ドキュメント、プログラム、HW、etc）

成果物を確認する

 WBSを作成する際に一番最初にすることは何が成果物かを確認することだ。成果物に課せられる制約条件や前提条件があればそれを含めた成果物の仕様を確かめる。

成果物の作成手順を確認する

 次に確認するのは成果物の作成手順を確認する。システム開発はチームで行う。メンバが違うやり方をしていては、同じ成果物を作れなくなってしまう。なので、成果物の作成手順を確認する。

もし、作成手順がなければプロトタイプを行い、成果物を作成できるモデルとなるテンプレートを確立することから始めなければならない。

作成手順は、必要とするスキルとスキルレベルを前提とし、その前提に立って組み立てる。

よく、どこまで作業手順を詳細化すればいいか聞いてくるエンジニアがいるが、この質問が出てくる時点で、WBSの雛形がないと気づかなければならない。チームのエンジニアが同じ粒度でWBSを展開するためにもテンプレートを最初に作ること。

工数を見積もる

構造化したお仕事は、最小のお仕事ごとに作業を見積もる。これは感覚でやってはいけないし、過去のノウハウ（痛い目にあったからとか）でバッファを持たせないこと。

理想時間（割り込みなしで集中してやれたら）で見積もること。

見積もりは、チームでレビューし、チームの標準的な技術レベルか、やや下あたりのエンジニアが担当したときの理想時間で設定すること。

なお、理想時間で見積もるかどうかは、チームで決めておくこと。理想時間で見積もったら、チームのバッファを持つこと。

マンガでわかる! 幼稚園児でもできた!! タスク管理超入門 impress QuickBooks

非凡な才能でコードを書くエンジニアだけではリリースできない

プロダクトをリリースするためにはコードを書くエンジニアが必要だ。できれば非凡で卓越したエンジニアであれば機能的なコードを書いてくれるに違いない。

でも、群を抜いたコードを書くエンジニアが必ずしもリリースできるとは限らないのがマネージャとしては気になるところだが、一歩引いて客観的に見ると面白いところでもある。

1つ目の理由は、エンジニアからコードが手離れするまで安定しない。この安定しないとは、だいたい期待する納期をオーバーランすると言う意味だ。非凡な才能を持っているなら他のエンジニアより早くリリースしてくれると期待してしまうかもしれないが、現実にはそうならない。

それはタスクを渡す側にも選ぶエンジニア側にも理由がある。タスクを渡す側は他のメンバでは完了の見込みが立たないテーマをアサインしたがるし、非凡な才能を持つエンジニアも面白みのあるテーマを選ぶ。ここは一致するがなにせ難易度の高いテーマになりやすいため、結果的に見通しが怪しくなる。

その観点では、最初からリリース日に間に合わない仕事の仕方をしているのかもしれない。

さらにリリースに間に合わなくしている理由がもう1つある。それは、難しいテーマがあるとチームの中で無意識に非凡なエンジニアがやってくれるのだろうという暗黙のルールが出来上がってしまうというものだ。

これは非常に拙い習慣だ。ただ、こうしたことは回避しようと思えば回避できる。それはメンバにはタスクを1つしか渡さないというルールを作ることと、原則、テーマのアサイメントはメンバに選ばせるか、そうなるような場づくりをすることだ。もちろん、技術的に不足しているエンジニアが担当になる場合はサポート体制でフォローしないと終わらないままでリリース日を迎えることになるため、マイルストーンやモニタリングは欠かせない。

2つ目の理由は、如何にコードを書いて実現するかに関心を持っているので、結果に、よりフォーカスしてコードを書く。集中して自分のペースで仕事をするから納期に合わせたコードにしない。

結果的にリリースのスケジュールを気にすることもない。納期に間に合うのかと聞けば、多分とはぐらかされてしまうが守られることは滅多にない。

自分のペースで仕事をするのは何も非凡な才能のエンジニアに限ったことではないから、他のエンジニアと同じように毎日進展を確認する他ない。それよりは、コードに集中できるような環境づくりをして集中させたほうが良い。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

エンジニアの体調管理と一番の処方箋

若手エンジニアと一括りにするのはちょっとアレなので年代では括らないが、自分のことをネタに振り返ると20代は割と休みを取っていた。休みを取るというとアクティブに思えるかもしれないが、ほとんどは（軽い）熱が出たとか、出たことにしてズル休みを取っていた。休んでいるのに（連絡は入れているのであれこれ言われたことはないが）気分転換と称して山間部までドライブに行ったこともある。まあ、何やっていたんだか、ではある。

一番多いのはやはり（軽い）風邪だろう。でも、気分が完全に後ろ向きなので寝込みを決めるわけだ。

原因は自分でもわかっていて、仕事が面白くないか、人間関係がヤバいか、その両方かだった。要は、よく風邪で休んでいた頃は仕事ができなかったのだ。

どうできなかったかというと自分が思うように仕事を進められなかった、と言い換えてもいいかもしれない。間接的に自分の仕事の拙さや技術力の未熟さを理解できていたのだろう。それはそうだ、一番自分のことを知っているのは自分なのだから。

あるとき、使い切れなかった年休を見て、逆に使った年休の理由を思い出して見たら前述のような理由しかなかった。特段、旅行に行くわけでもなし、用事があるわけでもなし。そのとき思ったのは、休むのは何か有意義な理由で休んだ方がいいのではないか、となんとなく思ったのだ。

頭の中では、せっかくの年休に一日中、ベッドで寝込んで、症状がひどい場合は無理に起きて病院に診察と薬をもらうために待合で並んだり、食事をしてもろくに食べられず風邪ダイエットだと自虐をしている自分を思い浮かべた。

なんとも勿体無い。

今思えば、休みかたが下手だな、とも思った。たぶん、属する組織のエンジニアも割と休みかたが下手なように感じる。彼彼女らは自分とは違って本当に具合が悪くて休みを取っている。もちろん、夏季休暇などで休みを取ることがあるがでも、それだけである。

有意義かどうかは個人の価値観に任せるが、休みを勿体無くしたくないと気づいてからは、休みは好奇心を擽ぐるようなことに使うか、仕事ではない活動に使うために取るようにしている。

この価値観のピボットはとても自分の休み方にインパクトを与えることになった。なぜなら、体調と上手に付き合えるように気を少しだけ回すようになったかだ。

システム運用では、監視対象に閾値を設け、モニタリングするのは常識だ。それと同じことを自分身体に対して行う。

1つ挙げるとすれば、日中でもものすごく睡魔に襲われることがある。スーッと意識を持っていかれ、数秒だろうが感覚は数分寝てしまったような気分を味わい、そうすると少し体が楽になる。この症状が出たときは、軽い風邪が這い寄ってきているのだ。

そこで引き出しから葛根湯を1回分頓服しておく。喉や目の疲れも緩和されるので葛根湯は推しておきたい。

でも、である。一番の処方は仕事ができるようになることである。実際、自分で仕事の段取りを考え、アレコレと思うようにならなくてもどうにか遣り切るようになると仕事をしたくなるから不思議だ。ここで言う仕事が出来るとはチャンクになった一纏まりの仕事を任せられるようになる状態を指している。

仕事が塊になると裁量が生まれるのだ。ここに仕事の楽しさが生まれる源泉があると思うのだ。裁量が確保できると仕事をコントロールできるようになり、時間を自由に使える。そうすると、休みを好きなように入れられるようになる。もちろん、年休は申請すればとれるが、そういった制度上の話ではないので。

【第2類医薬品】葛根湯エキス顆粒Sクラシエ 12包

若手SEに雑務をやらせておいて成長しないというなんて

若手エンジニア、大雑把に27歳くらいまでをそのゾーンだという前提で話を進めよう。

若手SEに対して最優先にしなければならないのは一人前になってもらうことだ。そうだろう、手が足りなくて若手を回してもらったのだろう。だったら、最優先事項も若手SEへの期待も全部引っくるめて一人前になってもらうことが当面のゴールだ。もちろん、仕事をやりながら、である。

若手SEが配属されると雑用をさせる

本来、一人前の仕事ができるようになって欲しいのだから、参画したタイミング以降に予定している作業を全て一通り経験してもらうことをOJTのプログラムとして番組を作らなければならない。

では実際はどうかと言えば、雑用ばかりさせている。本来、雑用なんてプロジェクトでは存在しないものなのだが、動機付けをしなかったり、教える側の先輩エンジニアが仕事の意味を理解していないばかりに自分がやりたくない仕事を押し付けてしまうからわざわざ雑用と言ってやらせているのが現場で起きていることではないか。

例えば、雑用といって押し付けられる議事録作りは、本来、

• 参加メンバの顔を覚える
• 用語を学ぶ
• プロジェクトの物事の決まり方を知る
• 議論や決定事項を聞き取って要約する力をつける
• 議題の結果と宿題などToDo管理のやり方を知る

などが身につく。そう言ったことができると教えてからやらせるなら。

仕事の中から一部分を切り出してやらせると

繰り返すが、若手SEに身につけさせたいことは一人前のエンジニアになるように仕事を一貫して経験させ、一人で出来るようになってもらうことだ。

そうなってもらうための仕事は連続する仕事を縦に切って渡してはいけない。横にスライスしなければいけない。仕事を縦に切って一部分だけを渡すとアルバイトになってしまう。それでもまだコンビニバイトの方が完結した仕事をするのでそっちの方が仕事の一貫性で見ればまともな渡し方だ。

ところがエンジニアには縦に切り刻んで渡す。

なぜなら、渡す方の中堅エンジニアが仕事ができないからだ。仕事は切り刻まれて、パーツの部分だけをやってきた。言い換えれば、そのやり方しか知らないのだ。人は知っていることからしか教えられない。

成長していないエンジニアの出来上がり

やらなければならなかったことは、仕事としての塊を渡して、仕事の頭からしっぽまで経験させ、助けがあればなんとか一人で進められるエンジニア作りだ。

でも、半年もして出来上がる若手SEが出来ることはろくに書けない議事録やテストデータを指示されたようにしか作れないとか、そんなエンジニアだ。

それって、若手SEが仕事できないからなのかそれとも成長しなかったからなのか。

仕事ができないのは誰だ。

ITエンジニアのための「人生戦略」の教科書 ~技術を武器に、充実した人生を送るための「ビジネス」と「マインドセット」~

調達 純米本味醂 福みりん 1800mL

純米本味醂 福みりん 1800mL