Day: February 8, 2021

1.7 ここにドラゴンがいる 1.8 未知を見積もる 1.9 素人業界 1.10 本章のまとめ 内容 ソフトウェア開発の未知について説明している。 エンジニアは経験から作業を見積もるが、これは結局の憶測を越えない。全部で9ヶ月のPJを8ヶ月目にふたを開けてみたら全体で6ヶ月の遅れがあるなんてこともある。 なぜこんなことになるかというと、単にわかっていないで憶測したから。 業界の冗談で、開発の3つの状態「終わった」「始めていない」「ほとんど終わった」とういのがある。 ドラゴンというのは、モンスターが多くて恐ろしいことや未知なことの例え。 タスクを見積もることができないのはやったことがないから。わからないことが多いから。 見積もりはちゃんとやろうとすると時間がかかる。再利用できるもの、ライブラリの利用などを始め、作ろうとすることに対してもろもろの経験を活かしながら。 しかし、一見似たようなことも進めてみると違っていて、当初の見積もりどおりにならないことがほとんど。 間違った前提で見積もりをすることもある。ウォーターフォールでコーディングに時間をかけずに設計書を最新に保つことに多くの時間を割くのが代表的。これが問題解決の手助けになると信じて作られているが、こういった設計書は実際は殆ど使われず、価値を発揮できないまま捨てられるので、無駄が多い。 ソフトウェア業界は安定して成功できる決まったやり方はまだない。 エンジニアによって多種多様なアプローチをする。その中でもうまくいくのは本当に自分たちの問題を直視し、過去のやり方にとらわれずに勇気をもって踏み出す人たちだけ。 まだまだ未熟な業界だからエンジニアもマネージャーも、ソフトウェアは変化できるという性質と、その必要性を共通認識としてもち、協力して勇気を持って進まなければいけない。 今の業界は全然未熟で、特にウォーターフォールは全然間違っていることが多い。 時代の変化についていくためのソフトウェアづくりのために、みんな目を覚まして真剣に変えていこう。 学び 経験上、「ほとんど終わった」は怪しい。 正確に見積もるのは難しい 自分たちの問題をどんなことでも直視し、他のやり方は参考にすれど、囚われずに考え実践する姿勢がまず大事。特に、コミュニケーションプロセス。多くのジャンルの人達が関連するから。 学びを活かすアイディア・行動 特になし

1.5 「プロセス」が「忙しい仕事」になるとき 1.6 ガチガチのマネジメント 内容 人は成果を出せないとやる気を失う。初めはやる気があったとしても。 IBMのプログラミングのコメントポリシーは何をやっているかをすべて書くことだったが、これは良くなかった。自明なコメントはコードが読みづらくなったり、シンプルすぎるメソッド名にコメントで注釈を入れて実際のふるまいとメソッド名にギャップがあったり、コメントへの反映し忘れでコメントが嘘になってしまったり。 このような良くないプロセスは忙しさを産み、やる気を無くさせる。 マネージャーは開発者が正しいことをしていると保証したい。 正しいこととは何か？答えられる人はほとんどいない。 ソフトウェア開発でやっていることは、考えること、モデル化、コーディングで、これらは創造的でそれぞれが違うことがほとんど。実質、定量的に図ることは難しい。 正しいことをしたいあまり、プロセスを追加することがあるが、追加すればするほど悪くなる傾向がある。創造性にプロセスは影響しないから、単純に作業が複雑になり創造性を阻害し忙しくなるだけ。 学び コメントはプログラムで表現できないことを書く。 結局の所どうやって計測する？という疑問が出た 学びを活かすアイディア・行動 現場のコーディング規約づくり