読者です 読者をやめる 読者になる 読者になる

TAMALOG

記すことは生きること。知的欲求の最果てに。

ソフトウェア開発プロセスを学べる小説『デッドライン』を紹介します

会社で働くようになって、10ヶ月が経過しました。

関わったプロジェクト

会社では、以下のプロジェクトを担当し、遂行しました。 どのプロジェクトも、すでに存在するシステム上での構築だったため、既存のコードリーディングから行っています。

  • ある社内システムの構築(5名→2名)
  • 変更不可能だったデータから依存をなくして、変更可能にするプロジェクト(1名)
  • 登録を簡略化し、新規導線を強化するプロジェクト(1名)
  • サービスの連携基盤に特殊な変更を加えるプロジェクト(1名)

下の3つでの実作業者、一人で担当しています。別途、随時レビューは受けていました。

1人でプロジェクトを遂行する上での問題

変更を加えるそのシステムに精通していない1人の人間が、プロジェクトを担当すると当然のように問題が置きます。

  • システムへの理解不足・考慮漏れによるバグ・エラー
  • 規模感の過小評価によるスケジュール遅延

上記の1番目は十分周知したり、レビューを頻繁に受ければ、起こりにくくなる問題です。しかし、2番目はそのような工夫では根本的解決はできません。

個人の意識を変える必要があります。

『デッドライン』

デッドライン

私は、一時期スケジュール遅延が多く、マネージャーから「ある先輩から本を教えてもらいなさい」という指示を受けました。 その先輩から勧められた本は『デッドライン』という本です(参考書評: 名著!「デッドライン」: わたしが知らないスゴ本は、きっとあなたが読んでいる)。

この本は小説です。とあるソフトウェア管理者が大規模プロジェクト6つを掛け持ちします。途中、途中に無茶難題を押し付ける上長と戦ったり、どうしたらソフトウェア開発プロセスを短縮できるかと考えたりする物語です。ウォーターフォールのソフトウェア開発のプロジェクトについてよく書かれています。

小説自体がよくできているため、すらすらと読めてとてもおもしろかったです。2日間で読み切ってしまいました。

この本は、個人のスケジュール遅延を簡単に解消する物ではありません。しかし、スケジュール遅延がどのような要因で生じるのか、ソフトウェアを効率的開発するにはどうするのが良いのか、学ぶことができます。

疑問

『デッドライン』を読んで思ったのは、今のアジャイル開発とはどのように違うのだろうという点です。まだ結論はでていません。

私は先の本よりも、『アジャイルサムライ』という本を先に読んでいました。アジャイルという聞きなれない言葉に「従来のソフトウェア開発よりも画期的なんだろう」という雑然とした思いを抱いていました。しかし、『デッドライン』を読み、そうでもないのかもしれないと感じています。

アジャイルが何を解決して、何を解決していないか調べる必要がありそうです。