この記事では、新入社員の方や新しくプロセス担当になられた方、開発プロセスについておさらいしたい方向けに
開発プロセスとはなにかをざっくりと説明します。

イラスト付きで解説するのでイラスト部分だけ見てもなんとなく理解してもらえるのではないかと思います。
お気軽に読んでいただけると幸いです。

CONTENTS
  1. はじめに
  2. 開発プロセスとは?
  3. どうして重要なの?
  4. A-SPICE や CMMI、規格対応
  5. まとめ
  6. わりに
 

はじめに

弊社では、新人研修のひとつに開発プロセス研修があります。
もちろん私も、プロセスとはなんぞやを研修で教えてもらいました。
のですが、教えてもらったあとも、しばらくは「うーん、わかったような、わからないような(´・ω・`)」
という感じでした。

学校でプログラミングを学んできた人や、実際に会社で開発を行っている人でも、
「プロセスに沿って開発とかいうけど、正直ちょっとよくわからない(´・ω・`)」という人がいるのではないでしょうか。

そんな人向けにイラストを交えながらかんたんに解説します!
※ イラストはイメージです。

 

開発プロセスとは?

または

開発プロセスとは、ひとことでいうと、

「システムやソフトウェアを開発する際の一連の工程 (流れ・手順)」

または

それをまとめた「システムやソフトウェアを開発する際の手順書」です。

上図で示した工程は一例ですが、開発をする際はこのような手順を踏みます。

  • 要件定義   :どんなものをつくりたいかを考える活動
  • 設計     :つくりたいものを実現するために何が必要かを考える活動
  • プログラミング:設計をもとに実際につくる活動
  • テスト    :つくったものがつくりたかったものになっているか、問題ないか確認する活動
  • 運用保守   :つくったものを実際に安定的に使えるようにする活動

何かをつくるときに、上記のことを何も考慮せずに行き当たりばったりでつくっていては、
「この検討が漏れていた!」「ここのケアができてない!」など、
あとになってから大事なことを抜かしていたことに気づきます。

そうならないためにも、開発プロセスとして、
「こういう活動を行いましょう」「そのときにはこの点を注意しましょう」など、手順を定めています。

 

どうして重要なの?

つぎに、なぜ開発プロセスが重要なのかについてです。
開発プロセスを制定し、それに従って活動を行うことで以下のような効果を得られます。

品質のばらつきを防ぐ

回転寿司屋さんに行ったとき、どこの店舗でも同じものが食べられますよね。
これはお寿司の作り方が決まっているからです。

例えば、炙りサーモンチーズ的な品があれば、

  1. 焼きトロサーモンを耐熱板の上に乗せる
  2. その上にチーズを乗せる
  3. マヨネーズをかける
  4. 5秒炙る
  5. 炙ったネタをシャリに乗せる

など、手順に従って作業すれば誰でも一定の品質のものがつくれるようになっています。

たまに、もはやキュウリ軍艦になっているイクラ軍艦や、キンキンに冷えてやがるマグロの握りも流れてくるけども…
(´-`).。oO

と思った人もいるでしょう。
そのとおりで、いくら手順を定めていても実際にそれに従って作業を行わないと意味がない部分があります。

そのために監査などがあり、きちんと定められたルールに沿って作業が行われているかなどを確認し、
できていなければ、対策を打つ。というような活動があるのですね。

 

チームで共通認識を持つ

ひと昔前は開発プロセスはそこまで一般的ではなかったようです。
シャカリキな時代から効率化の時代になってきたことや、
開発の規模が大きくなってきたことが一般化してきた要因のひとつと考えられます。

システム・ソフトウェア開発は、かなり小規模なものを除いて、チームを組んで行うことが一般的です。
チームで動く以上、「こんなときはこうする」などの共通認識のルールが必要になります。

チームで動くときは、設計する人と実装(プログラミング)する人、テストする人をそれぞれ別の人が担ったりします。
「設計書にはこういうことを書きましょう」というルールがなければ、
実装担当の人が受け取った設計書は設計担当の人にしかわからない代物になっている可能性があります。

こういうこともあって、みんなで円滑に開発プロジェクトを進めるためにも
共通認識としてのプロセスが必要なんですね。

 

問題が起きたときに作業者を守る

開発プロセスに何を定めているかは、企業により異なりますが、
例えば、「OSSを使うときは OSS管理表 に使用したOSSを記録してください。」という手順を定めていたとします。
この手順の目的としては、OSSに脆弱性が発見された際、
アップデートなどの適切な対応を迅速に行えるようにするためなどがあります。

きちんとプロセスに従って、OSS管理表に使用しているOSSを記録していれば、
脆弱性が発見された際にもすぐに対応が可能です。
しかし、プロセスに従わずにOSSの記録をしていなかった場合、
脆弱性への対応が漏れ、最悪その部分から攻撃を受け、製品の悪用や情報漏洩に繋がるなどの問題に発展しかねません。

手順に従ってものごとを進めていれば、重大な問題に発展することを未然に防げます。
上記はプロジェクトとしての利点となりますが、
自分のせいで大炎上 orz という思いを作業者の人がしなくて済みます。

OSS (オープンソースソフトウェア) とは、インターネットから簡単に入手することができる、製品を開発するときに使える道具や素材のようなものです。有効に利用することで開発期間の短縮・開発コストの削減、品質の向上が図れます。

 

A-SPICE や CMMI、規格対応

開発プロセスを定めるときに、一からつくるのは大変ですよね。
そんなときにお手本にできるのが、Automotive SPICE (通称 A-SPICE) や CMMI などのモデルや指標です。
(とりあえずAutomotive SPICE や CMMI はお手本みたいなやつと思っておけば大丈夫です)

開発をするときには、こういう活動をした方がいいよ。その目的としてはこういうのがあるよ。
実際作業するときは、こういう文書を参考に、こういうことを意識して作業して、
結果として、こういう内容を含めた成果物を作っておくといいよ。

ざっくりいうと、上記のような内容を予め書いておいてくれています。
それをベースに組織体制や製品の分野などを考慮し、自社に合ったプロセスをつくっていくと楽です。

また、これらのモデルや指標にはレベルという概念があって、
「ここまでの基準でできていたら、Lv3 です。」などの認定をしてもらえます。

ここはしっかりルールがあって、しっかりルールに沿ってものづくりできています。
これは信頼できますよ!

とお墨付きをもらえるようなイメージです。

国や業界ごとなどにも 規格 というものが存在し、
例えば、「これくらいのルールや基準を守ってつくってないと、製品として売れませんよ。」
と逆に言われてしまったりもします。

「認証」などの言葉が出てくるのはこのあたりのことですね。
こちら から規格に関連する記事に飛べるので興味がある人は読んでみてください。

 

まとめ

ざっくりとまとめです。

  • プロセスとは、「システムやソフトウェアを開発する際の一連の工程 (流れ・手順)」または「システムやソフトウェアを開発する際の手順書
  • 品質のばらつきを防ぐ、チームで共通認識を持つ、作業者を守るためにもプロセスが重要
  • 開発プロセスにはベースとできるようなモデルや指標がある
  • プロセスの認定を受けることで、製品の品質、安全性にお墨付きをもらえる
  • 規格対応しないと、製品の販売ができないことがある
 

おわりに

いかがでしたか?

この記事を通して、開発プロセスについてなんとなく理解が深まっていたり、
興味を持っていただけていたら嬉しいです。

末尾になりますが、プロセス管理システム「Stages」の宣伝をさせていただけますと幸いです。
Stagesは、従来文書ベースが一般的だったプロセスをわかりやすく見える化することができます。

ただプロセスを参照できるだけのシステムではなく、作業項目をJiraなどのプロジェクト管理ツールにチケット化でき、
作業者の人はそれに従って作業を進めていけるなど、
開発プロセスに従って実際の開発プロジェクトを行う際に非常に使い勝手のよい、他にないシステムです。
製品についての詳しい情報は下記リンクよりご確認ください。

これからじめじめ暑くなってきますが、気温の変化に気を付けてご自愛ください!

プロセス管理システムStages(ステージズ)

Stages(ステージズ)は、Automotive SPICE、ISO/SAE 21434、ISO 26262などの国際規格とのマッピング機能をはじめ、複雑化するプロセス管理をシンプルにする、製品開発のためのプロセス管理ソリューションです。プロセスの定義、共有、運用の課題をこれ一つで解決。プロセスのPDCAサイクルの着実な運用が可能になります。

Stagesは UL Solutions の製品であり、弊社は国内の正規代理店です。

詳しくはこちら!