プログラマーの正道を歩むきっかけをつかもう

Transcript

1. プログラマーの正道を歩む きっかけをつかもう SIMNET 田中 理

2. スピーカー自己紹介 • 田中　理（たなか　るく）（本名です） • ３１歳　一児の父です。 • 株式会社シムネットでエンジニアやってます。 • システム開発、インフラ、ネットワーク等、 色々やってきました。

   • 趣味はDTM、作曲、ラーメン

3. 注意事項 この物語はフィクションです。 登場する人物・団体・名称等は架空であり、 実在のものとは関係ありません。

4. 注意事項 2 プリンシプル・オブ・プログラミングの 7章を参考に作成していますが、 書籍とは一部適用や考え方が異なります。 ですので、このスライドで使用した項目も 書籍をぜひ読んでみてください。

5. しくじり開発 俺みたいになるな!!

6. 先生の紹介 • ルクくん • 25歳 SI系会社のプログラマー歴４年 • システム開発、インフラ、ネットワーク等、 なんでも真面目に取り組む •

   新しい技術なども積極的に取り入れ、 会社の仲間に頼りにされている • 趣味はDTM、作曲、ラーメン

7. プロジェクトリーダーに抜擢

8. そして、彼のプロジェクトは......

9. • リリース日から遅れること3ヶ月 • 当初予定していた機能の3割が未実装 • リリースした機能はバグが多く、瑕疵対応に追われる • 違約金や改修コストで大幅な赤字に • 顧客の信用を失う

   • 社内での立場を失う • 家庭での立場を失う

10. なぜ、こうなってしまったのか！

11. ルクくんの失敗から学ぼう！ はじめてのリーダーで失敗しちゃった先生

12. プロジェクトの立ち上げ

13. 新規プロジェクトの立ち上げ • とある会社の業務改善アプリの開発プロジェクトが始まる • 既に見積もりは終わっており、社内工数は18人月とされていた • メンバーは自分を含めて3人、若手2人が割り当てられていた • 期間は半年間 •

    WBS を顧客の要望が全て期間内に収まる様に作成

14. この時点で、既にしくじっていた

15. 新規プロジェクトの立ち上げ • とある会社の業務改善アプリの開発プロジェクトが始まる • 既に見積もりは終わっており、社内工数は18人月とされていた • メンバーは自分を含めて3人、若手2人が割り当てられていた • 期間は半年間 •

    WBS を顧客の要望を全て期間内に収まる様に作成

16. 既に見積もりは終わっており、 社内工数は18人月とされていた ひとつめのしくじり

17. WBSを顧客の要望が 全て期間内に収まる様に作成 ふたつめのしくじり

18. 作業名 4月 5月 6月 7月 8月 9月 作業１ 作業２ 作業３

    ふたつめのしくじり

19. これらのミスが要因となり、 この後、徐々に追い詰められることに

20. プロジェクトの序盤

21. • 自分のスケジュールはやや遅れていた ◦ プロジェクト管理業務 ◦ 技術調査 ◦ メンバーの教育 • 一方、他メンバーに投げたタスクは、やや前倒していた

    • このため、概ねスケジュールは守られている ように見えていた プロジェクト序盤の推移

22. 実は、メンバーのスケジュールの 前倒しには予想外のカラクリがあった

23. パレートの法則

24. パレート法則 (80:20の法則) 全体の数値の大部分 (8割) は、全体を構成するうちの 一部(2割)の要素が生み出しているという理論 • 売上の8割は、2割の顧客が生み出している • 障害の8割は、2割のコードに集中している

    といった法則。 今回の場合はメンバーが、全体としては2割程度の 技術的難易度の高い箇所や、他システムとの連携箇所を 先送りにしており、8割の実装しやすいところのみ進めて、 「8割方完了した」と報告していた。

25. 実質、総コストの半分以下のものを 8割完了と誤認していた

26. 機能追加と増員

27. 機能追加と増員 • 顧客から、上司と営業に機能追加の打診があり、それを受諾 営業はそれを社内工数 6人月と算出 • その際、リリース日の変更は不可とのことで、 メンバーを増員して対応することとなった

28. この安易な増員こそが 最大のしくじりポイントとなる

29. ブルックスの法則

30. ブルックスの法則 安易な要員追加は火に油という意味 • 1人×10ヵ月 = 10人月 • 10人×1ヵ月 = 10人月

    どちらも10人月だが、結果は全く異なる このことを指摘し、人月による管理は 全くの無意味(神話)であると説いた 名書“人月の神話”の著者 フレデリック・ブルックスの名前が由来 銀の弾丸などない！

31. 増員の結果 • コミュニケーションコストや教育コスト、管理コストの増大 • それらにより、自身のタスクは完全に停止 ◦ 代替できる技術者はおらず、コア機能の開発が止まる • 単純に、数人月分の作業が不足するため、 さらなるスケジュール圧迫が発生

    • 残業の常態化と品質の低下がより顕著に

32. 開発中盤の状況

33. 開発中盤の状況 • 一人当たりの教育やレビューに割ける時間が減少し、 コードの品質が低下 • アーキテクチャやコーディング標準を無視したコードが増える • しかし、それ以上に動作しないコードが増えたため、 動作を優先して品質管理は二の次に •

    そして、品質の悪いコードは加速度的に増えていった

34. 割れ窓の法則

35. 割れ窓の法則 「建物の窓が壊れているのを放置すると 誰も注意を払っていないという象徴になり やがて他の窓もまもなく全て壊される」 悪い環境を放置すると更に環境が悪化すると いう理論。 荒れている状態＞軽犯罪が増える＞モラルが 低下して犯罪が増える＞凶悪犯罪を含めた犯 罪が増えるというもの。 コードでも同じことが起こる。

36. • 品質の低いコードが存在する事を認識していたが、 時間が無いので動作を優先して放置を続けた結果、 さらにアーキテクチャを壊すようなコードが増えていった。 • しばらくすると、コード以外の他の作業の 品質やモラルも低下した。

37. モラル低下の例 • レビューに対する意識の低下 • ドキュメントの作成・更新の未実施 • 勤怠状況の悪化 • バグなどの犯人探しを端とした、仕事や課題のなすりつけ合い •

    独断専行が増える。報連相が機能しない。

38. これらの問題が表面化するにつれ、 再発防止策として、規則や手順が増加

39. 結果、更に作業に余裕がなくなり、 さらなるモラル低下と規則・手順追加の連鎖へ発展

40. しかし、それでも開発を止めるわけにはいかなかった

41. 開発の末期

42. スケジュールに多少の遅れはあるが、 それでもリリースへはこぎつける見通しだった

43. しかし　

44. 8割で止まっていたタスクを回収し始めると 状況が一変する

45. とあるタスクの回収 • サブシステムとの連携(REST API)を行う箇所が未実装だった • 連携用のライブラリがこの環境では使用できないことが判明 • 別ライブラリを探して実装するが、 今度は連携パラメータが設計と異なっていた •

    パラメータを修正するも、サブシステム側の戻り値がなかった • 原因調査を指示するが、サブシステム内のコード品質が悪く、 開発者自身でも修正が難航......

46. ヤクの毛刈り

47. ヤクの毛刈り

48. パレートの法則: 二割の残タスク ✕ ブルックスの法則: 一人あたりのコストの増大 ✕ 割れ窓の法則: 品質の悪さ

49. バグを 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、

    回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、 回収しても、

50. 永遠に終わらない

51. そして

52. プロジェクトの顛末 • コードは8割完成しているが、全体としては一つも 正しく動作しないので、分割リリースさえ行えない • 沼の底を漁るような開発がその後さらに何ヶ月も続く • リリース後も瑕疵対応に追われ、 それだけでは売上にならないので、 その後も、二足のわらじを履くことに

53. その結果 • 違約金や改修コストで大幅な赤字に • 最大限努力したが、顧客の信用を完全に失う • いままで培ってきた、社内での立場を失う • 残業続きの生活で家庭を失う なにより、この状況から抜け出す目処が立たない。

54. ルクくんはどうすればよかったのか......？

55. 教訓

56. パレートの法則 問題を発生させないために 完了しているかいないか、この二元で管理を行う。 問題が発生した場合の対策 難易度や専門性で更にタスクを分割する。 対策を講じるのが難しい場合の対応 どうしても進捗率を求められるなら、 0%=未着手, 20%=作業中, 100%=完了

    といった割合で 管理する。 8割までは容易だが、のこりの2割は困難が伴う

57. パレートの法則 問題の簡単なところだけ抜き取ってはいけない。 一つのタスクに対して、やりきるという意識が重要だ。

58. 割れ窓の法則 問題を発生させないために コーディング標準やアーキテクチャを全員で共有する 問題が発生した場合の対策 リファクタリング（ボーイスカウトの規則）の推奨 対策を講じるのが難しい場合の対応 中核機能をコアメンバーのみで開発する。

59. 割れ窓の法則 日頃から、ドキュメントやコードの品質を保つようにしよう。 ルールは全員で納得して共有することで、はじめて意味が生まれる スタイルチェッカーなどのツールを補助的につかうのも良い。 実効性のない規則をなくすことも、重要だ。

60. ブルックスの法則 問題を発生させないために 単純なコスト算出に人月をつかったことが間違い 問題が発生した場合の対策 リスケジュールする 対策を講じるのが難しい場合の対応 できる人が最大限のパフォーマンスを発揮できるようにする

61. ブルックスの法則 作業量の管理に人月を用いるのはやめよう。 開発者自身が見積もりをすることで、精度を上げることができる。 短期的な人の追加は悪手である。 リスケジュールしたほうが、かえって早くなることのほうが多い。

62. ヤクの毛刈り 問題を発生させないために 一つ一つの問題を放置せず、着実に片付けていく 問題が発生した場合の対策 実装をダミー化するなどして、問題を切り分けて対処 問題箇所を一旦、実装対象から外す 対策を講じるのが難しい場合の対応 「銀の弾丸などない」

63. ヤクの毛刈り 問題が大きくなる前に、刈り取るようにしよう。 そのために、前述のような法則に気をつけて開発しよう。 問題が大きくなりすぎても、「銀の弾丸はない」のだから。

64. さいごに

65. 先人の失敗(アンチパターン)を心しよう 覚えやすいように7・５調の苦を用意しました • 見積もりに　安易に人月　用いるな • 8割は　終わっていない　まだ2割 • 良識を　育てて規則　へらしましょう

66. 注意事項 この物語はフィクションです。 登場する人物・団体・名称等は架空であり、 実在のものとは関係ありません。

67. 以上、ご清聴ありがとうございました