時間に追われてもまずまずの出来の資料の作り方

ペアプログラミングは、二人一組がコードを書く役割と書くコードに対してプロポーズ（積極的に提案）する役割になってコードを書くプログラミング技法です。

＃かなり雑な説明ですけど

技術のギャップが強制的に徒弟関係を作れる

ペアプログラミングの良い点は、技術的に優秀なエンジニアと組むことで成長途中のエンジニアに対して（そのコードを書いている間に限り）徒弟関係が成立することです。

徒弟関係が成立する間は、積極的に優秀なエンジニアの技術移転が進む環境が作られます。成長途中のエンジニアに対し、技術的なホワイトスペースや仕様をコードに変換する思考、つまり、発想の仕方を半ば強制的にインストールすることができます。

まあ、捉え方によっては、ですけど。

徒弟関係で技術移転を図れる

でも、技術的なギャップは意識をせずに生じるものですから、なら一層のこと技術的なギャップを作り、優秀なエンジニアから成長途中のエンジニアに技術移転を図ることが組織的な技術の向上を進める上で採用しない手はないことになります。

では、コードになる前の、

「仕様案を作る際のペアプログラミングに相当する手法はないのかしら」

と思ったのです。

文書作成でも同じ効果の方法があるか

さて、あるのでしょうか。「ブレスト」はどうでしょう。イメージします。会議室に複数人が集まり、ファシリテータがホワイトボードの前に立ち、テーマについてディスカションを促します。

現実はどうでしょう。ブレストでも他の会議でも話す人は話すし、話さない人は話さない。

では「レビュー」はどうでしょう。レビューアとレビューイに分かれ、レビュー観点に沿って指摘をし、合否を決定します。

ペアプロと圧倒的に違うのはレビュー対象が事前にできていることが前提で、静的なオブジェクトに対してウォークスルーするのです。また、レビューは基準をボーダーとして合否を決め、リジェクトされれば修正の上、再レビューというプロセス設計になっているところがあります。ペアプロはその場でより良いコードに修正して行きますから時間に対する価値観が違うという見方もできます。

知っているインプットでしか仕様は作れない

以前、トラブルの説明をする必要があるにも関わらず、技術的な情報を持ち合わせていない（メンバが知っている）ときに、プロジェクタにワードを映し、メンバにはそばについてもらい、技術情報を教えてもらいながら資料を作ったことがあります。

ある意味、ペアプログラミングの手法をしつつトラブルの説明資料を作ったとみなすことができるでしょう。

その際の経験で思ったことは、インプットをもらいながら文字に変換しなければならないので「会話」をしながら文字を生成するプロセスをするのはしんどいな、ということです。

じゃあ、会話せずに文章を作ればいいじゃないかと思うかもしれませんが、何せ情報を持っていませんから会話をせざるを得ないのです。

会話をする、理解する、文字で表現する、実際に打ち込む、声に出して読み上げる、ということをリアルタイムにするわけです。

とても難しい作業で終わった後、さずがにヘタリましたがアウトプットされた資料はまずまずでしたし、出来上がりも早かったです。

この事例から、ペアプログラミングと同じように仕様を検討する資料を作る（デザインする、でもいいかも）際にも、ペアで作成する方が効果的かもしれません。

エクストリームプログラミング

エンジニアとして開発手法やツールを変えたいと不満を言うより確実に変えるために

エンジニアが所属する組織の中で、特にプロジェクトの開発手法、ツールなどにおいて、あれこれと思うところを場面場面で意見だったり愚痴だったりを言っている光景を見かけることがあるのですが、そうした行為、つまり、意見や愚痴がどれだけ実現に向けて進むかと言えば、ほとんど実現しないのではないか、と思うのです。特に、愚痴の類は。

担当エンジニアができること

担当エンジニアができることは自分の裁量の中で、です。

チームのプロセスや手法を変えるためには、影響と、リスクと、見通しの裏付けが現状取られているコストに対して優位性が必要です。

不満に思っていることが、現状を変えるコストを投下し、且つ、リスクをテイクしてまでチームを動かす判断に至るかどうか、と考えることです。

チームのプロセスや手法を変えるために、自分の裁量の中で実績を作り、それを口コミで広めフォロワーを増やすことでチームのデファクトにしてしまうというアプローチもあります。

リーダエンジニアができること

リーダになると何らかのロールを一任されるので裁量の範囲が広く重くなります。ロールを一任されるということは、プロジェクトマネージャの権限を一部ですが権限移譲されてるということですから、担当する領域に限り、プロジェクトマネージャと握れれば好きにできます。

担当エンジニアとリーダエンジニアの違いはロールの範囲、つまり、負う責任に伴う権限の有無です。

プロジェクトマネージャができること

プロジェクトマネージャになるとそのプロジェクト全般の推進に係る範囲において責務と引き換えに権限を持つことになります。

プロジェクト内についてはヒラエルキーの頂点に立つ（現実は、開発責任者やプロジェクトオーナーがいるので中間管理職ですが）のでプロジェクトに向かう場合は最高権限を持っていることになります。

持論から言えば、チームの存在意義はプロジェクトの目的を達成するために存在するのであり、プロジェクトの開発手法やツールはプロジェクト最適化で選択されなければなりません。

ただ、負う責任の範囲において、裁量を持っているのでプロジェクトに対してプロジェクトマネージャの嗜好やプロジェクト内でのLabを試すことができます。

マネージャができること

マネージャができること。組織の中で担当するビジネスをキャリーする立場です。担当するビジネスに対して結果を出すことが大前提なので、結果に到達するオペレーションであればどのような開発手法もツールもプロジェクトチームに対して影響力を行使することができます。

ここまでロールで分けてそのロールの立場から開発プロセス、開発手法、若しくは、ツールにおいて変えたいとか改善したいと思うとき、愚痴をいうことがどれだけ無駄かがはっきりしたのではないか、と思うのです。

エンジニアにおいても組織のメンバである以上、組織を巻き込んでまで負う責任とひもづく（はずの）権限がなければ変えることはできません。

現行の開発プロセス、開発手法又はツールを変えることによる効果の実績がなければ。

逆に言えば、権限を持ち合わせれば、その権限に応じて変えていくことができます。

つまり、組織の中で自分自身を超えた範疇まで影響を及ぼすようなシステム開発をしたければ、影響を及ぼしたいポジションにつくことが必須なのです。

影響力の武器[第三版]: なぜ、人は動かされるのか

DevOpsの前にAppsInfraである

ご存知のとおり、DevOpsとは開発と運用を「上手いことやろうね」という開発手法なので、そうした手法が必要だということの裏を返せば開発と運用は良い関係でない組織が多い、という証左なんですね。

確かに、開発プロジェクトで運用までを考えて非機能要件を真面目に考えているケースってどれだけあるのかな、と天を仰ぎたくなることもなくもないですけど。

顧客によっては、非機能要件や非機能の機能仕様には全く関心がなく、機能要件や機能仕様だけしか関心がないこともありますから。まあ、そうした顧客は自分でお守りをすることをしないし、作った後の運用は運用業者に丸投げしているからかもしれませんが。

このDevOpsは割とわかりやすいのですよね。少なくとも契約が開発と維持管理で分けますので。どうして分けるかというと、開発は請負契約だったり請負契約と準委任の混合契約だったりする一方、維持管理は請け負うような性格のものではないので準委任契約（保守契約みたいな言い方もしますが）と契約自体を一緒にしないものなので。

それよりもう少しなんとかした方が良いのはAppsInfraです。Appsはアプリケーション開発でInfraはインフラストラクチャー、つまりインフラ基盤ですね。こちらの方がプロジェクトの中でのせめぎ合いが（観測範囲では）激しいです。

過去に経験した超大規模プロジェクトではそれはそれでバトルってましたから。

はたから見ていた感想ですけど、あれはインフラが「不憫だな」と思いましたもの。契約はアプリもインフラも同じようにするか、得てしてアプリを先行させます。なぜなら、インフラはアプリ要件で機能要件やキャパプラが左右されるから。

その上、アプリと同時か後からスタートするのにアプリ要件が出てこないとフェーズをexitできないという依存関係ができてしまうんですよね。まあ、だからインフラをクラウドで買って、後から気軽にスケールアウトしようと思うわけですが。

あとはせっせとアプリの非機能要件を聞き出してパラメータに落として作ってしまいたいのがインフラ屋の気持ちなんですが、アプリはアプリで顧客が決めないからと中々スペックを出さない。で、とりあえずでいいからとか、いついつまでに諸元を出さないと

「デフォルト値で構築しちゃうゾ』

とか言い合いになってアンニュイな気持ちになるわけです。

それを解決するには、アプリとかインフラとかのレイヤーで分けるプロジェクトチームの組織ではなくて、業務機能をある程度のサイズでクリップする方が良いのです。

ただ、それでは問題があるですよね。

例えば、工数的なものでは、アプリはガバッとバジェットを確保する（しやすい）のは顧客の業務要件を実現するのがアプリなので。一方、インフラは残りカスみたいなバジェットだったりするわけです。少ないインフラの工数を業務機能でクリップ単位に振り分けできるほどの単位かどうかということです。

更に言えば、技術エリアの話です。インフラシステムを作るための技術領域ってめっちゃ広いし、深いです。だから、インフラエンジニアは専門で細分化されすぎているという面もありますが。

それをアプリのメンバも含めて技術的なカバレッジができるか、と。廃れた言葉を使えばフルスタックエンジニア、みたいなもののライト版でもいいからカバーできるかどうか、と。

スクラム開発のLeSS（Large-Scale scrum in scrum）だとその辺はどうするんでしょうね。やっぱりアプリに専念して、まあアプリ基盤的なものでクラウドインフラのあたりは吸収してもらって、って感じでしょうか。

DevOpsだと開発エンジニアが維持管理エンジニアになる（残る）ケースも一般的ですから、対応する技術エリアのカバレッジは増えるにしてもAppsInfraのような畑の違う感じではないので、割とシームレスだと思うのです。モチベーションは別ですが。

AppsInfraは技術的なシームレス化とか技術の共有はムズそうですなぁ。

変革の軌跡 【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】

「なぜ」を知るエンジニアと知ることができないエンジニア

エンジニアにも「なぜ」を知ることができるエンジニアと「なぜ」を知ることができないエンジニアがいるのです。

以前、アーキテクトと雑談をしているときにこんな話をしてくれました。

「あるプロジェクトが相談したいと言ってきたから話を聞きに行ってきたんですよ。リリースを早くするにはどうしたらいいかということだったんですけど」
「リリースねぇ」
「今ならアジャイルとかテスト自動化とか色々手段があるじゃないですか。だから、そうした手段を使えばリリースを早くする方法は取れますよ、って情報提供をしたのですけど」
「けど」
「どうもツールを導入すればリリースを早くできると早ガッテンしてしまったみたいで」
「そんなバカが今時いるなんて信じられないけどね。ほんとなの」
「実話です。じ・つ・わ」
「ご苦労なことでしたね」

まだまだ続きます。

「まだあるんですよ。ツールだっていろいろあるのでどうしてリリースを早くする必要があるか参考までに教えて欲しいって説明をお願いしたんですよ」
「まあね。ビジネスニーズなのか開発プロセスの課題なのかでどこまでやればいいとか、運用をどう変えないといけないとか考えないといけないからね」
「そうなんです。それです。要求を実現するための道具なんですから、使う目的がはっきりしないと導入した後の効果も測定できないですし」 

 誰の「なぜ」は「何」か

「なぜ」それをしなければならないか。

なぜには誰かの要件があるものです。誰かが実現したいという要件を持っているから、それを実現してくれる、実現する役割を持っている人に要求するのです。その要求は顧客かもしれないし、自らの要求かもしれない。いづれにしても、誰かが実現したいことがそれを実装できる役割に伝わってくるのです。

要求を受けた人は、なぜを知る必要があります。知らなければ実現したい要件を現実にすることはできないのですから。

「なぜ」の当事者になれるか

話はさらに続いたのでした。

「でですね、わかっていると思いますけどとわざと前置きしてこう言ったんですよ」
「ふーん」
「なんかあまり興味がないようですね」
「だって学びがなさそうだもん」
「もうちょっと付き合ってください」
「いいけど」
「わかっていると思いますけど、ツールですから運用に耐えられるように設定しなければならないし、ツールに合わせて運用も変えなければなりません」
「そりゃそうだ」
「でしょう。それでそれはプロジェクトで考えて、やらないといけませんよっって」
「普通だよね。それ以上でもそれ以下でもない」
「そうしたら、『え、そうなの。そんなんじゃウチでは使えない』ですって」
「それで」
「説明が済んだので退席しました」

「なぜ」を知ったら、次はそれを実現しなければならないのです。それがあなたの役割なのであれば。

要件が増えればそれを実現する手立てが必要になりますし、場合によっては現状のプロセスを捨てて新たに設計してチームにインストールしなければならないかもしれないのです。

それでも、実現しなければならない要件があるなら、実現する役割を負わなければなりません。役割を負うということは当事者になるということです。実現するために必要なことは全てに関わらなければならないのです。

見方を変えれば、「なぜ」を知ることができるエンジニアは当事者であろうとするし、「なぜ」を知ることができないエンジニアは他人事なのです。だから、要件を実現するためにプロアクティブに動けないのです。

歌を聴くフレンズなんだね

 デフォルトで出てくるのはプレミアムをつけている業者なので、右のサイドバーから定価で買えるショップを選ぼうね。

ようこそジャパリパークへ(初回限定盤)

説明が下手なエンジニアはスコープを使おう

スコープというキーワードから何を発想するでしょうか。プロジェクトマネージャをやっていると、つい、スコープマネジメントを思い出してしまいます。

プロジェクトマネジメントでのスコープは契約して履行しなければならない委託された業務です。契約書に書かれたドキュメント、プログラムなどがそれにあたります。

ところで、先日あるメンバの仕様説明を聞いていて

「（何について話しているのかわかりにくいな）」

と思いながら聞いていたときに気づいたのは、仕様を説明している対象について、その仕様が存在する世界と仕様の関係や各種の条件が出てくる際のケース分けがはっきりしないからだ、ということでした。

どこの世界について話しているか界面を示す

まずはこれから話そうとしている世界を示して欲しいのです。表でも図でも良いので、世界は広いけれど

「これから話す範囲はここですよ」

と界面を明確にして欲しいのです。

なぜ界面を明確にするかというと、これから説明しようとしている対象自体が間違っていたり、大きすぎたり（過大）、小さすぎたり（過小）するかもしれないからです。

いくら良い仕様だとしても世界観という前提が間違っていたら意味がありませんし、界面が曖昧だと界面に隣接している条件は対象になるのかならないのかの判定ができないためです。

界面をはっきりするということは、界面で対象を明確にすることなり、これから説明するスコープを示しているということができますね。

条件も図表で分離する

兎角、話のわかりにくい説明をするエンジニアにあるあるなのは、インプット情報として知っていることだけを仕様にしようとするこということです。じゃあ、

「このケースは」

とケース分けをしていくと考えていないということがしばしばあります。そのケース分けを何度か質問してみると次第に不機嫌になったりします。考慮が足らないのはエンジニア自身の不作為なんですよ。

そうしたことを起こさないためにも、条件はAと仕様を定義したら、A以外の仕様の定義をしなきゃいけない。

ここでも仕様の中でAというスコープだけを示すのではなくて、仕様全体を示してその中を条件で分けるならAというスコープばかりを照らすのではなくて、常に仕様全体を捉えなければならないのです。

そういう意味でスコープは何について話そうとしているか範囲を照らすツールとして使うと良いと思います。

誰が担当しても同じようにできる見積もりの作り方

作業の見積もりをメンバのひとりに頼むとメンバの経験値で次のように作業を見積もります。

見積もり工数＝（自分だったらこのくらいでできそうかな）工数＋経験値によるバッファ

 （自分だったらこのくらいでできそうかな）は、見積もりをしたメンバが自分に期待する予測値です。経験値によるバッファは、これまでに経験してきたプロジェクトの中で類似から導き出した経験知による安全係数です。

なので、メンバに工数を見積もりさせる場合、誰に見積もってもらうかにより工数の算出するパラメータが違うのです。

チームで見積もりをするとどうなるか

メンバが違うと見積もり工数が変わってしまうなら、そのメンバ以外が見積もった仕事をすると見積もりどおりにならないということになります。見積もりどおりになったら偶然でしかないのです。だって、（自分だったらこのくらいでできそうかな）という自分を基準にした見積もりなのですから。

そこでチームで見積もりをするとどうなるでしょう。これは実例（フィルターかけていますけど）なので、真似てやってみていただければと思います。

 環境

・資料はプロジェクタに写し同じ情報を見る
・ホワイトボードに見積もる作業を書き出す
・制約条件を列挙する
・見積もり対象の作業を書き出す。

進め方
・見積もり対象の作業の完了条件を具体的に書き出す
・納期を日にちで明記する
・インプット情報を具体的に書き出す
・プロジェクト内で類似する作業がないかを探し実工数を書き出す
・類似プロジェクトがない場合は同じ規模、同じ難易度の作業を探し実工数を書き出す
・技術的に中レベルのメンバをモデルにする
・モデルメンバが実施した場合の工数を各人が見積もる
・最大値、最小値のメンバの考慮事項の説明を聞き、書き出す
・見積もり対象の作業で考慮すべき事項であれば取り込む
・見積もり対象の作業ではなくプロジェクトで考慮すべき事項は課題管理に書き留める
・見積もり対象の作業の工数をメンバ全員で同意する
プロジェクトとしての留意事項
これだと、正味の工数＝理想工数となり、特定のメンバが見積もりでしていたバッファが含まれていません。もし、トラブルが発生したら発生した時点で進捗遅延が確定です。それはそれで困ってしまいます。
ではどうするか。

チーム、つまりプロジェクトとしてのバッファを積みます。このバッファはメンバに預けるバッファではありません。悪魔でもプロジェクトのバッファです。それをマイルストーンの前に起きます。どのくらい置くかは、他の作業とリソース調整で決まります。目安は（例えば１０％とか）持っておいても良いでしょう。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~