今回もエンジニア向けのスキルアップ方法について書いていきます。
プログラミングの習得は、エンジニアにとって大きな課題で、前回の記事でも効果的なトレーニング方法としてインプット-アウトプット法を紹介しました。
インプット-アウトプット法の概要は以下の手順でした。
- 見本のソースコードを見つける
- ソースからプログラム仕様とコーディング技能をノートなどにまとめていく
- 仕様と技能を見て、実際にコーディングする
- 自分がコーディングしたものと見本のソースの相違点をチェックしながら、スキルアップする
今回はその詳細版で、プログラム仕様のまとめ方について詳しく解説していきたいと思います。
今回も以下の方向けになっています。
- これからエンジニアを目指す方
- すでにエンジニアで新しい技術を身につけたい方
- 主体的な勉強方法を取り入れたい方、部下などに紹介したい方
見本からプログラム仕様を書き起こすメリット
仕様を書き出すのは”リバースエンジニアリング”とも言われ、システムの実態の把握のため仕様書を起こす事が保守開発の現場ではよく行われています。
そして今回行う見本ソースコードからのリバースエンジニアリングには、以下のようなメリットがあります。
- プログラムを解読する訓練になる
- 仕様書(詳細設計)を書く訓練にもなる
- 仕様書からプログラムを書く訓練にもなる
このように一石二鳥どころか一石三鳥なので、一見手間がかかるように見えて効果が大きいです。
![](https://itskill-coating.mindhack-lab.com/wp-content/uploads/2022/07/22804915-1024x768.jpg)
概要版でも触れましたが、自分の頭で考えてプログラミングする為、スキルの定着に効果的な方法です
プログラム仕様を書き起こす方法
以下では、仕様を書き起こす方法について主に2つ説明します。
ソフトウェア設計のテクニックを使う
ソフトウェア設計の分野では、設計手法がいくつか提供されています。
そのため、色々ある設計手法の中から、適切なものを選んで仕様書を書くようになります。
つまりこの作業で、ソフトウェア設計手法を習得する訓練にもなるということです。
そこで、以下ではソフトウェア設計の中でも、プログラム開発に直接関わる詳細設計の分野からいくつか手法を紹介していきます。
モジュール分割法
プログラムソースから仕様を起こすため、基本はモジュール単位で仕様を書いていくようになります。
そこで代表的として、モジュール分割法を紹介します。*1)
モジュール分割法に、STS分割法・ワー二エ法・ジャクソン法などいろいろありますが、詳細は下記リンクを参考ください。
ここでは、例としてSTS分割法を元にした仕様の記載例です。
STS分割の仕様の例: ● プログラムへの入力関連の情報 → 入力方法:手入力・固定値・別モジュールからの引数などで記載 → 入力内容:上記方法で何が入力されるか(具体的な変数やオブジェクトなど) ● 処理内容 → 入力データの加工内容 → 途中での別モジュールとの連携 → ループや分岐などの処理 ● 出力内容 →出力方法:テーブルや画面、帳票など →出力のイメージ図を記載
STS分割法はソフトウェアの処理を、「入力」「処理」「出力」という枠組みで仕様整理していきます。
必要に応じて図で示しても良いでしょう。
もしプログラムが「入力」「処理」「出力」の形式で整理できるものなら、STS分割法は適切になります。
フローチャート
フローチャートも詳細設計における有名な手法です。*2)
特に分岐が多い・分岐が複雑なプログラムにはよく使われます。
![](https://itskill-coating.mindhack-lab.com/wp-content/uploads/2022/07/22805770-1-1024x828.jpg)
UMLの詳細設計
IT業界では、オブジェクト指向言語としてJavaや.NETフレームワークをベースとした言語(VB,C#など)がよく使われています。
オブジェクト指向言語で、複数のオブジェクト間で連携さする処理の場合は、UMLを使って仕様を書くのもお勧めします。*3)
UMLはオブジェクト指向における、概要設計と詳細設計を記述するためのツールです。
下記リンク*2)でも、UMLの設計のイメージやテンプレがありますが、詳細設計を書くのであれば、「シーケンス図」や「アクティビティ図」、「モジュール構造図」、「IPO(処理詳細記述)」などが該当します。
職場標準の仕様書の書き方に従う
2点目は、自分の職場や開発環境の詳細仕様書に従ってみる、ということです。
もちろんメリットは職場の仕事に慣れることですが、一方で職場標準の仕様書にも改善の余地がある場合もあります。
上記で紹介したソフトウェア設計の手法を学びながら、以下のように工夫をしてみると良いでしょう。
- 標準的なソフトウェア設計手法の良い点を、職場標準の書き方に取り入れて仕様書を書いてみる
- 職場標準の仕様書の書き方の問題点(非効率な部分や品質改善の観点など)を発見し、現場の改善提案につなげる
このように改善意識を持つことで、単なる仕様書作成の練習に留まらない有意義な時間を過ごすことができるのです。
また正式な仕様書が無い現場も往々にしてあります。
仕様書がない職場で働いている方にとっても、書く練習や、職場に仕様書を提案する機会にもなり得るでしょう。
また主体性も上がるのでよりスキル習得に効果的になります。*4)
リンク
*1) モジュール分割法
https://e-words.jp/w/%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E5%88%86%E5%89%B2.html
*2) フローチャート
https://cacoo.com/ja/blog/keep-it-simple-how-to-avoid-overcomplicating-your-flowcharts/
*3) UML
https://pm-rasinban.com/dd-write
*4) [ラーニング・マスターズ株式会社] 主体性を持って仕事をするための効果的な習慣
https://www.lmi.co.jp/column/20211112070041/
コメント