知って得・あなたの生活をもっと豊かに!

こんにちは、拙作ブログのご紹介です。このブログは河原健次がお届けしています。大分市出身、木更津市在住です。すでに半世紀以上も生存しています。その長い歴史から、日常生活や人生に参考になりそうな情報を提供しています。読者のみなさんに役立つことを願っています。

ソフトウェア業界に向いている人、私が実践してきたユニークな適正判断も紹介

f:id:kawa2496:20190201065343j:plain

こんにちは。
拙作ブログをご覧いただきありがとうございます。

今回は、仕事の話をしたいと思います。


IT業界の話です。
具体的にはソフトウェア開発についてです。


といっても、細かい中身の話ではありません。
ソフトウェア開発に、
向いているかどうかの話です。

一般の職種に較べて、
ソフトウェア開発は特殊です。

よって、向き不向きで生産性や品質、
ひいては、モチベーションも違ってきます。

このへんのところを考えてみたいと思います。

 

1)ソフトウェアの生産性

ソフトウェアの生産性は、「行/人月」で表します。
すなわち、
1人が1ヶ月に何行のソフトウェアを開発するかです。

このソフトウェアの生産性は、
人の能力によるところが非常に大きいようです。
もちろん、開発環境や言語、ツールも生産性に
影響しますが、人(開発者)に依存した下記要因が
もっとも大きいようです。
(私の体験からの結論です)


①センス
②経験
③知識

私の体験では、この生産性は、人によって
10~10数倍の差があります。

つまり、
できる人が1ヶ月で完了するところを、
できない人は、
10数ヶ月もかかってしまうのです。

この要因のなかで、
特に、
私が重視しているのは「センス」です。

 

このソフトウェア開発における
人の「センス」を中心に、

詳細をみていきます。

 

そして、
その人の見分け方、
つまり「適正判断」に、

血液型を採用しました。

 

この血液型による人の見分け方は、
私の経験に基づくものです。

このへんのところも触れます。

 

 

楽天/生活   Amazon/生活

楽天/人生   Amazon/人生

 

1.ソフトウェアの特徴

ソフトウェアについて、少し触れておきます。
ソフトウェアにお詳しい読者は、
本項を読み飛ばしてください。

 

1-1.ソフトウェアは正直

ソフトウェアは正確に動作します。
同じ条件であれば、同じように動作して、
同じ結果を返します。
人間のように気まぐれな動作はしません。

 

1-2.ソフトウェアは経年変化がない

ソフトウェアは劣化しません。


何年経っても故障したり、
動作がおかしくなることはありません。


もし誤動作したとしたら下記が原因です。


①ソフトウェアを動作させるところに
異変があった。

ハードウェア、
OS(オペレーティングシステム)などです。


②細部の動作条件が変わった。
該ソフトウェアの動作タイミングなどです。
動作タイミングは、
動作環境の負荷や、排他制御によって微妙に変わります。
このへんは難しくなりますので、ここまでとします。

 

1-3.ソフトウェアは見えない

ソフトウェアは電気と同じで、
目で見ることができません。


実は、ここが「やっかい」なのです。


唯一その欠点を補うのがドキュメントです。


しかし、
そのドキュメントに不備が多いのが現実です。

保守員泣かせになっています。

 

保守経験者なら、
よくお分かりでしょう。

 

2.ソフトウェア開発の基本工程

次に、ソフトウェアの開発工程をみていきましょう。

◆私のソフトウェア経験

その前に、
私のソフトウェア経験をご紹介しておきます。


①経験年数:約50年
②会社:某大手鉄鋼メーカー
③分野:鉄鋼現場の
制御用コンピュータシステム

※この制御用コンピュータシステムを、
我々は「プロコン」と呼んでいました。
プロセス制御用コンピュータシステムの略です。
④開発システム数:約500システム

 

2-1.開発工程

開発工程は、おおむね下記になっています。
工程名の呼称は、ソフトウェア業界によって、
少しずつ異なっているようです。


ですが、
大きな流れは、ほぼ同じです。

 

なお、下記の括弧内は、
当該工程で作成されるドキュメント名称です。


①要求定義(機能仕様書)
ここでは、システムに組み込む機能を明確にします。
いわゆる「WHAT(何を)」を定義するものです。
よって、メンバーには現場(工場)の人も参画します。

 

②機構設計(ファイル仕様書、処理仕様書)
ここでは、①で設定した機能の実現手段を明確にします。
いわゆる「HOW(どのように)」を定義するものです。
ここで、ある程度のシステムの概観が見えてきます。
ハードウェア仕様を決めるのも、この工程です。

 

③プログラミング(プログラムソース)
ここでは、具体的なソフトウェアを作成します。
いわゆる、コーディング作業です。
また、テストの一部として「単体テスト」が含まれます。
つまり、コーディングしたプログラムの動作検証です。
ここで行うのはホワイトボックステストです。
つまり、
全「カバレッジ」が検証の対象です。

 

④テスト(テスト仕様書)
ここでは、テスト対象ごとに下記に分けて行います。
◇組合せテスト:ある機能単位のテスト
(仮のテストデータを使用)
◇総合テスト:全機能の一斉テスト。
(仮のテストデータを使用)
◇現地テスト:実際の信号を使ってのテスト。
(電気、計装、機械との接続テストを兼ねます)

 

2-2.開発の標準化

上記ソフトウェア開発においては、標準化が行われています。
代表的な標準化項目を列挙しておきます。
①基本工程(上記)、②ドキュメント用紙、③工程管理規定、
④品質管理規定
この標準化によって、
冒頭で述べた、
人による「バラツキ」を抑えています。


ただ、これにも限界があります。


この標準化は、
「弱者救済」でしかありません。

あくまでも、底辺の底上げが目的です。

 

3.向いている人

ソフトウェア開発に向いている人を整理しておきます。
これも私の経験則です。

工程別にご紹介します。

 

3-1.要求定義

要求定義では、システムの専門知識より、
むしろ、対象設備についての知識が必要です。
①専門用語
②製造工程(プロセス)
③問題点(ニーズなど)
これらの知識をもとに、
ユーザー(工場側)と対等に議論できなければなりません。


◆資質
必要な資質は、下記になります。


①大所高所から物事を見ることができる。
②即断即決ができる。
③枝葉末節にはこだわらない。
④コスト意識があること。
⑤全体意見をまとめることができる。
⑥対人交渉が好きな人。

 

3-2.機構設計

機構設計では、
システムに関する、
高い知識と経験が必要です。

問題点に対する洞察力も必要です。

 

◆資質
必要な資質は、下記になります。
①ファイル設計やプログラム設計の
コツを知っている。

②いきなり細部ではなく、
骨格から仕事ができること。

③大規模システムのような分業化作業では、チームリーダーの素養も必要です。
④そのためには、
人の適正を即座に判別できること。

⑤もちろん、粘り強さも必要です。
⑥ある程度の対人交渉も必要です。

 

3-3.プログラミング

プログラミングは特殊な作業です。
そのために、知識や経験だけでなく、


「その特殊な作業に向いているか」

 

がポイントとなります。

◆資質
プログラミングに必要な資質は下記です。
論理的な思考ができること。
②その論理的な思考が好きなこと。
③しかも、最後までその思考を、
漏れなく、矛盾なく貫徹できること。
④そういう意味での「耐性」が大きいこと。

 

3-4.テスト

テストのポイントは下記です。
①テストケースを全件抽出できること。
②そのテスト結果を客観的に評価できること。
思い込みや、推定は絶対ダメ

◆資質
必要な資質は下記です。
危険予知ができること。
(テストケース抽出時に必要)
②途中であきらめない。
粘り強く最後までできる人)

 

4.向いている人をどう見分けるか

ソフトウェア開発の向き不向きの見分けは、
かなり難しいものがあります。


採用前に、経験や知識(資格)を
ひととおりみますが、
それは、

「しないよりまし」

程度で、
あまり当てにはなりません。

 

◆センスの見極め

特に私が重視しているセンス(上述)は、
面接等では絶対に分かりません。

よって、
下記のような血液型判定を採用しています。

 

( )内は次候補です。

①要求定義:O型(B型)

②機構設計:B型(A型 or AB型)

③プログラミング:A型、AB型

④テスト:B型

 

5.まとめ

f:id:kawa2496:20190201065723j:plain

どうでしたか。
ソフトウェア開発の概要がお分かりになったでしょうか。

同時に、

開発工程ごとの適正な血液型

がお分かりになったでしょうか。

 

--血液型--   --向いている作業--
 O型    上工程(要求定義)、工程管理
 B型    全体機構設計、全体テスト
 A型    プログラミング、単体テスト
 AB型   プログラミング、単体テスト

 

なお、性別は関係ありません。
強いて言うなら、


プログラミングは女性に向いているようです。
粘り強さがあるからです。

 

上記は私の経験(実績)にもとづくものです。

かなり確度はあると自信を持っています。

ただ、保証の限りではございませんので、
そこのところはご勘弁ください。

 

◆ちなみに私はO型です。
私の血液型は「O型」です。

ということは、上記適正でいくと下記となります。


O型の人間は、
ソフトウェア業界では、
上流工程のみ。

 

つまり、要求定義のみです。

 

システム機能を発掘し、
ユーザーと、
その仕様を確認するぐらいです。

 

肝心なソフトウェア開発には、
向いていません。

 

理由は下記です。
①飽きっぽい。
②考え方がおおざっぱ。

これも私の経験則です。

 

ぴったりです。

あたっています。

 

まあ自分でいうのもおかしいですが、
細かい仕事には向いていないようです。

読者のなかに「O型」がいると、
申し訳ないです。

 

ただ、管理職に向いていますので、

どんどん「上」を目指してください。

 

最後までお読みいただき、
ありがとうございました。

 

※更新履歴※

【更新】2019年9月21日
CMリンク追加。

【更新】2019年9月10日
「目次」を追加しました。
これで少しは読みやすくなったと思います。

 

楽天/生活   Amazon/生活

楽天/人生   Amazon/人生

 

 

 

 


ソフトウェアデザイン 2019年10月号

ソフトウェア品質判定メソッド: 計画・各工程・出荷時の審査と分析評価技法

ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 (EXAMPRESS)

ソフトウェアデザイン 2019年9月号

Practical Developers ――機械学習時代のソフトウェア開発[ゲームアプリ/インフラ/エッジ編] (WEB+DB PRESSプラスシリーズ)

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

Clean Architecture 達人に学ぶソフトウェアの構造と設計

ソフトウェア要求 第3版

岩波講座 ソフトウェア科学〈〔環境〕6〉オペレーティングシステム

はじめて学ぶソフトウェアのテスト技法

ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点