勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

Kindleでケヴィン・ケリーの近著やSOFT SKILLSを始め技術書籍が50%オフ

久しぶりに割と広範囲にテクノロジー関連書籍が50%オフセールになっている模様。というわけで気づいたものを中心に紹介。

〈インターネット〉の次に来るもの 未来を決める12の法則

〈インターネット〉の次に来るもの 未来を決める12の法則

技術エッセイの類だが非常に興味深く、オススメ。本書については本ブログの以下記事で触れているので参考まで。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

一般的なビジネス啓蒙書(7つの習慣とか)をあまり読んでいないエンジニアにはオススメだけれども、その手の本を読んだことがある人にはいまさら、という微妙な本なのだけれどもたくさんの情報が詰め込まれている事は確かなので、セールは手に取るチャンスかも。

ヘネシー&パターソン コンピュータアーキテクチャ 定量的アプローチ 第5版

ヘネシー&パターソン コンピュータアーキテクチャ 定量的アプローチ 第5版

現在読んでいるところ。高価なのでセールはチャンスだけれども、当然万人向けではない。教科書の類。

こちらも名著の類。高価なのでセールはチャンスだけれども、最近は本書を読むよりリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)を読むほうが良いという評もあるようだ。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

名著の類。こちらは現在も読むといろいろと示唆があると思っている。時々読み返している。

あまり手が動かないタイプのいわゆるSIerに所属しているエンジニアなどが最初に読む本としては、いろいろと詰め込まれていて便利な印象。最近よく人に勧めてる。

音楽の所有をやめたことと、ケヴィン・ケリー〈インターネット〉の次に来るもの

ポエムの類。最近音楽の所有をやめたことと、最近読み終わったケヴィン・ケリー「〈インターネット〉の次に来るもの 未来を決める12の法則」について考えたこと。同書で語られるテクノロジートレンドは、割と実感に即しており、いろいろ考えさせられる。
ipod

音楽の所有をやめるまで

これを書くと歳がバレるのだけれども、高校生まではCDとWALKMAN類、学生時代と社会人数年間はMDが主な音楽の所有手段だった。で、社会人になって数年経ってデジタルオーディオプレーヤーが発売され、早い段階から使い始めてた。

最初に使い始めたのはHyperHyde ExrougeというMP3プレーヤーの名機で、すごく使い勝手が良かった。片っ端からCDをリッピングしてデジタル化しながら聞いていた。ただ容量が小さく持ち歩ける量はアルバム3-4枚程度。でも手軽さが何より素晴らしかった。それまでに溜め込んでいたカセットテープとMDはデジタル化出来ないので全部捨てたのもこのあたり。

ちなみにちょっと話がそれるのだけれどもMP3の誕生から普及に関する想像とは異なるドラマについて書かれた「誰が音楽をタダにした? 巨大産業をぶっ潰した男たち (早川書房)」はドキュメンタリーとしてめちゃくちゃ面白いので、この時代にCDをリッピングしてきた世代の方は一読をおすすめしておく。

次に買ったのが確かiPod Shuffleの第1世代(512MB)。最初は単に容量が大きい点が嬉しかったのだけど、この時点で蓄積された大量のデジタルオーディオからランダムな楽曲を転送して聞くことの楽しさがあった。音楽のライブラリ管理をitunesに移行したのもこのあたりのタイミング。

そして2007年くらいに世の中に遅れてiPod Classicを購入。たしか容量は80GBだったが、当時保有していた全てのデジタルオーディオを全て持ち歩けるようになった。振り返ると、このあたりが自分の音楽所有のピークだったような気がする。

その後スマートフォンを利用することになってiPodはいつの間にか使わなくなり、つい最近まではiPhoneに1GBくらい音楽を入れて持ち歩いていたのだけれども、先日ついにこれをやめた。音楽ファイルの同期をやめた。

で、今は何で音楽を聴いているのかというと

である。
自宅の母艦PCのHDDには約60GBのデジタルオーディオの蓄積があるけれども、今後これにアクセスする頻度はどんどんと下がっていくような気がする。

〈インターネット〉の次に来たもの

最近読んだ本でとても面白かったのが、ケヴィン・ケリーの「〈インターネット〉の次に来るもの 未来を決める12の法則」である。同書は技術そのものの持つ特性を考察することで、インターネットの次にどんなことが起こるのかを論じている。
たとえばこんな感じである。

所有することは昔ほど重要ではなくなっている。その一方でアクセスすることは、かつてないほど重要になってきている。
〈インターネット〉の次に来るもの 未来を決める12の法則 5.ACESSING、より

高度に進んだテクノロジーのおかげで、こうした魔法のようなレンタル店が実現する。それこそ、インターネットとウェブとスマートフォンの結び付いた世界だ。このバーチャルな棚は無限だ。この最大のレンタル店では、ごく一般的な市民がまるで自分が所有しているかのように、即座に商品やサービスを利用できる。これを利用する方が、自分が持っているものを地下室から探し出すよりも早い場合もある。しかも、商品の品質は自分で所有している場合と同じだ。アクセスする方が所有するよりも多くの意味で優れているので、それが経済を最優先で牽引している。
〈インターネット〉の次に来るもの 未来を決める12の法則 5.ACESSING、より

〈インターネット〉の次に来るもの 未来を決める12の法則

〈インターネット〉の次に来るもの 未来を決める12の法則

そして今まさに自分は音楽を所有するものから、アクセスするものに変えようとしている。その理由は同書に書かれているものとほとんど同じだ。

  • ローカルのライブラリを維持するのが面倒。頻度は高くないけど機器をリプレースする度にデータ移行しなければならない
  • 利用するのにローカルのライブラリにアクセスするのが煩わしい
  • 物理的なメディア(CDなど)の取扱いは面倒の極み。取り込んだ後の保管や廃棄など
  • デジタル音楽についても購入手続きが面倒→定額視聴最高
  • 新譜や話題の音楽に出会うための活動も省力化したい→radikoのタイムフリー視聴でチャート番組や好きなDJプレイを視聴

といった理由を考えて、思い切ってPrime Musicに移行したのだけれど今の所は不満なし。他の定額サービスに比べてレーベルや新譜のカバー範囲に制限は多いのだけど、自分の興味の範囲がそこに無いので問題なしだ(それでも聞きたい新譜があれば楽曲単位で購入すれは済むし)。

ちょっと悩ましいのは、所有からアクセスに方針を切り替えると、利用する際にはネットワークが前提となってしまうところである。まあモバイルという観点では最近は電波圏外も少ないし、WiFi利用可能な場所も多いから問題ないか・・・この間静岡から東名を走りながらPrime Music利用してみたけれども、まったく問題は無かった。

もちろん災害などでネット断絶など起こればアクセスできなくなっちゃうのだけれども、その時はその時だなぁと。以前の震災(いわゆる311)の際に計画停電などにより数時間の停電も経験したけれども、まぁその時には電池で動くラジオがあれば十分だった。

次は何がおこるのか

〈インターネット〉の次に来るもの 未来を決める12の法則」を読むといろいろな事が予想されているのだけれども、それが遠い世界の物事ではなく実感できる生活レベルで経験できるというのは非常に面白いと思う。また、これを実感として楽しめるのは現代に生きている世代の特権な気もする。本記事で取り上げた「Accessing」というキーワードだけでも、音楽だけでなく、どこまで「所有」から「アクセス(権)」に移っていくのか考えるのは興味深い。

フォードのエベレストプロジェクト

ジョイ・インク 役職も部署もない全員主役のマネジメント」で言及されていたシステム開発のトラブルプロジェクト事例「フォードのエベレストプロジェクト」について調べてみたメモ。2004年のシステム開発失敗事例の模様。

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

フォードのエベレストプロジェクトを考えてみよう。ドットコム時代の巨大なプロジェクトで、さまざまなサプライヤー向けに別々に作られた30もの購買調達システムを一つのWebシステムに統合しようとしていた。2004年、フォードは助かりそうにないITプロジェクトをついに中止した。すでに4億ドルも投資していた。1億ドル投資したあとに、プロジェクトの中止を何回見送ったと思う? もう1億ドル投資すれば、予定どおりに挽回できますと宣言したのだろう。で、さらに2億ドルを追加し、そして……ついに中止した。4億ドルをどぶに捨てたあとで。
ジョイ・インク 役職も部署もない全員主役のマネジメント

概要

  • 1999年エベレストプロジェクト開始。30種類の異なる購買システムと調達システムを、複数の階層のサプライヤーが利用する1つのWebベースのシステムに統合し、コストのかかる手作業の調達作業を自動化するのが目標。
  • 2000年よりアプリケーション稼動開始。「ローリング・ローンチ」方式で段階的に現行システムから新システムに移行する計画。
  • 2004年 プロジェクトを中止し、実績のある現行システム(メインフレーム)に戻すことを発表。

問題点

  • コストの増加。初期見積りでは2億ドルだったが、作業が進むにつれて膨れ上がり、プロジェクト中止前には4億ドルに達していた。
  • 使いやすさの欠如。エンドユーザである自動車部品のサプライヤにとって使い易いシステムを構築できなかった。新旧システム並存の状態での業務の実施が困難なことに加えて、新システムでは多くの機能が不足しており、新システムに移行するインセンティブも無かった。
  • 困難な統合。チーム間のコミュニケーションに問題があり、サブシステム間やセキュリティ、基盤、CRMといったコンポーネントの統合がうまく出来なかった。
  • プロジェクトのゴールそのものが非現実的、野心的すぎた。

感想

  • さすがに13年前の事例ということもあり、あんまり情報が無かった。論文類もちょっと調べたけど、あまり言及が無い印象。
  • とりあえず、壮大なプロジェクト名をつけるとずっコケた時に悲しいのでよろしくない。
  • サンクコストを考える事例として名前くらいは覚えておくか・・・

ソフトウェア開発の失敗確率と、原因が上流工程にあるという根拠データを確認してみた

「ソフトウェア開発プロジェクトの成功確率は3割」「ソフトウェア開発が失敗する原因は、往々にして上流工程(企画とか要件定義)にある」という都市伝説(?)に関して。これを説明する際によく紹介される業界データがやたら古かったり、引用があいまいだと感じることがあるので整理してみた記事。
Taupo Bungy Jump

日経コンピュータによるプロジェクト実態調査(2003、2008)

プロジェクトの成功率が

  • 2003年調査 26.7%
  • 2008年調査 31.1%

となっていて話題性が高いのと、記事のファインダビリティが高いのでよく引用されている印象。
また雑誌記事が元ネタなので(根拠は無いけど)ちょっと数字を作りにいっているイメージがある。

いっぽうで、プロジェクトの中で品質問題がどこで発生しているのかというデータも提示されている。

  • 2003年調査
    • 第1位:要件定義が不十分(35.9%)
    • 第2位:その他(27.7%)
    • 第3位:テストが不十分、移行作業に問題(21.9%)
  • 2008年調査
    • 第1位: テストが不十分、移行作業に問題(41.7%)
    • 第2位: 要件定義が不十分(36.7%)
    • 第3位:システム設計が不正確(31.7%)、システム開発の質が悪い (31.7%)、エンドユーザへの教育不十分 (31.7%)

こう見ると、引続き「要件定義が不十分」という要因はトラブルの主因であるとは言えそうだ。

ただ、データそのものが10年前のものなので、現在このデータを参考にするのはちょっといかがなものかと思う。

IPA/SEC ソフトウェア開発データ白書 (2017-2005)

さて、一方でIPA/SECさんのデータ白書でもプロジェクト成否のデータが収集されている。こちらではどうか。試しに日経コンピュータの調査と対比できるように2005年、2008年、および最新2016年のデータを拾ってみた。

プロジェクトの成功率(QCD全て成功)は

  • 2016年調査 67.1%
  • 2008年調査 63.0%
  • 2005年調査 46.1% ※ただしこの年の調査はQCD達成基準は不明確

となっている。前述の日経コンピュータ調査は(おそらく)発注者視点であることに対して、こちらの調査は受注者(ベンダー)視点であることが成功率の乖離の原因なのだろう。そういう意味では、例えば以下のデータのほうが、発注者視点で見た場合のプロジェクトの成功率をより明確にあらわしているのかもしれない。

顧客満足度に対するベンダ側の主観評価で「十分に満足している」は

  • 2016年調査 31.2%
  • 2008年調査 28.8%
  • 2005年調査 データなし

となっている。

また、プロジェクトの成功という観点ではないが、品質観点で以下のような分析もあるようだ。

  • テスト密度と、信頼性の高さは有意な関係にない
  • テスト検出不具合密度が低いほうが、信頼性が高い傾向がある
  • テスト検出能率が低いほうが信頼性が高い傾向がある
  • つまり、テスト開始時点での作りこみ品質の高さが、信頼性に直結する
  • よって、信頼性を確保するには上流工程の注力が重要である

ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開 ~定量的データに基づくソフトウェア開発のプロセス改善を目指して~:IPA 独立行政法人 情報処理推進機構

日本情報システム・ユーザ協会(JUAS)企業IT動向調査報告書(2017-2003)

最新版は一般公開されていないのだけれども、2016年の結果の一部は"SEC BOOKS:ユーザのための要件定義ガイド ~要求を明確にするための勘どころ~"で引用されているのでそこからピックアップ。

プロジェクトの成功率そのものは示されていないが、同報告によれば

年度別システム規模別 システム開発工期遵守状況

  • 開発規模:500人月以上
    • 2015年度 ・・・ 予定通り完了 21.9% ある程度は予定通り完了 35.8% 予定より遅延 42.3%
    • 2009年度~2014年度平均 ・・・ 予定通り完了 19.7% ある程度は予定通り完了 35.7% 予定より遅延 44.5%
    • 2004年度 ~2008年度平均 ・・・ 予定通り完了 11.1% ある程度は予定通り完了 36.9% 予定より遅延 52.1%

年度別システム規模別 システム開発の品質状況

  • 開発規模:500人月以上
    • 2015年度 ・・・ 満足 14.2% ある程度は満足 59.6% 不満 26.1%
    • 2009年度~2014年度平均 ・・・ 満足 14.1% ある程度は満足 56.7% 不満 29.2%
    • 2004年度 ~2008年度平均 ・・・ 満足 8.2% ある程度は満足 61.8% 不満 30.2%

(出典: 日本情報システム・ユーザ協会「企業IT動向調査報告書2016」)

とのことである。

また、工程遅延理由のアンケート結果のうち55%が要件定義の問題となっており、具体的には

  • システム化目的不適当
  • RFP内容不適当
  • 要求仕様の決定漏れ
  • 開発規模の増大

が工程遅延を引き起こしているという記載もあった。

Standish Group Chaos Report(1995-2016)

ここまでは国内システム開発に関する情報だが、グローバルでは有名どころとしてStandish Groupが出しているChaos Reportがある。というか、ITプロジェクトの低い成功率を最初に示して話題をさらった元ネタという印象。リサーチ自体は非公開の模様だが、InfoQに解説記事があがっている。

これによれば、

  • 2015年 成功(Successful)29% 課題あり(Challenged)52% 失敗(中止)19%
  • 2011年 成功(Successful)29% 課題あり(Challenged)49% 失敗(中止)22%

となっていたりする。

まぁ、他にデータが無いならいざしらず、国内におけるITプロジェクトの成功率を語るのなら、Chaos Reportを参照するのはちょっと筋が悪いだろう。

まとめと感想

  • 発注者の観点から見るのであればJUASのレポートが参考になる。
    • 利害関係者すべてが満足するプロジェクトの成功は引き続き難しい。計画期間内に十分な品質のソフトウェア開発を完了させられる確率は2割以下である。
  • 受注者の観点から見るならIPA/SECのデータ白書が参考になる。
    • ベンダー観点でのプロジェクト成功確率は6割強であり、適切にベンダを選定し発注したのであればプロジェクトはちゃんと完了する。
  • 上記を踏まえると、プロジェクトの成否を決めるのはベンダーへの発注以前、すなわち計画や要件定義といった上流工程がポイントであろう。
  • 日経コンピュータの調査はけっこう古いので、現時点ではあまり参考にしないほうが良い印象 (個人的な見解)
  • Chaos Reportを参考にするのはやめておけ(個人的な見解)

まぁ、改めて言うほどのことはなく、いたって普通の結論である。

情報システムの障害状況ウォッチ(2016年後半)

SEC Journal48号で2016年後半の情報システム障害状況まとめが公開されたので読んでみる記事。いろいろあってすでに2017年も4分の1が過ぎてしまったので今更感もあるのだけれど。

過去に書いた関連記事は以下の通り。

SEC Journal最新号の入手はこちらから。

情報システムの障害状況ウォッチ(2016年後半)

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案ばかり。

  • [1635]地震発生時に警報システム等作動せず(2016/11/12)
    • 会員登録のお願い - 毎日新聞
    • SEC Jounal記事によれば「通信障害が起きたためとみられるが原因 は分かっていない」とのこと。また報道によると発生前日に保守点検をやっていたということから、点検作業のミスと見るのが妥当か。

2016年はここまで。さて今年はどんなことが起こるやら。

失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)

日経BPさんKindleセールで「Cloud First Architecture 設計ガイド」など50%ポイント還元中

目に付いたのでピックアップ。日経BPさんの書籍がKindleで50%ポイント還元中の模様(あさって3/12まで?)。見逃しもあったかもしれないけど「Cloud First Architecture 設計ガイド(日経BP Next ICT選書)」など初めて大幅値下げとなった気がする(即刻購入した)。というわけでめぼしいものをご紹介。

以前から気になっていた本(というか読んでなくてごめんなさい)。

ソフトウェア要求 第3版

ソフトウェア要求 第3版

要求定義の教科書としての鉄板本。新版なのでアジャイル開発までフォローされている。高額なのでこのタイミングでの購入をおすすめ。本ブログでもいくつか関連記事を書いた。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

昨年くらいにちょっと話題になっていた、技術者向けの技術以外のスキルについて書かれた本。この手の「仕事術」をあまりチェックしていないエンジニア向け。逆にいろいろな仕事術本を読んでいるのなら、重複感があってつらいかもしれない。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

人月見積もりというキーワードで敬遠されてしまうかもしれないけど、ソフトウェアの規模を測定するという点において鉄板本。ソフトウェアの見積もりをするすべての人が読むべきと思っている(わたしは営業にも読んでもらっている)。「なんでそんなにコストがかかるんですか」と質問する前に読んでくれ(お顧客は免除)。

ソフトウェア開発全般の鉄板本。最近はこの本を読むのはコスパが悪いという批判もあるけれども、買うならセールのタイミングがオススメ。

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

個人的に好きな本。Googleのテスト戦略に関する本なのだけれども、組織改革に関して書かれた本でもある。Googleが品質問題に悩んで、どう解決していったかが描かれている。

技術書じゃないけど超オススメのマネージャ向け書籍。


他にもデマルコの本など名著類もセールになっているので後は各自確認いただきたい。なおセールは突如終了する場合があるので購入時には注意いただきたい。

マイ仕事術2017を「マニャーナの法則」を読んでアップデート

ある時期から仕事術や手帳術に関する書籍は読まないようにしていたのだけど、いろいろなところで「マニャーナの法則」がオススメされたのでこの手の本としては久しぶりに読んでみた。いろいろと示唆があったので、整理してみる。

書籍「マニャーナの法則 完全版」の感想

ホワイトカラーで管理職で複数のプロジェクトを兼務している自分としては、いろいろと学びの多い良書だった。新入社員さんとか若手よりは、いろいろとタスク管理について煮詰まっている中堅以上のプレーヤー向けな印象。なおチケットやカンバンでしっかりと作業管理できているエンジニアなら、もしかすると読む必要は無いかも。個人的に良かった点は以下の通りである。

”理性の脳"と"衝動の脳" の話

あなたが仕事に仕事に追われるのはあなたの脳に原因があります。ですから、まずは脳の仕組みを知ることがベストな順番なのです。
仕事に追われない仕事術 マニャーナの法則・完全版 CHAPTER01 ”理性の脳"と"衝動の脳"

本書ではあまり科学的な観点で説明されていないのだけれども、まさに「ファスト&スロー」の話から本書は始まる。

  • 人間には”理性の脳”と”衝動の脳”という2つの脳がある。
  • "理性の脳"より"衝動の脳"のほうが優位である。
  • "衝動の脳"をコントロールする事が重要。
    • コントロールするためのシステムを自ら構築する必要がある

という事が書かれているのだけど、以前に読んだ「ファスト&スロー」と組み合わせて考えても、とても腑に落ちる説明である(ちなみに「ファスト&スロー」は思考と判断を仕事に使う方には断然オススメ)。

ファスト&スロー (上)

ファスト&スロー (上)

ファスト&スロー (下)

ファスト&スロー (下)

「ファスト&スロー」は、直感的思考をつかさどる「ファスト」なシステムと、論理的思考を担当する「スロー」なシステムを使ってわれわれは意思決定をしているという事について書かれた本である。"衝動の脳"あるいは「ファスト」なシステム部分は高速で反射的に動作するが、印象や感覚に影響されやすく合理的な判断が不得意という困った代物である。というわけで、仕事をする上では“衝動の脳”をコントロールする必要があるというのは、自分としてはすごく納得できた。

マニャーナの法則

表題にもある、本書で紹介されている仕事術の根幹は次のようなルールである。

  • 新しく発生した仕事は「明日やる」を基本にする
  • 次々と作業を積上げるToDoリスト(オープン・リスト)ではなく、ここまでやると予め決定したその日の作業リスト(クローズド・リスト)を元に作業管理する

一つ目の法則は、"衝動の脳"をコントロールするためのシステムとして、目の前に飛び込んできたタスクにすぐに飛びつくのではなく、少なくとも1日置いて計画的に作業するため。二つ目の法則は1日の作業コミットメントを作り、締め切り効果などを作り出して効率的に作業するためのものである。これを根幹に、いろいろな具体的な実践法を紹介するのが同書のキモである。ちなみに本書を読まなくても以下のブログ記事などでざっくりとしたことはわかる。

マイ仕事術を2017版にアップデートする

というわけで、「マニャーナの法則」で読んだ事を踏まえ、仕事方法を少し見直そうと思っている。構想はこんな感じである。

タスクリスト駆動で日々作業する(継続)

もともと1日の作業は日誌を中心に管理をしているのでこれを継続していけば良いと思ってる。

  • 作業は日次のノートをベースに管理する
    • 日中は日次ノートに書かれたタスクリストだけを意識して働く
  • 前日までの積上げ+朝の15分でいったん当日に実施する作業を全て洗い出す
  • 飛込みの臨時作業も、日次ノートの末尾に書き加えてから、他のタスクとの優先順位を判断した上で実行する(衝動的に反応しない)
  • 作業実施の結果などのメモも随時ノートに付け加えていく(作業記録を取る)
  • 当日に終えなかった作業については、翌日のタスクとしてカレンダーに登録する
  • 結果として1日の作業が終わった段階で全て記録されている状態で仕事を終える

「マニャーナの法則」でも紹介されているが、飛込みの作業に対してすぐに取り掛かってしまうのは“衝動の脳”による行動であり効率的ではない。すぐに着手するとしてもいったんはきちんとタスクリストに落とし込んで、"理性の脳"でよく考えてから実行するようにしたい。

新規の作業は明日やる(新たな習慣として追加)

実はもともと、アタマを使う作業(分析、意思決定)は午前中にするように心がけている。

というわけで、従来より飛び込みの分析や検討タスクはその日にはやらず、翌日午前に消化するようにしていた。しかし改めて「マニャーナの法則」を取り込んで、新規の作業は全般原則として明日やることにしようと思う(もちろん例外はある)。

  • 翌日以降に先送りすることは、当日の作業を効率化効果(割り込みを減らす)だけではない。
  • 例えば一晩以上寝かせると、寝ている間に脳内で整理が行われることによって効率化されることもありそう。すぐに作業にとりかかったら見落としそうな課題や、より良い進め方のアイデアなどが沸いてくることは少なからずある。
  • また、外部からの依頼作業などについては1日待つと要望の内容が変化したり、キャンセルされることもあるので、「すぐにやらない」は割と重要。
  • 次の日(作業する日)の通勤時などに、どのように作業を片付けるかを少し悩んでおく時間が持てるのも良い。

作業に集中しやすい仕事の仕方(新たな習慣として追加)

何かの作業にとりかかったら集中的に(ダッシュで)作業をするようにする。これを実現するために、

  • タイマーなどを活用する(脳にプレッシャーをかける)
  • 休憩に行くのは「作業の切れ目」ではなく「次の作業の仕掛り(例えばファイルを開いたり1行だけ文書を書いた状態)」とし、戻ってきてからすぐに作業に復旧できるようにマインドハックしておく

このあたりは他の仕事術でも似たようなものがあったような気もするけれど、改めて習慣化したい

週次の作業ふりかえり(継続)

これは「マニャーナの法則」とはあまり関係ないのだけれども、いろいろな作業(プロジェクト)を兼務で抱えているので、ヌケモレが発生しないように週次で振りかえりを行い、見つけたヌケモレタスクについては翌週の日次タスクにしっかりと組み込んでいく。このあたりは以前に書いた。

仕事の効率を上げるには、優れたシステムが必須であり、優れたシステムが効率できるのであれば、時間と費用をかけても絶大なリターンがあります。
しかし現実には、多くの人が形だけ立派な役に立たないシステムを使っています。システムそのものがなかったり、そもそも目先の仕事で精一杯で、システム構築に目を向けることすらできない人さえいるのです。
仕事に追われない仕事術 マニャーナの法則・完全版 CHAPTER02 問題はシステムで解決する

まったくもって、その通りだと思う今日この頃である。