退職しました（旧職でやったことまとめその２）
上記記事の続きです。 前職でやったことの備忘録的な色合い強いです。
チケット駆動開発
Tracを社内に先輩が導入してくれたのですが、最初はどう使ったものかよくわかりません。
Excelでのプロジェクト管理とタスク管理を徐々にTracへ移しながら世の中の利用方法を調べながら試行錯誤しながらチケット駆動開発をチーム内で行いました。
一番、この試行錯誤で役に立ったのが新人教育の各自のタスク管理等をチケット駆動でやる試みです。
新人研修はやることが決まっているので、チケット化しやすくチケット駆動に慣れていない人間がチケット駆動の勘所を学ぶのに適していると結果としてわかりました。
レビュー文化
アジャイルの書籍を読み漁った結果、職能横断的なチームを作りたいと思ったのがきっかけです。
なぜ、職能横断的なチームを作る上でレビュー文化が必要と考えるに至ったかというと、それ以前はWBSを元に各自の担当を決めると「自分の担当はこれ、あとは知らん」という部分が多かれ少なかれ各担当者に出てしまいます。
ただ、（ソース、ドキュメントの）レビューをWBSあるいはチケットの担当者以外が行うことによってチームメンバーとして自分の担当箇所以外にも責任を持ちやすくなるのではないか？と考えたからです。
つまり、大きな目標として職能横断的なチームを作るというものを立て、その手段の一つとしてレビューを取り入れたのが始まりといえば始まりです。
そして、結果からいえば2-3年ほど時間はかかりましたが、そういった多少なりとも職能横断的な部分のあるチームに我々は育つことができました。
ただし、職能横断的なチームは人の入れ替えに弱く、その面で生産性を高く保つことは非常に困難だったのですがレビュー文化がチームに根付いたことで当初考えていた職能横断的なチームを作るという目的以外にも、「新しいチームメンバーへの文化の伝道」であったり「チームメンバーの向上心への寄与」であったり色々な面で非常に有意義な取り組みに育ったと後から考えれば思え、ある意味自分が旧職でやったことのなかで一番目に見えない形での組織への貢献だったのではないかなあと考えています。
サーバー監視導入
当時請負プロジェクトのリーダーとして、複数案件を抱えた状態だったのですが、システム管理者が社外常駐業務となってしまい、社内システムをメンテナンスする人間がいなくなってしまうことを防ぐため多少なりともLinuxを触ったことがあった自分がシステム管理者になりました。*1
その時、問題意識を感じたのが利用者が報告を上げるまでサーバーの異常に気づかないことでした。
利用者が障害報告を上げてきた時点ではたいてい業務が滞るため特急の対応が必要な状態になっています。
請負プロジェクトをやりつつ、特急のシステム障害対応をちょくちょく割り込みでなんてやってられないのでシステムの異常を早期発見、早期対処をする必要があると感じました。
社内システムにはコストをかけないというシステム管理者にとっては萎える思想で運用されていたので、廃棄マシンの中からまだ動くものを無理やり復活させてzabbixを立ち上げ勝手に監視体制を敷きました。
効果が分かってからは申請すれば新規サーバ購入の予算が通ったのでしょうが、暇もなかったのでそのまま運用を自分の退職まで続けましたが、サーバー監視としては非常に役立ちました。
ランチタイム勉強会
ランチタイム勉強会と称する内輪の勉強会を毎週社内の会議室で昼食をつまみつつ、様々なテーマで勉強会を開こうという企画を考え、実行に移しました。
これをやるにあたっては、誰の許可も取らず会議室の予約を取って社内掲示板に告知を勝手に出した訳ですが、誰も文句を言ってこなかったのでそのままのやり方で5年くらい断続的に続きました。*2
内容は、その時の流行りの技術についてであったり、プロジェクト管理やツールの使い方、ワークライフバランスについてや雑談などあまりとりとめもなくなんでもやった記憶があります。
というのもテーマを絞ってしまうと少ない人数でやっている会のため続かなくなってしまうので、続けることを優先した形で自由度を高く開催していました。
自分は言い出しっぺではありましたが、周りの人間の協力や理解があって続けられたものだと思います。
イテレーティブな開発
アジャイルプロセスに傾倒していた頃（5年前くらい）からウォーターフォールプロセスは自分たちのような数十人月程度の規模にはフィットしないと考えており、それならアジャイルプロセスはどうなのだろうか？というところが出発点です。
実際、小規模な割に要件も要望もモヤッとしたものが多く、早くリリースして顧客の反応を見る形でないと立ちいかないという結論に手痛い失敗から学習しての結論でした。
実際にはウォーターフォールでないからといってプロジェクトの成功が約束された訳ではなく、利益を出すのに苦戦もしましたが、プロジェクトがコントロールを離れて『とにかく作れ」とは以後ならなくなりました。*3
デイリースタンドアップミーティング
6,7年まえから朝会というやつをデイリースタンドアップミーティングという形で実施してみました。
週次進捗会議というのは自分の新人時代からちょこちょこ経験していたのですが、やはり情報共有という点であまり効率が良くないと以前から思っていました。
そんなとき、朝会の話をネット上で目にして物は試しとやってみたのが始まりです。
やり方はシンプルかつ柔軟をモットーにしていて、朝でも昼でも夕方でもプロジェクトメンバーの一番都合が良い時間をチームで決めて「これまでにやったこと」「これからやること」「問題点」の三つを報告するというものでした。
この会議体の意義や捉え方は時期やチームによって様々でしたが概ね常に*4実施しており、時間的なスパンや生産性等を考慮すると非常に良い取り組みができたと思います。
これは、時差のある遠隔地のメンバーやリモートワークのメンバーがいなかったから出来たともいえるのでそういうチームではどうしたら良いかな？というのも考えてみると面白いですね。
議事録のExcel廃止MarkDown化
おそらく、日本の多くの企業では会議後の議事録をExcelまたはWordで記録しているのではないでしょうか？ とりあえず、この件はブログに以前書いています。
書き出してみるとぶっちゃけ普通じゃんという感じの事を色々やっていた訳ですが、組織内では誰よりも早く何かを始めるというやり方をやってちょっとは貢献できていたはず…。
そう思いたいです。
これからは一技術者としてコードで何かを残す方向にシフトするのが当面の目標ですね。
