ソフトウェア業界に向いている人、私が実践してきたユニークな適正判断も紹介
こんにちは、
拙作ブログをご覧いただきありがとうございます。
今回は、仕事の話をしたいと思います。
IT業界の話です。
具体的にはソフトウェア開発についてです。
といっても、
ソフトウェア開発の中身の話ではありません。
ソフトウェア開発に従事する人の話です。
一般の職種に較べて、
ソフトウェア開発は特殊です。
よって、
向き、不向きで生産性や品質、
ひいては、
モチベーションの差までが出てきます。
そのへんのところを
考えてみたいと思います。
１）ソフトウェアの生産性
ソフトウェアの生産性は、
「ソフトウェア開発（行数）／人月」で表します。
すなわち、
１人が１ヶ月、何行のソフトウェアを開発するかです。
このソフトウェアの生産性は、
人の能力によるところが非常に大きいようです。
もちろん、
開発環境や言語、ツールも生産性に影響しますが、
人（開発者）に依存した下記要因がもっとも大きいようです。
（私の経験からです）
①センス
②経験
③知識
私の経験では、
この生産性は、人によって、
１０数倍の差があります。
つまり、
できる人が１ヶ月で完了するところを、
できない人は、
１０数ヶ月もかかってしまうのです。
この要因のなかで、
特に、私が重視しているのは、
「センス」です。
このソフトウェア開発における、
人の「センス」を中心に、
詳細をみていきます。
そして、
その人の見分け方、
つまり
「適正判断」
をするのに、
血液型を採用しました。
この血液型による人の見分け方は、
私の経験に基づくものです。
そのへんのところも本稿で触れます。
- １．ソフトウェアの特徴
- ２．ソフトウェア開発の基本工程
- ３．ソフトウェア開発に向いている人
- ４．ソフトウェア開発に向いている人をどう見分けるか？
- ５．まとめ
- 【関連記事】
- ※更新履歴※
- ※CMリンク※
１．ソフトウェアの特徴
ソフトウェアについて少し触れておきます。
ソフトウェアに詳しい読者は、
本項は読み飛ばしてください。
１－１．ソフトウェアは正直
ソフトウェアは、
いたって正確に動作します。
同じ条件であれば、
同じように動作して、
同じ結果を返します。
人間のような気まぐれではありません。
１－２．ソフトウェアは経年変化しない
ソフトウェアは劣化しません。
何年経っても故障したり、
動作がおかしくなることはありません。
もし誤動作したとしたら下記が原因です。
①ソフトウェアを動作させるところに
異変があった。
ハードウェア、ＯＳ（オペレーティングシステム）などです。
②細部の動作条件が変わった。
該ソフトウェアの動作タイミングなどです。
動作タイミングは、
動作環境の負荷や、
排他制御によって微妙に変わります。
このへんは難しくなりますので、
ここまでとします。
１－３．ソフトウェアは見えない
ソフトウェアは電気と同じで、
見ることができません。
実は、
ここが「やっかい」なのです。
唯一その欠点を補うのが、
ドキュメントです。
しかし、
そのドキュメントには、
不備が多いのが現実です。
保守員泣かせです。
このへんは保守の経験者なら、
よくお分かりでしょう。
２．ソフトウェア開発の基本工程
次に、
ソフトウェアの開発工程をみていきましょう。
◆私のソフトウェア経験
その前に、
私のソフトウェア経験をご紹介しておきます。
①経験年数：約５０年
②会社：某 大手鉄鋼メーカー
③分野：鉄鋼現場の制御用コンピュータシステム
※この制御用コンピュータシステムを、
我々は「プロコン」と呼んでいます。
プロセス制御用コンピュータシステムの略です。
④開発システム数：約５００システム
２－１．開発工程
開発工程は、おおむね下記になっています。
工程名の呼称は、
ソフトウェア業界によって、
少しずつ異なっているようです。
ですが、
大きな流れは、
ほぼ同じです。
なお、
下記の括弧内は、
当該工程で作成されるドキュメント名称です。
①要求定義（機能仕様書）
ここでは、
システムに組み込む機能を明確にします。
いわゆる「ＷＨＡＴ（何を）」を定義するものです。
よって、
開発メンバーには現場（工場）の人も参画します。
②機構設計（ファイル仕様書、処理仕様書）
ここでは、
①で設定した機能の実現手段を明確にします。
いわゆる「ＨＯＷ TO（どのように）」を定義するものです。
ここで、
ある程度のシステムの概観が見えてきます。
ハードウェア仕様を決めるのも、
この工程です。
③プログラミング（プログラムソース）
ここでは、
具体的なソフトウェアを作成します。
いわゆる、
コーディング作業です。
また、
テストの一部として「単体テスト」が含まれます。
つまり、
コーディングしたプログラムの動作検証です。
ここで行うのは、
「ホワイトボックステスト」です。
つまり、
全「カバレッジ」が検証の対象です。
④テスト（テスト仕様書）
ここでは、
テスト対象ごとに下記に分けて行います。
◇組合せテスト：ある機能単位のテスト
（仮のテストデータを使用）
◇総合テスト：全機能の一斉テスト。
（仮のテストデータを使用）
◇現地テスト：実際の信号を使ってのテスト。
（電気、計装、機械との接続テストを兼ねます）
２－２．開発の標準化
上記ソフトウェア開発においては、
標準化が行われています。
代表的な標準化項目を列挙しておきます。
①基本工程（上記）、②ドキュメント用紙、③工程管理規定、
④品質管理規定
この標準化によって、冒頭で述べた、
人による「バラツキ」を抑えています。
ただ、
これにも限界があります。
この標準化は、
「弱者救済」でしかありません。
あくまでも、
底辺の底上げが目的です。
３．ソフトウェア開発に向いている人
ソフトウェア開発に向いている人を整理しておきます。
これも私の経験則です。
工程別にご紹介します。
３－１．要求定義
要求定義では、
システムの専門知識より、
むしろ、
対象設備についての知識が必要です。
①専門用語
②製造工程（プロセス）
③問題点（ニーズなど）
これらの知識をもとに、
ユーザー（工場側）と対等に議論できなければなりません。
◆資質
必要な資質は、下記になります。
①大所高所から物事を見ることができる。
②即断即決ができる。
③枝葉末節にはこだわらない。
④コスト意識があること。
⑤全体意見をまとめることができる。
⑥対人交渉が好きな人。
３－２．機構設計
機構設計では、
システムに関する、
高い知識と経験が必要です。
問題点に対する洞察力も必要です。
◆資質
必要な資質は、下記になります。
①ファイル設計やプログラム設計の
コツを知っている。
②いきなり細部ではなく、
骨格から仕事ができること。
③大規模システムのような分業化作業では、
チームリーダーの素養も必要です。
④そのためには、
人の適正を即座に判別できること。
⑤もちろん、粘り強さも必要です。
⑥ある程度の対人交渉も必要です。
３－３．プログラミング
プログラミングは特殊な作業です。
そのために、
知識や経験だけでなく、
「その特殊な作業に向いているか」
がポイントとなります。
◆資質
プログラミングに必要な資質は下記です。
①論理的な思考ができること。
②その論理的な思考が好きなこと。
③しかも、最後までその思考を、
漏れなく、矛盾なく貫徹できること。
④そういう意味での「耐性」が大きいこと。
３－４．テスト
テストのポイントは下記です。
①テストケースを全件抽出できること。
②そのテスト結果を客観的に評価できること。
（思い込みや、推測は絶対ダメ）
◆資質
必要な資質は下記です。
①危険予知ができること。
（テストケース抽出時に必要）
②途中であきらめない。
（粘り強く最後までできる人）
４．ソフトウェア開発に向いている人をどう見分けるか？
ソフトウェア開発の向き不向きの見分けは、
かなり難しいものがあります。
採用前に、
経験や知識（資格）をひととおり見ますが、
それは、「しないよりまし」程度で、
あまり当てにはなりません。
◆センスの見極め
特に私が重視しているセンス（上述）は、
面接等では絶対に分かりません。
よって、
下記のような血液型判定を採用しています。
（ ）内は次候補です。
①要求定義：O型（Ｂ型）
②機構設計：B型（Ａ型 or AB型）
③プログラミング：Ａ型、ＡＢ型
④テスト：B型
５．まとめ
どうでしたか。
ソフトウェア開発の概要がお分かりになったでしょうか。
同時に、
開発工程ごとの適正な血液型
がお分かりになったでしょうか。
--血液型-- --向いている作業--
Ｏ型 上工程（要求定義）、工程管理
Ｂ型 全体機構設計、全体テスト
Ａ型 プログラミング、単体テスト
ＡＢ型 プログラミング、単体テスト
なお、性別は関係ありません。
強いて言うなら、
プログラミングは女性が向いているようです。
粘り強さは、女性のほうが上です。
上記は、
私の経験（実績）にもとづくものです。
かなり確度はあると自信を持っています。
ただ、
保証の限りではございませんので、
そこのところはご勘弁ください。
◆ちなみに私はO型です。
私の血液型は「Ｏ型」です。
ということは、
上記適正判断でいくと下記となります。
Ｏ型の人間は、ソフトウェア業界では、
上流工程のみ。
つまり、要求定義のみです。
システム機能を発掘し、
ユーザーとその仕様を確認するぐらいです。
肝心なソフトウェア開発には、
向いていません。
理由は下記です。
①飽きっぽい。
②考え方がおおざっぱ。
これも私の経験則です。
ぴったりです。
あたっています。
まあ、
自分で言うのもおかしいですが、
細かい仕事には向いてないようです。
読者のなかに「Ｏ型」がいると、
申し訳ないですが・・。
ただ、
管理職に向いていますので、
どんどん「上」を目指してください。
（と自分を励ましています・・苦笑）
最後までお読みいただき、
ありがとうございました。
【関連記事】
※更新履歴※
【更新】2020年1月12日、2月29日、5月23日、10月10日、2021年7月18日、2022年8月3日
少しだけ校正させていただきました。
【更新】2019年9月21日
CMリンク追加。
【更新】2019年9月10日
「目次」を追加しました。
これで少しは読みやすくなったと思います。
※CMリンク※
ソフトウェアデザイン 2019年10月号
ソフトウェア品質判定メソッド: 計画・各工程・出荷時の審査と分析評価技法
ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 (EXAMPRESS)
ソフトウェアデザイン 2019年9月号
Practical Developers ――機械学習時代のソフトウェア開発[ゲームアプリ/インフラ/エッジ編] (WEB+DB PRESSプラスシリーズ)
【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践
ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)
Clean Architecture 達人に学ぶソフトウェアの構造と設計
ソフトウェア要求 第3版
岩波講座 ソフトウェア科学〈〔環境〕6〉オペレーティングシステム
はじめて学ぶソフトウェアのテスト技法
ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点
