読者です 読者をやめる 読者になる 読者になる

MyEnigma

とあるエンジニアのブログです。#Robotics #Programing #C++ #Python #MATLAB #Vim #Mathematics #Book #Movie #Traveling #Mac #iPhone

1.分別のある行動 Seb Rose:『プログラマが知るべき97のこと』

以下の記事は,オライリージャパン社から出版された

プログラマが知るべき97のこと』

の中から1つのエッセイを選び,

そのエッセイを,クリエイティブコモンズ3.0の条件の元で転載したものです.

Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0

もし,他のエッセイを読みたい場合には,

記事末のリンクを辿るか,

以下のリンク先のTwitterアカウントのつぶやきからお探し下さい.

Twitter Account: 97 Things Bot



01 分別ある行動 セブ・ローズ(Seb Rose)

何をするにせよ,常に分別を忘れてはならない.



自分のしたことがどうゆう結果を生むか,良く考えるのだ.



(作者不明)

どんなに余裕あるように見えたスケジュールでも,

実際に作業を始めれば,

必ずどこかで追いつめられた状態になるものです.

そして,同じ事を「正しくやる方法」と「手早くやる方法」があれば,

後者の方が魅力的に見えてしまうことはよくあります.

後者を選べば,後で修正が必要になるとわかっていても,

その時は「必ず,すぐに修正しよう」と自分に誓うでしょう.

プロジェクトチームのメンバーや,顧客などに修正を約束することもあります.

約束した時点ではもちろん,絶対に約束を守るつもりではいます.

次のイテレーションなどが修正のチャンスなのですが,

実際にイテレーションが始めると,

また新たな問題が起きて,そちらに注力してしまい,

結局,修正が不可能になってしまうことも多いのです.

このように先送りされていく修正作業のことを

技術的負債(Technical debt)などと

呼ぶことがあります.

当然,好ましいものではありません.

Marthin Fowlerは特に,

今述べたような技術的負債のことを

故意の技術負債と呼んでおり,

故意ではない,

不注意から発生する技術的負債

とは区別すべきだと言っています.



技術的負債は,

その名の通り,

借金のようなものです.

短期的には,利益になりますが,

完済するまで利息を払い続けなくてはなりません.

早くできるからと手を抜いてコードを書くと,

機能追加やコードのリファクタリングが難しくなります.

新たな不具合を生む温床となり,

テストケースの価値を損なう原因にもなります.

長く放置するほど害は大きくなるでしょう.

ようやく元々の問題を解決したら,

その問題が原因で生まれた新たな問題が山積みになっていた,

ということにもなりかねません.

問題が放置されていたために,

正しい設計の選択ができないこともあります.

リファクタリングや修正の難しいコードを

仕方なく次々と書いてしまうこともあるでしょう.

実のところ,

事態が極端に悪化してしまい,

もうその他にどうしようもない状態に陥って初めて,

元々の問題の修正に取り組み始める,

そんなことが多いのです.

その頃には,

修正は極めて難しくなっています.

修正しようにも膨大な時間がかかるため,

あるいはリスクが高すぎるため,

手の打ちようがないこともよくあることなのです.



納期に間に合わせるため,

ほんの少しの機能追加のため,

どうしても技術的負債が生じてしまう,

ということがあります.

そうならないように

努力しなくてはならないのですが,

状況によって,

どうしてもそうせざる負えないことがあります.

その場合は,

あえて技術的負債を抱える道をとる以外ないでしょう.

しかし,(ここからが何よりも大事です)

技術的負債の存在は常に忘れないようにし,

できるだけ早く返済すべきです.

さもなければ,

事態は急速に悪化していきます.

やむなく妥協する決断を下した時には,

すぐにタスクカードに書く,

問題管理システムへの登録をする,

などの対処をし,

技術的負債の存在が忘れられないようにしておくべきなのです.



次のイテレーションでの返済を

スケジュールに組み込むことができれば,

コストは最小限に抑えられます.

負債を放置すれば,

利息が発生します.

この利息を常にトラッキングし,

コストを明確にする必要があります.

そうすれば,

技術的負債が事業価値にどれほど大きな影響を及ぼすかが意識され,

返済のための作業の優先順位が自然に上がることになるはずです.

利息の計算,トラッキングをどうするかは,

プロジェクト毎に違うでしょうが,

ラッキングをしなくてはならない,ということだけは,

どのプロジェクトでも同じです.



技術的負債はできるだけ早く返済する.

分別のある人ならそうするはずです.



■著者データ

[セブ・ローズ (Seb Rose)]

エディンバラのRational DOORSチームで,

首席ソフトウェアエンジニアとして働く.

初めてプログラミングの仕事をしたのは1980年で,

その時はApple lleを使い,

BASICで不動産業者や電話勧誘業者のためのアプリケーションを書いていた.

1987年にエディンバラ大学を卒業後はREKURSIVプロジェクトで働き,

その後フリーのコントラクターになった.

現在は主にアジャイルプラクティスや,

レガシーコードの改善などに関心を持っている.