逆フラゲ申し訳ありません。フライング土下座

はじめに(まとめです)

レガシーコードからの脱却 を Google先生に訊いてみると沢山の感想が在ります。

『Qiitaユーザーが選ぶ、2019年に読んで良かった技術書』アンケート結果発表 - Qiita Zine にも！

個人的にもオススメしたい一冊です。

特に、エライ人に読んでほしいです！

金銭的・時間的に余裕のない方も、上記をはじめ他の皆さんの感想を読んでみると良いと思います。

が、読了してみて思った事(あるある・納得感だけじゃなく、モヤモヤ感)が日々(の出来事を見聞きする度)どんどん積み上がって来ているため、お目汚しとは思いますが ~~随筆？エッセイ？~~ チラ裏を書き捨てさせていだだきます。

ここから先はそっ閉じ推奨！

そもそも

レガシーコードとは

世の中的には様々な定義がありますが、レガシーコードからの脱却には

レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。

と書いてあります。

バグを多く含み
壊れやすく
拡張が難しい

バグを多く含んでいる

× 本番で(一見)正常に稼働しているソフトウェアは、十分な(手動)テストもしているのでバグは(あるかも知れないが多くは)ない"はず"

壊れやすい

× 本番で(一見)正常に稼働しているソフトウェアは、最善の設計・コーディングをしているので壊れやすくはない"はず"

拡張が難しい

× 本番で(一見)正常に稼働しているソフトウェアは、メジャーな言語・フレームワーク・設計を(利用)しているので拡張は難しくない"はず"

表現は異なるかも知れませんが、概ね『否定(NO)』的な認識が大多数ではないでしょうか。

いやいや、そんなことはない。私(我々)は常に危機感を持っているよって方が居たらごめんなさい。

個人的な印象としてはこんな感じなんです。

己を知る

孫子の兵法「彼を知り己を知り、天を知り地を知る」 | PRESIDENT Online（プレジデントオンライン）
- 己を知ることの難しさ – 南充浩オフィシャルブログ

個人的にも苦手意識しかないのですが、やはり己を知るのは重要なのではないでしょうか。

自分への戒めも含めて・・・

技術的負債

蛇足

初っ端から蛇足なんですが、技術的負債というキーワードが最近とみに見聞きするのではないでしょうか。バズワードってやつですかね。

改めて Wiki を見てみたところ、なぜか関連項目の方が気になってしまいました。自分は Lisp に疎いからなのか、大きな泥だんごは初見でした。

パッと見、日本語訳も無さそうなので、その辺もあるのかな？

結構昔のキーワードなんですが、廃れるより寧ろ流行っているのでは？と思わせる内容です。

Big Ball of Mud

原文(Google翻訳)でも大体の内容はわかりますので、お時間ありましたら是非ご一読をオススメいたします！

蛇足(つづき)

アジャイル・スクラム・XPと技術的負債、大きな泥だんご、メテオフォールまで

改めて英語力は大事だと痛感。日本に広まるまでのタイムラグが絶望的。
途中抜けてますがご容赦を・・・

1986 The New New Product Development Game (スクラム)

1992 The WyCash Portfolio Management System (技術的負債)

1995 SCRUM Development Process (スクラム)

1997 Big Ball of Mud ( 大きな泥だんご )

1999 Pattern Languages of Program Design 4 (大きな泥だんご)

1999 エクストリーム・プログラミング (XP)

2001 アジャイルソフトウェア開発宣言 (アジャイル)

2001 Agile Software Development with SCRUM (スクラム)

2003 技術的負債

2004 エクストリーム・プログラミング(第2版) (XP)

2007 The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method (スクラム)

:
:
:

2018 メテオフォール型開発 - 実践ゲーム製作メモ帳2

2019 スケールドメテオフォール開発 - hogepiyohoo’s blog

アジャイル/スクラム、ウォーターフォール、メテオフォール

本題

「技術的負債」とは何か。原典とその対応策を探る－ Publickey ★☆☆
- 技術的負債 ★★☆
技術的負債の「会計的」性質 - Ryohei Tsuda - Medium ★☆☆
技術的負債が紛らわしいので改善対象となる設計不備に名前をつけたい - Tbpgr Blog ★★★
- 技術的負債の四象限 ★☆☆
- 荒ぶる四天王と『完了』の定義 ―アジャイル開発と品質― | Qbook+ ★★☆
  - プロジェクト目標マネジメント（ＱＣＤＳのＳ） / PMstyleコラム ★☆☆
    - QCDとは？PMBOKで覚えておきたい生産管理の3評価指標(QCD)を分かりやすく解説！ | eploth ★☆☆
      - プロジェクトマネジメント - Wikibooks ★☆☆
        
        弊社 @mako2kano 先生に聞けば詳しく教えてくれる(はず)
    - プロジェクトの三角形 - Project ☆☆☆
      - 鉄のトライアングル ☆☆☆
    - プロジェクト・インテグレーション・マネジメントと「鉄の三角形」 : タイム・コンサルタントの日誌から ★☆☆
      - わたしはなぜ、「プロジェクト管理」という言葉を使わないのか : タイム・コンサルタントの日誌から ★★★
        
        マネジメント（management）
        
        コントロール（control）
        
        アドミニストレーション（administration）
        
        新任リーダー学・超入門(2)　マネジメントとリーダーシップというコトバに気をつけよう！ : タイム・コンサルタントの日誌から ★★★
        
        Google re:Work - マネージャー ★★★
    - プロジェクトの制約条件とアジャイル – ライトパスのブログ ★★☆
      - 'アジャイルの三角形'によるアジャイルのパフォーマンス測定 ★★☆
    - Prince2 Agile プロジェクト六角形でアジャイル・トラレンスがわかる – プロダクト・マネジメントの要諦 The Rules of the Game of Product Management ★☆☆
技術的負債の中身｜wadap｜note ★★★
技術的負債の上手な積み上げ方・返し方 - ログミーTech ★★☆
技術的負債を調査する10のポイント（翻訳） ★☆☆
スピード優先の開発で溜まった技術的負債の返済計画（サーバーサイド編） - dely engineering blog ★☆☆
技術的負債を抱えた状態で技術者がすべきこと - sandbox ★☆☆
技術的負債としての「オブジェクト指向」 — しっぽのさきっちょ | text.Baldanders.info ★★☆
Webサービスが当たると、いずれ返済できない技術的負債に突入する由々しき構造について | F's Garage ★★☆
- ロードマップ指向とエコシステム指向 - アンカテ ★☆☆
既存システムの運用・保守に割かれてしまう資金・人材ーDXレポート | IoT NEWS ☆☆☆
デジタルガバナンス・コードと外部の客観的な評価制度～企業の格付において国内企業に求められること～ | NTTデータ経営研究所 ☆☆☆

キーワードをもとにGoogle先生に訊いてみた結果(の一部)。

星は個人的なオススメ度(の様なもの)。

個人的には本題から横道に逸れた管理についての気付きが思い掛けない成果でした。

やはり英語は難しい・・・。

皆さんはキチンと区別して管理を取り扱えていますか？

私は今の今までアヤフヤで勝手な解釈で使ってました。

マネージャーは本来マネジメントする人なんですよね。

我が身を振り返ってみると、コントロール主体になってしまっていたんじゃないかなぁと猛省。

(※現在、ボッチのため過去を振り返ってみました)

あと、荒ぶる四天王ってキーワードは上手いネーミングだなって思いました。

どの王が先鋒でしょうか・・・最弱。

メテオフォールの神とかもそうですが、単純な擬人化じゃないところがイイですよね。

アジャイルとウォーターフォールはスコープの扱いが真逆ってところが面白いですよね〜

現実のウォーターフォールは殆どスコープ調整が発生するものだという認識(経験則)です。

予算(Cost)、納品(Delivery)の調整ってハードル高い事が多い気がしますが、とすると残るは・・・品質しかないですよね！

これが俗に言う技術的負債？？？

技術的負債の認識と立ち向かい続ける覚悟

現状を認識する
関係者各位に認識してもらう
計画する
改善し続ける

1. 現状を認識する

コード自体だけでなく、プロセスも大きく関係するのでしっかりと把握。

2. 関係者各位に認識してもらう

このハードルが高い気がする。

これだけ世間に広まっていれば、すんなり通じる気がするのですが・・・

この辺から上記己を知るに繋がりました。

質とスピード / Quality and Speed - Speaker Deck

これくらい分かりやすくまとまった資料を作れてプレゼン出来れば、可能？

3. 計画する

とりあえずやってみる事も大事。

ただし、闇雲に向き合っても↓に影響があるため、プランニングも大事。

4. 改善し続ける

ここ重要。

昔の人はいいこと仰る。

『継続は力なり』ってね。

話は変わって

ピープルウェア

トム・デマルコ『ピープルウェア(Peopleware)』の要約

1989年という私の業界デビューよりずっと昔に出版されたものですが、今更ながら読んでいます。(※読んでない方はまずは上記サイトがオススメ)

日本人の生産性が〜と言われる昨今ですが、弊社だけでなく多くのオフィス環境は様々な制約があって理想とは程遠い状況なのではないでしょうか。

そんな中、おそらく少なくはない方々が思い付いている事とは思いますが AirPods Pro 等アクティブノイズキャンセリングを導入するのが”吉”なのではないだろうか。

『話しかけにくい』『無視される』等の弊害が阻害要因として考えられますが、例えばチャットツールのステータスのように周りの人達がわかるようなサインを掲げておけばよい(帽子を被るでも良いと思う)し、チャットツールの通知はONにしておく等のルールを合わせて導入すれば、本に書いてあるような劇的な効果は上がらなくとも費用対効果はプラスになるのではないだろうか。

これはとりあえず個人的に検証してみたいと思っているが、先ずは先立つ・・・ゲフンゲフン

言い訳

Qiita Advent Calendarという事で、企業・学校・団体として投稿内容を吟味して・・・等いらぬ事を考え過ぎて書くことが全然決まらなかったんです。
自分で勝手にハードル上げすぎ。
初歩的なミスです。ごめんなさい。
結果も、このような駄文となってしまい申し訳もございません・・・

・個人的なメモ
モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました - Graat（グラーツ）
DevOps 技術: トランクベース開発 | DevOps | Google Cloud
Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita
　　Feature Toggles (aka Feature Flags)
　
GE幹部を「ウン」と言わせる資料の作り方：日経ビジネス電子版
　
SIerとWeb系の違いを知らずにエンジニアになると100％後悔します｜未経験から独学でエンジニアを目指す人のためのブログ
【ＩＴ業界地図？】WebとかSIとか自社開発とかSESとか、言ってることわけわかんねえんだよ！ | BAMV-LLC-blog
　　ＩＴ人材が不足というウソとSE35歳定年説の謎 | BAMV-LLC-blog

`レガシーコードからの脱却`をクリスマスプレゼントにしてみてはいかが？

逆 フラゲ 申し訳ありません。 フライング土下座