ソフトウェアの開発をしていくと、どれだけソースコードを修正する権限があるかどうかで、開発しやすさが変わってくる。
他にも仕事がうまくいくようにするには、判断の修正が必要になることが多い。
開発コードの修正
リファクタリング重要 よい名前をつけること
・変数名・クラス名・メソッド名が、実際の内容として食い違っているときに、適切な名前に変更することができること。
名前が不適切だと、トラブルの原因になる。名前の付け間違いの場合もあるし、実装が変化したのに、名前がそのままになって、食い違いを生じたこともある。どちらの場合も名前と実装が食い違っていることがトラブルの問題となす。
リファクタリング重要 メンテナンスしやすいコードすることが大切
・機能の追加をしていくと、いつの間にかコードの複雑さが高まっていく。コードの複雑さが高まり過ぎるとメンテナンスがやっかいになっていく。それを防止するには、機能を追加しようとする前に、既存のコードの段階でリファクタリングをすることだ。
そんなことは、qiitaの記事を読んでいる人には今更すぎる話だろう。
しかし、問題なのは、そのようなリファクタリングが機能していない開発現場だ。
リファクタリングが機能していない開発現場の特徴
- git以前のソースコードのバージョン管理をしている。（あるいは、バージョン管理ツールを使っていない）
- CircleCI などのツールを使っていない。
- リファクタリングに適したエディタ・もしくは統合環境を使っていない。
リファクタリングが機能していない開発現場の開発スタイル
- 仕様書があって、それにしたがってコーディングすればいいだけになっているという神話があって開発をしている。実際には、あいまいもことした状況から実装を作り上げていって、仕様書はコーディング・テストが完了してから作られる。
- 最近は、ヘッダファイルを元に仕様書を作成することも増えてきている。
- でも、神話としては「仕様書があってそれに基づいて開発している」になっている。
- 一連の開発プロジェクトの中で、担当している作業の範囲が狭く、担当している範囲を超えてのチーム間連携は少ない。
- 適切に変わり続けることの重要性を理解していない。
- 「一度作ったモジュールのインターフェースを変えていけない」とされてしまっている。それが適切な実装のインタフェースかどうか検証されていなくても。
- 時として関数の引数には、将来使うかもしなれい引数が前もって含まれているということが起こる。
本当によい実装のしかたを、最初から設計・実装することはできない。
結論：リファクタリングするしかない。
何から開発するべきか、開発の優先順序の修正
修正する必要があるのは、ソースコードだけではない。
何から開発するのがよいのかという開発の優先順序も修正が必要だ。
ただ、従来型の企業の場合、「それはお前の口に出すことじゃない」とされてしまう。開発の優先順序を定める権限を持っている人が適切な判断をできる場合には、問題は少ない。しかし、どんなに適切な判断ができる人でも、１年間に開発する内容を正確に予測し続けることは困難だ。なぜなら１年間も経つと、外部の状況がすっかり変わってしまうのです。使用する前提のハードウェア、ソフトウエアの状況が変わってきます。競合の行動も変わってきます。そのため、年度の冒頭に立てた計画は必ず修正する必要があるのです。
その結果、何から開発する必要があるのか、優先順序を修正する必要があるのだ。
しかも、実際に開発を進めて見えてきた課題をもとに、開発計画を修正する必要はあるのです。
では、どのように修正したら、開発が成功しやすいだろうか。
よく課題を知っている人の考えを反映させることだろう。
従来型の組織の場合、担当部署のリーダーがそのためのマネジメントをすべて行う。その中で、チームの他のメンバーの声をきくかどうかは、リーダーしだいだ。
成功させるには、開発の優先順序をチーム全体で修正できることだと私は思う。
結論:開発の優先順序を修正することのできる組織運営が大事。スクラムという開発スタイルが大事になってくる。
判断の間違いを組織として修正できるか
人は判断の間違いをするものである。
組織もそのような判断間違いをする人の集まりである。
だから、組織にも判断間違いはつきものだ。
判断の間違いをしてしまうことは、防ぎようがない。
でも問題は、判断の間違いを修正して、同じ間違いを繰り返さないのか、間違えていないふりをして、同じ間違いを繰り返すかどうかだ。
避けられる間違いを繰り返すことは傷口を大きくする
間違えていないふりをすると、組織は嘘をつく。
残念な事例： 判断の修正をしないことが傷口を大きくしてしまう
ある段階での判断が、その後の状況の進展で今なら違う判断にたどりつく状況になる。しかし、組織は（正確には組織を構成する人員は）、その組織で行なった判断が間違いであったと認めることを嫌がる。そのため、判断を訂正せずに、時間を無駄にしてしまう。
そのために、傷口をいたづらに大きくしてしまう。企業での事業の場合、各部署で用いる費用の調整も重要だ。適切な判断がなされれば、成功の確率も上がるが、そうでなければ失敗しやすくなる。しかし、そのような判断が間違っていることに対して修正がきく組織かどうかだ。
組織の一員として働くときには、君が何を主張しても、最後は組織の判断に従わなくてはならない。だから、判断の間違いを修正できない組織に属してしまったら、君の能力は活かせなくなる。
所属する場所を選べる状況にいるのなら、君がこれから行こうとしている組織は、判断を間違えたときに修正することができている組織かどうか、確かめてみよう。
事業を成功させるために、変化し続けることができる組織であるかどうか
段階によって、必要な作業は変わっていく。
事業を成功させるために必要な作業は、そのつど変化している。開発の初期の段階、製品レベルに近づいてきたとき、出荷後の初期の立ち上げ。それぞれの状況で事業を成功させるために必要なものは変わっていく。当然、開発初期の段階の組織構成・人員構成では、その後の段階を乗り越えていくことができない。同じ一人の人員がこなしていかくてはならない作業の内容も変わっていく。そのような変化をし続けることができる組織であるかどうか。
硬直化した組織の場合：
組織構成が固定化してしまっていて、今必要な分野に人を異動させることもできない。必要性がほとんどなくなった部署も、管理職のために継続し続ける。そして、組織が変わるのは、その事業全体がだめになって、後は、事業の廃止、事業の売却になることが決まった段階ということがある。
事業展開の前提条件が間違っている可能性を考慮して修正できるか
すべきだった判断の例：相手の言い値でものを買ってはならない。
例：日立によるHDD事業の買収、東芝によるWH社の原発事業の買収
これらは、売却元の企業がやっかいものを上手に日本企業に押し付けて上手に売り抜けた例である。
このようなことを許してしまった日本企業は、相手の状況について十分に調査していない愚かな行為をしてしまったと言えるだろう。かつての名門の事業を（名門と呼ぶにはふさわしくない状況になっていることを理解しないまま）事業の買収に踏み切ってしまっている。おそらくは、その事業の買収を手柄だと主張する経営陣に対し、「今のその会社のその事業はそれだけの価値がない」という声を社内で上げることができなかったのだろう。
これらも、この買収を行なってしまった時点で、「詰んでいる」のであって、もはや現場の技術者ではどうすることもできない。