Slide 1
Slide 1 text
プログラマーの正道を歩む
きっかけをつかもう
SIMNET 田中 理
Slide 2
Slide 2 text
スピーカー自己紹介
● 田中 理（たなか るく）（本名です）
● ３１歳 一児の父です。
● 株式会社シムネットでエンジニアやってます。
● システム開発、インフラ、ネットワーク等、
色々やってきました。
● 趣味はDTM、作曲、ラーメン
Slide 3
Slide 3 text
注意事項
この物語はフィクションです。
登場する人物・団体・名称等は架空であり、
実在のものとは関係ありません。
Slide 4
Slide 4 text
注意事項 2
プリンシプル・オブ・プログラミングの
7章を参考に作成していますが、
書籍とは一部適用や考え方が異なります。
ですので、このスライドで使用した項目も
書籍をぜひ読んでみてください。
Slide 5
Slide 5 text
しくじり開発
俺みたいになるな!!
Slide 6
Slide 6 text
先生の紹介
● ルクくん
● 25歳 SI系会社のプログラマー歴４年
● システム開発、インフラ、ネットワーク等、
なんでも真面目に取り組む
● 新しい技術なども積極的に取り入れ、
会社の仲間に頼りにされている
● 趣味はDTM、作曲、ラーメン
Slide 7
Slide 7 text
プロジェクトリーダーに抜擢
Slide 8
Slide 8 text
そして、彼のプロジェクトは......
Slide 9
Slide 9 text
● リリース日から遅れること3ヶ月
● 当初予定していた機能の3割が未実装
● リリースした機能はバグが多く、瑕疵対応に追われる
● 違約金や改修コストで大幅な赤字に
● 顧客の信用を失う
● 社内での立場を失う
●
家庭での立場を失う
Slide 10
Slide 10 text
なぜ、こうなってしまったのか！
Slide 11
Slide 11 text
ルクくんの失敗から学ぼう！
はじめてのリーダーで失敗しちゃった先生
Slide 12
Slide 12 text
プロジェクトの立ち上げ
Slide 13
Slide 13 text
新規プロジェクトの立ち上げ
● とある会社の業務改善アプリの開発プロジェクトが始まる
● 既に見積もりは終わっており、社内工数は18人月とされていた
● メンバーは自分を含めて3人、若手2人が割り当てられていた
● 期間は半年間
● WBS を顧客の要望が全て期間内に収まる様に作成
Slide 14
Slide 14 text
この時点で、既にしくじっていた
Slide 15
Slide 15 text
新規プロジェクトの立ち上げ
● とある会社の業務改善アプリの開発プロジェクトが始まる
● 既に見積もりは終わっており、社内工数は18人月とされていた
● メンバーは自分を含めて3人、若手2人が割り当てられていた
● 期間は半年間
● WBS を顧客の要望を全て期間内に収まる様に作成
Slide 16
Slide 16 text
既に見積もりは終わっており、
社内工数は18人月とされていた
ひとつめのしくじり
Slide 17
Slide 17 text
WBSを顧客の要望が
全て期間内に収まる様に作成
ふたつめのしくじり
Slide 18
Slide 18 text
作業名 4月 5月 6月 7月 8月 9月
作業１
作業２
作業３
ふたつめのしくじり
Slide 19
Slide 19 text
これらのミスが要因となり、
この後、徐々に追い詰められることに
Slide 20
Slide 20 text
プロジェクトの序盤
Slide 21
Slide 21 text
● 自分のスケジュールはやや遅れていた
○ プロジェクト管理業務
○ 技術調査
○ メンバーの教育
● 一方、他メンバーに投げたタスクは、やや前倒していた
● このため、概ねスケジュールは守られている ように見えていた
プロジェクト序盤の推移
Slide 22
Slide 22 text
実は、メンバーのスケジュールの
前倒しには予想外のカラクリがあった
Slide 23
Slide 23 text
パレートの法則
Slide 24
Slide 24 text
パレート法則 (80:20の法則)
全体の数値の大部分 (8割) は、全体を構成するうちの
一部(2割)の要素が生み出しているという理論
● 売上の8割は、2割の顧客が生み出している
● 障害の8割は、2割のコードに集中している
といった法則。
今回の場合はメンバーが、全体としては2割程度の
技術的難易度の高い箇所や、他システムとの連携箇所を
先送りにしており、8割の実装しやすいところのみ進めて、
「8割方完了した」と報告していた。
Slide 25
Slide 25 text
実質、総コストの半分以下のものを
8割完了と誤認していた
Slide 26
Slide 26 text
機能追加と増員
Slide 27
Slide 27 text
機能追加と増員
● 顧客から、上司と営業に機能追加の打診があり、それを受諾
営業はそれを社内工数 6人月と算出
● その際、リリース日の変更は不可とのことで、
メンバーを増員して対応することとなった
Slide 28
Slide 28 text
この安易な増員こそが
最大のしくじりポイントとなる
Slide 29
Slide 29 text
ブルックスの法則
Slide 30
Slide 30 text
ブルックスの法則
安易な要員追加は火に油という意味
● 1人×10ヵ月 = 10人月
● 10人×1ヵ月 = 10人月
どちらも10人月だが、結果は全く異なる
このことを指摘し、人月による管理は
全くの無意味(神話)であると説いた
名書“人月の神話”の著者
フレデリック・ブルックスの名前が由来
銀の弾丸などない！
Slide 31
Slide 31 text
増員の結果
● コミュニケーションコストや教育コスト、管理コストの増大
● それらにより、自身のタスクは完全に停止
○ 代替できる技術者はおらず、コア機能の開発が止まる
● 単純に、数人月分の作業が不足するため、
さらなるスケジュール圧迫が発生
● 残業の常態化と品質の低下がより顕著に
Slide 32
Slide 32 text
開発中盤の状況
Slide 33
Slide 33 text
開発中盤の状況
● 一人当たりの教育やレビューに割ける時間が減少し、
コードの品質が低下
● アーキテクチャやコーディング標準を無視したコードが増える
● しかし、それ以上に動作しないコードが増えたため、
動作を優先して品質管理は二の次に
● そして、品質の悪いコードは加速度的に増えていった
Slide 34
Slide 34 text
割れ窓の法則
Slide 35
Slide 35 text
割れ窓の法則
「建物の窓が壊れているのを放置すると
誰も注意を払っていないという象徴になり
やがて他の窓もまもなく全て壊される」
悪い環境を放置すると更に環境が悪化すると
いう理論。
荒れている状態＞軽犯罪が増える＞モラルが
低下して犯罪が増える＞凶悪犯罪を含めた犯
罪が増えるというもの。
コードでも同じことが起こる。
Slide 36
Slide 36 text
● 品質の低いコードが存在する事を認識していたが、
時間が無いので動作を優先して放置を続けた結果、
さらにアーキテクチャを壊すようなコードが増えていった。
● しばらくすると、コード以外の他の作業の
品質やモラルも低下した。
Slide 37
Slide 37 text
モラル低下の例
● レビューに対する意識の低下
● ドキュメントの作成・更新の未実施
● 勤怠状況の悪化
● バグなどの犯人探しを端とした、仕事や課題のなすりつけ合い
● 独断専行が増える。報連相が機能しない。
Slide 38
Slide 38 text
これらの問題が表面化するにつれ、
再発防止策として、規則や手順が増加
Slide 39
Slide 39 text
結果、更に作業に余裕がなくなり、
さらなるモラル低下と規則・手順追加の連鎖へ発展
Slide 40
Slide 40 text
しかし、それでも開発を止めるわけにはいかなかった
Slide 41
Slide 41 text
開発の末期
Slide 42
Slide 42 text
スケジュールに多少の遅れはあるが、
それでもリリースへはこぎつける見通しだった
Slide 43
Slide 43 text
しかし
Slide 44
Slide 44 text
8割で止まっていたタスクを回収し始めると
状況が一変する
Slide 45
Slide 45 text
とあるタスクの回収
● サブシステムとの連携(REST API)を行う箇所が未実装だった
● 連携用のライブラリがこの環境では使用できないことが判明
● 別ライブラリを探して実装するが、
今度は連携パラメータが設計と異なっていた
● パラメータを修正するも、サブシステム側の戻り値がなかった
● 原因調査を指示するが、サブシステム内のコード品質が悪く、
開発者自身でも修正が難航......
Slide 46
Slide 46 text
ヤクの毛刈り
Slide 47
Slide 47 text
ヤクの毛刈り
Slide 48
Slide 48 text
パレートの法則: 二割の残タスク
✕
ブルックスの法則: 一人あたりのコストの増大
✕
割れ窓の法則: 品質の悪さ
Slide 49
Slide 49 text
バグを 回収しても、 回収しても、 回収しても、
回収しても、 回収しても、 回収しても、
回収しても、 回収しても、 回収しても、
回収しても、 回収しても、 回収しても、
回収しても、 回収しても、 回収しても、
回収しても、 回収しても、 回収しても、
回収しても、 回収しても、 回収しても、
回収しても、
回収しても、
回収しても、
回収しても、
回収しても、
Slide 50
Slide 50 text
永遠に終わらない
Slide 51
Slide 51 text
そして
Slide 52
Slide 52 text
プロジェクトの顛末
● コードは8割完成しているが、全体としては一つも
正しく動作しないので、分割リリースさえ行えない
● 沼の底を漁るような開発がその後さらに何ヶ月も続く
● リリース後も瑕疵対応に追われ、
それだけでは売上にならないので、
その後も、二足のわらじを履くことに
Slide 53
Slide 53 text
その結果
● 違約金や改修コストで大幅な赤字に
● 最大限努力したが、顧客の信用を完全に失う
● いままで培ってきた、社内での立場を失う
● 残業続きの生活で家庭を失う
なにより、この状況から抜け出す目処が立たない。
Slide 54
Slide 54 text
ルクくんはどうすればよかったのか......？
Slide 55
Slide 55 text
教訓
Slide 56
Slide 56 text
パレートの法則
問題を発生させないために
完了しているかいないか、この二元で管理を行う。
問題が発生した場合の対策
難易度や専門性で更にタスクを分割する。
対策を講じるのが難しい場合の対応
どうしても進捗率を求められるなら、
0%=未着手, 20%=作業中, 100%=完了 といった割合で
管理する。
8割までは容易だが、のこりの2割は困難が伴う
Slide 57
Slide 57 text
パレートの法則
問題の簡単なところだけ抜き取ってはいけない。
一つのタスクに対して、やりきるという意識が重要だ。
Slide 58
Slide 58 text
割れ窓の法則
問題を発生させないために
コーディング標準やアーキテクチャを全員で共有する
問題が発生した場合の対策
リファクタリング（ボーイスカウトの規則）の推奨
対策を講じるのが難しい場合の対応
中核機能をコアメンバーのみで開発する。
Slide 59
Slide 59 text
割れ窓の法則
日頃から、ドキュメントやコードの品質を保つようにしよう。
ルールは全員で納得して共有することで、はじめて意味が生まれる
スタイルチェッカーなどのツールを補助的につかうのも良い。
実効性のない規則をなくすことも、重要だ。
Slide 60
Slide 60 text
ブルックスの法則
問題を発生させないために
単純なコスト算出に人月をつかったことが間違い
問題が発生した場合の対策
リスケジュールする
対策を講じるのが難しい場合の対応
できる人が最大限のパフォーマンスを発揮できるようにする
Slide 61
Slide 61 text
ブルックスの法則
作業量の管理に人月を用いるのはやめよう。
開発者自身が見積もりをすることで、精度を上げることができる。
短期的な人の追加は悪手である。
リスケジュールしたほうが、かえって早くなることのほうが多い。
Slide 62
Slide 62 text
ヤクの毛刈り
問題を発生させないために
一つ一つの問題を放置せず、着実に片付けていく
問題が発生した場合の対策
実装をダミー化するなどして、問題を切り分けて対処
問題箇所を一旦、実装対象から外す
対策を講じるのが難しい場合の対応
「銀の弾丸などない」
Slide 63
Slide 63 text
ヤクの毛刈り
問題が大きくなる前に、刈り取るようにしよう。
そのために、前述のような法則に気をつけて開発しよう。
問題が大きくなりすぎても、「銀の弾丸はない」のだから。
Slide 64
Slide 64 text
さいごに
Slide 65
Slide 65 text
先人の失敗(アンチパターン)を心しよう
覚えやすいように7・５調の苦を用意しました
● 見積もりに 安易に人月 用いるな
● 8割は 終わっていない まだ2割
● 良識を 育てて規則 へらしましょう
Slide 66
Slide 66 text
注意事項
この物語はフィクションです。
登場する人物・団体・名称等は架空であり、
実在のものとは関係ありません。
Slide 67
Slide 67 text
以上、ご清聴ありがとうございました