そして要件定義をできるエンジニアはいなくなる

要件定義では要件を決める。少なくともシステム化要件を知らなければ、システム方式や実現仕様に詳細化、展開しようがない。

ところが、システムが何世代も続くと要件定義をせずに、基本設計からとか、詳細設計からプロジェクトが始まることがある。こうしたやり方を繰り返すと開発者のエンジニアサイドに弊害が起きる。

何が弊害となって困るか想像がつくだろうか。

いくつかの改修を繰り返してしばらく経つと、途中から人が入ってくる。特に、大規模なシステムや数年経ったパッケージ開発ではよくあることだ。そうした環境下で中途参画してくるエンジニアが入ってくれば、まず、業務説明をする。

その業務説明では、こんな風に業務は説明される。

『こうなっているので』

『これがこのプロジェクトのルールに決まっているから』 

 経緯は一切説明されない。

これが拙い。『なぜ』がないのである。

気づきの感性を持っているエンジニアはそこに違和感を覚えるものだ。だから、

『どうしてですか』

『なぜですか』

 と素朴に、本当に素朴に質問を投げかけても答えられないことが出てくる。

要件定義を経験した当事者が残っていれば、まだ良いのである。要件定義を定義した経緯を知ってるからその関係者を引っ張ってくればいい。残っているならば。

ところが、いつの間にかエンジニアサイドに一人として要件定義をしたエンジニアが誰もいなくなっていることなんてことになるのである。

その上、エンドユーザ側も誰一人としていなくなる。

そこに残されるのは、要件定義をできないエンジニアのチームである。

嘘だと思うかもしれない。

でも、周りを見て欲しい。そう、今座っている席で同じチームのエンジニアを眺めるのである。

例えば、今担当しているシステムをリプレースすることになったとしよう。グローバル化するので要件定義からすると、エンドユーザの役員からオーダがあった。

さて、誰が要件定義を引っ張ることができるだろうか。

それは周りの誰か。

それともあなた自身か。

要件定義をする実力がないことがバレたとき、他のベンダに乗り換えられるのである。

はじめよう! 要件定義 ~ビギナーからベテランまで

実現性検証とテーマが決まっているPoCにアジャイルは関係しない

Poc（Proof of Concept）についてはどのくらいのエンジニアが知っているだろうか。例えば、実現したいシステム化要件があり、それが本当に実現できるか小規模な環境を作り、そこで実現方式が実装できるか実装し、評価する。

その結果を踏まえた上で、本格的にプロジェクト化するかを意思決定するのである。

つまり、PoCは委託側のリスク対策として行う。

ところが、である。

　PoCをいくら実施しても、その先が続かない。ベンダーに対価を支払って支援を仰ぐのであれば、リターンを得るどころかお金が出ていくばかり。これがPoC貧乏の実態だ。こうした状況は珍しくないと、講演者は強調する。

tech.nikkeibp.co.jp

その点から言えば、引用している記事は間違いである。間違いはいくつかある。

PoCは委託側の都合で行う

冒頭にも書いたが、PoCは委託する側がいきなりプロジェクト化して失敗するリスクを識別しているからPoCを行うのであって、ベンダ側の都合ではない。

意思決定するのはどんな場合でも、最終的には発注する委託側である。

ベンダ側もPoCを提案することがあるが、それは、要件が曖昧だとか、要件での実装をしたことがないためとか、起因は委託側の要件である。その要件をベンダのソリューションで実現するには確信が持てないからPoCを提案して、ベンダ側のリスクを下げようとするのである。

PoCで損はしない

その後が続かないと書かれているが、それはPoCで期待する結果が得られていないからではないのか。

つまり、PoCとしての成果である実現性検証はできているのである。ただ、結果は本格的なプロジェクトに進めてはいけない結果になったからPoCでおしまいにするのである。

もし、PoCで期待する結果を得られたなら、本格的なプロジェクト化のための予算を確保し、PoCをやったベンダに特命で発注するか、競争入札すれば良いのである。 

PoCとアジャイルは無関係

 PoCはコンセプトが実現できるかを検証するのであって、必然的に最小の論理的には本番と同じ構成にするのが望ましいが、スピードと小さな予算で行う（条件付きで制限を設けることがある）ため、環境に制限を設けることが多い。

タスクも実証できるかテーマを決めるので、検証のスコープは決まっている。

これを実現したいのか、ではなく、技術検証として確かめたいテーマを実装できるか、できたところで期待する動作をするかを確かめるのである。

よって、全くアジャイルは必要ない。

この記事はPoCの考え方を知る上で、お勧めできない。

POC ポック コープ キャップ one size Meyhylene Green

失敗しない データ分析・AIのビジネス導入: プロジェクト進行から組織づくりまで

仕事で予習することと恋愛の共通点

先だって、あるテーマで人と会うことになった。テーマ的に先方のことを知っておいた方が良いだろうと思い、その会社の事業やサービス、ロケーション、四半期決算書などを読む時間を作り、読んでおいた。

まあ、お仕事の予習である。

企画業やコンサル業、提案などでは、相手のことを知っておくことは、とても大事なことで、公開されている情報だけでも知っておくことは『あなたに関心を持っている』という一つのメッセージだと自分は思い、やっている。

そうした予習は自然と身についたものではなく、過去にそうした予習をせずに出かけて行き、冷や汗をかいたことが何度もあり、これはやっておかなければ拙いと身にしみて勉強した成果である。

担当エンジニアやリーダ程度ではしなくてもプロジェクトマネージャやマネージャの方を見れば、そっちで答えてくれるからそれでよかった。

だんだんと、場のメインキャスタになると、そうはいっていられなくなる。なにぶん、『お前知っているか』と顔を向ける相手がカウンターパートになるためである。

予習をしていないと、その場で『やべぇ…無理して読んでおけばよかったよ…』という事態になるが、調べる時間を作り、読んでおけば『（それ知ってる）』とそれはすっ飛ばして、話しかけられているテーマの本質がどこにあるか、真意はテーマの流れ的にどちらにあるのか、と考える時間を確保できるのである。さらに、その『真意を探る質問を考える』こともできるようになる。

先方は、課題を持ってこちらを召喚しているので、話したいテーマを先方の言葉で持っている。こちらは予習をしている。そうした条件で話したいテーマを話すとどうなるか。

テーマに集中して話をできるから、テンポよく、会話のやりとりもスピーディに進むのである。そうした会話の印象、特に、初回の印象はとても強く残る。さらに、本音で話をするまで最短で進む。話の終わりに次に会う約束まで取れる。

これ、何かと同じではないか。

そう、恋愛である。

相手に関心を持ち、予習をしておく。予習といっても何もデートコースを念入りに調べあげたりすることではない。相手の知っていることから、想像を膨らませて、関連することをざっとキーワードを押さえておく。

相手の時間をもらえるのだから、相手が関心を持っていることを調べるだけである。仕事の予習であれば会って話したいテーマ（＝相談事）が伝えられるものだ。デートではそれはないだろうし、逆にこちら側が会いたいのであるから、会いたい理由はこちら側で作る必要がある。

だから、共通の話のテーマになりそうなことを予習するのである。ただ、先方がその界隈のスペシャリストである（悩みを持っていれば勉強する）ことはよくあることなので、決して場のマウントを取ることをせず（それが目的ではないんだぞ）、聞き手に徹することは、仕事でコンサルや提案をする前のヒヤリングでも大事なコミュニケーションの取り方である。

この、知らないことを知りたいというポーズは、ある意味、弱みを先に見せておくということである。これ、人間関係を醸成していく上でとても大事なことである。
＃テストに出でるよ

知らないことを無理に知っている風にするのはコンサル芸であるが、デートではそこは頑張りすぎずに、相手に華を持たせつつも『貴方の話で興味を持ったのでもっと聞きたい』とメッセージすることで『次に繋がる』のである。

さて、なんの話を書いているのかというと、仕事の予習と恋愛は似ているよ、である。

オクテ女子のための恋愛基礎講座 (幻冬舎文庫)

モテたいわけではないのだが ガツガツしない男子のための恋愛入門 (文庫ぎんが堂)

ゼロから始めるオクテ男子愛され講座

エンジニアがマネジメントに興味を持ったら読む本

読んで良いと思った本の感想を書き残すのは良い習慣だとおもう。それがブログなら、コメントも、感想に対するリプもあるだろうから、そうしたコメントからまた、理解が深まることもある。エンジニアは、そうして自分自身で得る学びより、他のエンジニアから学ぶ方が多い。

dskst9.hatenablog.com

その点で良いとおもう。紹介されている本で気になるのがこの目次構成である。

この切り口がどうも人の単位を切り口に構成されているのが良し悪しではなく、単に特徴的に感じて気にかかるのである。

推薦の声
まえがき
はじめに

1章 マネジメントの基本
1.1 上司に何を求めるか
1.2 管理のされ方
1.3 自己診断用の質問リスト

2章 メンタリング
2.1 チームの新人に対するメンタリングの意義
2.2 メンターの務め
2.3 すごい上司、ひどい上司──アルファギーク
2.4 メンターを管理するコツ
2.5 メンターの重要な心得
2.6 自己診断用の質問リスト

3章 テックリード
3.1 優秀なテックリードなら必ず知っている、ある奇妙な「コツ」
3.2 テックリードの基礎知識
3.3 プロジェクトの管理
3.4 プロジェクト管理の実務
3.5 決断の時──技術職を貫くか、管理職への道を選ぶか
3.6 すごい上司、ひどい上司──プロセスの何たるかを心得ている上司と、プロセスツァー
3.7 優秀なテックリードとは
3.8 自己診断用の質問リスト

4章 人の管理
4.1 直属の上下関係
4.2 チームメンバーとのコミュニケーション
4.3 1-1の進め方
4.4 すごい上司、ひどい上司──細かすぎる上司と、任せ上手な上司
4.5 効率よく仕事を任せるために──実践的アドバイス
4.6 「継続的なフィードバック」の文化をチームに根付かせる
4.7 勤務評価
4.8 キャリアアップの取り組み
4.9 やりにくい仕事──成績不振者の解雇
4.10 自己診断用の質問リスト

5章 チームの管理
5.1 ITスキルの維持
5.2 機能不全に陥ったチームの「デバッグ」の基本
5.3 盾になる
5.4 チームの意思決定を主導するコツ
5.5 すごい上司、ひどい上司──「対立を何とか手なずけられる上司」と「対立を避けて通りたがる上司」
5.6 やりにくい仕事──「チームの結束を乱す人」への対処
5.7 管理者が担当するべき、より専門的なプロジェクト管理
5.8 自己診断用の質問リスト

6章 複数チームの管理
6.1 時間の管理──何はともあれ「重要な仕事」に照準を
6.2 意思決定と委任
6.3 やりにくい仕事──「ノー」にも言い方がある
6.4 コードの作成以外のITスキル
6.5 直属の開発チームの健全性を見きわめる
ほか

7章 複数の管理者の管理
7.1 スキップレベルミーティング
7.2 部下である管理者たちに責任を課する
7.3 すごい上司、ひどい上司──「ノー」と言える管理者とイエスマン
7.4 新任管理者の管理
7.5 ベテラン管理者の管理
ほか

8章 経営幹部
8.1 技術系の経営幹部の肩書と役割
8.2 技術担当バイスプレジデントとは?
8.3 CTOとは?
8.4 優先順位の変更
8.5 戦略の策定
ほか

9章 文化の構築
9.1 自分の役割の見きわめ
9.2 会社や担当部署の文化の創成
9.3 コアバリューの活用
9.4 文化に関するポリシーの策定
9.5 キャリアラダー作成のコツ
ほか

10章 まとめ

索引

引用　https://amzn.to/2zUbVZu 

振り返れば、自分自身のマネジメントに対する知識は、プロジェクトマネジメントから入ったのだろうと思っている。プロマネを経験しながら次のステップを考えたとき、目指したのがマネジメントだった。

そこで調べてみるとマネジメントのメジャーどころは、P.F.ドラッカーだったのである。それに本も多く出ていてどれがどう違うのかがさっぱりわからない。だったら、要約版を読み、なるほどと１つでも思えばよかろうと買ったのがこれである。

マネジメント[エッセンシャル版] - 基本と原則

さて、エッセンシャル版のマネジメントの目次を見てみよう。

Part1　マネジメントの使命

第１章　企業の成果
企業とは何か
事業とは何か
事業の目標
戦略計画

第２章　公的機関の成果
多元社会の到来
公的機関不振の原因
公的機関成功の条件
第３章　仕事と人間
新しい現実
仕事と労働
仕事の生産性
人と労働のマネジメント
責任と保証
「人は最大の資産である」
第４章　社会的責任
マネジメントと社会
社会的影響と社会の問題
社会的責任の限界
企業と政府
プロフェッショナルの倫理
Part2　マネジメントの方法
マネジメントの必要性

第５章　マネジャー
マネジャーとは何か
マネジャーの仕事
マネジメント開発
自己管理による目標管理
ミドルマネジメント
組織の精神
第６章　マネジメントの技能
意思決定
コミュニケーション
管理
経営科学
第７章　マネジメントの組織
新しいニーズ
組織の基本単位
組織の条件
五つの組織構造
組織構造のついての結論
Part3　マネジメントの戦略
ドイツ銀行物語

第８章　トップマネジメント
トップマネジメントの役割
トップマネジメントの構造
取締役会
第９章　マネジメントの戦略
規模のマネジメント
多角化のマネジメント
成長のマネジメント
イノベーション
マネジメントの正統性

結論
付録　マネジメントのパラダイムが変わった

 引用　マネジメント[エッセンシャル版] - 基本と原則

アプローチの違いがわかるだろうか。『エンジニアのためのマネジメントキャリアパス』の方が取り扱っている世界が技術の世界だけを対象としている。

マネジメントの世界は広いが、その中のエンジニアの世界を切り出したと書いてあれば良いのだが、そうかどうかはまだ読んでいないのでわからない。

本が売れない時代だからこそ、ターゲットのセグメントをフォーカスし、そう取り扱っているのだろうと察している。

さて、エンジニアがマネジメントに興味を持ったらどの本を読んだらいいか、である。エンジニアに特化した本であれば、上記の本からもで良いのかもしれない。

自分のアマゾンの購入履歴を古い順で追ってみると以下の本を読んでいたらしい。

マネジメント[エッセンシャル版] - 基本と原則

組織構造のマネジメントを買ったのは、旧版である。

【新版】組織行動のマネジメント―入門から実践へ

ジョイ・インク 役職も部署もない全員主役のマネジメント

本棚にはもっと多く積んである。組織だとこうなる。

組織戦略の考え方―企業経営の健全性のために (ちくま新書)

リーンソフトウェア開発と組織改革

組織パターン (Object Oriented SELECTION)

米海軍で屈指の潜水艦艦長による「最強組織」の作り方

チームの切り口だとこんな状態である。

システム開発現場のファシリテーション ~メンバーを活かす最強のチームづくり~

あなたのチームは、機能してますか？

すごいチーム―結果を出すチームマネジメント12の方程式

チームビルディングの技術―みんなを本気にさせるマネジメントの基本18

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 アマゾンでの購入履歴だけで振り返ると、割と理屈っぽいところからhow toの方によっているのは、マネジメントはドラッカー以降、代わり映えしておらず、how to本やプラクティス本が多く出て、ある界隈で話題になるくらいに手に入れているかだろう。

ただ、これを全部読んだかと言えばそうでもない。最初の概論的なところを読み、大枠を押えたあとは経験と論理をすり合わせ続けているから、それほど必要としないのである。

エンジニアもマネジメントに興味を持ったらどこかでドラッカーはつまみ食いしておいた方が良いかもしれない。

あなたは、今年何回メンバをアピールしたか

最近、チームのミーティングがほとんど勝手に進んで行く。みんなが集まって、最初に話すは誰とは決まっていないが、タイミングをみて自分から、『これだけはリマインドしておこう』というものだけ、口頭で『念押し』する。

わざわざ、本社部門からメールやポータルで周知されていることを限られたミーティングの時間で繰り返して伝えるのは勿体ないし、メンバの自主性を信頼していないのと同じである。

ただ、締め切りを守らないと後工程になる依頼元の部門が困るものも中にはある。そういったものについては、chatでもリマインドするが、口頭で終わったどうかだけを尋ねる。終わっていないメンバには、『NN日までだよ』と具体的に伝える。

後は、チームの主テーマのスケジュール確認も勝手にやってくれるし、資料準備や手配もやってくれる。それさえ終われば、後はメンバの時間になる。今は、残りの時間を当てて、技術テーマを一緒に勉強しているのである。

では、いきなりそうなったのかとか、自然発生的にそうなったのかと言えば、そんなことはない。

繰り返し、刷り込んできた結果である。チームを作り、チームで考えてあれこれと準備するようになるまでにはそこそこの時間を必要としたようにも思えるが、思った以上に早く自律し始めたとも思える。受け身のチームはずっと受け身であることが多いので。

前に少し述べた通り、最初からそういったチームの活動ができたわけではない。スタートをゼロとして、そこから実現したいチームに到達する道のりを考えるとあちらこちらと寄り道や足踏みをしながら進んできている。

今日もまた、チームの目指す、チームの存在意義とは反対のことを言っている、なってことは何度もあった。それを都度、それは目指すチームの姿とは反対を向いていると伝えてきたのである。

メンバはチームの中での発言と、実際の一人ひとりの行動とずれることがある。一人ひとりの行動の積み上げがチームの行動になり、それの積み重ねが結果として残る。だから、ときどき、小さな会議室で『違うのではないか』と伝える。

一方、チームの外、組織の中では、メンバはパーフェクトなわけではないし、過去のキャリアや受け止める側にこびり付く印象がとても強く残る。そうした印象はネガティブなことが多く、評価でマイナスに働く。それがたとえ過去のことだとしてもずっと引きずっているのである。

自分は自分のチームのメンバが今のチームで、どれだけチームの存在意義を理解し、そうした方向性に合わせて活動をしているかをみている。個人の評価は個々の目標設定とエビデンスを照らし合わせ、行う。個人の貢献は行動の結果であるから、過去は無関係である。

恋人の過去の恋愛話より、今の自分とどれだけ楽しい時間を過ごしているかの方が余程価値がある。

いや、自分と過ごす時間以外に自分にとっては、価値（＝幸せ）はない。

好きな人を好きだと思い、好きだと伝えるように、メンバの貢献をそのまま伝える。自分にとってメンバの過去はどうでも良いし評価の対象ではない。

『○○さんは××だよね』

『（××な過去は知らないが）今の○○さんはこんな風に貢献している。それで何か』 

 アピールするのが自分の仕事の１つである。メンバをアピールし、評価を上げる。

事細かにみれば、まだまだなところもあるのも事実だが、それをいう必要はどこにもない。できていることを出来ているというだけでいい。

出来ていないところが目標なのだし。

【華やかな色合いが人気のフルーティな辛口ボジョレー ロゼ ヌーヴォー】 ジョルジュ デュブッフ ボジョレー ロゼ ヌーヴォー 2018 750ml [フランス/ロゼ/辛口/750ml]

WBSのスキルをアップする思いつきイベントアイデア

一つピークを超えて、ひと段落しているのだが実際はそう甘くはなく、次から次へとさらに高い山を登らなければならないような気がするも、そう言う気にはなれない。

自分が仕事をする場合は、ある程度感覚的にこれをやればいいのだろうというイメージを掴めないとどうにも仕事が手につかない。そういった掴めないところは、ただ悶々と考えるよりは、何か知っていそうな誰かと話をしたり、聞いて回って情報を集めて形作るほかない。

そうした自分の仕事の仕方は自分ひとりなので誰にも影響を与えないが、プロジェクトチームになると作業プロセスをデザインしたり、それを雛形にWBSに展開したりする必要が出てくる。

担当のエンジニアに『WBSを作って』と依頼すると、作業プロセスのデザインや準備段階や周りとの連携を全く気にせず言われた範囲だけのWBSを作ってくる。さらに、そのWBSは日単位で作るので正味どのくらいでできるのかわからないし、全部、上手くいったらという前提付きでもある。

今どき、WBSを作る際に誰も見てあげないのだろうか。そのままでは本人が不幸になるだけではなく、周りもひどい目にあうのは見えているのだが。

WBSをただ眺めるビアバッシュの会

ということを考えながら思いついたのは、WBSをただ眺めるビアバッシュの会をやったら面白いだろうと。組織の中なら自由にやっても良さそうだが、公募イベントだと勘弁的にNDAを結ぶか、クレンジング前提でやる配慮はやっておいたほうがよさそうだ。

WBSを作るモブ

もう一つは、プロジェクトチームが工程やDoingのながでどのような作業プロセスを踏まなければならないか、最初にモブでWBSを作るワークショップをやったらいいんじゃないかという思いつき。

それぞれの目的、レベル感

前者のWBSを眺める会は、WBSを作れる人が気づきをもらいに行くレベル感だろう。後者は、WBSを作れないエンジニアをドライバーに（もちろんモブなので順番に）して作り方をスキルトランスファする感じだろう。

 誰かやってみたら教えて欲しい。

東芝 E-CORE(イー・コア) LED電球 <キレイ色-kireiro-> ボール電球形9.6W(高演色タイプ・ボール電球40W相当・610ルーメン・電球色)外径95mmタイプ LDG10L-D/G95 口金直径26mm

エンジニアにとってコスパの良いスキル

ちょっとした事情があり、大型書店に行ってある分野の書籍を買い、読んでいるのだが、走りながら勉強（本などの情報を仕入れて）して、それまでの経験知だったものを体系立てて整理し直すのは、経験から知見に変換するプロセスとしてとても良い。

何より、自分の専門家としての経験と言うよりは、それにプラス方法論や手法、元となる法規などを引用した方が、そうした『専門性の知識を持っていない』相手に認知してもらう手段として即効性がある。特に、役職者の方に効果がある。

などと思いをつらつらとしていたとき、エンジニアにとってコスパの良い、それに相応したものがあるに違いないと思ったのである。

さて、何がエンジニアにとってコスパの良いものであろうか。

エンジニアが持たなければならない、専門性のスキル、コンピテンシは、

• 基礎スキル
• 技術スキル

がある。基礎スキルは、その人の性質に根付くスキルである。性格やそれの現れとしての行動様式も含む。気づき、意志、伝達、判断、交渉などなど。

技術スキルは、2つに分ける。

• 手法・方法論
• 技術の適用

手法、方法論は、例えば、システム開発手法などである。技術の適用は、言語、製品知識などシステム開発を行う上で、必要となるものづくりのスキルである。

基礎スキルと技術スキル。前者は普遍的なものであり、エンジニアその人に根付いている。どのような技術領域、ロールに変わってもどこでもいつでも使える。その意味では、ここのスキルを伸ばすのはとてもコスパがいい。

基礎スキルは身につけばコスパはいいのである。しかし、身につけ方はとても難しい。何が難しいかといえば、これを覚えれば実践できる、とはなかなかいかないところである。

例えば『気づき』は目標設定でよく見かける項目なのだが、じゃあ、『そのスキルを身につける（＝実践できるようにするために）どうするの』と聞いてみると『意識します』くらいしか出てこない。精神論しかない。『チュートリアルをやったので、基礎は身につきました』と言うわけにはいかないのである。

身につければとても便利なのが基礎スキルであるが、身につけるまでは人によっては真逆かもしれない。

では技術スキル、である。こちらの、技術の適用は一言でいえば、道具の使い方を覚える、である。ノミ、カンナ、ノコギリ。そういった道具を使い、ものを作るための技術である。

システム開発で適用される技術は、時代の変遷で代替わりをする。フルスクラッチで書いていたコードは、IDEの上で書くようになった。タイポすれば教えてくれる。そんな時代である。であるから、道具を置き換えていかねばならない。

もう1つの、手法、方法論は、そうした道具を使うルールである。コードを書くために、段階的にコードを書けるように情報をこのレベルで記述する、コードはこのパタンで。コードはこのテストのやり方で、と言う風に。

こちらの移ろいは緩やかである。やはり変遷があるがとても気づくエンジニアは少ない。気づけるエンジニアは、基礎スキルを活用する人であり、何が求められているかを探求できる人である。

ここまで思考を巡らせて、結局、何がエンジニアにとってコスパの良いスキルなのだろう。

思いついたら『やってみる』スキルなのではないだろうか。

大絶賛バカ売れポプテピピック 圧倒的成長 Tシャツ ブラック XLサイズ