yamashiro0110の日記

yamashiro0110の日記です。おもにIT技術のメモを綴っていきます(^o^)

「デスマーチ」を読んだ


この本を読んだ理由

デスマーチの最中なので、どうすればよいのか知りたかった。


デスマーチとは

初めから失敗することがわかっているプロジェクト

公正かつ客観的にプロジェクトのリスク分析をした場合、失敗する確率が50%を超えるプロジェクト


なぜデスマーチは発生するのか

  • 社内の政治

  • 無謀なスケジュール(通常12ヶ月掛かると見込まれるものが、6ヶ月に短縮される)

  • 予算(人員不足、人数は足りていても経験の無い人ばかり)

  • 過度の要求(提供する機能が多すぎる、要求される性能が高い)

  • その他いろいろ


デスマーチを乗り切るにはどうすればよいのか

  • トリアージ(要求の優先順位付け)

  • クリティカルチェーンと制約条件(よくわからず使いこなせないのにデスマーチプロジェクトでやろうとすると失敗の要因になる)

  • スカンクワーク(会社の偉い人たちや部外者に邪魔されないように会社から隔離された場所で作業を行う)

  • そこそこ使えるソフトウェア(完璧ではないがそこそこ安く、速く、機能が充実していて、安定して使えるソフトウェア)

  • 80:20の法則(ソフトウェア全体の内、使われる機能は20%であり、残りの80%はなくても困らない)


デスマーチプロジェクト(に限らず)の主な問題は、技術的な要因であることは少なく、人に起因するものであることが多い(ピープルウェア問題)。

ITプロジェクトを円滑に進めるためには、ピープルウェア指向アプローチで取り組む必要がある(プロジェクトの問題を解決してくれる銀の弾丸はない)。

交渉術の例が面白かった。

例) プロジェクトが9月1日ではなく、9月5日に完成するとしたら、9月2日に倒産を宣言するのですか?

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

「イシューから始めよ」を読んだ

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

知識労働における生産性を上げるためにはどうすれば良いかということについて書かれています。

生産性を上げるためには、今解決するべき問題(イシュー)は何かを見極めて、 そのイシューを解決することで可能になるとあります。

がむしゃらにタスクを消化した結果、疲弊してあまり成果が出てないとか感じている場合は、 なにかヒントが得られるんじゃないかと思います。

見積もりやスケジュール管理で参考になる記事10選を読んで


印象に残ったところ忘れない内にメモ。

工数見積もりやスケジュール管理で参考になる記事10選 | UX MILK


開発の見積もりとスケジュール管理 - クックパッド開発者ブログ

スケジュールと工数は一緒にしない。

工数3人日は、3日後に終わるわけではない(3日間全部、そのタスクに使えるわけじゃない)。

進捗率の図り方

  • 0%(未着手), 25%(着手), 50%(動く), 75%(レビュー中), 100%(完了)

不安とストレスから解放される見積りとスケジュール方法 - Qiita

不確実性コーン

  • プロジェクトが進むに連れて、工数見積もりのブレが少なくなっていく
  • プロジェクト初期で60 ~ 160%のブレがある
  • 詳細設計の段階で+10% ~ -5%くらい

スケジュールバッファ

  • 実際には6ヶ月後に完了する予定だけど、1ヶ月はバッファとして5ヶ月後に完了としておく

フィーチャバッファ

  • 作る機能を減らして工数を削る(必須の機能のみで完了とする)

なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;

理想時間と現実時間

  • ソフトウェア開発は、オーバヘッドがつきもの
    • 3日で終わるからといって、3日後に完了するスケジュール組むとやばい

見積もりの解決策として、ポイントでつけるというのがわからないので本を読む。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~


開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | 開発手法・プロジェクト管理 | POSTD

あいまいな要件

  • 実装に着手出来るほど仕様が固まってないために発生する手戻りによる遅れ
    • 開発を始める前に機能について検討すること
      • なぜ必要なのか、どんな機能なのか、どう使われるのか

要件の変更

  • タスクを開始するとすぐに変わる仕様
    • プロトタイピングで仕様を固めて手戻りを減らす
    • 仕様変更によりスケジュールが延びることを伝える

コンテキストスイッチ

  • マルチタスクはスピードが落ちる
  • 同時に2つ以上のことをやらない

だいぶ開発者目線だと思う

「クリティカルチェーン」を読んだ

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

プロジェクトマネジメント本。

大学の講師がプロジェクトマネジメントについて授業をしていくなかで、 なぜプロジェクトは遅れるのかについて結論を導き出していくストーリーになっている。


TOC(Theory of Constraint)

制約条件。

ボトルネックを改善することで全体のスループット(生産性)を向上させることができるというもの。 逆にボトルネックを改善しなければ、他を改善したところで全体のスループットは向上しない。

例えば製品Xを作るとして、そのためにステップAとステップBを行わなければならない。

ステップAは完了するのに1時間かかり、ステップBは2時間かかるとする。

ステップの順序がA > BとするときにXが完成するのは3時間掛かる。

ステップAが先に完了して、ステップBに渡せる状態で開始しても全体では2時間掛かるわけなので、 全体の時間を短くする(スループットを上げる)ためには、ステップB(ボトルネック)を改善しなければいけない。

ステップBがボトルネックでなくなったならば今度はステップAがボトルネックになるので ステップAを改善するというサイクルを繰り返していく。

TOCでプロジェクトのリードタイムを短くする。


クリティカルチェーン

プロジェクト開始時には非クリティカルパスだったパスが、 遅れて結果的にクリティカルパスよりも長くなってしまうことがあるためクリティカルパスになってしまう。

例えば、ステップの担当者が同じだけど開始時期が同じなのでどっちかを開始できない状況になり、 結果的にクリティカルパスよりも長くなってしまうとか(リソースのキャパシティを超えている状況)

クリティカルパスはステップの従属関係を見てリードタイムを決定しているため、 リソースの競合については考慮されてない。

クリティカルチェーンは、クリティカルパスにリソースの競合についての視点を加えたもの(?)。

プロジェクトの計画はクリティカルチェーンでやる。

「世界を動かすプロジェクトマネジメントの教科書」を読んだ

プロジェクトマネジメントに関する本。

プロジェクトの定義から進め方まで解説していて、ストーリー形式で話が進んでいくので読みやすい。

マネジメント系はストーリー形式多い気がするんだけど結果が見えにくい分、状況をイメージしやすいようにする意図があるのかな


チャレンジのOS

本書のなかでプロジェクトを成功させるために必要なチャレンジのOSという言葉を使っている。

OSというとコンピュータのOSを連想するけども、 プロジェクトマネジメントの観点でいうところ組織の習慣や体制のことを言い表している。

改善のためにツールを導入したところでOSがちゃんと機能してなければ意味がないというところかな


システムズアプローチ

チャンレンジのOSの1つ。

プロジェクトにとりかかる際に、 このプロジェクトはどういう作業(アクティビティ)で構成されているのか、 アクティビティの前後関係(クリティカルパス)はどうかを見ながら 計画(WBS)を作成していく。

ここでアクティビティに抜け漏れがあると、手戻りが発生してダメージ大きいのでしっかりやっておかないといけない

各アクティビティ毎に見積もり工数を載せてプロジェクト全体のスケジュールを出す方法なども紹介されている。


プロジェクトの実行フェーズだけでなく、 まずプロジェクトとは何かなぜやるのかといったところにも触れている。

プロジェクトマネジメントのスキルは、 経験を積むことで得られる属人的なものだと思っていたけど技術なんだなと感じた。

行き当たりばったりで作業をやってしまうことが多いので、 作業の洗い出しとクリティカルパスを意識しないといけないな。

WBSは、作るの面倒だからツールで運用して行けたら良い。

「なぜ、システム開発は必ずモメるのか?」を読んだ

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

システム開発プロジェクトにおいて、実際に起きた裁判を元に発生するトラブルの事例やそれに対する対応の例を挙げている本。

ストーリー風に書かれているため読みやすい。

受託開発における契約の問題などを取り上げているため、 自社で開発しているところには当てはまらない部分もある。

ベンダは専門家としてユーザー側に情報共有を積極的に進めなければ、 不備があった場合にそれに対して契約書に記載がない場合でもベンダの責任と認められることもある。 このあたり裁判所は、契約書だけを見ないで実態をみて判断しているんだなと感じた。

プロジェクトを成功させる上で必要なのは、 ユーザーとベンダが双方協力しあうことが不可欠だと言っていてやっぱりそうだよなとなった。

システム開発の目的は単に発注側の依頼を完了させるのではなく システムを使う人にとって価値を提供するという、 作ったその先にある目的を達成することが大切なのだと言っていて、 これまで開発していてあまり考えてなかったなと思い反省。

プロジェクト開始から終了までに管理上の注意するべきポイントが挙げられていて、 当たり前のことなのかもしれないけどマネジメント経験がないのでとても参考になった。

PlayFramework-2.4


Playframework 2.4にアップデートしたところ、activator newで作成したプロジェクトが、 IntelliJ IDEAにSBTプロジェクトとしてimportできなくなったので、その対応をめも。

エラーの内容を一部抜粋

java.lang.UnsupportedClassVersionError: com/typesafe/config/ConfigException : Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
...skipping...
        at xsbt.boot.Boot$.main(Boot.scala:20)
        at xsbt.boot.Boot.main(Boot.scala)
[error] java.lang.UnsupportedClassVersionError: com/typesafe/config/ConfigException : Unsupported major.minor version 52.0
[error] Use 'last' for the full log.

環境

Java

$ java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

Activator activator-launch-1.3.6.jar

IntelliJ IDEA 14.1.4

IntelliJ IDEA: SBT (plugin) 1.7.0

IntelliJ IDEA: Scala (plugin) 1.5.2


以下の手順だと、エラーが発生する。

Java, Scalaの両方ともダメ

activator new ${PROJECT_NAME} play-java

activator new ${PROJECT_NAME} play-scala


以下の手順だと、エラーが発生しない

Java

activator new ${PROJECT_NAME} play-java-2.3

2.3.10のJava Project。 2.4系だと、エラーでるので諦めた。

www.typesafe.com

Scala

activator new ${PROJECT_NAME} play-slick-quickstart

Slickという、ScalaのORMが入ってるやつ。

www.typesafe.com


上記のコマンドは、プロジェクトテンプレートを利用して新規で作成している。

プロジェクトのテンプレートは、↓のページで一覧が見れる。

www.typesafe.com

コマンドだと、↓

activator list-templates

Fetching the latest list of templates...

Featured Seed Templates:
  minimal-akka-java-seed
  minimal-akka-scala-seed
  minimal-java
  minimal-scala
  play-java
  play-scala

Featured Tutorial Templates:
  hello-akka
  hello-scala
  hello-slick-3.0
  reactive-maps
  reactive-stocks

Other Seed Templates:
  akka-http-adaptive-cluster-aws
  akka-scala-seed
  basic-project
  boilerplay
  ~ 省略 ~