逆 フラゲ 申し訳ありません。 フライング土下座
はじめに(まとめです)
レガシーコードからの脱却
を Google先生に訊いてみる と沢山の感想が在ります。
『Qiitaユーザーが選ぶ、2019年に読んで良かった技術書』アンケート結果発表 - Qiita Zine にも!
個人的にもオススメしたい一冊です。
特に、エライ人に読んでほしいです!
金銭的・時間的に余裕のない方も、上記をはじめ他の皆さんの感想を読んでみると良いと思います。
が、読了してみて思った事(あるある・納得感だけじゃなく、モヤモヤ感)が日々(の出来事を見聞きする度)どんどん積み上がって来ているため、お目汚しとは思いますが 随筆?エッセイ? チラ裏を書き捨てさせていだだきます。
ここから先は そっ閉じ 推奨!
そもそも
レガシーコードとは
世の中的には様々な定義がありますが、レガシーコードからの脱却
には
レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。
と書いてあります。
- バグを多く含み
- 壊れやすく
- 拡張が難しい
バグを多く含んでいる
× 本番で(一見)正常に稼働しているソフトウェアは、十分な(手動)テストもしているのでバグは(あるかも知れないが多くは)ない"はず"
壊れやすい
× 本番で(一見)正常に稼働しているソフトウェアは、最善の設計・コーディングをしているので壊れやすくはない"はず"
拡張が難しい
× 本番で(一見)正常に稼働しているソフトウェアは、メジャーな言語・フレームワーク・設計を(利用)しているので拡張は難しくない"はず"
表現は異なるかも知れませんが、概ね『否定(NO)』的な認識が大多数ではないでしょうか。
いやいや、そんなことはない。私(我々)は常に危機感を持っているよって方が居たらごめんなさい。
個人的な印象としてはこんな感じなんです。
己を知る
個人的にも苦手意識しかないのですが、やはり己を知る
のは重要なのではないでしょうか。
自分への戒めも含めて・・・
技術的負債
蛇足
初っ端から蛇足なんですが、技術的負債 というキーワードが最近とみに見聞きするのではないでしょうか。バズワードってやつですかね。
改めて Wiki を見てみたところ、なぜか関連項目の方が気になってしまいました。自分は Lisp に疎いからなのか、大きな泥だんご は初見でした。
パッと見、日本語訳も無さそうなので、その辺もあるのかな?
結構昔のキーワードなんですが、廃れるより寧ろ流行っているのでは?と思わせる内容です。
原文(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 (スクラム)
:
:
:
2019 スケールドメテオフォール開発 - hogepiyohoo’s blog
アジャイル/スクラム、ウォーターフォール、メテオフォール
本題
-
「技術的負債」とは何か。原典とその対応策を探る - Publickey ★☆☆
- 技術的負債 ★★☆
-
技術的負債が紛らわしいので改善対象となる設計不備に名前をつけたい - Tbpgr Blog ★★★
- 技術的負債の四象限 ★☆☆
-
荒ぶる四天王と『完了』の定義 ―アジャイル開発と品質― | Qbook+ ★★☆
-
プロジェクト目標マネジメント(QCDSのS) / PMstyleコラム ★☆☆
-
QCDとは?PMBOKで覚えておきたい生産管理の3評価指標(QCD)を分かりやすく解説! | eploth ★☆☆
-
プロジェクトマネジメント - Wikibooks ★☆☆
- 弊社 @mako2kano 先生に聞けば詳しく教えてくれる(はず)
-
プロジェクトマネジメント - Wikibooks ★☆☆
-
プロジェクトの三角形 - Project ☆☆☆
- 鉄のトライアングル ☆☆☆
-
プロジェクト・インテグレーション・マネジメントと「鉄の三角形」 : タイム・コンサルタントの日誌から ★☆☆
-
わたしはなぜ、「プロジェクト管理」という言葉を使わないのか : タイム・コンサルタントの日誌から ★★★
- マネジメント(management)
- コントロール(control)
- アドミニストレーション(administration)
- 新任リーダー学・超入門(2) マネジメントとリーダーシップというコトバに気をつけよう! : タイム・コンサルタントの日誌から ★★★
-
わたしはなぜ、「プロジェクト管理」という言葉を使わないのか : タイム・コンサルタントの日誌から ★★★
- プロジェクトの制約条件とアジャイル – ライトパスのブログ ★★☆
- Prince2 Agile プロジェクト六角形でアジャイル・トラレンスがわかる – プロダクト・マネジメントの要諦 The Rules of the Game of Product Management ★☆☆
-
QCDとは?PMBOKで覚えておきたい生産管理の3評価指標(QCD)を分かりやすく解説! | eploth ★☆☆
-
プロジェクト目標マネジメント(QCDSのS) / PMstyleコラム ★☆☆
-
スピード優先の開発で溜まった技術的負債の返済計画(サーバーサイド編) - dely engineering blog ★☆☆
-
デジタルガバナンス・コードと外部の客観的な評価制度 ~企業の格付において国内企業に求められること~ | NTTデータ経営研究所 ☆☆☆
キーワードをもとにGoogle先生に訊いてみた結果(の一部)。
星は個人的なオススメ度(の様なもの)。
個人的には本題から横道に逸れた管理
についての気付きが思い掛けない成果でした。
やはり英語は難しい・・・。
皆さんはキチンと区別して管理
を取り扱えていますか?
私は今の今までアヤフヤで勝手な解釈で使ってました。
マネージャーは本来マネジメントする人なんですよね。
我が身を振り返ってみると、コントロール主体になってしまっていたんじゃないかなぁと猛省。
(※現在、ボッチのため過去を振り返ってみました)
あと、荒ぶる四天王
ってキーワードは上手いネーミングだなって思いました。
どの王が先鋒でしょうか・・・最弱。
メテオフォールの神
とかもそうですが、単純な擬人化じゃないところがイイですよね。
アジャイルとウォーターフォールはスコープ
の扱いが真逆ってところが面白いですよね〜
現実のウォーターフォールは殆どスコープ調整が発生するものだという認識(経験則)です。
予算(Cost)、納品(Delivery)の調整ってハードル高い事が多い気がしますが、とすると残るは・・・品質しかないですよね!
これが俗に言う技術的負債
???
技術的負債の認識と立ち向かい続ける覚悟
- 現状を認識する
- 関係者各位に認識してもらう
- 計画する
- 改善し続ける
1. 現状を認識する
コード自体だけでなく、プロセスも大きく関係するのでしっかりと把握。
2. 関係者各位に認識してもらう
このハードルが高い気がする。
これだけ世間に広まっていれば、すんなり通じる気がするのですが・・・
この辺から上記己を知る
に繋がりました。
質とスピード / Quality and Speed - Speaker Deck
これくらい分かりやすくまとまった資料を作れてプレゼン出来れば、可能?
3. 計画する
とりあえずやってみる事も大事。
ただし、闇雲に向き合っても↓に影響があるため、プランニングも大事。
4. 改善し続ける
ここ重要。
昔の人はいいこと仰る。
『継続は力なり』ってね。
話は変わって
ピープルウェア
1989年という私の業界デビューよりずっと昔に出版されたものですが、今更ながら読んでいます。(※読んでない方はまずは上記サイトがオススメ)
日本人の生産性が〜と言われる昨今ですが、弊社だけでなく多くのオフィス環境は様々な制約があって理想とは程遠い状況なのではないでしょうか。
そんな中、おそらく少なくはない方々が思い付いている事とは思いますが AirPods Pro 等アクティブノイズキャンセリングを導入するのが”吉”なのではないだろうか。
『話しかけにくい』『無視される』等の弊害が阻害要因として考えられますが、例えばチャットツールのステータスのように周りの人達がわかるようなサイン
を掲げておけばよい(帽子を被るでも良いと思う)し、チャットツールの通知はONにしておく等のルールを合わせて導入すれば、本に書いてあるような劇的な効果は上がらなくとも費用対効果はプラスになるのではないだろうか。
これはとりあえず個人的に検証してみたいと思っているが、先ずは先立つ・・・ゲフンゲフン
言い訳
Qiita Advent Calendarという事で、企業・学校・団体として投稿内容を吟味して・・・等いらぬ事を考え過ぎて書くことが全然決まらなかったんです。
自分で勝手にハードル上げすぎ。
初歩的なミスです。ごめんなさい。
結果も、このような駄文となってしまい申し訳もございません・・・