2019-09-21

ソフトウェア開発メトリクスの話を聞いたので読書メモを引っ張り出した

参考書籍は Software Development Metrics 。

Manning | Software Development Metrics

著者はウォーターフォールなプロジェクトやアジャイルなプロジェクトのPMやコンサルをやってきた方。

ソフトウェア工学の知識よりも現場での経験が豊富な感じ。

アジャイル(適応型)やウォーターフォール(計画重視)それぞれの手法で、どのようなメトリクスをどのように活用できるのか説明している。

メトリクスを活用する目的として、プロジェクトの状況を予測可能にすること、プロセスを改善することを挙げている。

プロジェクトの状況を予測可能にすることはステークホルダーにとって重要。

プロセスを改善することはチームにとって重要。

目的別にメトリクスの正しい使い方や間違った使い方を紹介している。

書籍で紹介されているメトリクスを計算する Excel シートがサポートサイトで公開されている。

https://www.manning.com/downloads/156

メトリクスの性質

メトリクス自体には次のような性質がある。基本的には数値化された事実であり、解釈する人によって意味が変わってくる。

情報

善悪・良し悪しと関係ない事実

兆候

問題が発生している（しそうになっている）ことを伝える

動機づけ

人間の行動を変えるきっかけになる

メトリクスの解釈

過去を照らし出す

「計画」と「現在の状態」を比較して得られるメトリクスのこと
「今までの自分たちは間違ってないよね」を大事にする考え方
状況が変化しないことを前提としている

未来に向き合う

「現在の状態」から「達成すべき目標」を比較して得られるメトリクスのこと
「自分たちはどれだけできたのか」を大事にする考え方
常に状況が変化することを前提としている

プロジェクト管理手法vs目的別メトリクス一覧

どのメトリクスも「ビジネス価値を提供できる状態になった」ことを計測しないと意味のある情報にならない。

リリースできない中間成果物(設計書やテスト結果)を計測するのは効果がない。

書籍ではプロジェクト管理手法だけでなく、プロセスモデルや出荷モデルも分類の軸として紹介している。

プロセスモデルの分類は次のとおり

線形(最初に固定した要件を段階的に具体化していく)
反復(要件の具体化を繰り返して洗練していく)
タイムボックス(反復の期間を固定して、それぞれの期間で出荷できるソフトウェアを開発する)
フロー(流れ作業的な)

出荷モデルの分類は次のとおり

開発して提供したら終わり
継続的に保守開発

2019-09-21

分割統治と役割分担、そして職務を越えた協業

ソフトウェア製品を製造、販売して対価を得るという仕事。

製造や販売はそれぞれが複雑で困難なので、より簡単で小さな問題へと分割していった。

問題領域が狭く、専門化することで、問題解決者に求められる知識や技能も特殊化していった。

そういった経緯があり業界では今のような組織が一般的になっているのだと思う。

しかし、分割された問題領域の共通性が見いだされたことで、専門性の境界を跨ぐ課題が顕在化し、新たな役割が求められるようになった。

繰り返し現れる構造のような気がするなぁ。つまりパターン。

IT の利用範囲の拡大やコモデティ化により、今までの役割分担と問題の構造が合わなくなってきたのかもしれない。

振り子のように周期性のある傾向なんじゃないか、という意見もある。

2019-09-20

Google 翻訳ツールキットが終わる

初めて共同で翻訳作業をするのに利用したのが Google 翻訳ツールキット。

2019年12月に停止するという通知がありました。

独特なUIなのでもう使わなくなってしまったけど、いろいろあったなぁ。

（フレーズを塊として意識するとか、文の構造を意識するとか、とても勉強になりました。）

今までありがとうございました。

おかげで私にはもう不要になりました。

2019-09-20

久しぶりに使おうとしたらサービスクォータがほとんど0になっていた

aws.amazon.com

2019年の6月に登場したサービスなんですね。

アカウントメニューを見てたら発見しました。

t3.medium などのインスタンスが起動できなかった原因は、対象のクォータが 0 になっていたからでした。（デフォルト値は 5 なのに･･･）

他にもクォータが 0 になっているインスタンスタイプがたくさん。普段の使用状況から設定されているのかもしれません。

以前はサポートケースから行っていた上限数の緩和申請が、クォータ引き上げリクエスト、という名前で簡単に申請できるようになったのはいい改善ですね。

2019-09-19

ネガティブ思考になる

そんなこともあります。

1. 横入りや路上喫煙を見る

2. 不快になる

3. 丁寧な行動を見知らぬ人に期待していたことに気付く

4. 期待することの虚しさを実感する

5. 期待することを忌避する気持ちが芽生えたことに気付く

6. 人間に期待することを諦める

7. 諦めてしまったことを残念に思う

2019-09-19

bash のヒアストリング

www.tldp.org

ヒアドキュメントのように文字列を扱う仕組み。

通常の文字列として評価された後（変数展開された後）、指定したコマンドの標準入力へ渡される。

コンパクトにした json 文字列が欲しいときは jq を組み合わせて使う。

$ jq -c -r <<< '{
  "EbsOptimized": true,
  "EbsBlockDeviceConfigs": {
    "VolumeSpecification": {
      "VolumeType": "io",
      "SizeInGB": 20,
      "Iops": 100
    },
    "VolumesPerInstance": 1
  }
}'
{"EbsOptimized":true,"EbsBlockDeviceConfigs":{"VolumeSpecification":{"VolumeType":"io","SizeInGB":20,"Iops":100},"VolumesPerInstance":1}}

別のコマンドの引数の1つとして使いたいときは、たぶん外側をシングルクォートで囲むといい。

echo --json-option \'"$(jq -c -r <<< '{
  "EbsOptimized": true,
  "EbsBlockDeviceConfigs": {
    "VolumeSpecification": {
      "VolumeType": "io",
      "SizeInGB": 20,
      "Iops": 100
    },
    "VolumesPerInstance": 1
  }
}')"\'
--json-option '{"EbsOptimized":true,"EbsBlockDeviceConfigs":{"VolumeSpecification":{"VolumeType":"io","SizeInGB":20,"Iops":100},"VolumesPerInstance":1}}'

2019-09-18

ごめん、ここのところテストは書いてないんだ

learning.oreilly.com

わりと衝撃的なデイブ・トーマスさんの告白が補足記事に書いてある。

もう10年ほどテストを書いてないそうな。それまでは書いてたけど、試しに止めて様子を見たら、特に悪いコードを書くようにはならなかった、と。

それでも、依存ライブラリの動作を検証するとかそういう用途のテストは書いていたみたい。

アンドリュー・ハントさんからは、経験の浅い人が混乱するからそういうこと書かない方がいいよ、と忠告されたそうな。

「テストを30年書いてきたら自分の自由にしていいんじゃないかな」とのコメントがしみじみしてる。