「締め切りを守ること」の大切さ今までたくさんの日米のエンジニアと仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし,ものすごい生産性でプログラムを作ってくれる「馬力(ばりき)のあるエンジニア」もいた。そんな中でも,私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは,「⁠常に締め切りを守れるように仕事をすること」である。チームで仕事をする場合,どうしてもお互いが担当するタスク(=作業)の間に依存関係が生じる。そんなときに,どれか一つのタスクの完了の遅れが,ほかのタスクの完了に波及し,それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる,という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには,プロジェクトに関わる人全員が,自分に割り当てられたタスクは「必ず期日以内に仕上げる」という強い意志を持って仕事に取り組む必要がある。「そんなこと言ったって,ソフトウェアの開発過程において予想不可能な事態に陥ることはよくあることで,締め切りを絶対に守ることなんて無理」と思う人も多いだろうが,スケジュールの立て方・仕事の進め方の段階から締め切りを守ることの大切さをきちんと認識して働けば,「⁠常に締め切りを守り続けて」仕事をすることは十分に可能である。この文章を最後まで読んでいただければ私の言いたいことは理解していただけると思う。大半のエンジニアが,スケジューリング(開発工数の見積り)の段階から大きな勘違いをしてプロジェクトに取りかかっている。締め切りという言葉への典型的な誤った考え方は次のようなものだ。それでもどうしても締め切りに間に合わなかった場合は,その段階でスケジュールを変更してもらうしかないたとえばあるソフトウェアを作ることをこのような意識のエンジニアに依頼したとする。するとそのエンジニアは,今までの経験から「3ヵ月ぐらいでできると思います」と言う(漠然とした見積り⁠)⁠。多くの場合,その手のエンジニアはプロジェクトを甘く見て,最初の2ヵ月ぐらいはのんびりと過ごす。残り1ヵ月ぐらいになって「お尻に火がついた」状態になって頑張るのだが,あわてて作るためにスパゲッティコードになってしまう。残り2週間でそこそこ動き始めるが,まだまだ機能は不十分だし,バグもたくさんある。最後の1週間でバグの修正に取りかかるが,最後の最後になってアーキテクチャ上の欠陥が見つかる。後戻りはできないので,バグを回避するためのその場しのぎのコードを埋め込むが,そんなことをしているとますますコードが汚くなっていく。最後は徹夜もするが,寝不足でミスが続き,結局バグが取れずに締め切りの日になって「申しわけありません,できませんでした」と言ってくる。「⁠じゃあどのくらいで完成するの」と聞くと,「⁠あと2週間あれば大丈夫だと思います」と言う(根拠はない⁠)⁠。2週間ではアーキテクチャの変更もままならず,パッチにパッチを当てて,目も当てられないようなコードになっていく。結局2週間努力しても問題は解決せず,「⁠根本的な問題の解決のためにアーキテクチャの変更をするので,2ヵ月ください」と言う。しかたがないのでスケジュールの変更を認めると,時間に余裕があるので,最初の1ヵ月はのんびりと流してしまう。最後の1ヵ月でラストスパートをかけようとするが,再び同じような状況に陥り,最後は徹夜の連続。寝不足のためにコードが汚くなり,バグが多発。結局,新しく設定した締め切りも逃してしまう...。これでは「プロの仕事」とは言えない。その根底には「締め切り=努力目標」とう考えがあり,「⁠目標に向けて精一杯努力をすることが大切」という体育会的な姿勢がある。いけないのが,「⁠最初はのんびりしていても最後に頑張ればなんとかなる⁠」⁠,という「楽観的なラストパート思考」である。「ラストスパート」なもの作りの一番の欠点は,最後の最後まで,そのタスクの本当の難易度がわからないという点にある。どんなタスクでも,「⁠やってみないとわからない」部分はどうしてもある。個々のタスクに「本気で取り組む」タイミングを遅らせれば遅らせるほど,「⁠予想外に時間がかかってしまってほかの人に迷惑をかける」可能性が高くなる。「締め切りは絶対に守るもの」と考える大切なことは,スケジューリングの段階から「締め切りは絶対に守るもの」という前提で臨むことである。すると,スケジューリングの段階からずっと真剣にならざるを得なくなる。1「ほぼ確実にできるタスク」だけを抽出して,まずはそれのスケジューリングをする。万が一,半分の時間で「ほぼ完成」まで持っていけなかった場合,これを「危機的な状況」と認識してスケジュールの見直しを交渉するまず1だが,「⁠締め切りは絶対に守るもの」ということを常に念頭に置いておけば,「⁠3ヵ月でリリース可能なところまで持っていく」みたいなあいまいなものではなく,「⁠この機能の実装には1週間」「⁠このUIの追加には3日」という,より明確に定義された細分化されたタスクリストになる。当然だが,プロジェクトの最初の段階では見積りすら不可能なタスクもあるものだが,その手のものを「今までの経験をもとにざっくりと」見積もるのはとても危険である。いう場合は,まずは3日とか1週間の「調査期間」をスケジュールしてもらい,その期間に実際にプロトタイプを作りながら「タスクの難易度」を測定するのだ。その間に「これなら作れる」という感覚が得られたのなら見積りを出すし,それでも無理ならば「相当難しいタスク」と覚悟したほうがよい。その場合,この手の「難易度の予想が難しい」タスクをほかのタスクより先にやることがとても大切である。それが「相当難しいタスク」であるかどうかを見極め,全体のスケジュールを見直したり,機能変更をするのは早ければ早いほど良い。スタートダッシュで一気に作り上げる次に大切なのは,2のすべてのタスクを「スタートダッシュ」で行うこと。「⁠締め切りに迫られていないと頑張れない」のは多くの人々に共通する弱さだが,先に述べたように,ソフトウェアのプロジェクトがうまくいかなくなる原因の9割は,締め切り間際の「ラストスパート」が原因だ。大切なことは,2週間でやるべきタスクだったらその半分の時間の1週間で終わらせるつもりで,プロジェクトの当初からスタートダッシュをかけることだ。この段階でのミスならば簡単に取り戻せるし,テストの期間を十分に持つことができる。徹夜をするなら締め切り間際ではなく,この時期だ。スタートダッシュ時の徹夜ならば精神的な余裕もあるし,疲れてしまったら休む余裕もある。この時期に集中して仕事をして,可能な限りのリスクを排除する。アーキテクチャの変更が必要ならこの時期にする。書きはじめたコードが汚くなってしまったら,もう一度ゼロから書き直す。健康だけには気をつけながら,全力疾走で仕事をする。実際に半分の時間が過ぎた段階で,タスクがどのくらい完了しているかをできるだけ客観的に判断する。8割がた終わっていればスケジュール通りに進んでいると考えてよい。6割ぐらいしか終わっていなかったらかなりの危機感を持つべき。半分の時間が過ぎた段階で,万が一完成度が6割未満だった場合は,「⁠締め切りまでに完成できない可能性がある」とその段階で判断し,プロジェクトマネージャに状況を説明して,スケジュールの見直しをしてもらう(3⁠)⁠。締め切り直前ではなく,締め切りよりもはるか前に締め切りに間に合わせられるかどうかを見極めることがものすごく大切だ。この段階で「まだ半分しか時間を使っていないから大丈夫」と思うのは大間違い。全力疾走で半分の期間を使って,まだ「ほぼ完成」の状態に持っていけていなかったら,かなりの確率で締め切りには間に合わないと判断すべきである。予定通りに進んでいれば(つまり半分の時間に8割がた完成していれば⁠)⁠,あとはコードを見直したり,テストプログラムを書いたり,次のタスクの準備をしながら余裕を持って仕事をする。この段階での自分の仕事は,「⁠バリバリコードを書くこと」ではなく「書いたコードの完成度を高めること」にあることを強く意識して仕事をする。時間に余裕があるときにこそ全力疾走する,という働き方ここに私が書いた仕事術は,ひとことで言えば「時間に余裕があるときにこそ全力疾走で仕事し,締め切りが近づいたら流す」という働き方である。仕事に対する姿勢を根本的に変えなければならないので簡単な話ではないが,確実に効果があることは保証するのでぜひとも試みていただきたい。学生の人たちには勉強にもこのやり方を応用すること強くお勧めする。授業の前の予習に8割の時間を割き,残りの2割の時間を授業直後の復習に使う。試験前は一夜漬けなどけっしてせずに,体を十分に休めてフレッシュな頭で試験に臨む。そんなやり方で勉強すれば,必ず成績は向上する。スケジューリング著者プロフィール中島聡(なかじまさとし)米国シアトル在住の自称「永遠のパソコン少年」。Explorerの統合を実現。beautiful」。Engine上でのサービス作りに夢中。iPadアプリ「CloudReaders」開発中。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。その他の連載CSS3アニメーションでつくるインターフェイス表現CSS3によるアニメーション表現を紹介していきます。その中でも,幅広い読者に応用してもらえるだろうインターフェイスを主なお題とします。MySQL道普請便り本連載では,MySQLを使ったアプリ開発・運用に関するノウハウをご紹介していきます。RecipeUbuntuの強力なデスクトップ機能を活用するための,いろいろなレシピをお届けします。JavaScriptセキュリティの基礎知識JavaScriptに関するセキュリティ上の問題はどこで発生し,どうすれば防ぐことができるのか?について解説していきます。〜システムをきちんと運用するための基礎知識システムは「作って終わり」ではなく,運用の中でさまざまな問題が発生します。問題の発生に備えて事前にどのような対応をしておくべきなのか,問題発生時に何をしなければならないのか,ポイントを解説していきます。きたみりゅうじの聞かせて珍プレーソフトウェア開発の現場で体験したトホホな失敗,思わずうなる珍プレーをきたみりゅうじ氏が四コママンガで紹介。Linuxのメンテナンスの傍ら,Linuxやオープンソースソフトと日々を過ごす著者が,その魅力とつきあい方を,エッセイ風味でお届けします。PRESS特別編集部員,さわやか笑顔のスーパーハカーはまちちゃんとネット大好き14歳わかばちゃんが,毎号,読者の皆さんから寄せられたおたよりを紹介します。皆さんの日頃の悩みにも答えちゃいますよ。]メールでのお知らせメールで次の案内をお送りしております。メールの配信を希望する方は,利用したい項目をチェックしてメールアドレスを入力し,[登録]ボタンをクリックしてください。UPDATES[ほぼ週間に1回]新刊メールマガジン[ほぼ週間に1回]電脳会議の各号案内[ほぼ1ヵ月半に1回]※変更する場合や停止する場合は,登録情報変更ページをご覧ください。※登録いただいたメールアドレスには,そのお知らせ以外,配信いたしません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。