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コミックス)

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

『いいですね』から話せば伝えたいことを聞いてもらえる

あるチームは年齢層が高く、それぞれの専門性が尖っていて、何か裏も取らずに言おうなら「素人なのですが、その○○については…」と例の物言いで始まるのだ。気が抜けない。実際はそんなニュアンスで、なのだが。

そういった中で学んだことがある。その学びを実践できるようになるまでには、随分と時間がかかったというか、時間掛け過ぎじゃないかと思わなくもないが、それでもやはり、学びを実践して上手く使えるようになるとニンマリとしてしまう。

自分の考えと違うことを言っているときに

 仕事を任された以上、自分の経験から満足できるアウトプットをしたいと考えるだろうし、実際、自分の裁量で資料のレイアウトや自分で考えた流れに言葉を選び、資料を作っていると思う。

コードもこれまで経験してきたやり方や、やってみていい感じのスタイルで処理を書いていると思う。

そうして持ち寄った資料やコードを説明したり、レビューにかけたりしていると思う。

さて、メンバが作った資料が自分の知見から言えば、ああした方がいいとか、こうした方がいいと思ったとする。

「○○さん、それじゃダメですよ。そこはこうしないと」

せっかく、自分の意見を言ったのに、反応が悪い。なんか他のメンバも微妙な雰囲気に感じる。なぜだ。自分は自分の経験から『良い』と思ったやり方を教えただけじゃないか。結局、自分が意見したコメントは受け入れられなかった。

なぜだ。

自分の意見が受け入れられない

 エンジニアなのだから、議論するテーマについて自分の意見があれば、それを発言するのはチームのためにもなると考えるのは普通のことだろう。

実際、それそれのメンバが経験して持っている経験知を共有することで、他のメンバがその知識を使ってくれれば、同じ技術レベルに近づくだろうし、逆のシチュエーションになれば自分の勉強にもなって、それこそ、メンバ同士で相乗効果が生まれるのだ。

では上記の会話でなぜ意見が受け入れられなかったのだろうか。

自分が経験してきた中で、より良いと『思った』意見を伝えたいままに受け入れられるケースと上の会話のように受けれらないケースがあった。それが今は大体の意見が好意的に受け入れられるようになった。

聞く耳を持てない

それまで、つまり、学んだことを思うように、自然に振る舞えるようになったのは、最初の一言を変えてからだ。

「こんなスケジュールで進めようと考えています。何か意見ありますか」

「そんなスケジュールじゃダメですよ。このケースはどう考えているんですか」

 つい、こんな風に言いがちだけれど、こう言ってはいけない。言っていることは間違っていないが、こんな風に言われたら気持ちよく受け入れてもらえるわけがない。

立場を入れ替えてみよう。半日かけて書いたスケジュール案をいきなり全否定されるわけだ。素直に聞く耳を持てるだろうか。

さらに、自分が考えたスケジュール案に対して、足らないことを言われるだけで、じゃあ具体的にはどうすればいいかと質問に質問で返したくなる。肝心のアドバイスも全くないのだから。

こんな物言いをされても素直に意見を聞けるのは相当の熟練者か、成果しか信じないツワモノのエンジニアだ。

マジックワードを使う

 自分が学んだことは、ある意味マジックワードを手に入れたことに近い。もし、自分と意見が違う時にはこんなマジックワードを使う。

「こんなスケジュールで進めようと考えています。何か意見ありますか」

「いい感じですね。そうだ、○○はどこに入っているんでしたっけ」

マジックワードと言う言葉を使ったが、大したことは言っていない。ただ、この言い方をすると100％は言い過ぎかもしれないが、指摘したことは必ず入れてもらえるようになった。

二つの違いは何かを言えるだろうか。

「そんなスケジュールじゃダメですよ。このケースはどう考えているんですか」

「いい感じですね。そうだ、○○はどこに入っているんでしたっけ」

単純なこと過ぎて返って気づかないかもしれない。シンプルで単純な構造の方が気がつかないものだ。

前者は『否定』から入る。それも全否定だ。後者は『同意』から入る。それも労いが感じられる。

でも本質は、そのあとの文章が受け入れらるかどうかだ。足らないケースを反映させることが発言の目的なのだ。だから、『このケース』を反映してもらわなければ発言した目的は達成できない。

後者はどうだろう。『○○は』と欠けているものを具体的にしているのは同じだが、考慮されているだろうけれど、記載を忘れているのか、書き忘れか。どちらにしても考慮されているんだよね、と確認しているだけと受け取れる。

後者は実際、考慮漏れだったら、素直に『あっ、忘れてました』と反応するだろう。考えていたとしても書き忘れていたら素直に『ありがとう』と言えると思わないだろうか。

 繰り返すことになるが、発言する目的は言ったことに対して聞く耳を持ってもらい、それを実行してもらわなければ発言した意味をなさない。

マジックワードを使おう。

あなたソレでいいんですか(1) (イブニングKC)

システム開発で一度も失敗したことがないPMが実践していること

先日、facebookで元部下が誕生日だとわかり、久しぶりに会うことにした。facebookの良いところは、友人などの誕生日を教えてくれるところだと思う。流石に一人ひとりの誕生日を聞くことはないし、でも、知っていれば飲む口実が作れる。ソーシャルネットワークでは友人の近況を投稿から知る機会があるので物理的に会っても久しぶりな気が全く起きないが、それでも会話することでソーシャルネットワークではかかれないリアルさを知ることができる。

かれこれ2年振りくらいに会って会って、近況をお互いにとてもフランクに尋ね合う。自分は上司なんていっときのたまたまマネージャがロールの人くらいしか思っていないので、所謂、上司風を吹かせなかった（つもりだ）から非常にタメ口ウェルカムである。

そんな感じで色々と注文した肴を突きつつ、ふと、質問をされた。

「そう言えば、プロジェクトを一度も失敗したことがないんじゃないですか。そんな話は誰からも聞いたことがないし」

突拍子も無い質問をされると理解するまで時間がかかるが、これも言われてみればその質問のとおりである。自分がやってきたプロジェクトで所謂（QCD）失敗したことがない。

「そう言えば、そうだね」

「コツを教えてください」

そう言われても、である。やることを終わらせる。約束したことは履行する。ダメそうなら相談する。つらつらと思いつくことを言いかけるが、少し、空想する。頭の中の記憶を引っ張り出しても上手く言えない。

なぜなら、計画が計画したとおりに進むように色々と手はずをするからだ。こうしたことをそのまま伝えても多分、本質は伝わらない。もう少し、具体的にした方が良いし、箇条書きぽく短く、単純にした方が良いのだろう。

オジサンになって嫌われるのはくどくどと長ったらしく話すことだ。

• キーとなる人的リソースを揃える
• スコープを明確にする
• チーム・ステークホルダと確認するプロセスを回す
• 曖昧なまま手をつけない
• 上手くいくなんて思わない

少し上の空間を眺めながら、こんなことを言ったはずだ。システム開発は技術を持ったエンジニアで成り立っている。プロジェクトだけの観点で言えば、プロジェクトの制約条件、前提条件を満たすことを確認して始めなければならない。その筆頭なのが、エンジニアの技術力である。チームとしてプロジェクトが必要とするスキルセットとレベルを揃えていなければキックオフしてはいけない。

スコープが明確でなければ同じように始めてはいけない。定量的な仕様若しくは定性的でもキャップがかかっていることを確認しなければならない。それでもスタートするのであれば、何が起きるかリスクを識別し、プロジェクトのコンテンジェンシプランを作ってから始めなければならない。

チームメンバとも然り、ステークホルダである顧客とも然り、活動ごとにゴールを確認してそれが終わった状態であるかを確認するプロセスを回さなければいつまで経ってもその活動を終われない。その状態だと次の活動、工程に突入できない。見切りで突入した途端、終わっていない活動にリソースを取られたまま次の活動のリソースが足らずに始まるので混乱するだけだ。そして全く成果が出ず、曖昧なまま、さらに進んでしまう。良いことは何一つない。

曖昧さを残したまま進めてはいけない。システム開発はコードを仕様に沿って書く。数値や文字列を比較し、操作する。曖昧さはコードで表現できない。曖昧さをなくすために活動の工程を分割し、詳細化を図っているのだし、曖昧だから小さく、短い期間で作るプロセスを回し、都度確かめるのである。その点で言えば、これが欲しいのかとと尋ねるよりは、これが欲しかったものかと尋ねられる手法の方が良いのは決まっている。

何より、いくらプロジェクトチームのメンバが精査したとしても、プロジェクトの骨格は自分の経験と他所のアイデアを思いつきで混ぜて考えた考えでしかない。何より、計画はそのプロジェクト用に初めて作ったもので、どこでも一度も試したことがない。この事実をもっとプロジェクトマネージャもプロダクトマネージャもスクラムマスタも認識すべきである。つまり、上手くいく確証なんてどこにもないのである。基本は、大局的は楽観的に、局所的には悲観的に物事を考える志向が必要である。

しかし、失敗していないのはこれまでであって、次も失敗しないとは言い切れない。なにせ、やったことがないのだから。

失敗の本質―日本軍の組織論的研究 (中公文庫)