4年目エンジニア、配属されたマネージャに改造され始める

どこかのインタビューで『身につけた技術を捨てて行けることが大事だ』という趣旨の記事を読んだのだが、身についた技術を捨てるという言い方は違うと思う。伝えようとしていることはこちら側に伝わっているが、表現は変えたようが良いのではないか、と感じた。

身につけた技術は無形であり、作業をした結果、エンジニアがプロセスとなって適用した技術でアウトプットする。プロセスを司るエンジニアにはプログラムをインストールするように技術をロードすることはできない。エンジニアに繰り返し学習させることで次第に覚える（身につける）。その意味では機械学習に近いのかもしれない。

4年目エンジニア、上司が変わる

4年目になれば、エンジニアとしては中堅の部類に入ったと看做している。若葉ちゃんエンジニアは3年までだ。それまで基本的なところは身につけておいて欲しいと思うが、他の組織から移動してきた若手エンジニアと仕事をしていて軽いショックを受けた。それまでの仕事のアサイメント、仕事の身につけ方をどうしていたのだろうと思うほど、仕事の基礎ができていない。

評判の悪い4年目エンジニア

エンジニアであれば、適用する技術を身につけ、複雑な仕事の進め方を身につけなければ現場で仕事にならない。仕事ができないヤツだ、あいつはダメだと言われてしまう。そう言えば、業績評価でそのエンジニアの評価が芳しくなかったことを思い出した。

上司の趣味はエンジニアの改造

これまで組織の再構築、エンジニアの育成を事業の中で行ってきた。そうした中では部下になったメンバが程度は様々だがすでにメンタルを傷つけていたこともあった。それまでのアサイメントや育成がリーダ達に都合良いエンジニアとして使っていたであろう形跡がはっきりと手にとってわかるような仕事の仕方、保有技術しか持ち合わせていないエンジニアを何人も見てきた。

4年目エンジニアにターゲットオン！

 そういったエンジニアをかなりSIができるエンジニアにある意味改造してきたのは、そういったエンジニアをビジネスで期待に応えてもらえるように仕立てるのもマネージャの仕事だからだ。

4年目エンジニア、外堀が埋まる

 だから、同じように4年目のエンジニアにも基本から仕事の進め方、適用技術を身につけてもわなければならない。先輩エンジニアを1on1の場で課題と思っていることを伝え、その中で先輩エンジニアが得意とする専門スキルを活かして4年目のエンジニアを改造する手伝いをしてもらえるように手配する。

期待ばかりの4年目エンジニア

 4年目だからまだこれからである。自分なんて10年くらい経ってからある意味自分で気づき脱皮をしたのだ。4年目のエンジニアにとって幸いなのか、不幸なのは4年目に自分の部下になったことだ。4年目のエンジニアには変身してもらう。そして、自分の期待以上の技術を身につけてもらい、この組織から巣立って他で活躍しているという噂を聞かせて欲しい。

自分の部下になったら、ぬくぬくなんてさせない。

期待していない自分

期待はずれのドラフト1位――逆境からのそれぞれのリベンジ (岩波ジュニア新書)

結合テストと呼ぶことをやめる前にやっておこうよ、という話

自分の周りのプロジェクトマネージャやスクラムマスタは、ウォーターフォールに限らず、アジャイル開発であっても成果物（アウトプットと表現してもよい）を作る作業の括り毎に、作業内容の定義、完了の定義をしなければいけない、と言う認識を持っている。

言い換えると、工程（アジャイルに工程という概念がフィットするかは別にして）の作業プロセスをデザインしてから個々のタスクをWBS（開発手法やプロジェクトの方針で作らないかもしれないが）に展開した上で、作業を着手させろ、と言うことになる。

前説

工程の作業プロセスをデザインするとは、その工程の中で成果物を作成するためにメンバ誰もが行う共通の手続きを決めると言うことだ。

例えばテスト工程なら、以下の手続きを経て、テストの合格基準をパスしたものだけが次工程のデプロイに進める、などと決めておく。

1. テスト方針・計画を作成する
2. テストの粒度を決定する
3. テストの合格基準を作成する
4. 機能仕様書を読み、テストコードを書く
5. テスト環境を作る
6. テストを実施する
7. テスト結果を評価する

項番1〜3は、この工程を実施する前に決めておく。もちろん、メンバ全員が理解していなければならないので、決める際にはメンバと工程の作業と完了基準の意識合わせをしなければならない。

その上で、4〜7をメンバが各自で行う。

工程デザインをしないで始めたプロジェクトは… 

 前説を読んでご理解いただけていれば、どうなるか想像に難くないだろう。メンバの実績を聞き、完了したと報告を受けて実績を見ると、メンバごとにテストの粒度がバラバラであることが判明し、粒度を揃えてテストをやり直すことになる。

そうなることは、エンジニアであれば誰も手戻りという喜ばれない経験をしたことがあるから予測がつくはずだ。

でも、現場ではハルヒのエンドレスサマーのように繰り返し行われている。

段階的なテストを考える

細々としたことやお作法のテストについては、テストの書籍をご覧になって欲しい。以下は、あくまでも段階テストを行う上で、チームがどのような単位でテストをするかを考えなさい、という例である。

テストは、段階的にテストを行う。それはテストの観点があるし、そうしなければ、コードの不具合の解析が大変になるからだ。

テストは、機能を確認するためのホワイトボックステスト、機能を連結し、インタフェース及び連結した機能のテスト、対外システムとのインタフェーステストの3種類の観点を行う必要がある。

そのテストを自分のプロジェクトではどのコードの塊で行うかは、チームで決めることである。その決め事を工程の作業プロセスでデザインしなければならない。

例えば、ホワイトボックステストはxunitで行う。単体のプログラム、モジュール、クラスまでで、単体で動かないコードはスタブ、ドライバを用意する、と決めておく。

機能を連結して行うテストは、自分たちのプロジェクト全体のコードをすべて連結する、と決めておく。プロジェクト全体の機能、コードが大きければ、サブシステムに分解（当然、システムデザインの時点で機能分解されているはずだ）し、サブシステムの機能連結するテストを経て、システム全体のテストを行う。

最後に、システム全体を塊として、そのシステムと対外的なインタフェーステストを行う、などを決めておく。

テストに限らずチームで決めてから始めようよ 

 標題のとおりである。これしかない。何もしないで勝手にメンバが相互に慮って、テストの粒度を調整して、テストを始めることを期待するなんて馬鹿げている。

リーダ役は仕事をしていないのと一緒である。仕事しろ。以上、でしかない。

吉本新喜劇のギャグがいっぱい ちくび書きとりドリル (ヨシモトブックス)

テスト駆動開発

Self-physical management for engineers

2週間前の週の後半くらいか、急に気温が下がったと思ったら、また、元に戻って、先週末の暑さなんてひどいものだった。現場でもソーシャルネットワークでも体調を崩したり、喉をやられている人がそこそこいる。

そういう自分も局所的に見ればあちらこちらシンドイことはあるが、トータルでは夏バテもせずに毎日仕事をしている。夏休みを取っても、スライドを作ったり、原稿を書いていたりするので実質な休み有って無いようなものだ。

振り返ると、ここのところ、風邪を引いて寝込み、仕事を休むということがない。後から、これは風邪の予兆だったかもしれないな、的な症状を感じるときもあるが、そうしたときの対処をする。

それで、エンジニア向けの自己体調管理である。

睡眠時間のリズム

一番重要なのは睡眠時間のリズムを作ることだ。寝る時刻より、起きる時刻を決めてずらさない。これがリズムを作るコツ。

勉強会や読書会で就寝時刻が遅くなる場合があっても、起きる時刻は変えない。遅くなる日は予めわかっているので、無理なスケジュールは組まない。

睡眠時間

 睡眠時間は短い方だ。健康診断でも短いと言われる。短い睡眠時間は、色々と弊害があるようなので、これは勧めない。自分にあった睡眠時間を取ろう。

生活のリズム

日次、週次でやることを決めておく。一見、つまらない生活に見えるが、同じリズムで生活するから異常を体調から検知できる。

朝食

平日のみ、いわゆるバターコーヒーで済ませている。それまで、朝食をヘビーにしてみたり、軽く取ってみたりしたが、今の所、これが昼食まで腹持ちする。不思議なことに、食事を取った方が、お腹が空くのだ。バターコーヒーの方が空かない。なぜかはわからないが、午前中は、ミネラルの水だけでもつのだ。

昼食・夕食

昼はメインとサラダ。サラダは、ドレッシングやマヨネーズを使うのを止めた。ドレッシングのそばに、オリーブオイル、酢、胡椒と塩があることにふと気づいて、それらを直接かけまわしている。

たまにメインがイケてないときがあり、丼ものやカレーライスを選ぶときもあるが、ご飯を半分程度残す。上に乗っている物を食べる添え物的にしか食べない。

いわゆる主食を減らしているのは、午後に眠くなるからである。後、仕事上の移動量が減ったのでそのバランスもある。

仕事中の間食

お土産をもらうことがあるが、基本的に食べない。特に、午前中は食べたいと思わないのはバターコーヒーのせいかもしれない。午後も周りは食べている人が多いが口にしない。食べたいと思わなくなった。

通勤

雨天でなければ、1駅手前で降りて、歩く。多分、これで仕事上の移動量が減った分を多少は代替いているのではないかと思う。止めたら確実に太りそうだ。

運動

週末にフィットネスジムで1時間走る。そのあとスパでサウナ。これを飛ばすと次の回の汗がとても臭う。おじさんは臭いのである。

ただ、運動を続けて、汗をかけば軽減される。

眼精疲労

QPコーワiプラス一択。毎朝常用。

エナジー補給

QPコーワゴールドαプラス一択。これも常用。

お酒を飲んだら

ハイチオールCプラス一択。これは飲んだ翌日飲んでも効く。

急に猛烈な睡魔が襲ってきたら

風邪の症状のサインだと思っている。まず、葛根湯を頓服する。仕事にならんなと思ったら帰るポリシー。

家に帰れば、モンエナ、ビタミン剤をのみ、食事をしてそうそう寝る。

【第3類医薬品】ハイチオールCプラス 180錠

【第3類医薬品】キューピーコーワiプラス 180錠 ※セルフメディケーション税制対象商品

【第3類医薬品】キューピーコーワゴールドα-プラス 160錠

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

今日も渋谷駅で使い続けるWindows2000

昨夜の雷雨で京王渋谷駅のモニターにWindows2000のロック画面が表示されたとツイートがあった。

togetter.com

Windows2000のサポートは2010年7月13日で終了している。

Windows 2000は7月13日でサポート終了、マイクロソフトが注意喚起 -INTERNET Watch Watch

エンジニアならサポート切れのOSを使用していることに危機感を感じるだろう。日頃、OSやミドルウェアの脆弱性に対するセキュリティ修正プログラムを適用したり、コードの脆弱性診断を行い、セキュアなシステム環境を維持することが仕事の一部になっているからだ。

では、渋谷駅のモニターに写っているWindows2000のロック画面はセキュリティ的に危険な状態なのだろうか。なにせ、サポートは2010年に終わっていて、それから8年も経っているのだから。

なお、ここからの内容については、何分にも素人のため、間違ったことを書いているかもしれないし、想定も前提に誤りがあるかもしれない。その辺りを含めて読み進めて欲しい。

インシデントの発生要因

情報セキュリティのインシデントは、内部犯行か外部からの攻撃によって生じる。内部犯行は、得てして権限を持っているユーザが主体的に行うため、権限管理と異常検知が鍵となる。 外部からの攻撃は、エクストラネット（自分で書いておきながらではあるが久しぶりにこの言葉を聞いた）、つまりインターネットから攻撃されることで内部の情報を漏洩か破壊される。

内部犯行は、インターネットに接続していなくてもインシデントが起きる可能性がある。外部からの攻撃は、インターネットへの接続が皆無であればインシデントは発生しない。

NWの種類

 組織内ではNWを敷設して、NWを構築する。利用用途により、セグメントを分けたり、場合によっては、他のNWと接続しない、孤立したNWを形成することもある。インターネットに接続する要件がなければ、クローズドなNWを構築する方がよりセキュリティの担保がしやすい。

渋谷駅でWin2kが使われ続ける理由

ここからは、上述した内容とツイートの画面からの想像の上で話を展開する。

• サポートが切れて8年も経つOSを使用している。
• モニターに映すのは運行情報に限られる。

以上の2点から、閉鎖環境のNWが構築されていて、その環境下にWindows2000のOSを使用するシステムが存在するのではないか。

 アプリと書かずにシステムと表記したのは、いわゆる、OA用途のアプリケーションではなく、制御システムの類なのかもしれないと想定したことによる。

セキュリティ的にはもちろん、最新OSに更新することが望ましいが、こういったシステムはNW的に閉鎖環境であることが多いため外部環境からの影響を受ける可能性が少ない。

OSを更新するとなると全取っ替えになり、費用も多額に掛かる。機能は十分で、リスクが低いのであれば、更新する動機にならない。

よって、リスクは少なく安全であると判断しWindows2000を使い続けているのではないだろうか。

まあ、自分が責任者なら同じように判断するだろう。

渋谷ではたらく社長の告白〈新装版〉 (幻冬舎文庫)

図解まるわかり セキュリティのしくみ

要件定義を提案したら怒られる

以前、提案したときに要件定義フェーズを設けたら、提案説明に行った営業が怒られたと帰ってきた。先方が言うには『要件はこちらで決めるものだ』『要件定義は既に終わっている』なのだそうだ。

ごもっともである。SIerとしては、要件は顧客が決めるもので、その要件の中からシステム要件を抜き出し、その要件のシステム方式、実現仕様を仕様に落とし、コードに変換するのが理想である。ぜひそうありたい。

だがしかし、これまで要件が決まっていたことは大規模プロジェクト以外では１度もなかったと言う経験則がある。その経験から言えば、先の案件は非常に危うい。特に、これまでITのシステムが存在しなかった業務領域の場合はリスクが高い。なぜなら、一度も業務を可視化したことがない可能性が高いからだ。

システムリプレースであったとしても、単なる再構築ということはありえない。なぜなら、それでは多額の費用の稟議が通らないからだ。必ず、機能追加や非機能要件が追加されるか、再構築費用と維持管理費用が削減された上で、機能追加になることが多い。

情報システム・モデル取引・契約書（P14）をよく見直すと、契約形態に準委任契約とあり、開発基本契約とあるから要件定義は（委託を受ければ）SIerがやることも認めている。まあ、もっと遡るとシステム化の方向性までたどり着けるので、システム化要件を決めるところから、冒頭の考え方も間違っているわけではないということだ。

では、冒頭の場合は、要件定義をやらない（＝提案しない）前提で提案して良いのか。

答えは、NGである。要件定義をしたと言っているが、システム要件定義をしているとは限らない。そのリスクがプロジェクトで発現した場合、その作業は含まれていないと明確に主張できる準備ができているケースはとても少ない。

要件定義をやらない場合、つまり、基本設計から開始するための前提条件をつけ、システム化要件を記述したドキュメントの精査をプロジェクトの契約に含める必要がある。これが実際に起きてしまうとプロジェクトの雰囲気は最悪になるだろう。なにせ、プロジェクトの開始条件を満たしていないとSIer側がリジェクトすることになるからだ。

冒頭の提案では、要件定義とはせず、要件定義と基本設計の間にワンクッションの工程を設け、さらに前提条件を加えてリスクを回避する案を提示した。

覚えておきたいのは、SIerが要件定義と言ったら、システム化要件の定義である。業務要件をする気はさらさらない。一方、顧客がシステム化要件をスラスラと書けるかといえば、まだITで実現したこともない業務を文字や図表で可視化すること自体やったことがないのでイメージを持っていないから躊躇してしまうし、システム化要件以降の工程で欲しいインプット情報に何を必要としているかも知らない。本当は知っていて欲しいが。

SECBOOKS 共通フレーム2013 (SEC books)

調達 Clean Code/Clean Coder/Clean Architecture Kindle版が半額だと…3冊全部買っても5220円！！！

Clean Code　アジャイルソフトウェア達人の技 (アスキードワンゴ) Kindle版 ￥ 2,204

Clean Coder　プロフェッショナルプログラマへの道 (アスキードワンゴ) Kindle版 ￥ 1,160

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) Kindle版
 ￥ 1,856

Clean Code　アジャイルソフトウェア達人の技 (アスキードワンゴ)

Clean Coder　プロフェッショナルプログラマへの道 (アスキードワンゴ)

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Q エンジニアのあなたをあなたが買うならいくらの値段をつけるか答えない。

今日のキーワードを思いつく2秒前までは別のことを書こうと思っていた。要件定義のことについてだ。朝食を摂りながら、ふとソーシャルのアプリを開くか、開かないかというタイミングで『自分をいくらで買うか』『エンジニアの価値』『勉強』と続けて頭の中に浮かんだのだ。だから、今朝は何度か取り上げたエンジニアの勉強について車輪再発明的にエントリを書く。ただ、これまでとは違った切り口で。

Q　あなたは事業をしている。エンジニアサイドから見れば顧客だ。さて、（エンジニアとしてのあなたを）事業を進める上でエンジニアを採用する必要に迫られた。事業家としてあなたは（エンジニアのあなたを）幾らで採用するか。月額費用を書きなさい。

もし、あなたがエンジニアのあなたの月給を基本としてそれに数10%程度の係数をかけていたとしたら、それではエンジニアのあなたの月給は確実に減る。

なぜか。

100万を月額費用としたとする。この100万は事業者側の買う値段である。買われる側は100万の請求書を事業者に請求するが、採用され、仕事をするエンジニアには、1/3程度しか支払われない。ここのロジックはなんとなくでも理解できているだろうか。

比率はどうであれ、エンジニアと契約すると3つの要素で取り合い、だいたい1/3がエンジニアの月給となる。

これは事業を自社で開発している内製のエンジニアでも同じだ。事業としてあなたの給与、社会保障費・税金、事業収益を得られなければならない。

Q　あなたは{結婚し、子どもをも設けた。できれば私立の学校に行かせたい | 両親の介護で介護ヘルパーを頼んでいるが老人ホームでお世話になりたい}の環境に置かれた。今の月給ではかなり苦しい。あなたは、月給を増やすために何をするか。

回答は単純である。月給を増やす仕事をする、である。残業を増やすのはこのご時世もあるし、家に戻れば子どもか介護で時間を必要とするから限度があるし、あなた自身の年齢も加算され、続きはしない。

そうすると、月給自体を増やすことを考えなければならない。

どうやって。

役職に就くか、エンジニアとしてある分野で唯一無二の存在になり、それを必要とする顧客からオーダされる必要がある。簡単に言えば、収入を根本から増やす施策をするということだ。

役職に就くためには、ビジネスの実績かある技術領域での実績が必要となる。そういった組織への貢献という形で実績がなければ役職をあげられる理由が作れない。

Q　あなたは、{ ビジネスの実績を上げる | 専門技術の第一人者になる }　ために何をするか、具体的に述べなさい。

これもこのブログを読まれている方なら、簡単な設問である。エンジニアの技術的価値を増やすことである。

それは具体的にどうするのか。

あなたを事業する側があなたの言い値で買おうと思うほどのエンジニアとしての技術を持ち合わせていればいい。見合った技術を持つということはどこからか、技術をあなた自身に移転し、それをいつでも発揮できるように習得すれば良いだけだ。

あちらこちらでエンジニアが勉強する勉強する必要はないと不毛な意見を投げ合っているが、そんなことはどうでもよい。

あなた自身があなたの理由で勉強する、勉強しないを決めれば良い。

二人は底辺 (ZERO-SUMコミックス)

漫画 君たちはどう生きるか