技術者はexcelで自分の思考を拘束する
ここ10年くらいの新卒でエンジニアになった若手エンジニアは本当に優秀だと感心している。学歴もそうだし、実際、業務を任せると自分が同じ歳の頃の仕事ぶりとは雲泥の差だ。一生懸命に仕事をしていて、行き詰まって、一人で抱えているとついつい声をかけてしまう。
そんな若手エンジニアにどれだけの間、先を進んでいられるか。願わくば、20年くらいの経験知と少しだけ読んだ書籍などの形式知の貯金がまだ底をついていないことを過去の自分に対して期待したい。まだ、のりしろくらいのアドバンテージを保っているがそれがいつまで持つかはわからないが。
優秀なエンジニアは今も自分が20代だった頃の同僚でも同じように、頭の回転が滅法速い。頭の回転が速すぎて、言語化が追いつかないので興奮して言葉がたどたどしいように見えるが、そうした光景を見るたびに頭脳の回転が早い資質を持っているんだな、と思うようになったのはそうした資質を持つ同僚と仕事をしてスペックの違いを嫌と言うほど経験したからだ。
自分の頭で考えていることと言葉や図式で表現することが一致すること自体、実はそれほどないし、スキル的に高度な方に入ると思っている。
頭で考えているようで、それを言葉や図式で表すと全然考えが浅いとこが多い。それを知るためにもさっさと形にした方が自分のためなんだよ
— ふみさん (@finayama) August 2, 2018
例えば、 システム開発だと機能の論理構成や業務運用の運用フローなど実体のあるものを書き起こすのではなく、今はまだないものを一から書き起こす場合にその傾向が強い。
考えている風で実は触りも考えていない。
その考えていない程度を知ることはとても重要だし、それは早いうちに知るすべを持っていた方が良い。
自分と一緒に仕事をする若手エンジニアには、仕事に手をつける最初に流れ(フロー図)や関係図(関連図)や組み合わせ表を『手書き』するといいことがあるよ、と触れ回っている。
なぜなら、いきなりexcelやpowerpointで図形や表を書き始めてしまうと綺麗に見えるので、実際の中身のもみ加減が足らなくても満足してしまうのだ。これが拙い。
問題は、自分が思っているようなレベルでなくても『満足してしまう』状態を自分で作ってしまうことだ。
例えばexcelを使えば必然と2軸の表を使うのだが、人は持っている情報や知っている情報でしか考えることができないから、とりあえず行列にプロットしてしまう。そうすると本来は別の軸で整理しなければならなかった情報が思っていたものとは違う表現になってしまうが、なにせ、綺麗にまとまっているように見えるのでそこで思考が止まってしまう。
一度切り口を作ってしまうと新しい情報の切り口を作り出すのはとても難しい。
繰り返しになるが、一度自分で形として表現してしまうとその表現したもので自分の思考を縛ってしまう。
だから、そこで止まってしまうのだ。
その罠に嵌らない、ブレークスルーする方法が手書き。フリクションのカラーサインペンを使うと消せるのでいい。普段使わない色を使うのも形から変えようとするので良い。
バカに思えるかもしれないが、まあ、騙されて図式や表を手書きで描いて欲しい。
描きながら考える力 ~The Doodle Revolution~
- 作者: サニー・ブラウン Sunni Brown,壁谷さくら
- 出版社/メーカー: クロスメディア・パブリッシング(インプレス)
- 発売日: 2015/01/16
- メディア: 大型本
- この商品を含むブログ (1件) を見る
パイロット 消せるカラーサインぺン フリクションカラーズ 12色 SFC-120M-12C
- 出版社/メーカー: PILOT
- 発売日: 2015/11/14
- メディア: オフィス用品
- 購入: 3人 クリック: 48回
- この商品を含むブログ (1件) を見る
時間を奪う妖怪PM
昔話なのだが、ある部署に異動して少し経ってからのことだった。うろ覚えだが、もしかしたら夏の頃のことかもしれない。
執務室に戻ってくると若手のエンジニアがプロマネの側に立っている。プロマネに質問でもしているのかと思ったらどうやら全く違った。業務のことだし、コンフィデンシャルな話であれば会議室に行くだろうからプロジェクトのことについて話しているのだろう。
自席に戻りスタッフに小声で聞いてみたら、プロマネが若手エンジニアを呼びつけ、立たせたまま、自分は椅子にふんぞり返って説教をしているらしい。いつもこうなのかと尋ねるとスタッフは「そうなんですよ」と言う。
自分が担当するプロジェクトの作業に戻って仕事を再開したのだが、暫く経っても続けている。
もう1時間くらいやっているのではないかと思うくらいやっている。早口で、割と通る声でやっているのだから周りは堪らない。
それでも誰も助けに入るなり、会議室に行くように促したりする人はいない。
ここまでを読んで拙いところが幾つあるか数えて欲しい。自分では5つを挙げた。
- 若手エンジニアを呼びつける
- 若手エンジニアを呼びつけ立たせたまま話し始める
- 説教を全員の前でしている
- 声が大きい
- 誰も助けに入らない
自分ならこうする。
- 用事があるエンジニアの席に行く
- 時間が長くかかりそうならお互い座る。短時間ならこちらは立ったまま
- パーソナル(指導の意味合いを含め)な話題なら会議室で
- 普段の声量で
- 間に入る
ところで、上に挙げていないことで1つ重大な事項がある。それはエンジニアの貴重な1時間を説教で奪い取ってしまっていることだ。
よく考えて欲しい。仮に進捗の良くないことが説教をする理由だったとして、その進捗が遅れていることを忘れて1時間も説教をすること自体がプロマネの価値観としておかしい。
やってしまった(進捗を遅らせてしまった)ことを終わってからクドクドと1時間も話してどうなるのだろうか。単なるプロマネが若手エンジニアに期待していたパフォーマンスを得られなかったことに対する不満をぶつけているのではないだろうか。
離れた場所から見ているとよくわかる。
進捗が遅れている上に1時間を若手エンジニアから奪っているのだ。これでこのエンジニアは1時間以上余計な残業をすることが決まったも同然である。1時間ではない。1時間以上である。なぜなら1時間も説教をされては席に戻って気持ちを切り替えてコードを書けるだろうか。そんなことができるくらいなら進捗なんて遅れないだろう。
プロジェクトマネージャもリーダもしなければならないことは、エンジニアの作業をする時間を固めて確保することである。決して細切れにしたり、作業時間を奪ってはいけない。
エンジニアの時間を奪うプロマネは、妖怪でしかない。
今、あなたの後ろに立っている人は妖怪ではないか確かめた方がいい。
- 作者: Thomas A. Limoncelli,株式会社クイープ
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2006/10/19
- メディア: 単行本(ソフトカバー)
- 購入: 11人 クリック: 322回
- この商品を含むブログ (153件) を見る
これからリーダになるエンジニアがやってはいけないこと
自分が初めてリーダ役をやったのがいつだったか覚えていないが、少なくともエンジニアになって3年目くらいにはやらされいたかもしれない。そのときにはリーダだからとか全くリーダーシップを発揮しようとか、こんなリーダになりたいとか考えたことがなかった。意識したのは初めてマネージャになったときだ。そういう意味ではマネージャになったときにリーダとして意識したことにはそう考えた背景がある。
仲良しクラブを作る
リーダはその時々の状況によりメンバとは違う判断をしなければならないときがある。それは組織の方針に基づく判断であったり、マネージャの感覚によるものかもしれない。何にしろ、そのような判断をするときが遠からず来る。
仲良しクラブは一緒に過ごすときは楽しく感じるが、その場限りの時間をお互いに雰囲気を壊さないように問題を避けて取り繕う。リーダが問題を避けていてはチームが進捗出来ない障害にぶつかったときにチームを引っ張ることができない。
問題は問題であることをチームに伝え、チームが解決するように促さなければならない。問題を正面から向かって取り扱うことを決め多としても仲良しクラブではそれを乗り越えることはできない。
手順を指示する
リーダになるくらいだから技術的に長けていたり、強いリーダシップを持っていたり、絶妙なマネジメント感覚を持っているのだろうと思う。ぜひ、どのようなリーダシップを発揮しているか教えていただけると嬉しい。
手順を指示するのは、言ったとおりの手順で操作することを求めていることと同じである。つまり、エンジニアをオペレータ扱いしている。オペレータは手順どおり操作を行う。操作にまつわる異常を検知し、効率的に作業をするプロである。
エンジニアはどうだろうか。コードを書くときに実装のロジックを指示されるだろうか。仕様を決めるときに仕様の決め方を指示されるだろうか。
エンジニアはエンジニア自身が持っている形式知と経験知をフルに活用してアウトプットする。そこに必要なことは裁量を与えることである。
大体、リーダになるエンジニア自身だって箸の上げ下げまで指示されてやる作業はほんと作業でしかなく、つまらないことは知っているだろう。
メンバを見ない
同じプロジェクトルームや執務エリアにいるのだから、物理的に見ないというわけないは行かない。ただ、現実に目の前で起きているチーム内のメンバ間のコミュニケーションやチームの対外的なコミュニケーションの中で起きていることを見ないことはできる。
コミュニケーションは、発信元から目的を持って意思伝達する行為であるが受け手がそれを受け損ねたり、スルーすることだってある。そうした伝達のエラーが続けて起きると簡単に拗れる。
リーダのエンジニアとっては信じられないかもしれないが、人の感情は簡単に豹変することを知っておいて欲しい。
そうしたコミュニケーションの問題を放置していてはいけない。ものすごくパフォーマンスに影響するし、影響の即時性が高い。知まり、生産性が低下する。
リーダになったらメンバをよく観察しなければならない。
何にしろ、まだリーダを経験していないのだから、完璧なリーダでスタートするなんて思わないことだ。いつでも、素人リーダで勉強中が丁度良い。
あなたが落としたものは、テストコードですか、テストケースですか。
タイトルはアレだが、主旨は『テストを書け』であると理解した。同意。
テストを書いてと言われたら、
- テストコードを書く
- テスト項目(仕様)を書く
のとどっちが多いのだろうか。60万人とも80万人とも言われるエンジニアでアンケートを取ったら多分、後者の方が断然多いのではないだろうか。
ご存知のとおり、テストコードを書くというと仕様からコードが動くケースをコードで表現することになる。それに合わせて実際のプロダクションコードを書けば、仕様のとおり書けるわけだ。
後者もご存知のとおり、V字モデルとかW字モデルなどではテストフェーズに対応する設計の仕様をテストケースとして書き起こす。
ところが後者の場合、1つ問題がある。設計の仕様からテストケースを起こさず、コードからテストケースを起こしてしまうパターンである。このやり方をするとUTなどではバグが出ない。当たり前だが、コードに合わせているからである。
ではインフラエンジニアのテストはどうすればいいか。気を失いそうなほどのパラメータがあり、変更したパラメータの組み合わせでテストケースが必要なときもある。テスト対象の環境ごとにテストが必要となったり、仕様する端末の仕様も変わったりする。
インフラエンジニアがテストを書く前の上流設計の時点でテストの環境(端末、NW、サーバ構成)を整理し、テストの大項目、中項目くらいまで落とし込むとテストにおける制約や条件がはっきりとするのでテストのざっくり仕様を作るのが良い。まあ、○字モデルにしたら設計工程でテスト工程の設計はしておくものだが。
何れにしても、手持ちの情報でテストを考えるのではなく、立ち止まり、ちょっと考える時間を作った方が結果的に効率的に開発が進められるようになる。
誰だって行き当たりばったりで進めてバグを気絶するほど出して手戻りをして手作業でテストなんてしたくないじゃないかと思うのだが。
今どき「修羅場を経験してこい」なんて言われても何も得るものがない
SESはエンジニアとして成長しないとか、エンジニアとして成長するために勉強をするとか、様々な手段でエンジニアの不安を煽るエントリがある。
このブログでもネタ的には同じようにカテゴライズされそうなテーマを扱うこともあるが、マネージャの立場と年齢的に自分が経験したことを事例としてフィードバックすることで、これから多くのことを経験するエンジニアに同じ経験、轍は踏まないでいいよ、と言う意味がある。
若手のエンジニアの方達には余計なお世話かもしれないが。
それでも経験を書くのは、声の大きい一部のマネージャやシニア層のエンジニアの
「俺たちが修羅場を潜ってきたから今があるんだ。同じ修羅場を潜ってこい」
的な苦労の押し付けと言うか、俺の痛みを知れ的なやり方が精神論だけでなんのメリットも得られないからだ。
こうした、『同じ経験を』的なことを言う場合、『自分と同じ』と言うところがミソだ。同じ経験をすることで初めて仲間意識を持てるという、精神年齢が小学生レベルでしかない。
第一、修羅場を経験しないと仕事できないのなら、修羅場を実践できることがエンジニアのコンピテンシになっていなければならないはずだ。でも、ITSSでもPMBOKでもアジャイル開発でも研修の講座でも修羅場がテーマとして取り扱われることはない。
つまり、経験しなくて良いことなのだ。
だってそうだろう、必要なら研修の講座になっていなければおかしい。
見方を変えれば、修羅場を経験したエンジニア、元エンジニアはプロジェクトや技術やその他のプロジェクトでシステム開発を上手に進める手段や技術やスキルを持ち合わせていなかった、ということだけの話だ。
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
- 作者: エドワード・ヨードン,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2006/05/03
- メディア: 単行本
- 購入: 9人 クリック: 355回
- この商品を含むブログ (119件) を見る
50代で改めて実感するHRT
野暮用のスライドを作っているのだが、ふと、あるページに書いたことに間違いがないかを自分ではない誰かに見てもらおうと思った。
コミュニティの幹部メンバにそのページだけをシェアして、意見を照会することにした。便利な時代だ。見て欲しいスライドをPDFなりpowerpointなりスクショなりでシェアすれば、時間がある人がコメントを即座に返してくれるのである。
この即応性はスマホだからなんだろう。PCとメールの時代では、こうは行かなかった。PCを立ち上げ、メールを見た人が反応するだけで、PCを立ち上げるという行為に依存するため非同期にならざるを得ない。即、コメントが欲しければ架電するほかない。
それはさておき、スライドを見せる相手により、言葉を変えたほうが良いのではないかと複数名のメンバからリプライがあった。野暮用のスライドは、置き換えようとしている元の言葉さえ実践したことがなく(そのはずだ)、置き換えてしまうとちょっと飛躍し過ぎて受け止められないのではないかと思う。
とは言え、コメントはもっともなので表記を併記し、表現を広がって受け止められるようにすることにした。
いやはや、ありがたい。
何がというのはシェアして即応性のあるコメントが得られる道具立てのことではない。
50代になって、頼れる協力者がいるということ自体が、である。幹部のメンバはそれぞれの場で様々な発表のスライドをシェアしているが、そうしたスライドを見るたびに勉強になるし、自ら発表をすることでコメントを貰える。
なぜそこまでありがたがっているかというと、聞ける対象となる相手が減っていくし、年齢が上がれば上がるほど、刺さるコメントが減っていくのだ。
こうした知見や見識に対するフィードバックを継続して確保できるのは、とても貴重な財産となる。他者の意見を素直に聞く姿勢を続けなければならないし、自分の間違いや誤解を自分で正さなければならないからだ。
こうした所作をどこかで読んだ気がすると思いつつ、どんなキーワードでかと並べてみたら、
- 謙虚に耳を傾ける
- 意見照会するメンバを信頼している
- 自分とは違う価値を持っているので尊敬している
の3つがあげられる。
これなんだっけと、思い出してみたらHRT(Humility/Respect/Trust)だなと思い至る。良く知られている Team Geek の本と同じである。
このHRTを属する組織で得るために誰に意見照会しようとすると1名くらいしか名前が挙がらない。組織の中で年齢が上がるとか、専門とする知識エリアでコメントをもらおうとすると組織の限界が出てくる。
だからこそ、エンジニアは年齢がシニア層、40代、50代になればなるほど、外に意見を貰える関係づくりが必要となってくるし、フィードバックして貢献しなければならないのだ。
まあ、そうした活動をすると仕事よりオフの方が忙しく、知識的好奇心が増えてくるのが、また面白いところではある。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 作者: Brian W. Fitzpatrick,Ben Collins-Sussman,及川卓也,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/07/20
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (21件) を見る
「電車が遅れているので20分遅れます」
都心の電車は、例えば、4線(東武ーメトロー東急ーみなとみらい)が接続するようになり、埼玉での人身事故が横浜まで影響するようになった。個人的にはターミナル駅での乗り換えは、始発電車で座れるのでそっちの方が好ましいのだが。
以前のエントリで書いたように、自分は早朝の電車に乗っている。幸か不幸か、早朝に不通になっても振替できれば余裕で着くことが出来るし、8時代の運行支障なら影響を受けることはない。出社したメンバが開口一番「人身で再開した電車が激混みで」みたいな話をしても「大変だったね」くらいの感想しかない。各人、自分の都合で現場に間に合うような電車を選んでいるからだ。
これも直行するような出張の場合では話が変わってくる。もう10年も前のことになるが新幹線で数時間の地方都市に朝10時からミーティングすることになった。自分とアーキテクトと若手のエンジニアの3人くらいだったか。
若手エンジニアが集合先の新幹線改札口に集合時間になってもいない。会議があるので到着したメンバだけで客先に行き、会議を始める。会議が始まるまで、アーキテクトに何度か架電させたが会社支給の電話は留守電になるばかりだ。
会議の途中に着信があったようで折り返すと件のエンジニアが済まなそうな声で「今から向かいます」という。「今日は代打をしてもらったのでいいよ」と伝え、電話を切った。
極端な例だが、出張などにそういったことが起きるとただの出張が印象を残すことになる。それに比べたら、日々の電車の遅延なんてどうでもいいことに思える。
これを読む数日前に自分がメンバを守るには何か条件があるのだろうかと30度を超える夜道を歩いていて考えていた。
最初は、色々条件があるのではないかと思ってそれが何か、いくつか思いつくまま思い浮かべてみたが、その条件が本当に守らなければメンバのことを自分が守らなくていいのかと自問をし始めると細々とした条件はどうでもよくなっていくことに気づき始めた。
最後に残ったのはこの2つだけだった。
- チームで合意したルールを守ること
- 成果を出すこと
1番目は、チームで朝会を10時に始めると決めたなら、それを守らなければルール違反の評価をする。もちろん、突発的な事情があれば10時前に連絡すれば良いなど、運用で緩和する。
2番目は、コミットした成果を出し続けていればいい。コミットを履行できなければ相応の評価をする。
さて、引用した記事をこれに当てはめると自分のチームメンバが電車の遅延で出社が遅れた場合の対処が持ち引き出される。
社員には就業規則が課せられている。9時出社なら、9時から仕事を始めなければ相応の評価をしなければならない。立場的に、就業規則を守ることを求めるし、メンバの突発的な事情も配慮する。
結果としてこういった運用をすることになる。
- 始業時間に間に合わなそうであればメッセを入れる
たったこれだけで良い。
組織から支給されているスマホのチャットに『遅延で何分遅れます』といれてくれれば良い。もちろん、遅れる本人が主催の会議があれば話は変わってくる。色々と手配しなけばいけなくなるためだ。これは、遅れるエンジニアの業務の観点である。
もう1つメッセを入れさせる理由がある。労務管理の観点である。出社途中で事故に合えば、労働災害として扱うためだ。こちらは管理職しての責務であるし、遅れているのに連絡がなければ、純粋に何かあったのではないかと心配するのである。
引用の記事で相談している経営者さんは、成果の観点で労働力をみていない。どんなに生産性が低い社員でも9時から長時間残業してくれれば良いのである。そんな昭和の時代は終わっている。合意した成果をコミットした日にリリースしてくれればいいじゃないか。