勘と経験と読経

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

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

Work Kindle book

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

仕事に追われない仕事術 マニャーナの法則・完全版

仕事に追われない仕事術 マニャーナの法則・完全版

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

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

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

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

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

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

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

ファスト＆スロー　（上）

ファスト＆スロー　（上）

ファスト＆スロー　（下）

ファスト＆スロー　（下）

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

マニャーナの法則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

週次の作業ふりかえり（継続）

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

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

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

エンジニアのHR系(？)書籍などがKindleでセール中

book Kindle

昨日までもセールだったのだけど、値引率（ポイント還元含む）がさらに増えたようなので目についたものを紹介しておく。価格は変動するので購入時には確認いただきたい。

その「エンジニア採用」が不幸を生む　?良い人材を見つけ、活躍してもらうには何が必要か？

その「エンジニア採用」が不幸を生む　?良い人材を見つけ、活躍してもらうには何が必要か？

ちょっと気になっている本。未読。ござ先輩がオススメしていたのが記憶に残っている。現在40%オフの模様。

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

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

目次を見て興味があるならオススメの本。ただこの手の本やブログ記事をよくチェックしているのであれば、そんなに斬新な事は書かれていないと思ってる。現在49%オフ。

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

Googleのマインドフルネス本。エンジニア向けにわかりやすく書かれているのが好感だけど、実践はやっぱり難しい。現在35%オフ。

How Google Works

How Google Works

ワーク・ルールズ！―君の生き方とリーダーシップを変える

ワーク・ルールズ！―君の生き方とリーダーシップを変える

どちらもGoogleの人材管理の本。現在35%オフ。

HIGH OUTPUT MANAGEMENT

HIGH OUTPUT MANAGEMENT

骨太な本だけど非常にオススメ。現在35%オフ。

なおHR系をピックアップしてみたけれども、よくセールになる技術書類も割とセールになっているので気になるものはチェックしてみると良いと思う。

ソフトウェアにおけるアンチフラジャイルとレジリエンス

Project Management

気になったキーワード「アンチフラジャイル」について調べてみた。また類似の概念「レジリエンス」との違いについての現時点の理解とそれについて思ったこと。
fragile

アンチフラジャイル

自分がこのキーワードを知ったのはInfoQの記事なのだけれども、Qiitaにも整理された記事があったので、あわせて読んだ現時点での理解は以下の通りである。

いやぁ、文章としてはある程度理解できるような気がするけれども、具体的なイメージがまったく沸かないぞ・・・

アンチフラジャイルを目指すために必要なこと

個人的な印象で書くのだけれども、「アンチフラジャイル」なシステムを目指すのであれば次のような事を意識していく必要があるのだと理解している。

  • まず大前提として「レジリエンス」なソフトウェアであり、突発的な問題が発生したとしても最低限の安全性は担保できるようにする必要がある。簡単にサービスが停止してしまうような脆弱な（フラジャイルな）ソフトウェアが一足飛びに抗脆弱性（アンチフラジャイル）を得ることは難しいだろう。
  • 次の段階として、発生するさまざまな問題に対してスピーディに改善、改良を繰り返すことが出来るようにする必要がある。これは近年話題のDevOpsといったキーワードで語られている事柄と関連していて、継続的に改良・改善を繰り返していくための仕組みづくりが必要なのだろう。ただ、これが実現した状態がアンチフラジャイルな状態か、というとまだ足りない印象がある。
  • では何をするのか。さらに強制的・高速・大量の失敗を注入することによって改善改良を繰り返すことによって、アンチフラジャイルな状態に移行していくのではないか、というのが現時点の理解。

こういった考え方は、アンチフラジャイルとセットで語られることの多いNetFlixのカオスエンジニアリングの事例などをが参考になるようだ。

任意のサーバのシャットダウンやプロダクション環境のデータセンター全体のシャットダウンをシミュレーションしてきた経験に基づいて、NetflixがChaos Engineeringの原則を提案している。 NetflixはChaos Engineeringを「プロダクション環境の過酷な状況に耐えられるというシステムの能力に自信を持つため、分散システムで実験するという規律」だと定義している。コントロールされた実験でシステムの振る舞いを観察することにより、プロダクションシステムの弱点が望ましくないやり方で現れる前に見つける必要があると、Netflixは述べている。

またタレブは、ティンカリング (ブリコラージュ) あるいは試行錯誤の結果、イノベーションという良いブラックスワンが起こると指摘しています。もちろん、その際には数多くの失敗をしますが、その失敗のコストは小規模かつ予測可能な範囲に収めます。これを Taleb は「凸状のいじくり回し (convex tinkering)」と呼びます。予測可能な損失の範囲で試行錯誤しながら、ポジティブなほうに凸になるところをいじくりながら探すわけです。それは運にまかせるということではなく、一回の失敗ごとに学びや追加の情報が発生して、徐々に「どこに行くか」が分かる試行錯誤です。

話に聞くところによると、 マイクロサービスアーキテクチャに言及があるようで、これは未読なので早く読んでみたい。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

あとこちらは邦訳版は出ないのかなぁ・・・

Antifragile: Things That Gain from Disorder (Incerto)

Antifragile: Things That Gain from Disorder (Incerto)

祝復刊！Googleもホロウィッツも参考にしている「インテル経営の秘密」が手軽に買える

Kindle book

長らく絶版で入手困難だった、アンドリュー・S・グローヴの「インテル経営の秘密」が装いも新たに復刊されたのでご紹介。

HIGH OUTPUT MANAGEMENT

HIGH OUTPUT MANAGEMENT

いやぁ、人に紹介しやすくなった。なお詳細まではまだ確認していないのだけれども、早川書房の旧版と基本的には同じ内容の模様。訳者も同じだし、目次レベルでも変化はなさそう。追加要素は「HARD THINGS　答えがない難問と困難にきみはどう立ち向かうか」でも有名なホロウィッツの序文のみのようだ。

旧版の「インテル経営の秘密」の中身については、以前に書いた以下の記事を参照のこと。

ざっと記憶の限りでも、この本は以下の書籍で触れられ、称賛されている。

How Google Works

How Google Works

ワーク・ルールズ！―君の生き方とリーダーシップを変える

ワーク・ルールズ！―君の生き方とリーダーシップを変える

HARD THINGS　答えがない難問と困難にきみはどう立ち向かうか

HARD THINGS　答えがない難問と困難にきみはどう立ち向かうか

またちょっと前だと、以下のブログなどでも言及されたり。

割と世の中的には批判も多い「マネージャ」という仕事を、真面目に考える上で必読の書だと思う。

2016年下半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書)

book

上半期に引続き、2016年7月～12月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2016年下半期に読んだ本を並べてみた

オススメ文芸書編

2016年もいろいろ読んだのだけど、小川洋子さんの『猫を抱いて象と泳ぐ (文春文庫)』が最も素晴らしかった。2009年の本なのでもの凄くイマサラ感があるのだけれども、数ある書評にあるように『博士の愛した数式』を超えているという実感あり。チェスを題材としたお話ですが、チェスの知識はまったく必要ない。

猫を抱いて象と泳ぐ (文春文庫)

猫を抱いて象と泳ぐ (文春文庫)

その他としては、『聖の青春 (角川文庫)』『楽園のカンヴァス (新潮文庫)』も非常に良かったのだけれども、どちらも前提知識（将棋や美術）をそれなりに備えていないと楽しみきれないかもしれないというところで次点。しかしこの2冊も「読まずに死ねるか」という本である。

オススメビジネス書編

こちらも新旧織り交ぜて読んでいるのだけれども、一つだけ選ぶとしたら『LIFE SHIFT(ライフ・シフト)』をプッシュしたい。前作『ワーク・シフト ― 孤独と貧困から自由になる働き方の未来図〈2025〉』で非常にわかりやすい形で新たな働き方について提示した著者が、近年の具体的な傾向である「長寿化」をテーマに書いた本である。親世代の高齢化は今まさに直面している問題であるが、それを超えてさらに変化がやってくるという事を改めて認識する事ができる本である。

LIFE SHIFT(ライフ・シフト)

LIFE SHIFT(ライフ・シフト)

次点としては『サイロ・エフェクト 高度専門化社会の罠』も切れ味鋭く、新たな視点観点を付け加えさせてくれる良書。なお本書はテーマだけでなく、人類学者的アプローチで物事を分析するという点でも興味深いものになっている。

サイロ・エフェクト 高度専門化社会の罠

サイロ・エフェクト 高度専門化社会の罠

オススメ技術書編

すっかり技術書の近著を読めていない（もしくは、積読になっている）のだけれども、『システムテスト自動化 標準ガイド CodeZine BOOKS』は有用度の高い本であった。ツールやテクニックだけでなく戦略的な考え方まで学べる良い読書だった。

システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

それでは、テスト自動化のベンダーという魔法使いにお金を払い、問題を追い払うテストツールという魔法の道具を受け取ってはどうでしょう。ひとたびテストを作ってしまえば、後はツールに任せればいい。なぜそうしないのでしょう。それは、技術が「十分に発達」していないからです。修行を経た者でなければ、魔法の道具は使えません。魔法使いが触れないと、道具は力を失い、腐り始め、バグを見つけるという仕事から完全に離れていってしまうのです。
システムテスト自動化 標準ガイド CodeZine BOOKS

その他、例えば古典的名著と言われる『☆』がKindle化されていたので読んだのだけれども、興味深くはあったがさすがに内容も古く、教養が増した以上の効果は感じられなかった。

オススメしないけど面白かった本

ぶっ飛んでいる作品としては『最後にして最初のアイドル【短篇版】』が良かった。SF小説なのだけれども、内容的にも時空的にも期待をはるかに超えるスケールである。ちなみに本作はラブライブ！2次創作らしいのだが、知識なしでも問題なく楽しめた。

最後にして最初のアイドル【短篇版】

最後にして最初のアイドル【短篇版】

あと以前から興味を持っていた筒井康隆氏の書くラノベ『ビアンカ・オーバースタディ (角川文庫)』を読んだのだけれども、いろんな意味で想像以上だった。ネットで見かけた評「帯には「それは2010年代の『時をかける少女』」とあるが、さわやかなラベンダーの匂いではなく栗の花の匂いがする」が秀逸すぎる。全力でオススメしない。

2016年の読書振り返り

技術書を中心に、Kindleセールでうっかり購入するペースに読むペースが間に合っておらず、雪だるま式に積読が増えている。非常にまずい状況。現時点でお恥ずかしながら積んでいるのは次の通り。計画的に読み切りたい。

加えていくつかセールになったら購入しようと考えている本もあるわけで、ちょっとペースを上げていかないとまずい。

なお読書にはKindle Paperwhiteの第五世代(2012年)をあいかわらず使用中。最新モデルにするといろいろと便利なのだと思うのだけれども、別に不具合もなくバッテリーも調子が良いので、故障するまでは使い続けそうな予感。

カーゴ・カルト・ソフトウェア工学とか

Agile Project Management

そもそもソフトウェア工学が死んでいるという議論もあるかもしれないが、これとは別にカーゴ・カルト・ソフトウェア工学的な問題が拡大している実感があるので、それについて考えたことをちょっと整理してみるもの。国内で技術者教育の手法の主力となっているOJTがカーゴ・カルトを増産しているのではないだろうか。あとカーゴ・カルト・アジャイル開発について
Burning Man 2013: Cargo Cult

カーゴ・カルトとは

カーゴ・カルトあるいは積荷信仰とは、主に第二次世界大戦後に南海の先住民に発生した宗教のことである。

カーゴ・カルトという語句は、元々は第二次世界大戦後の南太平洋で見られた先住民の宗教に由来している。これらの人々は、戦時中素晴らしい積荷をもたらしてくれた神のような飛行機を呼び出そうと、一心不乱に精巧な飛行機の模型や滑走路を作り上げた

転じて、背景にある仕組みを理解せずに行動を過剰に（そしてその多くは無意味に）繰り返し実施することを「カーゴ・カルト」と評するのである。

「まるでカーゴ・カルトですね」と、依頼主である彼女の上司に進捗を尋ねられた私は、正直にそう言った。その会社の会議室には灰皿が置いてあったので、私は遠慮なく煙草に火をつけた。「ようするに、あのシステムを最初に作った白人は、ミクロネシアの奥地に飛行場を作ったんですよ。後任の彼女はそこで飛行機を初めて見た。そして、白人が去った後、彼女はあなたに飛行機を作るように言われたわけです。」戸惑う上司の前で、紫煙を吐き出す。「やり方は教わっていない。ソースコードしか手がかりはない。だから木の枝や藁で、無線機や、滑走路を作って、飛行機を呼ぼうとしているんです」

カーゴ・カルト・ソフトウェア工学

もともとプログラマの隠語として「カーゴ・カルト・プログラミング」という言葉はあったようだけれども、Steve MaConnell は著書「ソフトウエア開発プロフェッショナル」で これを拡張した「積荷崇拝的ソフトウエア・エンジニアリング」という概念について警鐘を鳴らしていた。

ソフトウエア開発プロフェッショナル

ソフトウエア開発プロフェッショナル

積荷崇拝的ソフトウェア・エンジニアリングの見分け方は簡単だ。そんなプロジェクトでは、全く意味のない作業でも、「いつもこうしてきた」とか「会社の規則でこうせねばらなない」と正当化している。また、プロセス指向の開発や、実力主義方式でのソフトウェア開発には、トレード・オフがあることを認めない。どちらの開発方式にも、長所と短所がある。さらに効率の良い新方式があっても、積荷崇拝的なソフトウェア技術者は、掘っ立て小屋にとどまり、大昔から伝わり快適だが何の役にも立たない儀式を続けるのだ。
ソフトウエア開発プロフェッショナル

  • コードレベルの無意味な風習というより、開発プロセス全般の無意味化された慣習
  • たとえばプロジェクトの特性を無視した不必要な手順
  • ソフトウェアの特性を無視した標準化
  • 実態に即していない、文書化やテストに関するプラクティス

あたりがイメージできる。うーん、あるある

OJTとカーゴ・カルト

どちらにしろ「カーゴ・カルト」的なものが忌むべきものであるという点には議論の余地がないと思うのだけれども、残念ながら現状の（国内の）ソフトウェア開発を取り巻く状況はこれを増長させるものとなっている印象がある。

  • 専門的教育を受けていないソフトウェア技術者が多い。IT人材白書2016を見ても「開発プロセス」をいつどこで学んだかというアンケートに対して「会社の実務経験を通じて」という答えが大多数
  • ソフトウェア技術者の育成については、OJTに頼っているのが現状。こちらもIT人材白書2016にて確認
  • IT人材白書：IPA 独立行政法人 情報処理推進機構

別にOJTを否定するものでもないけれども、察するに・・・

  • OJTを担当する上級者が必ずしもソフトウェア開発のエキスパートではない
  • 理論はさておいて、実践中心の指導となっている。というと聞こえは良いが、今やっていることを見真似することから教育を始めてしまう
  • 「とりあえず、チュートリアル・ガイドの通りにやって。わかんないことがあったら聞いて」

という状況が想起されてしまう。もちろん実践をしながら独習や研修などによって補完的に理論や仕組みを学ぶ人もいると思うのだけれども、実際にそういった人がどの程度の割合になるのだろう。けして比率は大きくない気がする。
その結果、カーゴ・カルト的なものが増えていくのではないか。SIerとか受託開発方面では特に・・・

ソフトウェア開発プロジェクトは、その前提となるビジネス側の要求も千差万別だし技術的な側面もプロジェクトによって大きく異なる。過去に学んだ知識を繰り返し活用することはできず、常に学習を継続しく必要もある。モチベーションを維持できず足を止めてしまうと、すぐにカーゴ・カルトの闇に落ちることになるのだろう。また、カーゴ・カルトによって実際には生産性が落ちたり品質が低下するはずなのだけれども、そのスピードが緩やかなので問題視されにくいという構図もある。どうせ人月単価の世界だしね・・・


そんな状況の中で茹で蛙にならないためには

  • 自分自身が学習を継続する
  • OJTを通じて後進教育をする場合は、表面的な作業説明だけではなく、背景について説明をする
  • OJTを受ける場合は、作業の背景についても興味を持ち調べる
  • 自分が実施している作業がカーゴ・カルト的かどうか常に疑問を持つ

ということが必要なのではないかと思った次第。常に実施できるかどうかは別にして

カーゴ・カルト・アジャイル開発

さて一方で、世の中的には「カーゴ・カルト・アジャイル開発」というものも増えてきているような話がある。

最近Twitterやメーリングリストでは、ルールに従うことこそ全てと信じているような人たちが、自分の満足いくようにルールに従わない相手に対して「あなたはアジャイルじゃない」と主張しているのを当たり前のように目にするようになりました。調査と順応の概念は一体どこへいってしまったのでしょう。近い将来起こり得る問題に対処できるよう手法の革新を図ろう、新たなやり方を導入しようという考えは、どうなってしまったのでしょう。よく用いられる正統派なアジャイル開発手法は、本質的には10年以上何も変わっていません。私たちは型にはまってしまっているのです。

プログラミングの仕事をしている現在の職場をやめ、別の職場を探すべき9つの兆候をInfoWorldの記事でAndrew C. Oliver氏がまとめている。 Oliver氏によれば、9つの兆候は以下のようなものだ。プログラミングの仕事に限らず、スラドの皆さんが転職を考えるべき兆候というのはあるだろうか。
(中略)
6. アジャイル開発を表面的にまねただけのカーゴカルト的アジャイルが行われている

本来のアジャイル開発プロセスであれば、定期的な振り返りの実施によって常に改善を行うプロセスが組み込まれているのでカーゴ・カルトの発生は抑えられるような気もするのだが、

  • トップダウンで導入された開発支援環境にロックインされ、作業プロセスが容易に変更できない
  • 強力なコンサルタント／コーチによって導入されたプロセスを自発的に変更できない
  • 目の前のバックログに圧倒されてしまい、改善するモチベーションが無くなる／現状継続を選択してしまう

ということは実際ありそうな気がする。

(良し悪しは別にして)ソフトウェア工学的、計画駆動型のアプローチは「どうしてこうなったのか」を分析することが容易である。一方でアジャイル開発におけるプラクティスはその実証主義的傾向から「どうしてこうしているのか」がわかりにくく、かつ時間が経過してしまうと、どうやって意思決定したのかも記憶の彼方に消えてしまうような気がしてならない。人が変われば経緯も忘れ去られてしまう。そういう意味では、カーゴ・カルトが発生する傾向は計画駆動型アプローチより高いのかもしれない。そんなことを想像した

Kindleで翔泳社新刊「レガシーソフトウェア改善ガイド」含め、50%ポイント還元中(12/8まで)

Kindle book

表題通りAmazon Kindleで大規模セールになっているようだが、新刊「レガシーソフトウェア改善ガイド」も対象になっている点に注目。さっそく購入。

レガシーソフトウェア改善ガイド (Object Oriented Selection)

レガシーソフトウェア改善ガイド (Object Oriented Selection)

この本のスコープは欲張りなもので、放置されたレガシーコードベースを、あなたの組織に価値をもたらす保守が可能で十分に機能するソフトウェアへと変身させるのに必要なことを、すべて伝授しようというのです。
レガシーソフトウェア改善ガイド (Object Oriented Selection) この本について、より引用

なかなか興味深そう。旧著レガシーコード改善ガイド (Object Oriented SELECTION)に比べるともう少し戦略的な事が書かれていそうな印象。技術面だと

ただし、この本に技術的な内容がないというのでは、まったくありません。本書は、Jenkins,Findbugs,PMD,Kibana,Gradle,Vagrant,Ansible,Fabricなどといった、広範囲なツールを扱います。数多くのリファクタリングパターンを詳細に取り上げ、モノリスからマイクロサービスにいたるさまざまなアーキテクチャにおける関連メソッドを論じ、コードをリライトするときにデータベースを扱う戦略も見ていきます。
レガシーソフトウェア改善ガイド (Object Oriented Selection) この本について、より引用

というカバー範囲になっている模様。

その他のオススメ本は以下記事などを参照いただきたい。