(番外編)会社で仮眠する方法

アジャイルに働くためには休息も重要です

• そこで今日は休息の一形態、仮眠について書こうと思います。

会社で眠る動機について

• ついうっかり終電を逃してしまった
• 昨日飲み会で眠い
• 昼休みに仮眠して眠気を振り払いたい

そういう機会に恵まれる事はないでしょうか
いや私はできればごめんですが。

そういう時に寝る方法として、できればソファスペースを確保できれば最高です。
次善策として段ボールをしいて、更にその上に毛布など柔らかい布をしくとよいです
しかし、そういうのをいきなり職場でデプロイするのは難しいと思います。
あるいは難民キャンプ感が出て若手社員が「ここはブラック会社だったんや・・・」とか誤解されるかもしれません。

そこで、職場で調達しやすいもので仮眠しやすい環境を作る事が肝要です。
経験上、尻の位置より高い位置に脚を上げて、椅子をリクライニングさせると寝やすいです。椅子を向かい合わせに2つつけるのもよいでしょう。
あるいは脚置きを確保しておくとよいかもしれません。 そうするとさっくり寝られます。

現場のテストにかけるコスト

3行で

• 私はテストを書くべきだと思う
• テストのあるまともなプロジェクトを回したらテスト量は以外と少ない
• テスト書かないとかありえないよ

昔こんなコピペ流行ってましたねえ

うちはテスト書かないよ、スピード重視だから
TDDってあれでしょ？単体テストを大量に書くやつ

私、あれの元ネタ知らないんですけど、あのコピペってどこ発祥なんです？

話は全然変わるんだけど

大学時代に助教の方からこう言われました

「(コンスタンチンとヨードンが提唱した)構造化設計において、結合度と凝集度という概念がある。 
　これは知ってるよね。 
　通常はこの２つを最高レベルに保つことはできない。限界があるからだ。
　しかし例外的にこの２つを最高に保つ方法がある。なんだと思う？」
「わかりません」
「全部メイン関数に書く」
「それって保守性はどうなるんです」
「最悪だろうね。結局こういうのはトレードオフだから」

トレードオフ

よくCOBOLerあがりのおっさんと若人が「コードの見渡しが悪くなるからできる限りクラスは大きく作れ」vs「保守性考えてクラスやメソッドは細かくしろ」論争していたのを、SIer時代に見かけました

前者がGODクラスを作りたがっているのに対し後者は責任分割や保守性の観点からクラスやメソッドを適切に切りたがっています。
ここで注目したいのは後者も「適切に分割せよ」といっているだけで「とにかく細かくしろ」とは言っていないです

DDD的的な概念も思考停止して適用すると3行以下のメソッド1~2個だけしかもたないクラスが乱立するよな、絶対レビューではねられるよな、って思ってました。

原理的には別メソッドや別クラスにすべきだろうが
それをやるとコストがかかる割に「やらんでもわかるだろ」という部分なので「やりすぎ」になる  

というシーンはコードを書く上でよく発生します
このあたりはトレードオフだと思ってます

テストもトレードオフですよ？

テストも基本トレードオフだと思ってます。

テストを書くべき場所

バグがあった時にUXを大きく損なう、金銭に関わる、データ不整合を引き起こすなど重要な部分には必ず必要です。 しかし、ある値に定数をかけて返すなどのメソッドには必要でしょうか？ 不要だと私は思います。 単純なメソッド、一見してわかる箇所、あるいは影響があるユーザーは運営の人間だけの場所など重要度低いと判断されテストが書かなくても良いと思います。

テストのコスト

テストは書くのに初期のコストがかかります。
プロダクトコードが変更されればテストコードを変更するコストもかかります。
複雑なテストコードや入り組んだテストにはバグが潜みやすくなります
さらに、前提から変更されるような変更が入る場合テストの大半は壊れていないか、不要にならないかの判定のあと、かなりの部分が捨てられる恐れがあります。
これらのコストは判断に大きな影響を与えるべきだと思います

ノーテストorALL

「GODクラス志向の実装or責任分割を厳密に守った実装」のように「ノーテストorテスト書きまくり」のような極端な二択を持ち出される方がおります。
ダブルディバイディングといって営業や詐欺師が持ち出す恣意的に片方の選択肢に誘導する話術だそうですね。

実際には書くべきところにはテストを書く、書くにしても正常系onlyか、異常ケースのメイン部分を全部潰すか、画面確認できない部分だけ書くか、そういった「どこまで書く？」の判断はリスクやコストと利益のトレードオフと合わせて判断されるべきだと思います。

テストを書くと採算があいづらい場所

障害が起きても不利益が運営の人間にしかかからない場所
設計の変更が起きやすい場所
画面から確認しやすい場所
テスティングフレームワークの限界から、コードでは確認しづらく、逆に人目で容易に確認できる場所

テストは保険

20代独身で月に5万円くらい保険に注ぎ込まれている方はおりますか？
あまりいないと思います。
給与が低くてなにかをもっていないからです
保険料につぎ込むよりもお金を別の場所につぎこんだほうが有益だからです。

同様にテストにはコストがかかるので、そのリソースを他につぎ込んだほうが有益です。

しかし、より高齢で持ち家があって妻子のいる方ならありえる選択肢です。
持てるものが多く、収入が多く、なにかを失った時のリスクが大きいからです。

プロダクトも同じで「立ち上げ時期」や「稼ぎ」「既に得ているもの」によって依存すると思います。
スタートアップならほぼノーテストでもかまわないでしょう。
でもヒットプロダクトを抱えた会社の新規事業なら、本体事業への悪影響を考えて最初からテストをかいたほうがいいかもしれません。

じゃあどれくらい書けばいい？

正直「コンテクスト次第」「チーム次第」と言わざるを得ません。
ただそれじゃあ無責任だと思います。

githubなどの伸びているプロダクトはプロダクトコードとテストコードの比率は1:1だそうです。
だいたい感覚値と合う感じです。

結論

テストは用法用量を守ってお書きください。

人間はどれだけの時間集中できるのか

このエントリは アジャイルCasual Advent Calendar 2014 - Qiita の6日目です

休日なので集中と休息の話をします
休息重要

私は学部時代遠隔学習(e-ラーニングみたいなもの)を研究テーマにしていて、その過程で人間の集中力について調べた事があります。

もうすでに記憶はおぼろ、研究メモはとっくにゴミ捨て場行きなんですがうろ覚えで書きます

人間の集中力のピークは高校時代で、だいたい最大90分程度維持されます。
予備校の講義が90分なのはここに由来します
また、腕のよい予備校講師や大学教員は90分続けて持たない事を理解しているため、40分程度で雑談を挟み聴講者の集中力の回復を待ちます。

20歳を超えると、人間の集中力持続時間は落ち続け、30代ならだいたい60分は保たないと思ってください。

集中力は作業の種類と質の相関関係もあります。
不慣れな作業や気乗りしない作業は集中が頻繁に切れます。

一度切れた集中は再度回復させるまでに20分かかります。

集中力を高く維持するコツは、集中する時間と休憩する時間のメリハリをつけることです。
高校生なら50分集中し、10分休む高校の講義形式がよいですし、
社会人なら集中力の維持時間が落ちているので、25分集中し、5分休むポモドーロテクニック方式が良いと思います

また修羅場モードの場合人間の脳はアフターバーナーに相当する機能を使います。
最大で2時間程度、最高レベルの集中を維持できます。
ただし、これを使うと脳が疲弊しその後60分程度頭痛とともに思考が働かなくなり注意力散漫になります
脳が"焼き付いた"状態になります

ペアプログラミングはペアがうまく機能すればこの状態を人工的に引き起こせます。
ただし、集中力が最大で2時間しか続かないため、頻繁に作業を交代しても2時間程度で作業を停止し大休止を入れる必要があります。
また、休憩時間はこの大休止の場合は60分程度必要です。
あるいは低負荷なメール作業をしても良いと思います。
この休憩を入れない場合、再度深い集中状態に入れなくなります。
(そのためペアプログラミングの効果もありません)

以上、記憶のあいまいな与太話でした。適当に聞き流してください。

KPIアンチパターン

KPIとは救われなきゃだめなんだ

KPIは一回やるだけでは意味がありません。

定期的に複数回おこない、「Problemにあがっていた問題は解決したか？」「Tryにあったことは実施されたか？」「Keepにあった試みは実施され続けているか？」をチェックする必要があります

その目的はチームの開発を改善するためです。
問題を可視化し、全員で共有し、全員で改善策を打つためにKPIは行われます
その目的が達成されなければ

KPIアンチパターン

Problemにふせんを一枚貼ればその問題が解決するほど社会は甘くありません。
実際には「あーあるねー」で終わっていつまでもふせんは残り続けます。
あるいは「あーあるねー」という反応すら得られず「誰かが何か言っているが俺には関係ない」になるかもしれません。

同じ調子でTryに貼られた試みは実施されません
Keepにあった試みは気づいたら消えています。

あるいは、いちいち捨てるか考えるのが面倒くさくなって、ふせんは一回ごとに捨てる方式にして、前回のふせんがどうなったかなんて気にしないようにしてませんか？

ふせんが消えるのは、あるいはふせんが貼られなくなるのは、事態が解決されたからではなく、提起者が諦めたときです。 そんなKPIになってませんか？

時は80年代、仕様は変化することがわかった

このエントリは アジャイルCasual Advent Calendar 2014 の 4 日目のエントリです。
前回はwkubotaさんのレビューに関するエントリでした。

• 1日目が空いているのでとりあえず埋める
• 2日目にsuenamiさんがめっちゃいいこと書いてくれる
• あれに匹敵するものを書かねば！ということでKPIに関する超大作を作る
• まとまらないうちに3日目にwkubotaさんが書いてくれる
• まだまとまらないから別のネタ書こう <= イマココ

アジャイルソフトウェア要求の序章に書いてある事まとめ

• この前Amazonで買ってちまちま読み進めているけど、序章で気になった部分まとめてみる
• アジャイルとあまり関係ないけど、アジャイル前史みたいなものという理解でひとつ。

「仕様が変化する」という事実が人類に周知された過程

• 天動説と地動説のように、今まで前提とされていたことがひっくり返される事がある
  このケースにおいては、「仕様は最初の段階で全て出てくる、以降は固定である」という通説が「仕様は常に変化する」という事実に置き換えられた過程について書く

鉄の三角形

通称荒ぶる四天王(The Furious Four)として知られるQCDS(品質、コスト、納期、機能)のうち、「コスト、納期、機能」を示す言葉。
荒ぶる四天王は、言葉からするとまるで4つが同格のように思われるが、鉄の三角形では前後関係のあるものとされている。
鉄の三角形は「機能が定義できれば」「コストと納期は見積もれる」とする言葉である。
逆に言うと、要求される機能が変化すれば、コストと納期の見積もりは変化する。
顧客が契約締結から仕様を変更した場合、当初に約束された納期と見積の前提が崩れるので、納期遅れやコスト超過は必然である。
また発注サイドの「仕様は変更するが、納期と見積もりは死守」という要求に対し開発サイドは荒ぶる四天王の中で唯一自由になる品質を常に生け贄に捧げ続けることが、近年の炎上プロジェクトや使いづらいプロダクトの発生理由である、としている

相次ぐ炎上とウォーターフォールの改良

Royceが示したウォーターフォールモデルの通りに進めても炎上は不可避であるということは明らかになりつつあった。
参考資料：ウォーターフォールモデルの図
※注意： Royce当人はウォーターフォールモデルという言葉は使っていない。また、80年の論文の中で、自身が提起したウォーターフォールモデルは大規模プロジェクトには不向きであると述べている

当時のアプローチ

当時のアプローチとしては、 原因は仕様が巨大すぎることであり、
巨大すぎる仕様は頻繁な変更と、鉄の三角形に由来する納期とコストのぶれをもたらすことが問題なのだから、
仕様(Feature)を細かく分割する事でぶれを制御可能な範囲に収めようとした。

変化する仕様

現実には仕様は「発見」によって変化する、という考えが80年代以降の主流になっている。
そこでIncremental Development(反復型開発)という開発手法において、小さく区切る事で機能のぶれをおさえよう、そうすればコストと納期のぶれを小さい幅におさえられる、というアプローチがとられた。
ただしこれはウォーターフォール型を分割し、小型化しよう、というアプローチのように私には思われる。

「仕様は全てのフェーズで湧いてくる」ことが認められた

90年代、天下のIBMのRational事業部が推進するRational Unified Processにおいて、仕様は最初の調査段階で特に多く沸き出すものの、その沸き出しの波はあるが、終盤でも発生し得るものであると認められた。
また実装も初期の仕様を踏み固める段階からプロトタイピングや検証などにおいて発生し得るものであり、テストや品質担保作業は全フェーズにおいて行われるものであるとされた。

なにがいいたい？

私が経験したウォーターフォールモデルは必ず炎上する。
これは必然であり、統計によっても実証されており、理論化されている。
私が新人研修で習った大量のドキュメントは炎上を抑止する、大規模プロジェクトは大量のドキュメントと厳密な工程管理によってこそ成功させられる、というのは誤りであった。

それではみなさんご一緒に

インセプションデッキを作る上での危険信号

この記事はアジャイルカジュアル Advent Calendarの1日目です。

インセプションデッキを作るときに、「このプロジェクトをこのまま進めたらヤバい」という危険信号がある。

それが出ている状態で進めると、だいたい炎上することになる。
炎上とは最後に燎原の火のごとく燃え広がるが、その火種は初期の段階から存在する事が多い。
もし火種を見つけたら、消してほしい。それが無理なら止めるか、せめて上司にエスカレーションした方がいい。
火種は恥ずかしがり屋なので、開発のカオスに隠れていないと自分の力を強める事は出来ないからだ。

今回はその実例を書く

パターン1.エレベーターピッチを作る が すごいゆるふわ

エレベーターピッチというかこのプロダクトを一言で言うと？でもいいと思う
例えば、飲食店を作ろう！というテーマで
良い例としては「最高の洋酒とそれに合うツマミを出すBAR」みたいな感じ。
聞いただけで頭の中にイメージが湧いてくる。
たぶん暖色の照明があって、主張しすぎないBGMと木製の机の上に、ヒゲのマスターが進めるメニューがあって、ナッツと一緒に頼むといい感じのウイスキーが並んでいるのだ。
トリスのソーダ割を頼むと蹴り出されるかも知れない。
響12年のシングルがたぶん980円くらいだろう。

では逆に悪い例は？「うまい食事をお手頃な値段で出す店」
限界まで抽象化を推し進めたような感じの言葉出てくるとヤバい。
飲食店だからうまい食事が出るのは当然であり、まずい食事を出す飲食店を作りたいやつはいない。
お手頃な値段って？牛丼いっぱい380円？それともワンコイン？ディナーだから3000円？それをはっきりさせないままってのはヤバい。

でもマネージャー側の思惑は、自分でもよく分からないからチームで手探りで進んでいって、その過程でいい感じのところに着地するのを期待しているケースが多い。
そしてたいてい着地しない。そして燃える。

パターン2.パッケージデザインがカオス

例えば男性向け映画を作ろうと言う企画で、パッケージデザインが「文字だけ」「ゴジラっぽいのがいる」「ヤクザ映画っぽい」「ポケモン」という素案の間をうろうろするという事態が発生する。
これは実態としてはリードする人間が複数いて、彼らはグランドデザインをゆるくしておいて、なんとか自分のやりたいことをねじ込もうとしたり、自分のやりたい方向にねじ曲げようとしている状態が多い。
始める前に方向性が統一されないまま中途半端に具体化しようとしている状態で発生する現象だったりする。
こうなると力関係や興味の濃淡の変化で方針転換が多数発生するし、終盤でダメだしと称する事実上の「俺のやりたい方向への強制方針転換」が発生する。
これは方向性の統一されないまま開発を進めてしまって、その過程でモーグルのように複数の方針の間を行き来する現象が発生する事が約束された状態なので、必ず燃える。

社内読書会を開いて思った事

前提

• 対象： Amazon.co.jp： リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice): Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典: 本
• 参加人数: 4人
• 開催頻度: 毎週
• 進捗: 2 ~ 3 章(30ページくらい) / 回
• 黙読した後、テーマから外れない程度にディスカッションした

書評

• 本の言いたい事は分かる。
• 言語やコンテクストによって通じないことがある
  その辺りは分かっている人間に喋らせると補完できる
  LL言語使いとネイティブアプリ屋の間でもコンテクストの違いによる混乱はあった。

結果

• 途中中断
• 2人参加しないと二人だけでの開催となるためその週は abort とした
• 結果、6週間開催されない期間が存在したため、その時点で勉強会を中止とした。

ここはよかった

• 60min以内なので、業務中に抜け出して参戦ができた。さらにバッチサイズを小型化し30minにすれば、昼食中に行うことも出来たと思う。

まあそうなるわな

• 業務の多忙度を考えると欠席者は必ず出る
• 定時 + 2h にすれば参加できるだろうが、定時であがった人間は何して時間をつぶせと言うのか。
  それも待っていた人間のモチベーションの低下につながる。

こうすれば中止にならなかった？

• 2人でも強行すべきだった。
• 欠席者には部(100ページくらい)単位での総集編でフォローすればよかった
• 最初に動機付けをするなどいて出席率を上げて、催行可能な最低人数を確保するべきだった