SQuBOKと人材育成
読者のみなさんメリークリスマス！
先日サンタクロースから私の息子のプレゼント配送を請け負ったのですが、
電話会議とか、この記事の更新に精を出してました。
先日サンタクロースから私の息子のプレゼント配送を請け負ったのですが、
電話会議とか、この記事の更新に精を出してました。
SQuBOKの認知度はいまひとつ？
今回、読破会ではSQuBOKを読み切りましたが、○○BOKで有名なものといえばプロジェクトマネジメントの知識体系であるPMBOKです。
私も、この業界に入って最初に知ったBOKはPMBOKでした。
仕事柄、PMBOKに絡んだプロジェクトマネジメント教育などはよく目にします。
SQuBOKはどうなんだろう？ということで、少しまとめます。
私も、この業界に入って最初に知ったBOKはPMBOKでした。
仕事柄、PMBOKに絡んだプロジェクトマネジメント教育などはよく目にします。
SQuBOKはどうなんだろう？ということで、少しまとめます。
| SQuBOK | PMBOK | |
| 関係する資格試験 | JCSQE | PMP |
| 受験資格 | 誰でもOK | かなり長い期間のPM経験が必要 |
| 対策セミナー | 少しある | たくさんある |
| 資格の維持 | 失効しない | 研修を受け続けないと失効する |
| 資格の実施団体 | 日本の団体 | 米国の団体 |
PMPはIT企業でも所持したい資格の一つとしてよく認知されています。自分の知る限りでは、維持するためのセミナーもいろいろなベンダがたくさん実施しており、とても盛んな印象です。
それと比べるとJCSQEはそんなことなさそうです。定量的に受験数など示せればいいのですが、そんなことしなくても明らかではないでしょうか。
私もソフトウェア品質やソフトウェアテスト系の研修を受け持つときに研修生に聞くのですが、SQuBOKやJCSQEを知る人は(僕の客には)ほとんどいません。だから受けに来ているのかもしれませんけど。でも品質第一をうたってる企業グループのくせに、参加者のほとんどが知らないのは酷いなぁと思うわけです。
私もソフトウェア品質やソフトウェアテスト系の研修を受け持つときに研修生に聞くのですが、SQuBOKやJCSQEを知る人は(僕の客には)ほとんどいません。だから受けに来ているのかもしれませんけど。でも品質第一をうたってる企業グループのくせに、参加者のほとんどが知らないのは酷いなぁと思うわけです。
ソフトウェア品質の教育を見直したい
資格を広めるでも何でも良いのですが、ソフトウェア品質についてもっと体系的に学んで、知識を実践していくという風土を醸成していくべきだと思います。せっかく先人たちが築いた素敵なメソッドやらテクニックやらがあるのですから。
そのために私として取り組みたいのは、ソフトウェア従事者に対するソフトウェア品質の教育を見直していくというものです。
アーキテクト育成が私の周りでのキーワードになってます。それはもちろん取り組んだほうが良いことだと思います。
ですがその前段として、ソフトウェア品質についてこれまでどんなことが考えられてきたのか、一通り知っておく必要があると考えます。
なぜなら、アーキテクチャは品質要求を実現するためのものなのだから。
なぜMVCパターンを使うのか、なぜ構造化設計をするのか、なぜ開発フレームワークを使うのか、なぜイベントドリブンなのか・・・、そういった説明を筋道一つ立ててできないとすると、アーキテクチャの知識だけ被った似非アーキテクトだと思います。
偉そうに言ってしまってごめんなさい。私もただの研修インストラクタですから、どっちかというとその類の人です。
アーキテクト育成が私の周りでのキーワードになってます。それはもちろん取り組んだほうが良いことだと思います。
ですがその前段として、ソフトウェア品質についてこれまでどんなことが考えられてきたのか、一通り知っておく必要があると考えます。
なぜなら、アーキテクチャは品質要求を実現するためのものなのだから。
なぜMVCパターンを使うのか、なぜ構造化設計をするのか、なぜ開発フレームワークを使うのか、なぜイベントドリブンなのか・・・、そういった説明を筋道一つ立ててできないとすると、アーキテクチャの知識だけ被った似非アーキテクトだと思います。
偉そうに言ってしまってごめんなさい。私もただの研修インストラクタですから、どっちかというとその類の人です。
ソフトウェア品質業界は資格ビジネスを展開すべき、というわけではありません。
PMに関していえば、PMP保持者がいてもうまく回ってないプロジェクトがたくさんあるわけですし。
(まぁこれについては、高いお金を会社から出してもらって維持してる人はもっと頑張れよって感じです。)
PMに関していえば、PMP保持者がいてもうまく回ってないプロジェクトがたくさんあるわけですし。
(まぁこれについては、高いお金を会社から出してもらって維持してる人はもっと頑張れよって感じです。)
ソフトウェア品質の教育を見直すとして、取り組みたいのは次の点です。もちろん業界全体を再構築してやるというような大それたことをする気はなくて、自分の手の届く範囲で見直していくということです。
- 国産のソフトウェア品質技術について教育の中で触れる。
日本の社会風土のなかで育ってきた日本固有の技術を知らずして、輸入品ばかり使うのはどうかと思うわけです。国産品、輸入品の良いところ悪いところを知ったうえで使い分けるべきです。
- 技術を学んだ人がひとまずそれを小さく回す場を用意する。
テスト設計コンテストなんかはまさにそれにあたると思います。セキュリティ分野、プログラミング分野ではこういったコンテストが活発ですよね。
おわりに
SQuBOKにはソフトウェア品質を取り巻く古今東西の技術がたくさん詰まっていますが、それを広く知ってもらうための教育などの施策が伴って初めて本当に役立つと言えるのだと考えます。
一方で、SQuBOKを広めるための施策はまだ不十分だと考えます。
一方で、SQuBOKを広めるための施策はまだ不十分だと考えます。
技術は人に依存しないものですから、自ら技術を求めて勉強する人しか使えないという状況は、技術教育を提供する身としてはまだ教育方法に改善の余地があると思うところです。
やる気のあるやつだけ掬えばいいじゃないという意見もあるかもしれませんが、教育者としてそれではプロとは言えません。
やる気のあるやつだけ掬えばいいじゃないという意見もあるかもしれませんが、教育者としてそれではプロとは言えません。
今回の読破会のように、勉強会後はお酒も飲みながら楽しくなれるような場が誰にでも受け入れられるようにできればいいなぁと思う次第です。
ということで、次回がAdvent Calendar最終回です！
