実践ソフトウェアエンジニアリング 第６章の感想
何回かに分けて、実践ソフトウェアエンジニアリングを読んだ感想を書いていきます。 素人感想、失笑してやってください。
まず最初は第６章「プラクティスの指針となる原則」について。ソフトウェアエンジニアリングにおける一般的な原則と概念を解説してくれています。原理原則から教えてくれる会社はそう多くないと思っているので、関連のない大学からこの世界に入った人には初見のものも多いのではと思いました。
コア原則
プロセスの指針となる原則
採用したプロセスモデルに関わらず取り入れられるプロセス原則が８つ。
ここに書いてあることは、悲しいぐらいにできていない。成果物には無駄が多いし、経済的な効果を忘れ目の前の業務に追われている。終了条件は曖昧で、変更の対応はいつも場当たり的である。
最初から意気消沈してしまうのだけど、これから転職しようというタイミングでこの原則を知れたのはとても良かった。転職先がどのような状況であっても、このプロセスの指針となる原則を頭に置いて対応したい。特に第８原則の「他者にとって価値のある成果を生み出せ」は常に頭に置いておくべきだ。後工程はお客様。
プラクティスの指針となる原則
ソフトウェアエンジニアリングの基礎とも言える原則８つ。
めちゃくちゃ耳が痛い。このページをお渡ししたい人がたくさんいる。特に「分割統治」と「抽象化」。ソフトウェア開発に限らず大きな問題は縦横に因数分解することで解決しやすくなるし、そのためには問題を目に見えるものだけ個別具体的に捉えていてはいけない。
久しぶりに細谷功さんの具体・抽象トレーニングを読もうと頭に浮かんだ。
私は開発に直接関わるポジションではなく品質マネジメントや教育がメインなのだけれど、業務が現場に近いときはどんどん思考パターンが”具体”に流れていくと感じている。個別具体的な事案で説明しないと話が進まないからだ。現場のメンバーの抽象化力を上げるためにも、自分が意識して抽象→具体→抽象、の行ったり来たりをして伝えていかないとなと思う。
フレームワークアクティビティの指針となる原則
コミュニケーションの原則
顧客やチーム内、ステークホルダとのコミュニケーションでの１０原則。
ここはリーダー昇進研修で配布したらいいんじゃないか（）
とにかく無駄な会議が多すぎるのだ。アジェンダが出てこなかったり、ファシリテーターを務められる人がおらず特定の人しか発しなかったり話題が飛び散ったり。話題を飛び散らせてしまうのは主に私なのですが ←
「（第２原則）コミュニケーションの前に準備する」ができていない例が多い。事前の情報共有や会議のゴールの設定をしてこない。「ちょっと打ち合わせいいかな」で呼ばれ、気づけば会議や打ち合わせだらけになっているチームもあると聞く。
個人的には第１原則の「傾聴する」が非常に苦手。とにかく先に進めたいがゆえに、「こういうことですかね」とまとめに入ったり相手の発言を自己解釈して強引に先に進めてしまうことが多い。気をつけないといけないなと思っている点。
計画の原則
計画・管理面で適用できる１０原則。
自慢ではないが計画自体は得意だ。とにかく初期のハイレベル計画が早い。ここに書いてあることも、８原則までは概ね頭に置いてできていると自負する。
しかし追跡と変更と調整に弱いんだよね・・・。
それに、最後に書いてある「チームメンバーに計画アクティビティに参加してもらう」っていうことができていない。絶対その方がいいことは分かっているんだけど、最初から様々な抽象度の話になりまとまらないのが目に見えているのでもどかしい。・・でもそれも進め方次第だよな。。。身につけたいスキルではある。まずはハイレベルの段階でちゃんとメンバーに話をすることか。
モデリングの原則
要求モデリング、設計モデリング作成に係る１０原則。
自分が関わっているのは主に要求モデル。この１０原則全て耳が痛い。
あくまでも「（第３原則）ソフトウェアやソフトウェアの解決する問題を簡潔に説明するモデルを作ることに努め」ていたはずなのに、「ここは正確に表していない」とか「ここはこっちの分岐もある」とか細部が気になりだして、簡潔には程遠いアクティビティ図が出来上がってしまったりする。
「（第７原則）完全なモデルのことは忘れて役に立つモデルを作る」を付箋でモニターに貼っとこうかしら・・。
構築の原則
コーディングに係る１３原則と、テストに係る９原則。
コーディングはしてないのでテストの方。ここだけで１記事書けそうなので まずはファーストインプレッションだけ。
「（第１原則）すべてのテストは顧客要求まで遡れるようでなければならない」。そもそもこの視点が抜けているかもしれないぞ？もちろんシステムテストについてはこの認識なのだけれど、一つ一つのコンポーネントまでその意識でテストできているだろうか。要求事項トレーサビリティマトリックスはそこまでの粒度で作っていない。他の会社ってどうなってるんだろう？
「（第４原則）テストは「小」から始めて「大」へと進むべきである」。これは常識だろうと思っていた。が、勉強会で伝えてみると目から鱗ですと言われることがままあり、驚いたことを覚えている。やはり原理原則は意外と教えられてきていないのだな。
「（第7原則）静的テストの技法は素晴らしい結果をもたらす」にある、”ソフトウェアの欠陥の85%は要件定義書、仕様書、ユーザーマニュアル等ドキュメントに起因する”は、技術レベルが低い場合にはもっと率が下がるっていうのを目にしている（苦笑）それでも、その技術レベルにあったドキュメンテーションや、ドキュメンテーションに変わる方法で開発者に要求や仕様を伝えられていないことが原因。
レビューの効果をあげる以前に、レビューをしていない、そもそもレビュー対象物（仕様書）がない、そんな現場をいくつも見てきたなあ。
デプロイの原則
出荷・サポート・フィードバックに係る５原則。
ここも耳が痛いな。サポートも操作マニュアルもエンドユーザ教育もトラブルシューティングも別の部署であるという体制の場合、「自分たちと関係ない」と思っている開発者は多かった。しかも、それらを担当している部署は開発部署とのコミュニケーションを諦めてしまっているのか、理解不十分なまま操作テキストが出来上がったりしている。
「（第5原則）バグを修正するのが先で出荷を後にしなければならない」は、もちろんもちろんそうなんだけど、どうにもこうにも稼働を遅らせることができず”条件付きリリース”なんて日常茶飯時。いつしかそれが当たり前になり、みんな麻痺して・・いやもうやめておきます（笑）
第6章の感想まとめ
一言で言うと「耳が痛い」。
一つ二つないがしろにしてるのがあるよね、とかいうレベルじゃなく、多くができていない。辛いのは、この原則を知らずにやってきましたというのではなくて、多くは知っていたし分かっている、のにできていないということ。納期優先で優先度を下げたり、今回はしょうがないよねって諦めたりしているうちに、いつのまにかそれが普通になってしまっている。
それぞれの原則は多くても１３原則にまとめられている。それぞれのロールに絞れば意識するのが難しい数ではない。しかし各メンバーがこれを読んで学び取るのは難しいだろう。チャーターにしたり方針書にしたりガイドラインにしたり勉強会にしたり、、、伝え方や浸透させ方を考えなくちゃな、と思いました。
６章を読んだ人と、感想や体験を交換したいものです。社内で読んでくれる人いないかなあ。
次は 第7章の感想を書きます。