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

SQuBOKの中で一番好きな箇所

はじめに

SQuBOK V2読破会アドベントカレンダー12日目のブログエントリーです。 11日目は 「不具合管理」を見てみる | 四方山話 でした。

www.adventar.org

SQuBOKというのはこれです。ソフトウェア品質知識体系ガイド。 Google Books で一部を読むことができます。

books.google.co.jp

熱い箇所:ソフトウェアの品質マネジメントの特徴

上のGoogle Booksを開いてみるとわかりますが、SQuBOKはBOKというだけあって、突っ込んだ記述や個々の著者の主張は含まれていません。 しかし、p48-50にかけて書かれている "1.3 KA:ソフトウェア品質マネジメントの特徴" では、BOKらしからぬ強い主張が含まれた長めの文章があります。

f:id:masskaneko:20151212232938j:plain

要約すると以下のようになります。

  • ハードウェア開発で培われた品質マネジメントの手法をソフトウェア開発に適用することはできない。
  • ソフトウェア開発のほとんどは知的作業であり、技術者のモチベーションがソフトウェアの品質と生産性に大きく関係する。
  • ソフトウェアはチームで開発するため、チームワーク・リーダーシップ・コミュニケーションが重要である。
  • 製品とプロセスの質は互いに依存するため、両者の質の評価と改善を融合させて進めなくてはならない。
  • 継続的な品質改善のためには「全員参加」「品質第一」「改善」「次工程はお客様」「5ゲン主義」「品質の作りこみ」という品質管理の基本原則の理解と実践が必要。

ハードウェア開発とは違う

"ハードウェア開発とは違う" という文脈からソフトウェア品質マネジメントの特徴を説明しているのがSQuBOKらしいと思いました。 SQuBOK策定の動機の一つとして日本の製造業を中心として発展した品質向上の取り組みを形式知化することがあるそうですが、 それが1.3KAの文章にも影響しているのかもしれませんね。

ソフトウェアはハードウェアに比べて設計の自由度が高いこと、再利用可能なコンポーネントの設計が難しいこと、測定すべき特性とは何なのかがはっきりしていないこと、 変更に対する影響の特定が難しいこと、故障モードのパターン化が難しいことなど、様々な違いが述べられています。 ハードウェア開発の経験はあるがソフトウェア開発の経験が無い方に対して、 何が違うのかを説明するために非常に参考になる文章だと思います。 電機メーカーなら技術者全員に基礎教育としてこの文章を読んでもらうのもありではないでしょうか。

SQuBOKには書いてありませんが、実装 という用語から想像する知的作業か否かのイメージはハードウェア開発とソフトウェア開発で大きく異なることには注意が必要だと思います。 コーディングは実装と訳されることが多いですが、ハードウェア開発者にとっての実装工程は "基板にパターンをひいて部品を載せる工程" なので、 設計が終わった後の工程であり、機械化が可能であり、知的作業ではないと捉えられてしまう懸念があります。 そうした誤解があるのであれば、コーディングは設計であり、工夫の余地があり、機械化ができるのではごく一部であり、知的作業であることを説いて理解してもらうことが重要ではないでしょうか。

知的作業の質にはモチベーションが大きく関係する

1.3KAではハードウェア開発との違いから始まって知的作業について触れられています。 私が一番熱いと思う部分を引用します。

人間の知的作業の質には、モチベーションが大きく関係する。モチベーションの高い技術者が開発すると、品質も生産性も向上する。 逆にモチベーションの低い技術者が開発すると、大量の障害を作りこんだり深刻なプロジェクトトラブルを引き起こしたりするため、 ともすると品質や生産性がマイナスになることすらある。 技術者のモチベーションを向上させるには、やりがいを感じ、快適と感じられる環境が必要である。 またソフトウェア開発はチームで開発するため、個人のモチベーションだけでなく、チームワークやリーダーシップ、 及びそれらを支えるコミュニケーションも重視しなくてはならない。

BOKでここまで書くか!と感じた文です。ただただ同意するばかりです。 ソフトウェアの品質マネジメントをやろうと言うのなら… 快適な開発ができるマシンとネットワーク環境を用意しなさい、オフィス環境を整えなさい、個々人の貢献を可視化する仕組みを作りなさい、 コラボレーションツールやチャットツールを使いなさい、朝会や振り返り会などで対話する機会を作りなさい、 モチベーションが下がってしまったメンバーをケアしなさい、ということなんですね。

先日参加した JohoKaigi - 情報会議 にも通じるところがあります。 ソフトウェア品質マネジメントの観点で情報共有を語るのも一興かなと思いました。 WikiやQiita:TeamやSlackなどのツールがソフトウェア品質に与える影響に関する文献があってSQuBOKのトピックとして載っていたらなあ。 でも無さそうだなぁ。え、書け?

おわりに

この熱いページ(48-50)はGoogle Bookでも読めるので、SQuBOKを持ってない方も読んでみるといいと思います。 ソフトウェア開発経験があんまり無い電気/機構エンジニアとか経営層の方が読むといいんじゃないですかね。

次、13日目は吉田東京さんです。よろしくー