週末コーディングから毎日コーディングへ。
今まで「コーディングはまとまった時間が必要。週末にやるしかない」と信じて疑わなかったのですが、最近になって心変わりしました。
きっかけはこのスライド（と元記事のJohn Resig - Write Code Every Day）。
OSS についてあれこれ from Takuto Wada
www.slideshare.net
毎日コーディングの記録
上記画像はプライベートで立てているGitLabのアクティビティです。まだ2ヶ月弱、しかも3日ほどサボっていますが、これまでと比べると雲泥の差です。
大きな変化： コンテキストスイッチ、バックグラウンド処理
実践してみて衝撃的だったのは、とりわけこの2つでした。
コンテキストスイッチ
今まで信じていたこと：
週末まとめてやったほうが集中できる。コンテキストスイッチも少ない。
毎日コーディングして感じたこと：
毎日やることで忘れずにいられる。実はコンテキストスイッチが少ない。
バックグラウンド処理
今まで信じていたこと：
コーディングは集中しないと出来ない。
毎日コーディングして感じたこと：
通勤時に「今日はどうしようかな？」と考えるようになった。
予め考えておくことで、スムーズにコーディングに入ることが出来た。
もっと大きな変化： ソフトウェア、リリース！
趣味で作りたいと思っていたソフトウェアが何年も完成しないままでしたが、たった2ヶ月弱で完成に漕ぎ着けました。
GitLabのアクティビティに色がつき、ソフトウェアが出来上がっていく。「やりたい」と思っていたことが具現化していく様子を見て、楽しいと感じないわけがありません。
今後も続けていきます。
SIerで3つの現場にWikiを導入した話。
SlackをSIerに導入した話 が羨ましくて、同僚や上司に「こんな話があって―」と宣伝しまくっている今日この頃です。
これまでに3つの現場でWikiを導入しましたが、それぞれ使われ方に違いがあって面白かったのでまとめてみます。
1: 暗黙知が多いプロジェクト。
Wiki導入前
- テスト用サーバのアドレスはもちろん、各工程の成果物さえも暗黙知。
- 「知っている人が隠し持っている（聞けば出てくる）」ということが多かった。
Wiki導入後
- サーバのアドレス情報やシステムの用語集などが徐々に記述されていった。
- 「ここに載ってる」と言えた。
- コメント欄を活用して、システムトラブル時の状況がつぶやかれるようになった。
- 朝出社して「昨晩トラブってたんだ…」と何となく把握できるようになった。
多少は効果があった。
2: 数百人規模なプロジェクト。
Wiki導入前
- 決定事項が「メール」か「2017mmdd_打ち合わせ」フォルダのどちらかに埋まっていて、聞いた記憶はあっても資料に辿り着かない。
- 手順書が不完全で、例えば開発のためにチェックアウトすべきプロジェクトが分からない。
Wiki導入後
- 誰も書いてくれなかった。ので、自らコンテンツをモリモリ作成した。
- コメント欄だけは活発で、顔も知らない人との交流の場になった。
- 担当していない部分の情報をちょくちょく知ることができた。
- プロジェクトが炎上しだすと荒れ出した。
3: 開発プロセスの改善がきちんと行われているプロジェクト。
Wiki導入前
- 資料はほとんど揃っていて、困ることが少なかった。
- 開発サイクルごとに、手順やツールはきちんとメンテナンスされていた。
Wiki導入後
- Wikiはほとんど使われなかった。
- 最近になってコメント欄がちょっとした息抜きの場みたいになった。
振り返ってみて、感じたこと
Wikiは「補完」的な位置付けなのかなと感じました。私自身もそういった使い方をしました。
プロジェクトで用意されている資料だけでは足りないから、Wikiで補完する。ひょっとすると、Wikiが活発なのはあまり良くない兆候で、寂れているほうが良いのかも？ とすら思ってしまいました。
余談
各現場ともWikiは勝手に導入しました。Demo or Die（SI現場でいろいろ作った話） でも書きましたが、実際に動かして「ほら」と見せたほうが早い、という考えからでした。
If it’s a good idea, go ahead and do it. It’s much easier to apologize than it is to get permission.
いいアイディアなら、さっさとやってしまえ。許可を得るよりも謝るほうがずっと簡単だから。
COBOL開発者 Grace Hopper (グレース・ホッパー)
幸い、怒られることもなく現在も動き続けています。
問題を速やかにエスカレ（報告・相談）してもらうには
リーダ「問題があったらすぐにエスカレ（報告や相談）してください」
メンバ「はあ…」
（数日後）
リーダ「すぐエスカレしろって言ったよね！？ なんでしなかったの！？」
メンバ「…すみません…」
こういうやり取りをたまに見ますが、エスカレしたいと思わせる工夫が大事だよな、リーダががんばらなきゃいけないよな、と思っています。
こんなリーダには、エスカレしたくない
別チームを見ていて感じた印象での話です。
何もしてくれない
メンバ「すみません、作業量が多くて遅延しそうです」
リーダ「期限は期限だから。月曜までだし、週末もあるでしょ。なんとかして」
メンバ「…はい（何もしてくれないんじゃ、エスカレしても意味ないな）」
言い出しっぺの法則
メンバ「別の設計書にバグを見つけたんですが」
リーダ「一緒に直しといて。時間ないけど、直さないと動かないから。直して」
メンバ「…はい（気づかないフリをしておけばよかった）」
仕事と言えどお互い人間ですから、「この人となら気持ちよく仕事ができる」とお互いが思えるような関係づくりが大事です。
こんなリーダには、エスカレしたい
メンバの立場での実体験です。
動いてくれる
メンバ「すみません、作業量が多くて遅延しそうです」
リーダ「そっか… どれくらい遅れそう？」
メンバ「予定よりもプラス1日は欲しいです」
リーダ「わかった。ただ、今後も遅れると危ないから、改善できるところがないか一緒に考えたい。あとで相談に乗って」
判断してくれる
メンバ「別の設計書にバグを見つけたんですが」
リーダ「そのバグは危ない。バグの修正お願いできる？」
メンバ「今の作業はどうしますか？」
リーダ「止めていいよ。タスクとスケジュールは見直しておく」
責任を持ってくれる
メンバ「すみません、修正ミスでした」
リーダ「いいよ。私がレビューしたんだから、私の責任だよ」
※新人だった私には衝撃的な言葉でした。と同時に、「リーダに迷惑を掛けないよう、自分自身で改善できることは積極的に改善しよう」とか「こんなリーダになろう」と思うきっかけになりました。
私もサブリーダの立場として、極力「エスカレしたい」で挙げた行動が出来るよう意識しています。
あとは、「作業が残ってても、『ベストを尽くした！』と思ったら帰っていいよ！」と言い続けています。
Raspberry Pi＠職場
ときには楽しい話題も。
今更ですがRaspberry Piを買って職場に置きました。
本体: Raspberry Pi 3 Model B
名刺サイズのちっちゃいコンピュータです。
詳しいスペックは Raspberry Pi - Wikipedia にありますが、USB 2.0x4ポートからGPIOまで遊べる要素が揃っています。
ACアダプタ付きで5,000円ちょっとです(KSY。Amazon.co.jpより安い)。
材料: HDMI 5インチモニタ(タッチパネル)
今回は、組み合わせに小さなモニタを買いました。Amazon.co.jpで4,800円。
電源はmicroUSBかGPIO。GPIO接続時のみタッチパネル使用可です。
モニタのほうが大きいですね。
OS: Raspbian Jessie with PIXEL (Debianベース)
「ただのLinuxマシンじゃねーか！」というのが正直な感想です。あっさり動きます。
日本語化＆日本語入力の環境も簡単。apt-get強い。
ソフトウェア: Cairo-Clock + 自作(Ruby+C#)
職場の時計が平置きで見えない（壁の釘が短すぎて掛けられない）、そして開発用PCはインターネット接続不可、ということで、時計と天気などを表示させるようにしました。
天気の表示部分は自作。ページのスクレイピングはRubyとNokogiriライブラリで、GUIアプリケーションはC#で（Monoランタイムで実行）。
あ、Flickrの猫写真をランダム表示させる機能もついています。癒し。
余談になりますが、.NET互換環境であるところのMono、最初の頃はWindows.Forms未サポートだったのですが、 Compatibility | Mono を見るとWindows.FormsどころかC# 6.0まで対応しているんですね。LinuxでもC#でゴリゴリ動かせる場面が増えるのは嬉しいです。
残業で「1日の生産性」は上がるのか？
ジェリー・ワインバーグは、プログラマにとってのデスマーチがどのようなものかを端的に説明している。
人は、期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りにできそうもないことがわかったときに、非難から身を守るために残業するのだ。 *1
この考え方は、その通りだと思う。
トム・デマルコ著「ゆとりの法則 (Slack)」を読んでなるほどと思ったのが、残業にまつわる話だった。
- ごく短期間だけ全力ダッシュで作業をすすめる「スプリント」と、そうでない「だらだらとした時間外労働」は別物。前者はその瞬間だけ作業量を増やせるが、後者はそうはいかない
- 知識労働の生産性は、時間ではなく日数による。つまり、1日の労働時間を増やしても1日あたりの生産性は上がらない
デスマーチに馴染んでしまっていると、この考え方はなかなか理解し難いのかもしれない。
「12時間かかる？ じゃあ4時間残業すれば1日で終わるね」とか、そういう感じだ。
こうなると、品質は下がっていき、あるいは未完成の部分が隠されて、プロジェクトは進んでいく。
時間外労働と生産性や品質との関係について、計測していたり、教育していたりするところは、あるだろうか？ 少なくとも私が担当したプロジェクトでは一切なかった。
エドワード・ヨードン著「デスマーチ」によれば、システム開発プロジェクトに携わる以上、政治的ないざこざは避けられないという。「残業」も、体を張った政治的なパフォーマンスなのだろうか。
一次請け・二次請けSIerに「技術力」が足りない気がする （品質分析編）
配属されたプロジェクトが炎上していく過程を見ていくと、弊社や親会社（広く言うと一次請け・二次請けSIer）に「技術力」が足りないように思います。
いくつかテーマがありそうですが、まずは品質分析を考えてみようと思います。
バグの根本原因に辿り着かない品質分析
正しい根本原因に辿り着いていない品質分析、とても多いです。
私が観測した範囲では、2パターンありました。
パターン1: 品質分析を下請けに丸投げ
この場合、立場の問題などもあって反省文じみた空気感が強くなります。
となると、もれなく「レビューでの見落としでした。今後レビューを強化します」といった、根本原因に辿り着いていない内容が出来上がってしまうのです。これでは改善は見込めません。
バグの根本原因は、開発プロセスにあることがほとんどです。つまり、開発プロセスがバグを生み出してしまっていて、だから開発プロセスを改善して防ぐ、という考え方が必要なのです。
まずは、お互いがこの認識をしっかり持たなくてはなりません。 …とは言っても、本来は開発プロセスを作った会社がきちんと品質分析をすべきだと思います。
パターン2: アーキテクチャや開発プロセスを知らずに品質分析
それでもバグ票の必須入力欄は埋まる。最低だ。
残念なことに、 ”開発プロセスを作った会社” つまり我々や親会社が品質分析しようとすると、このパターンに陥ることが多いです。なぜか？ 管理ばかりしていて、アーキテクチャや開発プロセスなんて知らない人ばかりだからです。
「作れなくてもよいが、勘所は知らないとダメ」
これが実践できている人は、ほとんどいません。管理ばかりしている場合ではありません。
形骸化する品質分析
「品質報告会（偉い人を説得させる会）があるから」とか「バグ票に必要だから」とか、形だけを義務的にこなして、品質分析が形骸化してしまっているように感じます。
形式的に品質分析をこなしている状態を放置するのではなく、品質分析・品質管理の体系的な知識・技術を持って「どんな品質分析をすべきか」「どこまでなら出来るか」を考える機会がないと、品質分析はお荷物のままなんだろうな… と思います。
デスマーチ気味の現場で倒れないために実践していたこと
4年目くらいまでのみなさん向け。
想定
- サブリーダや作業担当者
- 残業時間は月単位で100時間以下、年単位だと700時間くらい
1. 自己暗示
自分が出来ることはすべてやった
悪いのは無茶振りするリーダだ
倒れたり死んだりしても会社は守ってくれない
「他のメンバが頑張っているのに…」などと罪悪感・無力感が湧いてきても、
とにかく「出来ることはやった」と思い込む。
2. 自分ルール「22時退社」
「ここは譲らない」という線を引き、それを守る。
自分の場合は
「ご飯食べて風呂入って1時間ぼーっとして*1、5時間寝る」
という生活リズムを守るため、いつも22時には退社するようにしていた。
仕事が終わっていなくても、他のメンバが終電や徹夜でも、
そのまま居続けて生産性は上がるか？ 上がらないなら帰ったほうが良い。
3. 早朝出社
- 午前中のほうが集中出来る
- 人が少ないほうが集中出来る
というタイプにオススメ。
始業時間までに早くも達成感が得られるので、ネガティブ感情が和らぐ。
サブリーダにとっては、作業が中断されない、というのも大きなメリット。
4. 例外が起きたらプラスマイナスゼロにする
緊急会議が24時に終わった、というふうに例外が起きると、
生活リズム（自分ルール）が崩れ、限界だと思っていたラインを超えてしまう。
その時に「今日だけは仕方ない」と思わず、
数日中にプラスマイナスゼロにすること。絶対に。
自分の場合、午後出社をキメることが多かったかな。
5. 平日に小さな楽しみを作る
休日に遊べる気力など、滅多に湧いてこない！
例えば通勤時にコミックやネットラジオや動画などでなんとかする。
以上、よく考えたら大した話じゃなかった。
結局、「自分にとってココが限度」と思うラインを超えないのが大事。
「ちょっとくらい」と思うと、それが常態化してしまうので、そこは許さないように。
これまでの経験では、このスタイルで責任を問われることはまずありません。
*1:何故かは分からないけれど、1時間ほどPCに向かって無駄な時間を過ごさないと寝れなかった
