創造性を働かせるためには、頭の中を整理して目標への道筋を明確にすることが重要です。かといって、シンプルさを重視してすぐに整理するクセをつけてしまうと、かえって創造性が発揮できなくなります。イノベーションと創造性に関する専門家のジェフ・デグラフ氏が、「創造性はシンプルさから始まるわけではなく、シンプルさで終わる」というメソッドについて解説しています。
思考や記憶に負荷をかけすぎず、頭をシンプルにすることでクリエイティブな思考を発揮することができます。しかし、デグラフ氏によると、シンプル化を意識しすぎてあまりに早い段階で過剰に単純化してしまうと、かえって創造性が台無しになってしまう可能性があるとのこと。
その理由のひとつとして、創造性が発揮されるプロセスが挙げられます。創造性の専門家である心理学者のキース・ソーヤー氏は、「創造的な洞察は通常、はっきりとした状態ではなく、『ジグザグ思考』と呼ばれる構造化された混乱から生まれる」と強調しています。これは、思考の誤ったスタート、遠回り、予期せぬ方向転換に満ちた非線形のプロセスが、整然とした効率的な道筋よりも、創造性に結びつきやすいという考え方です。
創造性を発揮するためのアイデアとして、削減や簡素化を推奨することは多くありますが、デグラフ氏によるとこれは創造性のプロセスの終盤には役立つものの、初期段階では望ましくないそうです。可能性を十分に探究し、複雑な世界の中で理解し生まれてくるものがある中で、迅速な解決を求めることで、本来解き放とうとしている創造性そのものを制限してしまうことがあります。
⇧ とは言え、
- 課題発見
- タスクの優先順位
のようなプロセスのために、
- 情報の洗い出し
- 情報の分類・整理
が不可避であることが日常茶飯事の「エンジニア」にとっては、微妙なアプローチよね...
まぁ、「納期」もあるので、悠長なことしていられないというのが一番なのだが...
迅速な解決を保留することが許される牧歌的な時代は終わりを告げ、未曾有の大情報化社会に生きる現代人たる我々にとって、「創造性を発揮する」であろうとされるアプローチを取ることは、なかなかに難しいのではという気がしますな...
暇を持て余した有閑階級であれば、実践できるのかもしれないのだが、予算の限られた状況の中で取れるアプローチとは言い難い...
所詮は机上の空論と言うべきか...
「急がば回れ」は仕事だと許容されにくいというのもありますからな...
QA（Quality Assurance）と SQA（Software Quality Assurance）
とりあえず、ネットの情報を漁っていた感じでは、
- QA（Quality Assurance）
- SQA（Software Quality Assurance）
の2つがあるらしい。
■QA（Quality Assurance）
Quality assurance (QA) is the term used in both manufacturing and service industries to describe the systematic efforts taken to assure that the product(s) delivered to customer(s) meet with the contractual and other agreed upon performance, design, reliability, and maintainability expectations of that customer.
The core purpose of Quality Assurance is to prevent mistakes and defects in the development and production of both manufactured products, such as automobiles and shoes, and delivered services, such as automotive repair and athletic shoe design.
Assuring quality and therefore avoiding problems and delays when delivering products or services to customers is what ISO 9000 defines as that "part of quality management focused on providing confidence that quality requirements will be fulfilled".
⇧ 元々は、「製造業」と「サービス業」において、「顧客」に提供される「製品」が「契約」時の取り決め通りの水準を満たしているかの「指標」としての役割を担うものとして導入されたものらしい。
事例のセクションの中で、
In practice
Software development
Software quality assurance refers to monitoring the software engineering processes and methods used to ensure quality. Various methods or frameworks are employed for this, such as ensuring conformance to one or more standards, e.g. ISO 25010 (which supersede ISO/IEC 9126) or process models such as CMMI, or SPICE. In addition, enterprise quality management software is used to correct issues such as supply chain disaggregation and to ensure regulatory compliance; these are vital for medical device manufacturers.
Using contractors or consultants
Consultants and contractors are sometimes employed when introducing new quality practices and methods, particularly where the relevant skills and expertise and resources are not available within the organization. Consultants and contractors will often employ Quality Management Systems (QMS), auditing and procedural documentation writing CMMI, Six Sigma, Measurement Systems Analysis (MSA), Quality Function Deployment (QFD), Failure Mode and Effects Analysis (FMEA), and Advance Product Quality Planning (APQP).
⇧「ソフトウェア開発」における「QA（Quality Assurance）」の適用の話が出てきており、「SQA（Software Quality Assurance）」が導入されたということらしい。
■SQA（Software Quality Assurance）
Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards.
It may include ensuring conformance to standards or models, such as ISO/IEC 9126 (now superseded by ISO 25010), SPICE or CMMI.
SQA encompasses the entire software development process, including requirements engineering, software design, coding, code reviews, source code control, software configuration management, testing, release management and software integration. It is organized into goals, commitments, abilities, activities, measurements, verification and validation.
⇧とあるのだが、「ソフトウェア開発」のプロセスがファジーであり「透明性」が確立されていないので、茨の道という気がする...
「SQA（Software Quality Assurance）」は「ソフトウェア開発」の全ての「プロセス」を網羅しているとあり、
Activities
Quality assurance activities take place at each phase of development. Analysts use application technology and techniques to achieve high-quality specifications and designs, such as model-driven design. Engineers and technicians find bugs and problems with related software quality through testing activities.
Standards and process deviations are identified and addressed throughout development by project managers or quality managers, who also ensure that changes to functionality, performance, features, architecture and component (in general: changes to product or service scope) are made only after appropriate review, e.g. as part of change control boards.
⇧「活動」のセクションを見ると、「エンジニア」は「テスト」を通じて「品質」をより良くしていくということらしい。
ソフトウェア開発におけるQA（Quality Assurance）テストの位置付けが知りたいだけ...
とりあえず、
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。所管官庁は経済産業省。
⇧ 上記の情報を信用するしかないのだが、「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」の公開している情報によると、
⇧ とあり、「品質保証」のエビデンスの主なものとして、「テスト」の実施があると思うのだが、
| 工程順 | 成果物 | 工程順 | 成果物 |
|---|---|---|---|
| 1 | 要求定義 | 10 | - ※1 |
| 2 | 要件定義 | 9 | 運用テスト |
| 3 | 外部設計（基本設計） | 8 | システムテスト（外部結合テスト） |
| 4 | 内部設計（詳細設計） | 7 | 結合テスト（内部結合テスト） |
| 5 | 実装（プログラミング） | 6 | 単体テスト |
※1 要求定義に対するテストは無い。何故ならば、要件に落とし込む前段階であり、要件になっていない状態ではテストのしようがない。
⇧ のような感じで、様々な「テスト」があるのだが、「QA（Quality Assurance）テスト」がどの位置付けなのかがサッパリ分からない...
Wikipediaの「SQA（Software Quality Assurance）」の情報が正しいとするならば、「ソフトウェア開発」の全ての「テスト」が「QA（Quality Assurance）テスト」に該当するということになりそうだが...
ちなみに、
This article discusses a set of tactics useful in software testing. It is intended as a comprehensive list of tactical approaches to software quality assurance (more widely colloquially known as quality assurance (traditionally called by the acronym "QA")) and general application of the test method (usually just called "testing" or sometimes "developer testing").
The box approach
Software testing methods are traditionally divided into white- and black-box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.
⇧ 上記によると、「ソフトウェア開発」における「テスト」は、
- White-box testing
- Black-box testing
の2つに大別されるのが一般的ということらしい。
とりあえず、「QA（Quality Assurance）テスト」が、「ソフトウェア開発」における全ての「テスト」のことを言ってるらしいので、どの領域の「QA（Quality Assurance）テスト」のことなのかは分類してもらわないと認識が合わない気がする...
一般的な「ソフトウェア開発」の「工程」における「テスト」を全て「QA（Quality Assurance）テスト」とするならば、
⇧ という感じで、4つの「QA（Quality Assurance）テスト」があることになるので、ただ「QA（Quality Assurance）テスト」言われた場合は、どの「工程」の「QA（Quality Assurance）テスト」を意図しているのか認識齟齬が発生するわけだ。
このあたり、「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」に本気で整理してもらいたいのだが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
