決めないエンジニア
飲みながらアーキテクトの愚痴を聞いていたんだけれど、そのアーキテクトはこんなことを言っていたんですね。
「聞いてくださいよ、自分たちのプロダクトを作るのに要件が決まっていなければ手がつけられませんとか要件を出すのは私ではありませんとかいうんですよ」
「えっと、受託じゃなくて自社製品のプロダクトを開発しているんだよね」
「そうですよ、そうなのにおかしいじゃないですか。自分たちで仮説検証してものづくりしないと」
「プロダクト開発ならね」
「もう、要件をお伺いばかりしてきたから要件を自分で考えることができないんじゃないかって思っちゃいましたよ」
要件はお伺いするものだと考えているエンジニア。それはそれで問題なきがするけれど、要件を自分で考えることができないエンジニアの方が深刻な気がするんだけど。
お伺いは専門家としての職務放棄
確かに要件を提示することはSOWを書けば顧客に○がつくのは当然です。
要件は業務要件とシステム要件に分別しシステム化する際の費用と効果からシステム化をするかどうかを判断します。そのシステム化するシステム要件は確かに顧客側の要件定義の中での仕事だけれど、 ベンダ側の（システムの）要件定義の中で、システム化する要件はITの専門家としての知見を持って精査する必要があるしときにはシステム化要件から追い出したり、業務要件から巻き取ったりとバウンダリを変える必要もあるのですよね。
そうしたところで要件をお伺いばかりして顧客の提示を専門家としての識者の目線でレビューせずにこれで全部ですね、なんてやっているとしたら専門家としての責務を果たしていないことになりかねないです。
お伺いで失うもの
お伺いで要件を聞いてばかりいると用意された材料で料理を作るようなものでそこには新しい発想が生まればかりか要件が実現しようとしているシステムの知見からみて間違った解決策を選んているかどうかをろくに精査せずにパススルーすることになるんですね。
ここで知見を活かして間違いがないかを精査するということはシステム要件のテストにもなりますが知見自体を検証することにもなるんです。これをしていかないとシステム要件として出てきた要件が本来の事業上の要件の解決策としてのIT投資かどうかを見抜くスキルを鍛える場をみすみす手放してしまうことになるんです。
さらに言えば、要件はそうかもしれないけれど、物事の本質＝顧客のペインは実は別のもので、それを解決するなら解決する対応方法は違うという物事を判断するスキルも身につきません。
一番怖いのは自分で決められるスキルを持っていないことだと思うのです。ただ口を開けて待っているだけのエンジニアに高い費用を渡せるかって思いますよね。
SECBOOKS ユーザのための要件定義ガイド (SEC books)
- 作者: 独立行政法人情報処理推進機構
- 出版社/メーカー: 独立行政法人情報処理推進機構
- 発売日: 2017/03/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
トラックナンバーとハネムーンナンバーと新しいナンバーに耐えられるチーム運営をするためにマネージャがしておくこと
ある週明けの朝一に、プロジェクトチームのプロジェクトマネージャ役のエンジニアが今にも泣きそうな声で電話をかけて来たんですよ。大のオトナが早朝から、それも泣きそうなくらいに声を震わせて、です。尋常じゃないことはすぐにわかります。
「すみません…。体調がおかしくて病院に行ったら数日入院することになりました。プロジェクトがあるのに…体調管理もろくにできなくて…うっ」
「今病院なんだ、そう。大丈夫。なんのために毎週顧客との週次ミーティングに出ていると思っているの。大丈夫。病院って、あ、そこね。了解。ワタシが代役しておくから大丈夫。信頼して」
トラックナンバー
プロジェクトのチームであるメンバがいなくなるとプロジェクトが継続できなくなる人の数を表す用語（かなりざっくり）です。
上記の例でワタシがいないとしたら、プロジェクトマネージャが入院したのでプロジェクトチームは止まってしまいます。
現実的には、仕掛り中のタスクがあるのでそれがあるうちは止まるかといえば止まりませんがプロジェクトとしての意思決定が必要になったら仕掛り中のタスクがあろがなかろうがストップします。
これまでのエントリでは、人的冗長化をロールとしてすることを推して来たのはこう言った経験が何度かあって、その都度カバーしてプロジェクトを止めないようにして来たからです。
予め想定されるトラブルをこのブログを読んているエンジニアが同じ鉄を踏む必要はないので。
協力要請とWBSとリポジトリ
心配させないように電話を切った後、まー、大見得を切った割にはどうしようかなと思うんですよ。現実としては。マネージャなのでプログラムマネジメントはしても、個々のプロジェクトのWBSやタスクの状態や次回のagendaまでは首を突っ込んでいないので。
今必要なことは計画どおりに進捗させることです。
計画どおりにの裏には、チームを動揺させない＝進捗を停滞させない＝パフォーマンスを落とさせないというのが1つ。
顧客に不安を持たせない＝プロジェクトが止まらないが2つ。
この2点が頭を過ぎったんですね。さては初めに何をするか。
チームに事情を話して協力を取り付けること、プロジェクトの目の前のToDoを押さえること、少し先のタスクの段取りをしておくことをしようかと思ったんです。
それには、情報が必要で、情報の源泉は、WBSとドキュメントや検討資料などのリポジトリですね。これがほぼ現状を表す状態になっているから大見得を切って安心しろといえたわけですが。
これはプロジェクト開始時や週次に行く前に資料の事前説明をそうした情報から受けていたので情報がほぼリニアであることが把握できていたというのはあります。
ハネムーンナンバーと新しいナンバー
トラックナンバーはブラックジョークらしいのであまり好ましくないという意見もあるようですが、組織の上でのトラックナンバーは悪い意味で自分自身があるなと思っている（当時は同じレベルまで育っていなかったので）のですけれど、バスに轢かれたとき自分たちが困らないようにね、と仕事は振って経験させていましたねぇ。
プロジェクトが止まる理由はネガティブな事由ばかりじゃなくていいことでも度が過ぎれば止まります。ハネムーンとかね。組織の中でというか年代であるタイミングである年齢層が集中的に結婚する時期があったりするんですよねえ。数年に一度とか。
どっちかといえば行ってこい長期で休んでいいよ派なので、予め教えておいてね、なんですけれど、これは出産も同じですね。わかったら教えてもらえれば7ヶ月後やそのあとの育児休暇も想定してアサイメントを考えるわけです。
これはベビーナンバー、と呼ぶのはどうでしょう。
新しい。このベビーナンバーは新米ママさんばかりではなく、新米パパさんも当てはまるというところがミソ。
ハネムーンナンバーもベビーナンバーもそれでチームから一時的に離脱したら何人まで耐えらるかという指標です。
対策はロールの冗長化でプロジェクトが止まらないようにしておこうぜ、という考え方になるのはいつものことですけれど。
スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー
- 作者: 和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2017/09/11
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
PMの後任に指名されても困らないようにチームのSPOFを潰せ
マネージャのみなさんと是非とも共通理解を得たいと思うのですがよろしいでしょうか。
計画した予算や期日どおりに推進できるエンジニアがいたら最大級の待遇をしてあげてください。
放置したままでプロジェクトが計画した予算や期日に終わることはありません。計画どおりに推進できるエンジニアつまりプロジェクトマネージャやリーダが機能して初めて計画どおりに進捗するのです。
みなさんが最大の誤解をしているのは計画どおりに、普通に進捗していることはとてもレアですごいことなんです。
ましてやプロジェクトチームのリーダ役が異動ややめてしまった後はどうなるかを想像するだけでもおぞましいです（未経験のエンジニアが後任なら）。
例として次のエントリがありますが、プロジェクトのタスクコントロールをしていなければアドホックに作業とをしているのですからモグラ叩き状態で仕事をしていることになります。これでは作業を区切るという概念がプロジェクトの中にないのと同じことですから残業し放題な環境をリーダ役が自ら提供していると思われても仕方がない事案です。まあ、自爆案件です。
エントリの前説にプロジェクトマネージャが異動して後任にメンバが繰り上がったと記載があるのを読んで思うことは、プロジェクトマネージャやリーダクラスがいついなくなってもいいようにしておこうな、チームのSPOFを作らないようにしておけってことですよねぇ。
情報の SPOF
プロジェクトチームが持つ情報は誰かが独占するものは何一つありません。全ての情報は、役割、分掌に応じて共有する必要があります。組織の中でのお仕事だからね。
プロジェクトの機微な情報はプロジェクトマネージャとマネージャとチームの中の役割ではなく組織を含めた関係の中で共有される場合もありますけど、それ以外の情報はプロジェクトの目的を達成するためにメンバが知り得た情報は持ち寄る必要があります。
情報を持ち寄りいつでも誰でもがアクセスでき、利用できないのなら情報にSPOFがある状態です。これでは、誰かメンバが朝の通勤でバスに轢かれてしまったら…。そうそうないことで例えていますが1ー2週間くらい（インフルエンザとか忌引とか）で休むこともよくあるので情報の断片が起きないようにプロジェクトを始めた時から共有する文化を作りこむ必要があります。
役割の SPOF
プロジェクトマネージャの異動もそうですが人的リソースとして役割を負っているエンジニアがチームから抜ける理由は様々です。
例え少人数のチームであっても、役割のSPOF対策はプロジェクトを開始するときから方針を決めておく必要があります。経験的にはチーム内でセカンドを決めておけばいいので。
困るのがリーダ未経験者をPMのセカンダリにする場合です。そのようなメンバ構成の場合は、ことが起きたときに経験させるのではなく、通常運転のときにこそセカンダリのメンバにタスクを一部渡して経験させ訓練をしておくことが対策の一つとなります。
そういったセカンダリのメンバがぎこちなくても機能させるためにはやはり情報のSPOF対策が運用できていることが必要になるのです。
スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー
- 作者: 和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2017/09/11
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ
- 作者: エイミー・C・エドモンドソン,Amy C. Edmondson,野津智子
- 出版社/メーカー: 英治出版
- 発売日: 2014/05/24
- メディア: 単行本
- この商品を含むブログ (3件) を見る
計測していなければ見積もれませんし、無理な工期短縮を断れません
この記事を電車の中で読んだとき、正直、こんなことをされてはプロジェクトマネージャやってられないなーと思いました。
ブコメでどんな反応なのだろうかと思って見たら、過去に酷い経験をされたエンジニアが多いようで人気のあるブコメを読めばこの記事を読んで共感するところがあるのもわかるような気になって来て、そうかこれ立場の違いで受け取られ方が違う記事だわ、と思ったのでした。まる
でもですねぇ、ある程度の精度で見積もれるのはその作業をするエンジニアなのでエンジニアが記事の対応をするとちょっとあなたの技術レベルって 大したことないじゃん、と思えなくもないんですよ。全体的に無理な工期短縮がある前提だったり、そんなもの進めて見ないとコードなんて書けないと言っているのですけれどね、コードのアプローチまでは慎重に進めさせてよと言っている割にコードのバッファを倍で申告するとかどれだけ自分の余裕を確保したいのかなーと。それ、仕様を決めるスキルかコードを書くスキルがもっと頑張ろうな状態なんじゃないのかしら。
立場が違えば好き勝手をいう
まず、立場が違うのであればそれぞれの分掌に基づいて事情があることは認めましょう。そうしないとエンジニアの立場も事情も汲んでもらえません。お互いの存在意義を理解することが現代の分業している事業構造から予め知っておかなければならないことです。
精度の高い見積もりはできません
はっきり言えば、ソフトウエアのコードの見積もりなんて精度高くできるものではありません。なぜなら、1つのプログラムとして同じコードは存在しないからです。複数のエンジニアに同じ仕様のプログラムを作ってもらったら実装はそのエンジニアが経験した知識を背景にコードとして具現化されるのですから。
仕様も依頼元の顧客の業務要件が何一つとして同じものはありません。つまり、プログラムの入力もプロセスも違うのだからアウトプットも違ってくるということです。
何一つ同じものがないのにどうして精度の高い見積もりができると思うのでしょうか。
根拠のロジックを組み立てる
それでも一番精度の高い見積もりが可能な立ち位置にいるのがプログラムを作るエンジニアです。
引用しているエントリを見る限り、見積もり対象範囲、つまり見積もりとしてどのような作業をするかや、作業で見積もろうとしている実現するプログラムの仕様をコードに変換するまでの仕様の詳細化をプログラムに変換できるところまで進めないとコードの見積もりはできないよ、と言っているように読めます。
これはごもっともなのですが、それを倍のバッファをとったりとと手段が悪手に感じざるを得ないです。
エンジニアとしては想定している作業と根拠のある想定工数を算出して、それを整理して説明しなければ仕事を依頼する側は理解すらできません。
そのためにも、想定工数の算出根拠、ロジックを持って見積もりをする習慣が必要です。
見積もりの基本は計測から
では無理な工期短縮を断り、エンジニアとして必要な工数を確保するためにどうしたらいいか、です。
まずは、テストが完了したコードに到るまでの作業を可視化することです。これは自分がわかっていればいいです。なぜなら、見積もりをするための計測する対象の作業だから。人に見せるつもりなら、理解して欲しいように整理はしておく必要があるでしょう。
その上で、実工数とアウトプットした実績値を記録します。とにかく、記録することを続けることが必要です。エンジニア自身があアウトプットできる量はエンジニア氏から知らないのですから。
根拠がなければ言い値の工数に合わせるだけ
もし、見積もり根拠となるロジックと実績値を持っていなければどうなるでしょうか。
依頼する側に押し切られて言い値の工数の期間に収まるように残業をするか、見積もったバッファばかりの期間を全部使い切ってしまうかです。これはどちらも好ましいことではないです。
やはり、ある程度の精度の見積もり＋プロジェクトのバッファで見積もりは考えたいですし、実行したい。そうしないといつまでたっても終わらないプロジェクトになるか見積もり金額の倍のプロジェクトになってしまうから。そうしたプロジェクトに参画すること自体、エンジニアとしてはかなり辛いことだと思うんですよ。
上辺だけの再発防止策がエンジニアをスポイルしていく
作業ミスをすれば再発防止策を暗黙で求められるので作業ミスをした方も決まりきったように再発防止策という名のアクションプランを添えて双方の担当は手打ちをするのがすっかり様式美になっている今日この頃ですが週末にトラブルを起こしたエンジニアの方々も同じように再発防止策を考えているのかもしれません。
効果のある再発防止策は取られない
人には目に見えていることしか認知できないので作業ミスが目の前にあり、再発防止策を含め早々に報告しなければならないときには認知に視野狭窄が起きるので目に入る情報だけで対処案を導き出そうとします。
手近な情報として入るものは、作業ミスをしたエンジニア、作業そのもの、作業手順及び作業環境が挙げられます。こうした情報の中から簡易性と安価な再発防止策が選択されるのです。
報告を受ける側が優秀で無駄なコストに対して敏感であれば行使した再発防止策は無駄であり、効果のないことは一目で判別できるので差し戻しを要求することもありますが、報告を受ける側もまた内部では報告する側に回るので手間暇をかけずに処理することを判断基準にしていると往往にして効果のない再発防止策だらけになります。
効果のある再発防止策か見抜くには
そうしたケースもあることを知っていれば、再発防止策を取った後に作業が増えていたら、効果のない再発防止策が取られている可能性が高いと踏んで良いです。
作業ミスは元々の作業手順に不備があって起きるものでその原因は作業する側にあるものではありません。その観点に立てば、不備のある作業手順が作業ミスを起こさない作業手順に置き換える必要があるので作業を増やす必要はありません。
この考え方の基本には、作業者の善意によって対策することは愚であるという背景があります。言い換えれば、作業者は必ず作業の注意事項に沿って全ての作業を行うのだから作業ミスは起きないというような性善説を根拠とした精神論では何も変えられないということです。
意図させない作業プロセスに修正する
エンジニアの仕事はOJTで仕事の仕方を自分の経験を通して覚えてしまうので、外部からの指示でその覚えた仕事の作業手順を変えることは本人が意図的に行動を取らなければ早々は変えられないのです。
自分の胸に人差し指を当てて聞いてみたらわかるでしょう。
であれば、作業自体を入れ替えて作業ミスを起こさないプロシージャに修正する必要があるのです。
ただ、冒頭に書いたように作業ミスを起こさない作業手順に変えるという再発防止策は取られずに上辺だけの見えていることに対する対処でことをやり過ごそうとするので無駄な作業にエンジニアの工数が吸い取られてエンジニアが作業にかけられる工数が減り、自分で考える時間も減っていくという馬鹿らし循環がぐるぐると回っているとエンジニアはますます思考しない作業者になってスキルレベルが落ちてくのです。
35歳SE、次世代の生殖活動をしないと愚痴を言われる
今朝も神様がなかなか降りてこない…。さて、昨日で連続2400日らしいですが今日も平常運転です。
システムエンジニアの35歳定年説というのがありますが、なぜ35歳なのかと言う所の新しそうな考えが降臨されましたので信者の皆様にシステムエンジニアとしての心構えとして広く布教いたしますのでご査収ください。
25歳前後のSEに期待されること
新卒のSEなら25歳くらいまでに仕事の仕方を一通り覚えて、自力で仕事ができるようになると楽しいですよね。任された仕事を自分でどう進めるかを考え、意見をもらって試行錯誤しながら終わらせる。考えていたように動けば嬉しいし、出来が褒められればもっと嬉しい。
仕事を覚えたらメンバのリーダとしての役割を期待されます。主に若いSEの仕事の面倒をみて必要に応じて指示をしたり、アドバイスをしたり。任されている範囲の仕事を全体のスケジュールの中で足を引っ張らないように、メンバと二人三脚、三人四脚してゴールを目指します。
ここで期待されるのはリーダ業ですが新人SEがいれば育成も期待されるし、具体的にスールとしての後進育成も期待もされるわけです。
こうしたリーダ業のアサインを名目に実は後進育成という次世代を育成するという会社の事業目標を試されているんですけれどね。それを誰も気づかないでやっているか放棄しているですよ。
35歳SEは生殖を期待されている
35歳を過ぎたSEは25歳くらいに仕事を覚えて自立してリーダ業を経験させられて裏では後進育成を任されていたということに気づかないで消極的でも積極的でも好き勝手をやっていると上司の目線で選別されていることは知っておきましょう。
組織としては常に次世代を育成し続けることが経営課題なのですから。だから、中堅SEの頃から訓練をさせているのです。
新人SEが子どもエンジニアで、35歳くらいまでが青年エンジニアだとするといよいよ適齢期ですから（現実のエンジニアの婚姻も大幅に遅れているようですし、40歳50歳になってもシングルエンジニアもかなりいるようですけれど）次世代を育てる年齢層になったと見ることができます。
つまり、青年エンジニアになるまで上司が親の代わりとしてSEを育ててきたのだからマネジメントという親の世代から見れば、早く次世代の有望なSEを生殖して育むことを期待されているのです。
35歳SEが次世代を育てられないなら
次世代SEを育てられないのであれば、親が結婚しない子にだんだんと諦めて言わなくなるように35歳エンジニアに対しても期待はしなくなるのはもっともです。
次世代を担うSEを育てるのか、次世代の事業を育てるのか、現業の事業を伸ばすかのどれかの推進役をしないのなら目をかけてもリターンが少ないので労力が見合わないのですから諦められるのと一緒ですね。
35歳SE定年説って、次世代を育てられないエンジニアがキャリアのラインから外されることなんじゃないのかしら。
そうした次世代を育てられないSEが多いと経営者は他所で愚痴るんですよ、実家の母親みたいに「うちのSEは仕事はできるのに次世代のマネジメントが育たなくて〜」と。
進行を妨げるステークホルダーは同じ船に乗せてしまえ
ステークホルダーの多い会議体を1人のメンバに任せているのだけれど、だいぶ難儀をしているにも関わらず思うように進捗しないように見えたので声を掛けてみたんですね。
もちろん、報告を受けている範疇では把握していたし、ステークホルダーについては先の別案件でコントロールしていたのでどうってことはないと思っていたんですけれど、エンジニアは専門性を持っているので全員が同じようにできるわけでもないですから。
あなたがしなければならないこと
担当する案件のリーダですから少なくとも納期には何かしらの活動の成果を出さなければなりません。もちろん、案件で掛けられるコストは決まっており、出来栄えも案件をスタートする際に設定した品質特性を持っている必要があります。
それはさておき、現状は検討テーマをagendaにすればステークホルダーは好き勝手に発言して収拾が手に負えない状態です。
そうした状況であなたは何をしなければならないか、あなたのToDoを書きなさい。
ステークホルダーはなぜ関わってくるかを知る
ステークホルダーが好き勝手に場合によっては大きな声で発言することは進行に協力してくれるのでなければ、好ましい状況ではありません。案件で期待する役割を演じてもらわなければなりません。
誰かと共同作業をする場合、共同作業を構成するリソースに対して何かしらの期待をするものですし、作業分担をするためにリソースと対価を交換するのです。プロジェクトであればこの関係性が成り立ちますが、ステークホルダーについてはコスト負担をステークホルダー自身が持つこともあり、プロジェクトと同じ構造にできないというケースがあるのでちょっと考え方を変える必要があるかもしれません。
ただ、ステークホルダーもその案件により将来の利害関係が生じることを想定しているためにリソースを持ち出してまで関与していることを把握していればそこがステークホルダーのウイークポイントであり交渉のバーターの源泉になることを押さえておきましょう。
ステークホルダーに期待を示す
ステークホルダーは案件の正に利害関係を持つ登場人物ですから案件のリーダとしては期待するとおりの活動を分担してもらわなければなりません。期待することがあるのであれば明示的に示す必要があります。ステークホルダーも案件の他のメンバと同じなのです。
ステークホルダーの利害のためにも案件のSOWを作りましょう。意思決定に関わるのか、案件の一部作業、例えば情報提供や案件の広報と明確に示します。
好き勝手に話すことを制限する
ステークホルダーには将来の利害関係があるため我田引水のためにときには大声でときには傍若無人に進行を中断するように好き勝手をすることもあります。
そうならないためには、話す時間を区切る制限をかける必要があります。発言を遮ると遮った人に対し負の感情を抱くので、各人の発言を個別に制限するのではなく、全体としての枠を嵌めることで討議メンバ全員で自制が働くように仕組みを作ります。
そのためには、
・案件全体のスケジュールを毎回見せて刷り込む
・各回の討議テーマを予め決めておき、討議時間を可視化する
・agendaでテーマの目標、ゴール設定、意思決定できない場合の影響を理解させる
・ゴールにそぐわない発言は参加者全員が注意を促す
の4点を案件が終わるまで続けることで仕組み作りが作れます。
これによりステークホルダーを自陣側に引っ張り込み、同じ船に乗せてしまうんです。同じ船に乗ってしまったら目的地に到達するまでは降りることもできませんし、協力するほかありませんから。
