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

mhlyc -presentation

ソフトウェアテスト、品質に関わること、たまに変なことを書いていくブログです。

PFDを学ぶ前に

最近USDMについて学ぶ機会があったのですが、その中でPFDが出てきたので合わせて学習しています。

 

PFDというのは、プロセスを設計するツールです。PFD作者の清水さんは、プロセスを設計するスキルはソフトウェアエンジニアリングにおいて必須のスキルだと言われています。

 

 

しかし、僕は思いました。

「そもそも、プロセスをきちんと考えて仕事している人ってどれだけいるんだっけ?」

というのも、自分は開発部門ではなくサポートする側の部門で働いています。

私の組織でも、「組織標準」と言われるものの整備を進めていたりします。

しかし、実際にそういった標準はどれだけ活用されているでしょうか?

 

実際に仕事をするとき、指示をくれる人がいるとします。

指示を聞く側であれば、当然作業をする前に作業をどう進めたらいいのか聞きますね。

そうなんです。「指示をもらって、その通りに仕事をする」ならば、「この標準を読んで仕事してね」と言われない限りは標準なんて読まないんですね。(そして悲しいことに、指示された通りにしか仕事をしないという人も一定数存在します。契約上仕方ない場合もありますが…)

 

要するに何が言いたいかというと、物事にはステップがあると思っています。

 

レベル1:プロセスがない(定義されていない)

レベル2:プロセスがある(定義されている)

レベル3:プロセスがあり、状況に応じて改善することができる(設計できる)

 

なので最初はプロセスを定義して、その通りにやってみるところからなんですね。

いきなりそれを飛ばしてPFDを勉強しようとしても、なぜ勉強する必要があるのか意義が理解しづらいと思います。

 

実際にやってみるとわかりますが、しっかり手順を決めて仕事したほうがむしろ早上がりな場合もよくあります。

こんな作業すぐ終わるから、と思う仕事に限って意外と無駄があったりします。プロセスを定義することでそういった無駄を排除できるのです。プロセスを決めずにいきなり作業に取り掛かるのは、いきなりコーディングするのと一緒です。作業前にやり方を考えるというのは、すなわち良い仕事の進め方なんですね。

 

以上、PFDを学ぶ前にまずはプロセスをきっちり定義して仕事してみましょうという話でした。