owkyのブログ

マネジメントについて勉強するブログ

バーンダウンチャートから始めるアジャイルな見積もりと計画づくり

開発チームの作業進捗の管理にバーンダウンチャートを使い始めた。 そこでいろいろ疑問に思ったことを整理したみた。 結果として、ベロシティを安定させたり見積もりを漸次的に見直していくようなアジャイルなアプローチが、計画づくりや進捗管理においていかに効果的かを理解することができた。

理想線はどうやって引けばいいの?

バーンダウンチャートの進捗管理では、直線に残作業が減少していく理想線を基準にする。以下のような y = A x + B の直線が理想線となる。

  • x : 経過日数
  • y : 残作業量
  • A : 過去の実績から割り出した1日あたりの期待進捗(ベロシティ)
  • B : 見積もった総作業量

y = 0 となるポイントが作業の完了予定日となる。完了予定日ありきでAを逆算してしまうのは良くない。Aを実績ベースのベロシティにすることで理想線が信頼できるものになる。ベロシティが安定しているほど信頼度が上がる。

理想線からズレた(遅れた)らどうしたらいいの?

なぜ遅れが出ているのかをチームで確認する。何か想定外のことが起こっているのかもしれない。小さな遅れでも早期発見できれば対策として取れる選択肢は増える。

一方で毎日の進捗に一喜一憂するのも良くないと思う。 理想線とするベロシティは平均値なので、日々の進捗は良い日もあれば悪い日もあるはず。過敏に反応してると疲れてしまう。

ここでもベロシティがどれだけ安定しているかが肝になる。ベロシティが安定していて信頼できるものであれば、最終的には理想線に収束するだろうとして、どっしり構えることができる。スクラムのようにタイムボックスを重視してベロシティを安定させるプロセスは、実に理にかなっている。

理想線が引けたら、あとは進捗を測るだけで良いの?

最初に見積もった総作業量が完璧に正しいのであればそれで良いが、見積もりが正しくないことが判明したときに、突然進捗NGになる。

最初の見積もりが完璧に正しい訳がない。そのため、作業の進捗を正しく測るためには、残作業の見積もりを見直して精度を高くしていくことが必要になる。スクラムのように小さいサイクルで見積もり精度を高くしていく開発プロセスは、実に理にかなっている。

総作業量が増えたらどうするの?

ベロシティは変えないので、完了予定日が後ろにずれることになる。理想線を引き直しても傾きは変わらないので、チャートの見た目の変化が見えにくい。バーンアップチャートにすれば、総作業量が増えたことによるスケジュール影響が見えるようになるので良いかも。

スケジュールバッファは無いの?

バッファは考慮すべき。ベロシティにバッファ係数を掛けて、進捗度を小さくした「バッファ込み理想線」も引くのが良さそう。「理想線」と「バッファ込み理想線」の間に実績が収まっていればOKとする。

重要そうなポイントまとめ

バーンダウンチャート(もしくはバーンアップチャート)による作業進捗管理をより効果的に行うには以下2点を意識することが大事。

  • ベロシティを安定させて信頼できるものにすること
  • 総作業量の見積もりを見直して、その精度を高くすること

スクラムなどのように、小さなサイクルで計画とふりかえりを繰り返すアジャイルな手法は、ベロシティを安定させ、漸次的に見積もりが見直されるので、正しい進捗管理(予測可能性の最適化)ができるということになる。

総作業量の変化も可視化できるので、実はバーンアップチャートの方が良いかも

Chromebookのキーボードショートカットをmacのそれに合わせたい。※途中

Chromebookのキーボードショートカットをmacのそれに合わせたい。

最も利用時間が長いのは会社支給のmacで、平日は1日中このmacを使っている。 そのため、ショートカットなどキーボードに関する手癖はmacに最適化されている。

自宅で私用するためのノートPCとしてはChromebookを持っており、これは休日に使うことが多い。 当然macとはショートカットが異なるので、Chromebookを使う際に手癖がいちいち引っかかり、けっこうストレスになっている。

自宅用にもmacbookを買うのが正解なんだと思うが、Chromebookもそれなりに気に入ってるので、いろいろカスタマイズして抗いたい。

結論 (途中経過)

  • macCmdキーを使う操作は、Chromebookでは同じ位置にあるAltを使うようにする
  • Chromebookの設定でCtlキー、Altキー、Escキー、Backspaceキー、検索キーのリマップ(というか入れ替え)が可能だが、使ってない
  • ブラウザ操作は拡張機能 Shortkeys である程度対応できる
  • テキストエリアでのEmacsキーバインドにも対応したい
    • 拡張のIMEを入れると良いっぽいが日本語入力にも対応したいので調査が必要

OS基本操作

  • ウィンドウ切り替え
    • ChromebookではAlt+Tabなので、macの操作感と同じ。OK。

ブラウザ操作

Chromebookでは基本的にCtlキーを使うことになるが、macCmdキーを使う操作についてはAltキーを使うように変更していく。 変更は拡張機能Shortkeys を利用する。

  • 新規タブ
    • Alt+t に変更
  • タブを閉じる
    • Alt+w に変更
  • リロード
    • Alt+r に変更
  • 新規ウィンドウ
    • Alt+w に変更

Ctl+Click で別タブで開く操作を Alt+Click にしたかったけど、ShortkeysではClickを扱うことができなかった。

ブラウザ上でのテキスト編集

macだとEmacsキーバインドが使えて、それが手に染み付いてしまっている。これが一番たちの悪い手癖になっている。 下にカーソル移動しようとして Ctl+n を連打すると新規ウィンドウがいっぱい開かれてしまう。。。

Emacsキーバインドに対応した拡張のIMEがあるが、日本語入力に対応したものはない。 更に、IMEGoogle日本語入力を使いたいので、IMEではないやり方を調査中。

【開発組織のマネジメント】リードエンジニアが管理ばかりする問題

多人数&複数チームと開発組織の規模が大きくなると管理コストも大きくなるが、そのコストをリードエンジニアが担ってしまうのはもったいないという問題意識がある。 この問題をアジャイルなアプローチで解決しようとしている。

求められる「管理する人」

4つのサブチームで業務を分担する開発チームで、サブチームには5〜8人ほどが在籍するという編成で開発をしている。 この規模になると「旗振り役」とか「調整役」とか「まとめ役」とか、そういう役割を担う人が必要になってくる。 具体的には、サブチーム間での作業分担の整理とか、サブチーム内のタスクをWBSに整理するとか、定期的に進捗を確認して報告するとか。 こういう業務をここでは「管理業務」と呼ぶことにする。

リードエンジニアが管理ばかりする問題

管理業務はチームの中心となるリードエンジニアが担うことが多い。 周囲からの信頼もあるし、本人の責任感もあるので、このような役回りとなっていく。 そして、複数チーム&総勢30人規模という条件が重なると、だんだんリードエンジニアの仕事は管理業務が中心になっていく。 ここにいくつかの問題がある。

  • リードエンジニア本人が期待するキャリアプランとのギャップ
    • まだまだ技術面の積み上げをしていきたいが、管理業務が中心となり、モチベーションを維持できない
    • 自分の場合は「マネジメントも面白いな」と思ってキャリアパスを変えていったけど、これを皆に求めるのは間違っている
  • 技術面での貢献度の低下
    • リードエンジニアが管理業務中心になるので、成果物の質に影響が出る
    • ジュニアなエンジニアの育成にも影響が出る
  • 管理する人、管理される人の二極化
    • 役回りが「リードエンジニア」から「管理する人」という見られ方になっていく
    • 一方で「管理される人」という待ちの姿勢、消極的な姿勢が目立つようになってくる
    • みんな窮屈になり、本来の能力を発揮できずもったいない

管理業務はみんなで分担すればいいじゃん

管理業務はチーム全体で成果を出すためには必要になるものだが、リードエンジニアがそこに専念する必要はない。 やり方は他にもある。 チームのための管理業務なので、チーム全員で担いたい。 チームがチームをセルフマネジメントするというイメージで。

アジャイルなプラクティスは、チームのセルフマネジメントを促進できるように思う。 スクラムではチームが主体となってスプリントバックログやスプリントゴールを決定しコミットメントを持つ。 ガントチャートをやめてカンバンでタスクを管理すると、タスクのオーナーは個人からチームに見え方が変わる。

セルフマネジメントするチームを作りたい。

【開発組織のマネジメント】減点方式の評価をしていて組織は持続可能なのか

プロダクトが成長し、それに合わせて開発組織が拡大したり複雑になると、今まで当たり前にできていたことができなくなってくる。それでもプロダクトへの貢献や組織としてのアウトプットはこれまでと同じ水準を求められる。このときに、頑張って達成した成果が「できて当たり前」と評価されてしまうのはけっこう辛い。

この状態で開発組織は良い方向に進んでいくのか?この閉塞感をどう解決したら良いんだろうか?と悩んでいるが、ひとつ気付きがあった。

当たり前のことが当たり前にできない

僕たちが開発保守しているのは、サービスインから10年近くになるBtoB SaaSのプロダクトで、ありがたいことに現在は多くのユーザーを抱え、会社の主力事業になるまでに成長している。現在は市場も成熟しているが、そのぶん競合製品との機能優劣もはっきりしてくる状況なので、機能開発もまだ活発に続けている。

BtoBという側面もあり、プロダクトの品質はユーザーからの評価に大きく影響する。しかし近年は、以前には見られなかったような品質の問題によりユーザーの信頼を失うという事例が多くなってきた。開発組織の評価としても成果物の品質において「当たり前のことが当たり前にできなくなっている」と見られてしまっている。

「できて当たり前」から始まる減点方式での評価

今までは発生しなかった問題なのだから、やるべきことをやっていれば問題は発生しないはずだ。など「できて当たり前」という考えから始まると、やるべきことをやらなかったことを罰するような減点方式での評価が始まる。

不具合が発生しないように、議論を尽くして、何重にもレビューし、プロセスやチェックリストを遵守し、手続きを通してリリースする。ここまではやって当たり前。ひとたび不具合が見つかると、もう赤点の評価。自分たちは当たり前のこともできないんだという気持ちになってしまう。これでモチベーションを維持していくのは、なかなか難しい。

それは本当に「できて当たり前」なのか

できて当たり前だったものは、今では当たり前にやるには難しいものに変わってしまっていることを認識するべきだ。そして、そこには前提条件だったり自分たちを含めた環境だったりの変化があるはずだ。

僕たちの場合は、組織の拡大の中でコミュニケーションが複雑になったり、外部のプロダクトやサービスとの連携部分が増えてきたりといった変化があり、以前の当たり前がとても難しいものに変わってきたんだと思う。

求められることは「できて当たり前なんだからちゃんとやれ」ではなく、「状況や環境の変化に適応し続けろ」ってことだ。

「当たり前にはできない」から再スタートし加点方式で評価する

かつて当たり前にできていたことは、今では挑戦しがいのある難しい課題に変わっている。この理解の下に立つと、より本質的な問題に真正面から向き合えるようになるし、減点方式の評価も意味がないことに気付くことができた。問題を解決するためのアクションは加点方式で評価することができる。

減点方式の評価では組織は維持できない。解決すべき問題を正しく理解して、その達成を一つ一つ喜びながら開発に取り組んでいきたい。

DynalistのInboxに登録するAlfredワークフローを作った

最近タスク管理をDynalistに移したので、DynalistのInboxにサッとタスクを登録できる手段を整えている。mac利用時には、Alfredからサッと登録したい。

DynalistのWeb APIを利用してタスク登録するワークフローを作成した。

Dynalist API v1 Documentation

これをAlfredのワークフローから実行する。

APIのシークレットトークンはAlfredのWorkflow Variablesとして設定する。 Rubyスクリプトからは環境変数としてアクセスできる。

こんな感じのスクリプトAPIを実行する。

require 'net/http'
require 'json'

uri = URI.parse("https://dynalist.io/api/v1/inbox/add")
params = {
  token: ENV["secret"],
  content: ARGV[0]
}
headers = { "Content-Type" => "application/json" }

http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true

response = http.post(uri.path, params.to_json, headers)
result = response.code == "200" ? JSON.parse(response.body)["_code"] : response.code

print result

Alfredのワークフローでは、スクリプトの標準出力は次のノードへのインプットとして渡されるので、APIの実行結果を渡している。


ワークフローは公開しているので、良かったら使ってみてください。

github.com

ワークフロー変数の「secret」に自分のDynalist APIのシークレットトークンを設定すると動きます。

Microsoft TeamsでIriun WebcamやEpocCamが認識されない

iPhoneなどスマートフォンのカメラをWebカメラとして使うためのアプリ Iriun WebcamEpocCamMicrosoft Teamsで認識されない場合の解決方法。

いろいろ調べたけどなかなか有効な解決策に辿り着けず。しかし、Teamsのバージョン番号を含めて検索したら解決した。以下のページを参考にすれば良い。

情報を検索するときにIriun WebcamやEpocCamを指す総称が難しかった。英語だと "Virtual Camera" になるようで、日本語だと「仮想カメラ」「バーチャルカメラ」というキーワードでいろいろ出てきた。今回の場合は "External Camera" でも同じ情報に辿り着けそうだ。

解決手順

Microsoft Teams v1.3.00.28778

Teamsを終了する。

Terminalを開く。

Xcodeをインストールする。

$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

既に入っていた。

以下を実行する。

$ sudo codesign --remove-signature "/Applications/Microsoft Teams.app"
$ sudo codesign --remove-signature "/Applications/Microsoft Teams.app/Contents/Frameworks/Microsoft Teams Helper.app"
$ sudo codesign --remove-signature "/Applications/Microsoft Teams.app/Contents/Frameworks/Microsoft Teams Helper (GPU).app"
$ sudo codesign --remove-signature "/Applications/Microsoft Teams.app/Contents/Frameworks/Microsoft Teams Helper (Plugin).app"
$ sudo codesign --remove-signature "/Applications/Microsoft Teams.app/Contents/Frameworks/Microsoft Teams Helper (Renderer).app"

Teamsを起動する。

キーチェーンの情報にアクセスするための許可を求められるので、パスワードを入れて「常に許可」する。

CUPSを経由してChromebookからCanon PIXUS MP620プリンターを使う

Chrome OSではGoogle Cloud Printか、プリントサーバーを使っての印刷しかできない。 手元のCanon MP620はGoogle Cloud Printには対応してできないので、プリントサーバーを立てて使えるようにする。

CUPSでプリントサーバーを立てる

ubuntuでの作業。

Canonプリンター向けのCUPSバックエンドをインストール。

$ sudo apt-get install cups-backend-bjnp

こちらを参考に、CUPSの設定を変更し、ポート631を開けた。

CUPSのWebコンソールにアクセスする。

http://サーバーのIP:631

Webコンソールからプリンタを追加することができる。

  1. "管理"タブ
  2. "プリンターの追加"
  3. "その他のネットワークプリンター"から「Canon network printer」を選択し"続ける"
  4. "接続"欄に bjnp://プリンタのIP:8611 と入力し"続ける"
  5. "名前"MP620 とする。ここは任意。
  6. "このプリンターを共有する"をチェックして"続ける"
  7. "メーカー"は「Canon」を選んで"続ける"
  8. "モデル"は「Canon PIXUS MP620 - CUPS+Gutenprint v5.3.3 (カラー)」を選んで"プリンターの追加"

これでubuntuサーバーからの印刷ができるようになる。 CUPSのWebコンソールからテスト印刷ができる。

※プリンタの登録時に、プリンタが自動検出される場合もある

手元の環境では、ファイアウォール (ufw) をOFFにしたら自動検出された。 自動検出されたものを選ぶと、いろいろ入力の手間が省ける

Chromebookからプリントサーバーを利用する

Chromebookの設定画面から"プリンタの追加"を行う。

  • 名前
    • 任意
  • アドレス
    • プリントサーバーのIP:631
  • プロトコル
  • キュー
    • printers/MP620

これでChromebookからプリンタが利用できるようになる。

※プリントサーバーの認証に失敗する場合がある

CUPSからのプリンタ登録時に「このプリンターを共有する」をOFFにしていると、以下のエラーが出る。

Returning IPP client-error-not-authorized for Create-Job (ipp://192.168.xx.xx:631/printers/MP620) from 192.168.xx.xx.

参考文献