凄いエンジニアの困ったリファクタリング

プロジェクトでは納期があり、ウォーターフォールなら開発線表でリリース日を設定したり、見積もり可能な仕様かどうかで工程を分けて契約をしたりする。アジャイル開発であればイテレーションごとにリリースする。

何れにしてもプログラムはどこかのマイルストーンでリリースされる。

あるプロジェクトでとても優秀なエンジニアがjoinしていた。joinしていたと言うよりは、プロジェクトの目標を達成するためのプロジェクトチームとしてのスキルセットの重要なポジションを担うために引っ張ってきた。

このエンジニアが作ったプロダクトがあり、多分、50代のとあるクラスタなら誰もが知っているのではないかと思う。

ついつい、このエンジニアに難易度の高い開発テーマがを寄せてしまい、進捗がやばくなってTOCとアサイメントの見直しで乗り切ったプロジェクトがあったことは以前のエントリで書いた。

このエンジニアの凄さはなんとなく伝わったと思うのだが、いくら凄いエンジニアでも、いや、凄いエンジニアだからこそ常にコードを考えているのでコードをリファクタリングをする。

ここで問題が生じるのだ。

冒頭でプロジェクトはウォーターフォールでもアジャイル開発でも締め切りがあると述べた。それは必ずリリースするためだからだ。

一方、凄腕のエンジニアは常時コードか仕様を考えているので仕様を含め、閃いたらコードを手直ししてしまう。

金融のように構成管理や手続き、顧客とのレビュープロセスが厳密なプロジェクトでそれをやられると非常に拙い。なぜなら、コードを書き換えられてしまうと影響する範囲は全てプロセスをやり直しになってしまうからだ。

エンジニアの後ろ向きの考え方で、動いているものは変更するなと言う考え方があるが、リリースの手続きしたコードも触るな、なのだ。

もし、リファクタリングしたコードを差し替えたければ、別のテーマに抱き合わせでやる他ない。

こうした凄いエンジニアをコントロールするのは非常に骨が折れる。つまり、凄いエンジニアがプロジェクトに100％貢献しているかといえば、そうとは言い切れないのである。

まあ、進捗が前倒しだとか、もともとプロトタイプで作っていたのでプロダクションのコードとして置き換える約束だったとか、何かしらの理由がないと変えられないことが多いので理由を上手に作ってあげることも時々は必要だが。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

【緩募】エンジニアとして自信を持てるまで抱えていた不安を教えてください

元メンバの人とメッセであれこれと会話していたとき、

「エンジニアとして自信が持てるようになるまでどのような不安を抱えていたか」

と言うことを尋ねてみた。

まぁ、なぜこんなことを聞いてみようと思ったか、その背景は簡単に説明した方が良いかもしれない。

もう、50代も数年経験しているとすっかり自分の仕事の仕方が出来上がっていて、担当している仕事で不安になることはリカバリができないくらい失敗らなければそうそう体感することがない。別の表現をするなら、仕事はコントロールできる範疇にある、若しくは体裁を整えるくらいにはキャッチできる。

門外漢だったとしても、入門編でも読んで、友人関係から知っている人を探して飲みながらでもレクチャーを受けて落とし込んでいけばいいというパターンを持っているから、それこそ、まーなんとかなるかなと高を括っている。どこかで痛い目にあうんだろうがそのくらい冷や汗を書くくらいこととは時々しないと成長につながらない。

冷や汗ドリブンな成長

…あまり真似するようなものではないが。

そんな今、自分自身がいつどこでエンジニアとして自信を持てるようになったか、それまで不安だったか、何について不安だったかは遠の昔過ぎて参考にならない。

それに一人ひとり性格も能力もアサインされる仕事も違うから、他の人はどうだったんだろうと聞いてみたくなった。

元メンバ曰く、

「正解がわからない。結果が出ない。この2点に尽きる。正解がわからないから何をどうすれば良いかもわからない。（一人前になってからは）大抵のトラブルならアプローチ方法がいくつか思いつくが、一人前になるまでは誰に聞けばいいかもわからなかった」

なるほど、なのだ。上記のメッセージについて何をどうすればいいかを書くことに価値はない。ここで意味のある返しは「同じだった」だと思う。

さらにメッセージは続く。

「こうすればいいと思ってやったことが思ったとおりの結果にならなくて何度も焦りを覚えた。周りを見れば同期はどんどん仕事を任せられ、結果も出している。自分を同期に比べてさらに焦る悪循環をしていた」

同期が仕事を任されていると思ったのは人事報を見たときだ。どんどんと置いていかれる。方や自分は仕事を任されていないし、結果も出ていない。これでは仕事を任されるはずがない…。そんなことを感じていたときもあった。そんなことを感じたときは見て見ぬ振りをした。

他所は他所。

自分は自分。

面倒くさいから仕事でお金をもらえる。

結局、仕事を片付け、積み重ねるていく他ないのだが。

たまたま、このエントリを読んでくれた人がいたら、ブクマにエンジニア（社会人でも良いいよ）として自信が持てるまで抱えていた不安を書いて教えてくれないだろうか。

ありあけ横濱ハーバー ダブルマロン 5個入（マロンケーキ）

いきなりテストケース表を作ってはいけない

厄介なことにソフトウェアは形がないため、定規で測ることもできないし、重量を計測することもできない。第一、そうした単位を持たせて設計することができない。

現実的にできそうなものはプログラムのコード、ステップ数やバイナリのサイズがあることにはあるが、作り方により変動するので基準値を決めることができない。

やはり、ソフトウェアはハードウェアのように計測して品質を確かめることはできない。

ソフトウェアは業務要件を実現するシステム要件のほかに非機能要件の性質を持つ。業務要件は業務そのものであり、その一部分若しくは全ての業務をITに置き換える。どのように置き換えるかはIT要件であり、IT要件を実現するのがシステム要件である。

機能そのものの働きではなく、機能全体としての動きは非機能要件として様々な切り口で要求される。

とするとき、ソフトウェアの品質を確かめるにはどうしたら良いのだろうか。

ついつい現場でやってしまいがちなことは、書いたコードのとおりのテスト仕様書を書いてしまうと言うものだ。それではソースをなぞっているだけで、システム要件を確かめることにならないし非機能要件を確かめていることにはならない。

ここからわかることは、テストケース表を作ってはいけないと言うことだ。やらなければならないことは、テストをデザインすることである。

ただ、そのデザインを表現する仕方がテストケース表であれば、それは作らなければならないが、テストケース表を作る義務がないなら不要である。

必要なのはテストのデザインを記したものである。

テスト駆動開発

数学の不得意なエンジニアが数字に抵抗感を持たなくなるまで

エンジニアをやっていれば計算する処理なんていくらでもあるし、普段のexcelを使う方が簡単な計算式を思っている以上に使っている。

仕事のロールがエンジニアからプロジェクトマネージャ、マネージャに変わると更に計算することが多く頻度は格段に増える。

小学校の頃はなんとか理解できていた算数も中学に上がって数学になった途端、躓いた。さっぱりわからない。2年くらいの年次で部活の先生が数学の担当で、あるタイミングでわかっていないことがバレた。そのとき、公式の使い方レベルで教えてくれて、ああ、そうやって使えばいいのかとやっと理解できたことがあった。多分、そこでもう少し聞くことができればもうちょっと数学にコンプレックスを持つことはなかったのかもしれない。

担当エンジニアの頃は色々あったけれど、プロジェクトマネージャをするのならコスト計算をしなければならない。プロジェクトのお財布を管理するのはプロジェクトの成功の要因の一つにコストがあるからだ。

学生の時代になんの因果か簿記を取っていたのでP/LやB/Sは（そのときは）作れていたし、（単位を取った程度で）理解もできていた。

割とそうした取り敢えずこれはできたと言う体験があるとプロマネとしてコスト管理に必要な数字の計算に対する心理的なハードルは押し下げる方向に向かう。なんでもそうなんだけれど、成功体験は支えになる。

プロジェクトのコスト計算を毎月するとして、そうした計算した結果がプロマネとマネージャで見方が違うこともまたやってみるとわかると言うか、やってみないと気づかない。

プロマネがプロジェクトの月次の収支を計算するのはプロジェクトの収益の観点での健全性を確認するためが1つ、プロジェクトが終了した時点での収支の見通しを確かめるのが2つ目の目的になる。

それは当然で、プロマネはプロジェクトのaccountablityがあるからだ。これがマネージャになるとプロマネが計算した数字を違う見方をする。

プロジェクトのコストのほとんどは、エンジニアの人件費だ。HWをサービスとして使ったり、SWもOSSや自作をすればその他費用が下がるから更に人件費の割合は高まる。

その人件費を人件費としてまるっと見がちなのはプロマネである。まあ、進捗やら成果物の観点はそれぞれの管理エリアで直接みているからそれで良いのだ。

では、マネージャはどこを見るか。それは人件費をバラして人単位での時間を見る。それで何を見るかと言うと、労務時間である。

ところで、プロジェクトのコストはやった時間全て計上しなければいけない。間違っても他のプロジェクトに計上したり、ねぐったり忖度して過少申告してはいけない。これはコンプラよりもプロジェクトコストの実績をあるがままに記録しなければ次の見積もりで使えなくなってしまうからだ。

やった分は必ず計上する。それをみて、労務時間に異常値があるかどうかをみて、プロジェクトのメンバごとの負荷状況を推測したり、プロマネのアサイメントを見たり、メンバの健康状態の観点で見たりする。

マネージャともなるとべったりとプロジェクトに入ることはできないから、そうした客観的な数字でプロジェクトの状況（月次であればひと月遅れになるが）とリスクを識別する。

数字もこういった使い方なら割と親しみが持てる。目的があって、その道具になっているからかもしれない。

大人のための数学勉強法 ― どんな問題も解ける10のアプローチ

アジャイル開発だからじゃない。プロジェクトだから今、技術がないとリスクになる

「こんにちは」
「お、珍しい。今、プロジェクトで別のプロジェクトルームじゃなかったけ」
「そうですよ。地下鉄の側なので便利でいいですよ」
「都会だしな。毎日通勤帰りに寄り道しているんじゃないの」
「そーだったらいいんですけどね。もう、ほんと勘弁して欲しい」
「ちょうどいいや。コーヒーでも飲みに行く時間あるだろ」
「じゃあ、お・ご・り・で」
「最初からそれがお目当のクセに」

「それで」
「へ」
「いや、都会まで痛勤して洒落たお店にも寄れずに家からプロジェクトルームまで往復しているんだろ。どうした」
「アジャイル開発じゃないですか。プロジェクトが」
「そうだったっけ。なんのプロジェクトだっけ」
「今までオンプレで提供していたサービスにWebサービスでアドオンするヤツですよ」
「それか。あまり知らないけどな」
「それはいいんですけど。アジャイル開発経験したことがないメンバがいて、どうやってもウォーターフォールに持っていこうとするんですよ」
「なにそれ」
「リーダ役がいるんですけど、営業がこの機能が必要だからとか言い始めるとそれを入れようとするし」
「教育してやれ」
「メンバもアジャイル未経験のエンジニアもいれば、Webサービスの技術をあまり持っていないメンバもいるし。メンバの面倒見ているから自分の仕事を始めるのが夕方からですし」

「不思議だな。プロジェクトチームを組むときはさ、プロジェクトの目的を達成するために必要なスキルセットをチームとして持ち合わせていないとダメじゃん。プロジェクト内教育が計画されているならまだしも。でも、それも最初は先生役が必要だしな」
「そうなんですよ、それが全部こっちに回ってくるんです」
「たまに聞くけどさ、アジャイルだから技術が必要なんじゃないんだよ。ウォーターフォールだって同じ。同じことを繰り返して言うけど、プロジェクトの目的を達成するために必要なスキルとスキルレベルがないとそれ自体がリスク。アジャイルだからじゃないんだよ。期限のあるプロジェクトだから必要なんだよ」
「なんかそう言うのわかっている人がチームでいるのかな」
「前にも話したかもしれないけれどさ、自分のミッションを最優先にすることも必要なんだよ。プロジェクトの貢献としてさ。スクラムマスター役なりリーダ役なりがいるんだろう。そいつに選ばせればいいんだけどな。でも、今のキミは両方やっているわけだ」
「まあ、そういうことになりますね」
「それはさ、見積もり的にもおかしいし、作業計画的にもおかしい。作業を始める前に全員で作業のスコープやら、どんな作業をするかとか、ゴールを設定するときに必要なスキルとスキルレベルを確認するようにしたら」
「でも、それをしてもスキルが足らないメンバは進捗しないですよ」
「学習しながらやってもらうスケジュールを許容するか、入れ替えするんだよ。そのときに、キミのフォローがいるなら、キミの作業も織り込んだ作業見積もりにするか、そうだな、キミの作業時間はプールしておいて、そこからリーダがサポート用に引き出す方式にしたらいい。毎月120時間から始めて、メンバのサーポートをする前に差っ引いて行く。様子を見ながら自分で残り時間でできそうなチケットを取るか、先のことをやっておく」
「時間を可視化するんですか。へー、面白いですね」
「やっていることは大したことじゃないけどね」
「それ面白いですね。それやろうっと。さずが先輩ですね」
「珍しい。褒められた。雨でも降るか」
「ひどいので取り消しです。順調にいったらご飯奢ってもらいますので。ではー」

基礎から学ぶ Vue.js

統計ってなんの役に立つの?: 数・表・グラフを自在に使ってビッグデータ時代を生き抜く (子供の科学★ミライサイエンス)

現場のプロがやさしく書いたWebサイトの分析・改善の教科書【最新Googleアナリティクス対応・増補改訂版】（仮）

エンジニアが自己評価を適正にするために自分の推薦状を書いてみる

エンジニアが自己評価をすると2つのグループに分かれる。1つ目は自分に甘い評価をするグループ、2つ目は自分に厳しすぎるグループだ。ちょうど良い3つ目のグループは経験的にほとんど見かけない。

甘い評価をするグループ

自分に甘い評価をするグループは、実は自分の出来ること、出来ないことを内心では理解している。 理解しているから、それを誤魔化そうとする。

今度やれば出来る、次は上手くいく。

そこには実績が紐づいていないからすぐにバレる。

話し方も特徴がある。はっきりと話をせず、会話で使用する言葉も曖昧だ。やったのか、次もできるのかを尋ねるとやはりすぐに降参してしまう。

実績が一度でもあればやったとは言える。自信を持っているかどうかはそのやった結果が本人にとって想像したイメージどうりだったかどうかで変わる。自信を持っていない場合は、理想が高かったか、自分で考えてやっていないのどちらかだ。

ただ、やった実績があればやった、次もできると言ってしまうくらいで良い。

厳しい評価をするグループ

 理想が高いか、あれこれとやることを想定して不安材料を見つけ考えてしまう。慎重なのだ。

厄介なのは、後者である。自分の成果を成果と認識しない。助けてもらった、他の人がやってくれた、自分のスキルはまだまだだ。こうした思考を持つエンジニアにはきちんと評価をしてあげなければいけない。

ただ、生まれ持った性格でバイアスがかかっているためそれを軌道修正することは難しいのでやめたほうがいい。

それよりは、評価を小刻みにして出来たことを多く認めたほうが良い。

適正に評価をする練習

 以前、推薦状を書くことがあった。自分に取って推薦状を書く機会はそうそうない。ないので考える。

推薦をするということは、そのエンジニアの後援者となるようなものである。それほど大したことではないかもしれないが、それでも色々考える。

推薦するエンジニアが何をしてくれたか。推薦に値するか。

 そうしたことを思い出すと、エンジニアが他者に成り代わって自分に対する推薦状を書いてみるのは自分を適正に評価する良い練習になるのではないかと思いついた。

実際にやってみたのだが、これがなかなか難しい。

ちなみにこんな内容を書く。

推薦状を出す宛先

標題（推薦状）

推薦する意思表示を表明する。

以下、具体的にどの案件でどういった貢献をしたかを書く。推薦状には事細かくは書かない。案件、役割により、（案件で期待していたこちら側の）成果）を書く。

最後に推薦者の所属、氏名を記載する。

一度書いて見てほしい。褒めすぎると自分で書いていて恥ずかしくなるが。

掟上今日子の推薦文 (講談社BOX)

処理能力が高くても考えないエンジニアは優秀とは思わない

あるメンバがいて、処理能力は高いのだがもう少し考えながら仕事をした方が良いんじゃないか、と。そう思ったし、何度か伝えたのだがどうもそのメンバの仕方として染み付いているようでこれはこれで困ったものだ、と。

実際は、自分は困らないが、件のメンバは困るのだ。処理能力が高いとは仕事に落としこんでさえいれば、である。その仕事に落とし込むところができないと処理能力を活かすことはできない。

故に、そのメンバは仕事に落とし込むところを開拓しなければならないのに、処理する仕事と同じように仕事を落とし込む作業を処理しようとしてしまう。これはアウトプットの形のないところから進め方を含め作り上げていくような場合に要件を持っている人と衝突してしまう。

なぜなら、処理能力を発揮するパターンと同じように仕様を決めることを持ち出すからだ。ところが今やりたいのは処理能力を活かすことではない。その前段階である。

要件を実現するための仕組みを作るところである。その仕組みを作る、というためには目的の理解、アウトプットの詳細、進め方（段取り）を当事者同士で合意形成しなければならない。

それには考える対象のユニバースを決め、界面を線引きし、理解を同じものにしながら作り上げるシナリオを構成する必要がある。

そこには処理能力はそれほど必要ない。必要なのは仕事に落としたときに様々なケースに耐えられる構造を考える時間を確保することである。

ここを確保せず、想定が浅く、狭い場合には、浅はかな考え、やっつけでやった仕事にしか見えないのだ。

勘違いしやすいことだが、長い時間をかければいいというものではない。何をどこまで考えたか、それをする時間を取ったか、である。

仮説思考 BCG流 問題発見・解決の発想法