先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。
プログラマ間でのコラボレーションが一つの課題になった。 決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。
またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。
ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。
よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。
今回はこれをちょっとアレンジして実践してみることにした。
まずはこれでスタート。
実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。
今後であるが、以下の点をまだ行っていないので順次実行していきたい。
チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。
興味深いポイントについて:
今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。
先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。
ぐらさん言わく「見えない化」
開発中に発生する
などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。
後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。
やはり基本は顔合わせということを実感。
またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。
どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。
できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。
(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)
複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。
通常開発中のコード内でのこのようなインタフェース変更については
のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。
ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。
変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。
「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。
関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。
チームのトータルのスループットを最大にするようにコミュニケーションしよう。
短期決戦型プロジェクトが佳境状態。 かなりスピーディーさを要求される展開なので、応接室のホワイトボードを奪ってきて昨日からソフトウェアかんばんに仕立てあげた(さらにその前から、プロジェクトの情報用に占有していたりする)。
今まで何度か情報カードを使ってソフトウェアかんばんをしているけれど、今回は細粒度なタスクレベルでクリアしていく必要があるので、お手軽にポスト・イットにした。
強粘着のものを買ってきたのだが、あまりつきが良くない。 雑巾でホワイトボードを綺麗に拭いてから貼りはじめたんだけれど、まだ油分が残っていたのかなぁ。
そこそこの情報を書けるように 75mm x 100mm のポスト・イットにしたのだけれど、これだとちょっと大きすぎた。 小さなタスクを沢山貼るにはこれだとスペースが足りなくなる。
とりあえず半分に切ってペタペタ。
見える化すると、厳しさがより鮮明に見えてきた。 「もっと早めに……」というのは言いっこなしだ。
情報カードベースでソフトウェアかんばん(ストーリーカード + タスクカード)を作っている開発プロジェクトがあるのだが作ったっきりあまり活用されていないので、今回は試験的に WiKicker による Wiki 上でかんばんを作ることにした。
まだ荒削りだけれども、まずはとにかく以下のルールで始めてみる。
基本的には 1カード毎に WikiPage を作るようにする。 ページ名はストーリーカードを表す SC と 状態 (TODO / DOING / DONE) を含む名前にする。
タスク名も同様に作る。
カードの内容は XP で扱っている内容で。 新規作成が楽なようにテンプレートページを作っておき、これをコピーして作れるようにしておく。
TODO -> DOING -> DONE という状態変化にあわせて、WikiPage 名を変更してページを移動させる。
例: TC/TODO/名前をつけて保存メニューを追加 | V TC/DOING/名前をつけて保存メニューを追加 | V TC/DONE/名前をつけて保存メニューを追加
SC/TODO、SC/DOING、SC/DONE、TC/TODO、TC/DOING、TC/DONE ページを作りそれぞれに、子階層の一覧を表示させる (WiKicker の [[index:child]] を使用)。
タスクカードからは「SC/<ストーリー名>」という名前で、ストーリーカードへリンクさせる。
WiKicker では「SC/<ストーリー名>」というページない場合、「SC/*/<ストーリー名>」というページを探してリンクしてくれる。この機能のおかげで、状態にあわせてページ名を変更してもリンクはそのままで追従してくれる。
担当者が割り当てられて実行中のタスクカードには [[DOING:担当者名]] という文字列を記述しておく。
「DOING:担当者名」で検索することで、各担当者が何を実行中なのかリストアップすることができる。また DOING: を「DOING:担当者名」を検索する Wiki 自身への InterWiki として定義しておくことで、この記述自体を検索結果へのリンクとすることができる。
ソフトウェア開発の見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。
今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。
TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。
スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。
以下のようにスプレッドシートを作る。
列 | 内容 |
A | カード番号をつける。 |
ストーリーカードは S番号。タスクカードは S番号T番号とする。 | |
B | カード作成日を書く。 |
C | ストーリーカードの時にストーリー名と作成者名をかく。 |
D | タスクカードの時にタスク名と作者名をかく。 |
E | 期日をかく。 |
F | TODO の時に @ とかく。DOING に移行した時は @ を消す。 |
G | DOING の時に @ と開始日、担当者の名前を書く。DONE に移行した時は @ を消す。 |
H | DONE の時に @ と終了日、担当者の名前を書く。 |
I | 備考欄 |
TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。
※内容は個人的見解であり所属組織とは関係ありません。