2017-03-09

DevOpsの前にAppsInfraである

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者: Gary Gruver,Tommy Mouser
出版社/メーカー: 技術評論社
発売日: 2017/01/25
メディア: Kindle版
この商品を含むブログを見る

2017-03-08

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

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

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

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

まだまだ続きます。

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

誰の「なぜ」は「何」か

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

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

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

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

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

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

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

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

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

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

2017-03-07

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

off

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

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

アーティスト: どうぶつビスケッツ×PPP
出版社/メーカー: ビクターエンタテインメント
発売日: 2017/02/08
メディア: CD
この商品を含むブログ (5件) を見る

2017-03-07

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

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

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

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

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

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

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

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

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

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

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

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

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

条件も図表で分離する

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

「このケースは」

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

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

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

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

2017-03-06

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

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

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

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

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

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

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

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

環境

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

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

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

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

作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
出版社/メーカー: 毎日コミュニケーションズ
発売日: 2009/01/29
メディア: 単行本（ソフトカバー）
購入: 74人クリック: 764回
この商品を含むブログ (226件) を見る

2017-03-05

仕事をゲーム化するには

仕事なんだから楽しくやるし、遊びなんだから真剣にやる。これ、本質ですよね。月曜日から集中して仕事をするために。ブルーになっている暇はないのです。遊びを真剣にするために仕事は楽しく終わらせないと引きずってしまいますから。

では、どうやって仕事を楽しくするかですけれど、みなさんはどうやって楽しく仕事をしているのでしょうね。とても興味があります。そういうワタシはどうしているのかって。楽しい仕事とはゲーム化するのです。はい。

ゲーム化するとは

ゲーム化するとは、自分をゲームの主人公にしてゲームのステージをクリアしていくようなシナリオを自ら作り、それを実践することです。

はい、これも今書きながら定義しました。

仕様なので先に定義しておくことは必要ですし。

ゲーム化の制約条件

仕事をゲーム化する際の制約条件は以下のとおりです。

・世界（技術領域）は無指定
・職業は自分で決める
・世界（技術領域）は外的要因で突然変わる

ゲームの進め方

世界は広いので、そのうちどの地方に進むかを決めます。大きく、世界は２つに分かれていますが、境界は曖昧です。

・アプリケーション
・インフラストラクチャ

さらに開発と維持管理に分けられます。ある程度スキル上げが進捗するとステージが追加されます。

・アプリケーション
・インフラストラクチャ
・プロジェクトマネージャ　＊新しいステージが追加されました

スキル上げ

効率的にスキルを上げていきたいところです。ここでチートシートがありますので利用することができます。

レベルの定義は以下のとおりです。

・レベル１　見習い
・レベル２　師匠の指示に従って作業を完了させることができる
・レベル３　独力で仕事を完了させることができる
・レベル４　サブリーダとして自分の仕事を完了させ、メンバの作業を指導できる
・レベル５　技術リーダとして振る舞える

チートシートの記入方法は、実績で証明できるスキルエリアの★を書き込みます。これからレベル上げをしたい項目に☆を書き込みます。

	基礎スキル						技術スキル
	意思疎通を図る	協働して成果を出す	チームを運営する	課題を解決する	問題をエスカーレションする	仕事を完了させる	プロジェクトマネジメント管理方法	開発方法論	アーキテクチャ	アルゴリズム	言語	オペレーティングシステム	ミドルウェア	ネットワーク	DB
レベル１	★	★	★	★	★	★	★	★	★	★	★	★	★	★
レベル２	★	★	☆	★		★		★	☆	★	★		★		★
レベル３	☆									☆	☆
レベル４
レベル５