20年、30年前の組込みソフトウェア開発では、ハードウェア、ソフトウェアの区別もなく、ソフトウェアはハードウェアを動かすためのシーケンス処理の記述でしかなかった。このころプログラムの規模は1000行にもなっておらず、試行錯誤でソフトウェアを作ってもランダムテストでバグを潰し切れた。開発の時間的な余裕もあったし、どちらかといえばソフトウェア開発は技術者の個人的な取り組みだった。
このようなソフトウェア開発のアプローチで成長した技術者が20年たってマネージャクラスになるとどうなるか。
<失敗や成功の体験を取り込んだり、体系化したことのないマネージャの特徴と思考>
- ソフトウェア規模が小さい頃の成功体験、失敗体験でしかマネージメントできない
- 分析してから設計しない
- 直せと言われてたら、開発の後工程でもすぐに直してしまう
- 要するに工程（プロセス）の概念がない
- ソフトウェアの検証は作り込んだ後のランダムテストでやるものだ
- 設計ドキュメント作りは余計な作業だ（設計ドキュメントを再利用したことがない）
- ソフトウェアの再利用は過去のソースコードの適当な部分をコピー＆ペーストすることだ
- 金を払っているのだからどんな問題でも協力会社の技術者が解決すべきだ
<組込みソフトプロジェクトでダメダメマネージャを生み出さない教育>
- 先人の成功体験、失敗体験が体系されたもの（ソフトウェア工学、自組織の体験）を教える
- 分析してから設計することを教える
- 開発の後工程での修正はコストがかかることを教える
- ソフトウェア開発の工程（プロセス）の概念とその必要性を教える
- ソフトウェアの検証に対する考え方と種別と効果について教える
- 設計ドキュメントはどの場面でどのように使うものか教える
- ソフトウェアの再利用戦略について教える
- ソフトウェア品質マネージメントにおける発注と検収について教える
こんな状態で組込みソフトウェアに対する要求が複雑化し、ソフトウェアの規模が大きくなってくると、末端のエンジニアの作業工数がかさんでくる。その工数増加の分布は開発が終盤になればなるほど大きくなる。ただ、製品をリリースしたあとも後始末の工数があるため、次期製品の開発が始まった時期でも前の製品の保守に時間を割いていたりする。その結果、余裕を持って分析設計が行う時間がとれない。だからまた次の開発の終盤で苦労する。ようするに悪循環の構図だ。（『組込みソフト開発悪循環の構図』参照のこと）
そんな悪循環の中で、技術者個人が一番痛い目に遭っていて何とかしたいと考えるのが、よかれと思って修正したところが、別の問題を起こしたり今まで動いていたところが動かなくなったりするケースだ。この問題は個人に閉じている問題であり、また、プロジェクト全体に迷惑をかける問題でもある。バグの修正でデグレードしてしまうのはエンジニア個人にとって痛いし、プロジェクトにも迷惑をかけるので精神的にも負担が増える。簡単に言えばこれをやると個人的に痛みを感じる。
一度やるとイヤな記憶に残るので次は同じ目に遭いたくないと考える。そうなると最初に考えるのが何かしでかしてしまったときは、うまくいった状態に確実に戻せるようにしておきたいという心理だ。ようするに、ソフトウェアの構成管理をきちんとやろうということだ。
だから、組織にソフトウェア構成管理の取り組みを導入しようとするとき、現場に反発されることはほとんどない。すでに自分たちが行っている構成管理の方法やツールを変えるのはいやがることがあるが、ソフトウェア構成管理を行うこと自体に反対することはない。
なぜなら、バグの修正でデグレードしてしまう痛い経験をエンジニア個人が必ず一回はやっているから、その痛みを解消できるのなら多少の不自由があっても我慢できるのだ。
そして、次に考えるのがなぜ変更したのか、どんな変更を加えたのかを管理・記録することだ。バグ票を記入したり、データベースに登録したりして変更を管理する。
開発の規模が大きくなると日々バグが発生するので、次々と発生するバグや対応状況を記憶しきれなくなる。何かに記録しておかなければ分からなくなってしまう。構成管理の次は変更管理に取り組む。
テスト技術は個人でも修得できる部分が多い。だから、組織的に取り組まなくても技術者個人で技術を習得せよという命令を出せるから､プロジェクトをマネージできていないプロジェクトマネージャ､リーダでも部下に指示できる。
マネージメントされているとは言えないプロジェクトが､構成管理や変更管理をまがりなりにもできるようになるとプロジェクトのマネージメント＝毎週進捗会議を行うことだと考えていたプロジェクトマネージャはプロジェクトがマネージメントされるようになったと思うかもしれない。
でも、構成管理と変更管理ができるようになっただけでは試行錯誤のアプローチから脱却できたとは言えない。分析してから設計しているわけではない。どんどん作り始めてしまって、問題があったら直していくアプローチは変わっていない。後戻りする頻度が減っただけであって､ソフトウェアシステム自体は開発の工程が進むにつれて複雑性を増していることが多い。
実は、ここからプロジェクトや技術者が一皮むけて一つ上のステージに上がれるようになるのがとてつもなく難しい。
ソフトウェア構成管理と変更管理はソフトウェア工学を取り込んでこなかったプロジェクトにも受け入れられやすい。それはなぜか。それは個人の痛みを軽減し、個人的な利益につながるからだ。組織やプロジェクトをマネージメントするという発想からきた取り組みではないんじゃないか。
プロジェクトみずからソフトウェア構成管理や変更管理をやるべきだと考え行動したのなら、それはプロジェクトマネージメントと言えるが、誰かから言われてルールだからという理由で構成管理や変更管理をやっているのなら、まだ、プロジェクトの利益のため、顧客満足を高めるためだと考えるまでには至っていないんじゃないかということだ。
失敗や成功の体験を取り込んだり、体系化したことのないマネージャのもとで、プロジェクトマネージメントを教科書どおりにやってもらうのはとても難しい。10年以上染みついてしまったスタイルをシフトするのは大変だ。
行き当たりばったりの修正に対して技術者個人やマネージャは特に問題だとは感じていないケースもある。だから、これまで実施していなかった構成管理や変更管理をやるようになっただけでも進歩していると考える。
10万行クラスのソフトウェアに対して開発の終盤で行き当たりばったりの修正を行ってしまうので，それらの修正によりサブシステム間の結合がどんどん強くなってしまう。
その結果，担当技術者でしか分からないという状況が発生するが，技術者個人にとってはその状況（自分にしかわからないことがあるという事実）は保身の材料になるため，積極的にその状況を解消したいとは思わない。そして，状況をよく知っている技術者が協力会社にいたりして，なにも考えずに新しい開発で協力会社を切ったりすると，この複雑になってしまっているソフトウェアシステムの状況が分からず同じ問題を繰り返す。
切られた協力会社にしてみれば「それ見たことか」といった感じになるので，ますます切れのよいサブシステムを構築することが困難になる。
<試行錯誤のアプローチから脱却できない個人、マネージャ、組織の心理>
技術者個人：構成管理，変更管理さえやっていれば，個人の損害は防げる。ソフトウェア資産を再利用することに技術者個人としてメリットは感じない。
マネージャ：構成管理，変更管理もまともにできていなかった。ソフトウェア資産の再利用までマネージメントするする余裕はない。
組織：なぜ，毎回毎回日程に間に合わない，予算をオーバーする，品質確保に苦労するのか理解できない。資産の再利用をなぜしないのか。
したがって，上記の3つのグループに対しては，提案の効果についてそれぞれ別々のメリットを示す必要があると思う。
<試行錯誤のアプローチから脱却できない個人、マネージャ、組織への提案の例>
技術者個人：アーキテクチャが明確になり，サブシステムの分離が進むと，設計の前段階での完成度が高まり，後工程でのバグが減る。
マネージャ：ソフトウェア資産を再利用できるようになると，最終工程でのバグが減り，ソフトウェアシステムの品質が高まる。
組織：ソフトウェア資産を再利用できるようになると，開発期間の終了が見えるようになり，ソフトウェア開発工数，デバッグ工数が減る。
成熟していない組織の最大の問題は直近の、また、直接的な利益のことしか考えられないということのように思う。長いレンジのスコープを持てないので、今日の問題の解決のことで頭がいっぱいになってしまい、明日につながるカイゼンのことに気が回らない。
自分はエンジニア個人の取り組みで組込みソフトウェアが作られてきた歴史や、責任と権限を明確にしなくても仕事ができてしまう日本人の特徴がこの状況を助長していると考えている。
0 件のコメント:
コメントを投稿