エンジニアの採用はチームの文化で決める

エンジニアの採用では、だいたいこんなイメージになるのではないか。

1. 事前に業務経歴書を読む
2. 面談で、持っている技術スキルを尋ねる
3. 一番辛かった経験談などを尋ねる

1番目は参考になったことがほとんどない。なぜなら、エントリしてくるエンジニアの業務経歴書には、業種と適用技術しか書かれていないからだ。○○業界のプロジェクトで△△技術を使った、的な書きっぷり。

2番目は1番目では技量がわからないから尋ねることになるわけだが、上っ面だけで質問をする採用側もよく見かける。そんな質問でどのくらい技量が把握できるのだろう。

3番目なんてほとんど意味がない。例えば、修羅場やデスマの経験を聞いてどうするのだろう。修羅場やデスマ前提なプロジェクトマネジメント をやっているのだと採用側から漏らしているようなものだ。

中途採用なら即戦力を必要としている。であれば、即戦力で配置するポジションはどこなのだろう。アーキテクトのような技量を必要とするのだろうか。リーダのロールを任せたいのだろうか。であれば、アーキテクトに必要とされる資質に関する質問をした方が良いのではないだろうか。さらに、過去の事例のシステムデザインを持ち出して、自分ならどうするか所見を言ってもらうのが良いのではないだろうか。

ここまでは採用する側の欲しい技術的な資質を持っているかどうかだけを尋ねている。

では、採用したい組織の部門、チームに入って一緒に働けるかどうかはどうやって見極めるのだろう。採用候補者のエンジニアはそのエンジニアのキャリアとして経験を持っているのと同様に、採用したらjoinするチームにはこれまで培ってきたチームの家風、文化が育っている。採用後、エンジニアが新たな文化を持ち込むかもしれないが、それはベースに既存の文化に混入してくるのである。

要は、候補者がチームの文化に馴染めるかどうかを見極めなければならない。

チームは、候補者に対して、チームで持っているスキル、スキルレベルを伝える他に、文化として形作られた意思決定のスタイルを伝えなければならない。

少ない情報でも早く判断する、ある程度仕様を決められればとにかく作ってみる、全員でレビューしてから作る、などである。

採用で優先するのは、この文化に馴染めるかどうかが最優先事項だ。技術は資質を持ち合わせているなら、後から教育すればいい。

そう考えると、採用は変わってくると思わないだろうか。

世界で闘うプログラミング力を鍛える150問 ~トップIT企業のプログラマになるための本~

「コスト意識を持て」と言われたらリターンを増やすアプローチを考える

「コスト意識を持て」とよく聞くが、そういうことを言う人はその人自身にコスト意識がないことが多い。コスト意識を持てと言うなら、具体的にこうしろと言って指示する方がそれこそストレートに伝わるのだからコスト意識がある発言である。

まあ、それでもコストを知ることはエンジニアにとってもいいことだ。プロジェクトの限られたリソースをどこにどれだけ使おうとしているか、実際使ってみてどうだったかを理解するだけで働き方が変わってくるだろう。別のことに集中してしまうと忘れてしまうかもしれないが、それでも時々思い出すだけでもいい。

例えば、会議の値段を考えてみよう。

５人でプロジェクトを回しているチームがあるとする。

• プロジェクトマネージャ：1名
• リードエンジニア：1名
• エンジニア：3名

簡便的に時間給を以下とする。

• プロジェクトマネージャ：1万円/1時間
• リードエンジニア：5千円/1時間
• 担当エンジニア：3千円/1時間

会議体として、進捗会議を1時間開催するとする。

ではこのプロジェクトの会議のコストはいくらか。

1時間あたり24,000円掛かっている。大した金額ではないと思うかもしれないし、人によっては「高いな」と思うかもしれない。

1回当たりだと感覚がわからないかもしれないので3ヶ月（4週＊6ヶ月）で計算するとどう感じるだろう。

576,000円となると会議のコストに対する感じ方が変わらないだろうか。感覚が掴めない人は、自分の趣味のグッズが何個買えるか換算するといい。

ここで、あなたが会議のコストに対して「高いな」と思ったなら、何が高いと思ったのだろうか。

何に高いと感じるかは人それぞれかもしれないが、『会議』であれば会議の結果が576,000円に見合っているかどうかに対して『高い』と感じたのではないだろうか。

会議の目的が情報共有やノウハウの共有で、その会議を行うことで会議後の手戻りやメンバ一人ひとりの試行錯誤が減らせるなら24,000円以上の価値を感じ、安いと思うだろう。逆に会議を開き、情報共有をしたにも関わらず共有されたことが現場で繰り返されたなら、その会議は24,000円の価値がなかったと言うことになる。

同じように、進捗会議で遅延や困っていることを共有していなかったら、進捗会議の意味がなさないのだから、高く感じるだろう。

週1時間の進捗会議を日次の朝会に変え12分で終わるように変えよう。

週次（週1回、1時間）の進捗会議と日次の朝会（12分*5回）の会議時間に掛かるコストは同じである。1回当たりのコストが変わらないように時間を設定しているから変わらないのは当たり前だが、会議の価値は上がっている。

なぜなら、日々、進捗がわかるようになることとでプロジェクトのリスクを小さなうちに識別できるようになるためである。

「コスト意識を持て」と言われて何かアクションをしなければならなくなったら、会議などのアクティビティによるリターンをコスト以上の物を毎回得られるようにする策もあるが、間接的にリターンを増やす（マイナスリスクを低減する）仕組みを変えることも1つの手である。

会議でスマートに見せる100の方法 (早川書房)

クラウドサービス時代の納入を考える

成果物を委託者に引き渡す行為を『納品』と使っているケースがあるが、『納入』の方が正しいと思うのだが。ここでは一旦、受託者が成果物を納める行為を『納入』と統一することとする。

さて、クラウドサービス時代の納入を考える前に前時代的に思える納入を知っているだろうか。調達仕様や慣習や受託者のプライドかどうかは知らないが、以下のいづれかだろう。

• 黒バインダ（A4）＋金箔押し＋メディア
• キングファイル（A4）＋メディア
• メディア

契約書に記載された媒体で正副の2枚を納めるケースもある。納入自体は、契約の完了のタイミングで行われるため、いわゆる年度末に近い2月から3月上旬に掛けて複合機が活躍することになる。

ただ、紙による納入は委託者側も保管場所を取ることと構成管理の手間が掛かるので媒体による納入へシフトしている。

さて、クラウドサービス時代の納入をどう捉えればいいか。

ここで、クラウドサービス上で構築するWebシステム、サービスなのだから、従来のような設計書ではないのだから納めようがないと脊髄反射してはいけない。

ヒントは前時代的な納入の例に記載してある。一部のエンジニアには、頭では理解できているが、実際の業務に落ちてきてから異論を唱える方が存在する。しかし、それではエンジニアが思っているような納入はいつになっても実現できないことをそろそろ学習しても良い頃だ。

バックログから開発テーマの優先順位付けを行い、チケット管理システムやカンバンを使ってタスクをアサイメントし、テストを書き、コードを書き、TDDし、デプロイさせてチケットをDoneする。

ドキュメントなんか書くより、動くコードを書くことを優先しているんだと言うかもしれない。アジャイルソフトウェア開発宣言に

「包括的なドキュメントよりも動くソフトウェアを」

と書いてあるじゃないかと言うだろう。契約の履行という意味合いでも動くソフトウェアを納入することは正しい。ただ、顧客が契約で成果物に対するオーダをしてきたらどうするのだろうか。

「契約交渉よりも顧客との協調を」

では受託者から委託者側に契約交渉をすると捉えることができるが、逆の場合はどうするのだろうか。つまり、顧客がこの成果物仕様で納入して欲しいと言ってきた場合である。

対価を支払う契約であれば顧客の指定する成果物を納入するのも顧客と協調しているのではないか。

もちろん、いまどき、詳細なプログラムの仕様をwordやexcelで書くよりツールを利用し、ツールのデータを納める交渉はした方がいい。

端的に言えば、契約時に成果物をエンジニアが納入したい形式で契約を締結しておくことが必要なのだ。その契約書にドキュメントを一切記載せず、ドキュメントはモデリングツールなど受託者のしているデータ形式で納めるとすればそれを納入すればいい。

ただ、次のことに配慮しなければならない。

契約書に記載された成果物は納めなければならない。契約には期限ある。そのため、納入する成果は必然と納入時点でのスナップショットになる。リポジトリは納入用に分けなければならない。

それは委託者側の外部監査、内部監査が行われた場合に、契約書に記載の成果物がビシッと揃っていなければ指摘、是正勧告されてしまうからだ。

現場からオフィスまで、全社で展開する トヨタの自工程完結―――リーダーになる人の仕事の進め方

新メンバだけのチームで失敗できないプロジェクトマネジメント（経験談）

野暮用で00年代のプロジェクトの情報をひっくり返したのだが、これがまた、今更ながら良くキャリーしたなと。若さとは何事もやり遂げるバイタリティの1つの要素なのかもしれない。

いつもよりちょっと長め。2倍くらいの分量。

プロジェクト概要

みなさんがプロジェクトの背景を理解するために。

• 他のメンバが考えた机上のソリューションのモデルはあったが、実績はなかった。つまり初案件。
• プロジェクトメンバは誰一人一緒にプロジェクトでデリバリしたことがなかった。面識があったメンバが数人。
• チームは、社員とパートナーで編成。
• 地方の遠隔地プロジェクト。
• 当たり前だが、プロジェクトなので作って解散。継続的改善なんぞそんな悠長なことをやってられない。改善が必要ならプロジェクトの中で解決する必要がある。

開発方針（のようなもの）

開発方針を説明した記憶がない。今ならするだろう。なぜなら、同じバスに乗ってもらわないければならないからだ。

• ソリューションのモデルは概念としてだけ取り入る。ソリューション自体は、業務知識を持っていたので考え方はわかっている。モデルをどうデリバリに繋げるかの組み立てさえできれば良い。
• 提案仕様と成果物からWBSのざっくり展開。これを作りたい、他に作らないとメンバが困るものをメンバに提案してもらう。導入手順書や開発メモといった、中間生産物のようなものだ。
• コミュニケーション大事。遠隔地なので開発拠点を不在にすることが出てくる。不在中に手が止まってしまうことは進捗上は困るわけだ（現実にはほとんど心配がないことだが）。そういった心配事は上の全体WBSを渡しておけば次にやることはメンバが自分で考えてくれる。
• チームのリポジトリと組織のリポジトリ。プロジェクトのリポジトリを作る。全部、センター管理することでプロジェクトのナレッジを共有できる仕組みを作っておく。現実には自分のタスクにならないと関連文書なんて見ないだろうが、見たいときに見れる環境を作るのは大切。

実際にやったこと

作業プロセス

• 上流工程（要件定義、基本設計）のうち、要件定義からデータ設計を開始するなど上流に決め事をきちんと決めていく。決定を躊躇すれば顧客も詰める。
• これは開発での制約もあったため。
• 契約がある以上、実績のないモデルより、成果物を作るためのWBSを展開して、メンバと一緒にWBSを作っていく。プロジェクトの主役はメンバ。

コミュニケーション

• プロジェクト開始から朝会を毎日実施。ほぼ「初めまして」メンバだったので、プロマネがやりたいことを理解してもらうことが大事。
• 逆に、メンバがああしたい、こうしたいを取り入れることも大事。
• 今思い出してみても、どうして最初から朝会をやろうと思いついたのか思い出せないが、それまでの経験で、『トラブってから朝会をやるなら、最初からやればいいじゃん』と思っていたのだろう。
• プロジェクト全体のWBSを毎朝配布。もちろん、WBSに進捗実績を反映するのはプロマネのお仕事。
• 今のアジャイル開発の朝会と一緒で、『昨日やったこと」「今日やること』『困っていること』を（当時アジャイル開発はまだ知らなかったが）朝会で共有。
• 前日に更新したWBSを全員に配布して、今チームが『どこにいるか』とを共有。プロジェクト全体のWBSを毎日配布することで、今やっている作業じゃなく、次の作業、次の工程を刷り込もうと思っていたのかもしれない。 

作業見積もり

• WBSで成果物を分解したあと、作業工数の見積もりが必要だが、開発工程からは割り込みがない理想時間で見積もったら何時間で終わるかでスケジュール化。
• これは個々のWBSにバッファを持たせるのではなく、開発工程（つまり、プロジェクトチームとして）という全体のバッファにまとめておきたかったため。
• このプロジェクトの前にToCの本を読んでいたことが実務で活かされたのだろう。これでチーム全体で前詰する環境ができたし、メンバは理解して協力してくれた。

WIP

• チームメンバのスキルセットとして難易度の高い開発テーマをアーキテクトに集中させていたが、想像のとおりアーキテクトがボトルネックになった。
• 当たり前である。原因はプロマネがそうなるように仕向けた結果だ。
• 毎朝朝会で実績を確認しているので進捗遅れが後続作業を先送りしてまうプレッシャを一番感じていたのはプロマネ自身だ。ヤバさを感じ、これ以上耐えられなくなるタイミングで後続作業を剥がし、他のメンバの希望者にやってもらった。
• なんだ、最初から全員でやればよかったのだ。

プロマネに必要なこと

• プロジェクトを終わらせようする意思。
• 成果物を確認するまで気を抜かない。やったは信用しない。信用するのは成果物だけ。
• 成果物を作ってくれるのはメンバ。メンバが成果を出せる仕組み、環境を作る。
• 大局的には悲観的に、日々は楽観的に。

ザ・ゴール ― 企業の究極の目的とは何か

カンバン仕事術

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう！?

「○○して」と言われてイラっとしたら

誰から、そうだな上司やプロマネから「○○して」と言われてイラっとしたとしよう。

イラっとした自分は「何に」イラっとしたのだろう。

エンジニアはチームを組んで仕事を分担するやり方を取る。一人で全部やるには広く深い技術が必要になるから分業をせざるを得ない。

自分がチームの中でどういったロールにいて、チームメンバとどのような関係にあるかを自分で間合いを計りながら存在価値を確保しようとする。

リーダの役割で他のメンバと協働する環境を作ることに腐心しているかもしれないし、あれこれ指示を出しても思うように動いてくれないメンバに悩んている最中かもしれない。

自分はどうして「○○して」と言われてイラっとしたのだろう。

自分の経験から言うと、ストレスを感じていることに対して何かを言われるとスイッチが入るときがあった。流石に今の年になるとほぼなくなった。良いのか悪いのかは知らないが。ただ、それで困っていないので良いのだろう。

「○○して」と言われてイラっとすることの対処としてアンガーマネジメントが良いのではないかと言うことを言う人がいた。多分、イラっとした結果だけを取り出してそういったのだろう。もしかすると、そう言った人は話を聞くとアドバイスをしないと死んでしまう病に罹っているのだろう。

アンガーマネジメント自体、怒りを感じたときに自分のことを第三者的に外から見て、怒りの感情で反応することをコントロールする仕組みであるから、感情を抑えることが目的になる。

「○○して」の「○○」のことが敏感に反動するほどストレスに感じているのではないかというコメントをくれた人がいた。自分としては、この意見に同意したい。気に掛けていたことを触れられたからイラっとしたのだろう。これも自分の経験から言えばとても納得感がある。

自分で（ストレスを感じるほどのことに対して変えたい）実現したいことがうまくできていない状況で、外からそこをツンツンされると不快になる。自分でギャップを感じているのに別の期待が押し付けられるからだ。

こうした「○○して」と言われてイラっとしたと感じたら、やっぱり何かしら自分自身が感じているストレスを変えていくアクションをしたほうがいいと理解して、何かやってしまうと言うきっかけだと捉えるのが良いと思う。

ストレスに感じていること関係するメンバはそれほど気にしていないことが多いのでアクションを取っても反発を食うことはそうそうなく、肩透かしとなることの方が多いのだから。

そうそう、不思議なことに自分により身近にストレスを感じていることに対する方が、イラっと感じやすい。プロジェクトの大きな問題になると手に負えなくなって放棄するのか急に他人事になってイラっとしなくなる。

イラっとしたら、自分がイラっとしなければならないのかを考えてみるといいのかもしれない。

反応しない練習 あらゆる悩みが消えていくブッダの超・合理的な「考え方」

休めないエンジニアは自ら擦り切れてしまう

メンバには基本的に残業はしないように指示している。なぜなら、残業をすると家に帰っても何もできないからだ。住職が近くてもdoor-to-doorで小１時間は掛かるだろうし、１時間を超える方がほとんどなのではないか。そんな通勤時間で帰って、一人なら途中のコンビニかスーパーで惣菜を買って、冷房が効き始める頃にシャワーを浴びでちょっとネットをするだけで24時近くなってしまう。

そんな生活をしていたら、翌日いい感じで働けないじゃないか。

それでも担当の仕事の波はあるので、少しは残業をしているようだ。予算的には残業をすることを見込んでいるが上述のことがあるので極力させないが、残業したら必ず申告をさせている。労働時間の対価は受けってもらわなければならない。

そんな働き方は一向に関係がなく、休みを取るメンバはしっかりと取るし、休めないエンジニアは休めない。あれ、おかしいと思った人はその感覚は正しい。休みを取るとくれば、休みを取れない、となると予測するはずだ。でも、休めない、と続いた。

休みを取るエンジニアの価値観はどうなっているのだろうか。

観察していると、休みを取るエンジニアは、家族との都合で予め予定を調整してから休みの計画をスケジュールに入れてくる。（家庭内の調整をした上で）本人が休むことを計画してくるのでスケジュールはある意味フィックスドである。もちろん、仕事が繁忙かどうかを見極めた上での家庭内調整をしているので確実に休む。戦略的休暇取得である。

一方の休めないエンジニアはどういった価値観なのだろうか。こちらも全く休まないということはないが、休む理由が他者の都合なのである。家族から頼まれごとがあってとか、友人に誘われたのでとかである。休む起因、休む理由が休みを取る自分自身からではない。

だから、そういった外部からの起因がなければスケジュールを仕事で埋めてしまう。一見、こうしたエンジニアの方が外部のトリガーがなければ休まないので生産性が良さそうに見えるが実は生産性が悪い。なぜなら、休む予定を確実に休むために工夫をしないからだ。後者の休めないエンジニアの方が残業をしている。

自分の休み方を思い出してみよう。

休む理由はなんであれ、自分から休むことを決めた場合、その日程を確実に休むために仕事を片付け始める。そこで改善なり工夫をしているのだ。

休めないエンジニアは、仕事の予定を入れてしまう。そして休めない、と訴える。アプローチが間違っている。先に、休みの予定を入れてしまうのだ。その後で仕事を調整すればいい。

この暑さで毎日働くのはナンセンスである。休みを取り、身体の負荷を下げなければ続けられる仕事じゃないし、アウトプットし続けて擦り切れて壊れてしまう。

サマーウォーズ

1on1でスキル不足を間接的に

1on1をやっているとついつい目標達成に満たないだろう項目を取り上げて話したくなるのだが、そこはグッと我慢して本人からあれこれと相談してくれることを話したい。

ある中堅エンジニアとの1on1で、ちょうどフォローアップしたばかりでメンバは話すことがないと言う。

その日の1on1を始めて、メンバから話すことがないと聞いたとき、次の4つが繋がった。

1. 若手エンジニアがエンジニアとしての基礎力がかなり危うい状況にある
2. 中堅エンジニアは資格大臣（たくさん持っている）だが、実践力が足らない
3. 中堅エンジニアは自分は技術力を持っていると思っている
4. 中堅エンジニアは後進育成の活動をしていない

項番1は、WBSをWBSとして作れない。その上、WBSを作らないから作業が進捗しないし、作業上の問題をタイムリーに相談しない。

項番2は、ミーティングスペースで別のメンバとの会話が聞こえ漏れて来た話を聞いてみると、（確かに複雑な状況であったが）レビューアの目に叶うドキュメントが作れていない。

項番3は、資格は持っているし、仕事を任されている自負があるので技術力もあると思っているが、実際は項番2の状態なので自分の実力の評価にギャップがある。

項番4は、後進育成も中堅エンジニアのテーマだが、自分から積極的に関わろうとしない。

4つをつなぎ合わせて、こうしたらいいんじゃないかと話を（まさに）作りながら、話始めた。

若手エンジニアのスキルレベルをどう思っているかを尋ね、あまり知らないことを確かめた。もちろん、しならないだろうと言うことを想像していた。その次に、このままでは若手エンジニアは将来エンジニアとして困ってしまうだろう、と伝える。ここでWBSを持ち出す。

WBSは作れるよね、と。もちろんですよと言う。いいかい、中堅エンジニアの経験則ではなく、方法論としてWBSの作成手法を教えられるかと聞く。できますよ、○○の資格を持っていますよ、と。

OK、では、WBSなどエンジニアの基礎スキルの育成を手伝ってもらうことはできるか、とお伺いをしてみる。中堅エンジニアは、自分が持っているスキルを活かせて、期待されていることをやれると思ったのだろう、即答してくれたのでお任せすることにした。

ここの狙いは2つある。

1. 若手エンジニアの基礎力を身につけさせること
2. 中堅エンジニアに若手エンジニアの基礎力を身につけさせる教育をさせることで、中堅エンジニア自身の基礎力をおさらいさせること

若手エンジニア自身は頭脳は優秀なので、人のて赤に染まった経験則ではなく、形式知としての公式を覚えてもらう方が結果がすぐに見えるようになることを期待できる。

来週以降が楽しみで仕方がない。

シリコンバレー式 最強の育て方 ―人材マネジメントの新しい常識 1on1ミーティング―