「なぜ、あなたの仕事は終わらないのか」を読んだ

Interfaceの最新号を買おうと立ち寄った本屋で見つけてついつい買ってしまいました。

satoshi.blogs.com

のブログで有名な中島聡さんの書籍です。

主な内容は、

「時間の使い方」
「仕事術」
「仕事が早い人の考え方・仕事の仕方」

のような内容について中島さんのこれまでの人生のエピソードを交えて語られていらっしゃいました。

中島さんはネットメディアなどのインタービューを受けられていて、そういった記事で語られている内容と重複する部分(もちろんブログのLife is beautifulの内容とも)もありましたが改めて書籍として読んでみると面白い内容でした。

面白かった点

最強の昼寝は18分

昼寝に最適な時間をさがしてみようという話。中島さんの場合は18分という時間がマジックナンバーとのこと。
そういえば私も高３の受験生の時に昼寝の最適時間を探していろいろ試行錯誤していました。
確か15分にしたときに目覚めばっちりで、睡眠後に英単語なんかを覚えると調子がよかった気がします。
15分が最適だったというのは単純に5分、10分、15分、20分と、5分刻みで調べた結果でしたが18分という1分刻みで最適値を求める探究心は、私も意識しないといけないと思いました。

ちなみに、昼寝の最適時間はその時の体の疲れ具合によっても変わるので、時間とその時の体調という２つのパラメータを考慮して決めないといけないなと最近感じます。

最初の2日で8割を終わらせる

仕事が遅くなる原因の一つは「締め切り直前まで余裕があると思ってしまうからだ」という話が登場します。

締め切りを守るためには最初に全力で取りかかって、後半は流すのがよいという仕事術が語られています。

これはその通りだなと思いました。

(受託開発で)ソフト開発の納期が遅れる理由

少し横道にそれますが、私のソフトウェア開発の具体的な経験でいうと、納期を守れないプロジェクトの場合「締め切り前までだらだら過ごす」という怠け心によってプロジェクトが遅れているということはあまりないように思いますが、(日本人は基本的に真面目ですし、もしくは真面目に仕事をしているふりをする人がほとんどなので)

ではどうして納期を守れないというと、

「納期を意識して仕様を決めない」

からというパターンが多いように思います。(受託開発の場合ですが、私の経験ではほぼ100%これがプロジェクトが遅れる理由でした)

仕様を決めるという作業は、お客様と顔を突き合わせた話し合いやメールやQAシートでのやり取りが主体になります。

正直、地味で面倒な作業です。(仕様案を考えたら具体的にそれが実現できるかの検証も必要になります)

エンジニアはプログラムを書く(実装)ことが自分の本分だと考えて、

「お客さんから返事がないから仕様が決められないんです・・・」

「まぁ、仕様は決まっていない部分はとりあえず置いといて作れる部分から作っちゃおうか」

「多分インターフェースはこうなるからこう作っちゃえ。変わったら最後に頑張って調整すればいいや」

みたいなのがよく目にする光景です。

そして納期直前でなんとか仕様が決まって、

「今頃になって仕様を決められても、間に合わないよ・・・」

「仕様が決まった部分の実装量が思っていたよりも多い。どうしよう・・・」

「しまった、思っていたのとインターフェースが全然違う。これだと影響範囲がでかい・・・」

みたいなことで徹夜→バグ爆発→納期を守れない→炎上という流れを辿るプロジェクトが多いです。

私の考えるソフトウェア開発のスタートダッシュ論

さて、このような場合中島さんがおっしゃる「最初の2日で8割を終わらせる」思考で考えると、プロジェクトの最初にしないといけないことは「仕様を決めること」です。受託開発の場合製品の外部仕様・機能仕様は開発する人間が勝手に決めきるわけにはいかないので仕様案を出してあげてそれを元にFIXさせていく必要があります。

私の場合お客様にお話しさせて頂く際に、プロジェクトの前半で

「どうも～。今日は仕様を確定させて頂きに来ました。」
「今日は仕様がすべて決まるまで帰りませんので(笑)必要であれば朝までお付き合い致します！」
「えっ！？電車ですか？いいですよ近くのマン喫に泊まりますので！」
「今日仕様が決まらなかった場合は、期間を考慮して納期を守るお約束はできません。」
「ちなみにうちでできることは全部やった上での結果ですので、責任はもちろん・・・」

みたいなお話をさせて頂きます。

こうして書くとなんか偉そうなやつだなと思われてしまうかもしれませんが、お客様の方でも目的が「製品の完成」であれば、しぶしぶかもしれませんが仕様の整合などには付き合ってくれますし、真剣に考えて下さります。

そもそも仕様というのは、「決めるもの」であって要するに「こうするんだ」という意思決定の集合が仕様です。

なのでコーディングやテストと違って、「決める」という作業は一瞬でできます。
※仕様書に落とすという作業には少々時間はかかりますが、要するに意思決定の内容を共有できればいいわけです。

では、一瞬でできる作業なのにどうしてずるずると決めれないかというと

「決めた結果の影響範囲が分からない」
という点につきると思います。極端な話

「仕様がこうなっているからこの商品は売れなかった」

のような責任問題まで発展する可能性を仕様の決定は秘めていたりします。

なので担当の方もあまり積極的に仕様を決めようとしない事が多いです。

じゃあどうやったら決めれるのかというと

「仮設を立てて一つ一つ議論する」

しかないんじゃなかなと思います。

「○○という制限を設けた場合こうなりそうですね」
「いやいや、ＸＸがあるからそれは大丈夫だよ」

みたいな議論を重ねることでその時点で最も正解に近いと思われる仕様案が浮かび上がってきます。
なので上記のようにお客様のところに押しかけて

「この部分は○○で実行したいと考えています」
「ちょっとまってくれ、○○だと時間がかかりそうだがらＸＸにして欲しい」

みたいな時間を作ることがとても重要なんじゃないかなと私は考えています。
(ちょっとおおげさかもしれませんが、一緒に議論することによって同じ釜の飯を食うじゃないですけど、一緒に製品を作っているという連帯感も生まれると思います)

お客様も忙しい場合も多いので協力頂けない場合もあるかもしれませんが、最終的に納期を守れた場合に、お客様自身が上司の方から評価されたりするので、結果的に信頼を得られることに繋がったりします※上記の話ができるのは、もちろん見積りの時点で仕様のFIXと納期の関係についてはお様に納得頂いた上でですが。

技術的課題のスタートダッシュ的解決方法

ちなみにソフトウェアの開発プロジェクトが遅れるもう一つの原因として「技術的な課題」があると思いますが、こちらも中島さんが言われるようにスタートダッシュで解決すれば大きな問題にならずに済みます。

具体的に言うと、

「今度うちで、○○の技術を使うプロジェクトを受注しそうだ」

みたいな引き合いの話が入ってきた時点で「〇〇の技術」を使ってサンプルプログラムを書いてしまいます。
あくまでサンプルプログラムでよくて、ソースの体裁やコーディング規約とかは一切無視して、「技術を使う」「技術のノウハウを獲得する」の2点にフォーカスを当てたコードを書きます。こういったプログラムを書くのは新人さん勉強がてら書いてもらうとOJTにもなって一石二鳥ですね。余裕があればそのコードを使ってコードレビューをしてあげるのもいいでしょうし。コードを書くだけでなくネットや書籍で情報を仕入れたりstack overflow等でバッドノウハウを知ったりする練習にもなりますね。

なんか「プロジェクトの進め方論」みたいな感じでながながと書いてしまいましたが、中島さんが本書籍で語られていらっしゃるように後半ではなく前半に頑張る(スタートダッシュ)というスタンスは非常に共感しました。

批判

実は、数年前に一時期私は中島さんのファンになって、中島さんが発行されているメルマガを購読していました。

www.mag2.com

各週で送られてくるメルマガは、エンジニアにとって面白くてためになる内容のメルマガだったのですが、内容にムラがあると感じることが多く２か月くらい購読して解約しました。

解約した理由は、たしか２～３週間くらい続けて内容の薄いメルマガが送られてきて、月額相当の値打ちは無いなと判断して解約したんだったと思います。

この「メルマガ事件」のお蔭で、私の「中島聡熱」は一気に覚めてしまったのですが、本書を読んでいて

「なぜあのメルマガの内容が薄かったのか」

が理解できることが書かれていました。

100人に１人もできない「あること」とは？

本書に「100人に１人もできない「あること」とは？」という一節があり文字通り100人に１人もできない「あること」を中島さんは大切だと考えているそうです。

それは、

「常に締め切りを守ること」

だそうです。

この一節を読んだ瞬間に、当時のあのメルマガの内容の薄さが納得できました。

私の想像ですが、かなり多忙な日々の中で週刊連載のメルマガを書かれていて、他の仕事と比べたときにメルマガの優先度が低かったんだと思います。

ですが、「常に締切を守る」をモットーにされている中島さんですから、メルマガが発行できない＝締め切りに遅れるというという事態よりは内容は少々薄くても発行することが重要だと判断されたんだろうなと本書を読んで思いました。(そうだとしたら中島さんらしい判断だなと思います)

メルマガというメディアは、なんとなく軽いメディアという印象があるためか、毎週発行を謳いながら発行しない人とかもいる(しかも有料で)ので、そういった人と比べると中島さんは正しいように思いますが、(お金のためにやっているのか単純にいろいろと語りたくて書いているのかは分かりませんが)有料コンテンツである以上対価に見合ったモノを提供するのは当然ではないかなと思います。

なので私はメルマガをさっさと解約してしまいました。

ちなみに中島さんも自覚をされていたのか、