ソースコードの記号の意味

From:リスキルテクノロジー 高坂一城 新宿本校にて

kohsaka

ソースコードには英単語だけではなく、 様々な「記号」が登場します。 この記号の中には、 普段の生活で使っている記号とは 表現が異なるものがあります。 今回は、そのような間違いやすい記号と その用途についてお話します。

間違いやすい記号

「*」

「アスタリスク」と発音します。 この記号は多くのプログラミング言語で 「乗算(掛け算)」の記号として使用されます。 数学では乗算として 以下のような記号が使用されますが、 5 × 3 プログラミングの世界では、 5 * 3 と表現します。 キーボードで 「×」の記号が入力できないため、 見た目が近い 「*」が使用されてます。

「/」

読み方は 「スラッシュ」 と発音します。 この記号は、 多くのプログラミング言語で 「除算(割り算)」 の記号として使用されます。 数学では除算として 以下のような記号が使用されますが、 5 ÷ 3 プログラミングの世界では、 5 / 3 と表現します。 これも「×」同様、 キーボードで「÷」の記号が 入力できないためです。 三分の一を1/3と 表現することがありますが、 1/3は1 ÷ 3と同じことなので、 「÷」の意味として「/」が使用されます。

「%」

読み方は 「パーセント」 と発音します。 この記号は、 多くのプログラミング言語で 「剰余算(余りを求める)」 の記号として使用されます。 数学では剰余算として 以下のような記号が使用されますが、 5 mod 3 プログラミングの世界では、 3 % 5 と表現します。

記号の用途

今回お話しました 「*」や「/」という記号は、 プログラミングの中で数値の 計算に使用するため、 使用頻度が比較的高い記号です。 しかし、 「%」はどういったときに 使用するのでしょうか。 例えば、 キーボードから入力された数値が 偶数なのか奇数なのかを 判定するには、 どうしたらよいか考えてみましょう。 偶数は2で割り切れる数、 奇数は2で割り切れない数です。 2で割り切れるということは、 2で割った余りが0である、 ということです。 逆に、 2で割り切れないということは、 2で割った余りが0以外である、 ということです。 ここで「%」が登場します。 キーボードから入力された数値 % 2 上記の答えが0なら、 入力された数値は偶数である。 上記の答えが0以外(実際には1)なら、 入力された数値は奇数である。 ということになります。 このように、プログラム中に登場する記号は、 単に数値を計算するだけではなく、 今回のようなアルゴリズムとしても 使用することがあります。 -------------------------------------------------------------------------------------- PS. 業界未経験からIT業界へ就職するには 社会人のための" プログラマースクール"で夢をかなえませんか --------------------------------------------------------------------------------------

ソースコードを”発音”する

From:リスキルテクノロジー 高坂一城 新宿本校にて

kohsaka

前回、ネーミングについてお話しをしたときに、 「プログラミング言語の多くは"英語"  で記述するものがほとんどです」 と書きました。 世界的に見ても日本人は英語が 得意な人種ではありません。 しかし、ソースコードを書くには 英語は避けて通れません。 最初は英語と格闘しながら ソースコードを書くことになるかもしれませんが、 徐々に慣れていきますので安心してください。

ソースコードを"読む"

こうして、ソースコードを書くことに慣れてくると、 次は"読む"ことにも慣れたいものです。 読むと言っても、 目で追いかけて読むのではなく、 声に出して読む(発音する)のです。 ソースコードを"発音"する? どういうことでしょうか。 プログラマ同士で打ち合わせをするときなど ソースコードの一部を発音することが しばしばあります。 そのときに 英語の読み方を間違えて発音してしまう、 あるいは、 読み方が分からなくて言葉に詰まってしまう、 という状況を目にすることがあります。 そこでソースコードによく登場するが、 間違って発音されることが多い英単語を いくつか紹介します。

読み間違えやすい英単語

「height」と「width」

「height」は「高さ」、「width」は「幅」を 表現するときによく用いられる英単語です。 さて、みなさんどう発音しますか? 「height」は 「ヘイト」ではなく「ハイト」と発音します。 また「width」はよく 「ワイズ」とか「ウィドス」と発音されますが、 正しくは「ウィッズ」と発音します。

「allow」と「deny」

これもよく間違って発音される英単語です。 「allow」は「許可」、「deny」は「拒否」 を表現するときに用いられます。 「allow」は「アロウ」ではなく「アラウ」、 「deny」は「デニー」ではなく「ディナイ」と発音します。

プログラマに発音の能力は必要か

ソースコードの「発音」を間違えても プログラムの動作に影響はありません。 しかし、 一つのプログラムを作成するときに、 一人で全て作成することはほとんどありません。 プログラムを作成するには数人から数十人、 場合によっては 数百人というチームで作成することがほとんどです。 つまり、他のプログラマとコミュニケーションを取りながら ソースコードを書くわけです。 その際に 自分の書いたソースコードを読み間違える、 というのは 恥ずかしいこともさることながら、 プログラマとしてのスキルレベルも 疑われる可能性があります。 そのため「たかが読み間違え」と思わずに プログラミングを勉強する際には、 ソースコードの読み方も勉強していきましょう! ---------------------------------------------- PS. ITエンジニアを目指すのは今からでも遅くない!! 社会人のための" IT専門校"で学習を始めませんか? ----------------------------------------------

わかりやすいコードと”ネーミング”

From: リスキルテクノロジー 高坂一城
新宿本校にて
kohsaka

以前「綺麗なコードの書き方」について
お話をしました。

統一感があるソースコードは、
非常に見やすくなります。

さて、綺麗なコードを書けるようになったら、
次のステップとして
「分かりやすい」コードを書くことを
心掛けましょう。

分かりやすいコードとは、
一体どういうものでしょうか。

ネーミング

プログラミングには、

「ネーミング(名前付け)」

と呼ばれるものがあります。

皆さんも、コンピュータ上で
新しいファイルやフォルダを作成するときに、
適切なファイル名やフォルダ名を付けますよね。

これと同じように、
プログラマがソースコードを書く際に、
ソースコード中に自由に名前を付けることができる
場所がたくさんあります。

そういった場所に適切な名前を付けることを
「ネーミング」と言います。

ネーミングの難しさ

プログラミング言語の多くは
「英語」で記述します。

そのため、ネーミングも英語で行います。

例えば、
「日本語で"削除する"という意味のネーミングをしたい」

皆さんなら、どういう英語を使いますか?

プログラミングにおいて、
「削除する」という意味を表す
ネーミングとしてよく使われる英語が

「delete」と「remove」 です。

この違い分かりますか?

・delete
 完全に消し去る

・remove
 取り除く(消し去っていはいない)

という意味の違いがあります。

つまり、
あるものを完全に消し去る場合には「delete 」、

あるものをそこから取り除くだけで、
どこかにまだ存在する場合には「remove」、

というネーミングを使います。

その他にも、
日本語で"見つける"という意味を表す
ネーミングとして、

「find」と「search」という英語があります。

・find
 見つかることが前提

・search
 見つからないかもしれない

という意味の違いがあります。

「ネーミング」の重要性

ネーミングはコメントと同様、
適当に付けてもプログラムの動作には
影響を及ぼしません。

「delete」とすべきところを
「remove」と記述しても
プログラムは動きます。

それでは、
なぜ「ネーミング」が大切なのでしょうか。

それは、コメントと同様にネーミングも、
ソースコードをメンテナンスする人への
大切な情報源だからです。

「プログラミングとは名前を付けること
 そのものである」

という人もいるくらいです。

最初はネーミングを考えながら
プログラミングをすることは
時間が掛かり大変かもしれません。

しかし、ネーミングを考えながら
より多くのコードを書くことで

プログラミングをする時間も徐々に
短くなっていきます。

--------------------------------------------
PS.プログラミングやJavaを身につけたい方へ
これまでに5000名以上の卒業生を輩出の
社会人のためのIT専門校なら" LAプログラミングスクール"
---------------------------------------------

「コメント」の重要性

From: リスキルテクノロジー 高坂一城
新宿本校にて

kohsaka

プログラミング言語を学ぶとき、
「コメント」は最初に習う項目の一つです。

「コメント」とは、
「ソースコードに書かれている注釈」 です。

そのため、コメントがあろうがなかろうが、
実際のプログラムの動作には全く
影響を及ぼしません。

プログラムを実行するときには、
コメントは全て無視されます。

では、なぜコメントを書くことが
必要なのでしょうか。

ある、調査機関によると、

「ソースコードの平均19%がコメントである」

という調査結果が出ています。

なぜ「コメント」が必要か

その理由は、
「ソースコードをメンテナンス(保守)する人に
情報を伝えるため」
です。

多くの場合、プログラムを作成する人と
そのプログラムをメンテナンスする人は異なります。

どんな「コメント」を書けばいいのか

では、どんなコメントを書けばよいのでしょうか。

今までに私が見てきたコメントで一番多いものが、

「何をしているコードなのか」

というものです。

例えば、

「ここでファイルにデータを出力する」
「もし値が0ならばエラー処理する」  などなど...。

このようなコメントは必要なのでしょうか??

「何をしているコードなのか」は、
ソースコードを見ればわかることです。

「コメント」として書くべきこと

ソースコードをメンテナンスする人が知りたいのは、

「なぜそのようなコードになったのか」

です。

ソースコードに手を入れて変更するにも、
なぜそのようになっているのかが
解らないと手を入れられません。

一見すると回りくどいソースコードだけど、
もしかしたら何か理由があるのかも?

そう考えると迂闊に手は入れられません。

「何をしているコードなのか」は、
時間をかければ読み解くことができます。

しかし、
「なぜそのようなコードになったのか」は、
そのソースコードを書いたプログラマの
頭の中にしかありません。

その意図をソースコードから読み取ることは
できません。

だからこそ、コメントで補う必要があるのです。

「コメント」も成果物の一部

最初にも書きましたが、
コメントはプログラムの動作には影響しません。

実際にプログラマに話を聞くと、
「なんとなく」でコメントを書いている人も多いです。

しかし、
コメントもソースコード(成果物)の一部です。

また、ソースコードをメンテナンスする人への
大切な情報源です。

実際にプログラムを書く際には、
「なんとなく」ではなく、気を遣ってコメント
を書くようにしましょう。

--------------------------------------------
PS.これからITを勉強したいあなたへ
高坂も登壇!参加費無料のセミナーはこちら↓↓
IT業界セミナー・授業体験セミナー
--------------------------------------------

綺麗なコードを書くためには?

From: リスキルテクノロジー 高坂一城
新宿本校にて

kohsaka

「優れたプログラマが書くコードは綺麗である」

と、よく言われます。

これは私の経験上、真実だと思います。

では、「綺麗なコード」とは何でしょうか?

一言でいうと、「一定のルールで書かれている」ということです。

書き方が統一されていないコードは美しくありません。

また、書き方が統一されていても、
そのルールが美しくなければ意味がありません。

ということで、「美しい書き方のルール作り」が大切です。

名前の付け方

まずは名前の付け方を決めます。

全て英単語にする、といった場合、
以下の2つの表現方法があります。

【スネークケース】

単語と単語の間を"_"(アンダーバー)で区切る方法です。

例えば、「ユーザ名を取得する(get user name)」ことを

get_user_name

と表現します。

これは単語を"_"でつなげる様(さま)が、
スネーク(蛇)に似ていることから名付けられています。

【キャメルケース】

単語の頭文字だけ大文字にして連ねる方法です。

上記の例では、

getUserName

と表現します。

これは大文字の部分がキャメル(らくだ)の"こぶ"の
ように見えることから名付けられています。

基本は使用する言語に合わせる

名前の付け方(単語の区切り方)は、
使用するプログラミング言語に合わせます。

一般的に、Javaならキャメルケース、
Rubyならスネークケースが綺麗とされています。

「綺麗なコード」は、見返りの大きい、時間の投資

名前の付け方を考えて綺麗なコードを書くには、
時間がかかります。

10行や100行のコードをただとりあえず動くだけの
レベルで書くのに比べたら、余計に時間はかかります。

さらに、動いたらメンテナンスせずに捨ててしまうプログラムなら、
「綺麗」にこだわっても意味がないですよね。

しかし、たいていのプログラムは、10行や100行を
書いて終わりではないです。

実際は、もっともっとたくさんのコードを書き、
それをメンテナンスしなくてはいけません

(スマートフォンの中にはおよそ1億行のプログラム
が入っていると言われています)。

そこで綺麗なコードのために費やした時間に、
メンテナンスのし易さ、
という膨大な利子が付いて返ってきます。

さらに、綺麗なコードを書くために、
プログラムを整理することは、

こだわった分だけ、
そのプログラマ自身のスキルを確実に向上させます。

例えば、今、綺麗なコードを書くために10の時間がかかっても、

次は9の時間でそれができ、その次は8の時間で、というように、

投資に必要な時間がどんどん短くなっていきます。

投資額が少なくなる一方、見返りがどんどん増えていく。

こんな美味しい投資をしない手はありませんよね!

--------------------------------------------
PS.プログラミングを学ぶなら
LAプログラマースクール
--------------------------------------------

プログラムの正しい書き方とは?

From: リスキルテクノロジー 高坂一城
新宿本校にて

kohsaka

「プログラムの正しい書き方ってあるのでしょうか?」

プログラミングを
学び始めて間もない方から
先日このような質問を受けました。

さて、
そもそもプログラムに...

「正しい書き方」

...はあるのでしょうか?

プログラムって動けばいいの?

プログラムの
正しい書き方というのは
もちろんありますが...

「これが絶対的に正しい!」

...という
明確なものがあるかというと
ちょっと悩んでしまいますね。

エンジニアとして
活躍されておられる方なら
誰もが一度は...

「動けばいいから」

...という言葉を
聞いたことがあるかと思います。

これはプログラムの中身はどうあれ、
システムとして期待している

機能や結果が出ていれば
問題ないよという意味で使われます。

決してシステムの中身が
どうでもいいという訳ではありません。

じゃあ何が「正しい」ってことなの?

いきなりたとえですが...

例えばあなたが
小説を読み始めたとします。

せっかくの休日。
ゆっくりとした時間を取ろうと考えて、
本屋に行って買ってきました。

しかし、
読んでみると、、、

全然理解できない。
前後の文脈が合っているような、あっていないような、、、

「ああ、それが言いたかったのね」

...と後半になってやっと理解できるような
文章だったりすると疲れてしまいます。

ポイントはここです。

正しいプログラムの書き方のポイントも
小説などの文章と同じくここにあります。

まずひとつめは...

1.理解しやすい書き方かどうか

...ですね。

小説でも新聞記事でもそうですが、
文章は読みやすい方がいいです。

プログラムも
文章みたいなものです。

処理そのものはコンピュータがしますが、
人が書いて人が読むものです。

意図が伝わりにくいよりも
伝わりやすい方がいいのです。

システム開発は多くの場合
1人だけでするものではありません。

多くのエンジニアが
集まってシステムを作り上げます。

あるエンジニアが書いたプログラムが
非常に分かりにくいコードで、

そのエンジニアから

「設計書ないから、ソース読んで理解してね」

...と言われても、
言われた方が困りまってしまいますし、

効率の良い開発が行えなくなります。

そしてもうひとつのポイントは...

2.適切な書き方かどうか

...ということです。

処理結果が同じであっても
書かなくても良いことを書いていたり…

書かない方が良い
内容を書いたりしている場合、
そのときは動いていても、
何らかのバグの原因になりかねません。

プログラム言語は
書き方によってはどんな処理もできますが、

プログラム的には
あまり使わない方がいい書き方もあるのです。

javaの例を見てみましょう

簡単な内容ですが、
javaのコード例を少し見てみましょう。

例えばこちらは
雑貨、医薬品、衣類の売り上げを合計し、
平均売上高を出すロジックです。

int a,b,c,t,v;
a = 320000;
b = 200000;
c = 130000;
t = a+b+c;
v = t/3;

コードは短いですが
変数名がa,b,c,t,vとなっています。

これだとぱっと見ただけでは、
変数か何の値を扱うかが分かりにくいですね。

これをこのように書き換えます。

int salesItem = 0;
int salesDrug = 0;
int salesWear = 0;
int total = 0;
double salesAvl = 0.0;

salesItem = 320000;
salesDrug = 200000;
salesWear = 130000;
total = salesItem + salesDrug + salesWear;
salesAvl = total / 3;

変数名をしっかり設定するだけで
何の値を扱う変数か、
どんな処理をしているかがよくわかります。

続いてはこちら、乱数の計算です。

double totalValue = ((Math.random() * 10 )+(Math.random() * 20)-(Math.random() * 5)+(Math.random() * 15));

4つの乱数を加減算していますが、
1行でまとめてしまうと
ちょっと長くて読みにくいです。

これくらいならまだ読めますが、
もっと長い処理を1行で書こうとする
エンジニアもいらっしゃいますね。

double firstValue = Math.random() * 10;
double secondValue = Math.random() * 20;
double thirdValue = Math.random() * 5;
double fourthValue = Math.random() * 15;

double totalValue = firstValue + secondValue - thirdValue + fourthValue;

こちらはこのように書き換えると
乱数との積を求める値もわかりますし、
パッと見て理解できるかと思います。

続いては条件文です。

public boolean checkTarget(int targetValue){
if (checkValue1(targetValue) == 0){
if(checkValue2(targetValue) == 0){
if(checkValue3(targetValue) == 0){
if(checkValue4(targetValue) == 0){
if(checkValue5(targetValue) == 0){
return true;
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}

checkValue1~5の
5つのチェック全てにおいて
値が0かどうかをチェックしていますが、

ネスト(入れ子)が多すぎて
わかりにくいですね。

同じ処理をこのように書き換えると
見づらさは解消されます。

public boolean checkTarget(int targetValue){

boolean ret = false;
if(checkValue1(targetValue) == 0 &&
checkValue2(targetValue) == 0 &&
checkValue3(targetValue) == 0 &&
checkValue4(targetValue) == 0 &&
checkValue5(targetValue) == 0 ){

ret = true;

}
return ret;
}

最後にもうひとつ、
こちらはオブジェクト指向的な話です。

public class classA(){
public int ValueA = 0;
public int ValueB = 0;
...
}

このようなクラスがあります。

public変数はどのクラスからでも
参照できるものですが、

クラスの依存性が明確になりませんし、
カプセル化の観点からもあまり良いとは言えません。

public変数は
そのクラス内からのみ参照できる
private変数に変更して...

setter、getterと呼ばれる
値の設定と取得を行うメソッドを設定しましょう。

public class classA(){
private int valueA = 0;
private int valueB = 0;

public void setValueA(int _valueA){
valueA = _valueA;
}
public int getValueA(){
return valueA;
}
...
}

...こんな感じですね。

エンジニアとしての質を高める

このように
書き方ひとつで読みやすさが
段違いに変わってきます。

読みやすさが向上すると
メンテナンス性が高まりますので、

長い目でシステムを見た時に
バグが発生する可能性が低くなるのです。

このような
プログラムの取決めは

「コーディング規約」

にまとめられています。

javaの場合は
いくつかの団体が
コーディング規約を公表しています。

日本の企業でも
公表している企業がありますが、

開発経験が長い企業だと
独自のコーディング規約を作っている企業もあります。

プログラムをプロダクトして考えると
プロダクトの質を高めることが大切です。

その質を高めるためには
コーディング規約などによって

読みやすさや適切な処理などを
高める必要があります。

もちろんコーディング規約だけが
質を高める要素ではありません。

システムとして総合的な質を高めるには
プロジェクトの進め方や設計手法など
さまざまな要素の質を高めなければなりません。

全ての質を高めるには
多くの時間と経験が必要になりますが、

まずは基本となる...

「プログラムの質」

...を高めることから
エンジニアとしての意識を高めてゆきましょう。

 

PS

プロフェッショナルになるプログラミング講座はこちらから

ミスのない設計をするには?

From: リスキルテクノロジー 高坂一城
新宿本校にて

ミスのない設計をするには
どうすればいいか?

これは
全てのエンジニアにとって
命題と言っても過言ではないでしょう。

今回は
設計ミスを無くすために
何が必要かをご紹介します。

設計ミスは無くせるか

ミスのない設計をする!

と意識して
いざシステム設計してみたが...

実際には
さまざまな設計ミスが
システムの陰に潜んでいた....

そんな経験を持つエンジニアの方は
多いと思います。

設計ミスは100%無くせるのか!?

答えは残念ながらノーです。

人間が作るものですから
必ずどこかにミスが潜む可能性はあります。

なんだ、
やっぱり設計ミスはなくせないんだ...

なんて思わないでください。

そもそも

「無くせるか無くせないか」

という、
「0」か「1」で考えることに
無理があるのです。

設計ミスを防ぐにあたっては

ミスを無くす!

と考えるのではなく、

設計の品質を高める!

と考える方が遥かに建設的です。

システムと言えども
所詮は人間が作るものです。

言わば「ものづくり」ですね。

どのような
ものづくりでもそうですが、

品質の高いものをつくることが
ユーザーの評価に繋がりますし、

品質の高いものをつくることで
作り手(エンジニア)を育ててくれます。

とはいえ、
もちろん設計ミスは
無いに越したことはありませんよね。

設計ミスを
限りなく0に近づけるとともに

システムとしての
品質を高める姿勢こそが
エンジニアにとって重要なのです。

勘違いしてはいけません

設計品質を高めるために
勘違いしてはいけないことがあります。

それは...

「○○制度を導入しているから品質は高い」

...と言う点ですね。

○○には
設計手法であるとか
設計文書管理の規約であるとか、

テンプレート的な
手法や方法があてはまります。

確かに
一般的に広く使われている
制度や手法を導入することで

品質には一定の
ベースアップが見込めます。

それは非常に大切な事であり
導入することで品質が高まるのであれば
迷わず導入することをオススメします。

ですが、

「それを導入している=品質が高い」

という考えるのは誤りです。

制度や手法は
ある面では大きな効果を生みますが

その制度や手法に
そぐわないアイディアは実行しにくいという
ある種の縛りも生みます。

さらに、
品質を最大限に高めるのは

制度や手法といった
実体のないものではなく、
あくまでエンジニアという人間です。

システム開発を
1人で行うケースは非常に稀です。

制度や手法だけに頼らずとも
さまざまな経験やスキルを持った
エンジニアが必ずそばにいるのです。

制度や手法がもたらしてくれる
メリットを最大限に利用しつつ...

エンジニア同士が協力しあうことで
設計品質を高めることができます。

どうやって品質を高めるのか

設計品質を高めるために
エンジニアに必要な心がけを
いくつかご紹介しましょう。

ある程度の品質が保証されているものを利用する

これは先ほどの
制度や手法のメリットを
利用するということに繋がります。

たとえば設計書であれば
先日ご紹介したUMLを利用するのがいいですね。

UMLは
オブジェクト指向設計のために考案された
モデリング言語ですので、

多くのエンジニアが...

「こんな設計書があれば理解しやすいのに」

というニーズに合わせて
進化し続けている設計書の表現方法です。

また、実装段階では
デザインパターンを利用するのもいいですね。

デザインパターンとは
プログラムを実装する際に

特定のパターンでプログラムを書けば
問題なく実装できるといった
パターン集のことです。

デザインパターンについては
また別の機会に話しますが、

デザインパターンも
多くのエンジニアが
品質向上のために編み出した手法です。

もちろん、
UMLやデザインパターンだけで
ベストだということはありません。

UMLはシステム内外の
処理の流れや仕様を把握できますが、
それだけでは足りないケースも割とありますし、

デザインパターンは
あくまでパターンですので、

実装する時には
システムに合わせる必要があります。

レビューで設計品質を高める

あるエンジニアが設計した内容は
そのエンジニアの視点で作成されたものです。

特定のエンジニア視点だけだと
設計ミスが含んでいる可能性が高まりますので、

多くのエンジニアと設計レビューすることで
設計ミスを0に近づけることができます。

レビューは自分以外のエンジニアの
スキルや視点を反映できるチャンスです。

それだけで
設計品質を大きく高めることができますので、

できるだけ設計レビューの機会を
設けることをオススメします。

ここでひとつ注意したいのが...

レビューの形式化

...です。

レビュー回数が多くなりすぎて
レビューそのものが形式化してしまうと、

折角レビューをしたとしても

「うん、まあ大丈夫だろう」

...と、レビューを受ける側も
細かい判断を放棄してしまうことがあります。

これだと意味がありませんので、
レビューする側は淡々とレビューするだけでなく、

時には他のエンジニアに問いかけるような
工夫を織り交ぜながら行うようにしましょう。

チェックシートを活用する

これ、意外ですけど
結構品質を高める効果はあります。

建設業や旅客業など、
一歩間違えれば大事故に繋がる業種では
今でもチェックシートが活用されています。

システムについて
共通的に考慮すべき事項や、

システム固有の特徴から
チェックする必要がある項目をまとめ、
設計内容をチェックしてゆきます。

品質を高めるために行っていることが
正しく行われたかどうかを確認するフェーズですね。

時間的な問題から
十分に行われていない項目があれば
そこにミスの可能性が含まれている訳ですから、

システム開発で行った行動の
どの部分に懸念材料があるのかを把握できます。

その懸念材料に対して
後日にでも対策することで
高い品質を確保することができるのです。

今やシステム障害が発生したら
何億という被害や
社会的な信頼を失いかねない時代です。

このような大事故を防ぐことができるならば
大きな手間ではありません。

基本はエンジニア間のコミュニケーションです

設計ミスを0に近づけるために
設計品質を高めるためにできることは

他にもたくさんありますし、
企業によってさまざまな工夫が施されています。

いろいろ書きましたが、
やはり基本となるのは
開発チーム内のコミュニケーションです。

制度も手法も
レビューもチェックシートも
活用するのはエンジニアという人ですので、

高度な技術を持っているけど
コミュニケーションに問題があったりすると、
メリットを最大限に引き出すことができません。

実際に
設計書もそこそこしかない
小さなソフトハウスだけれども、

設計ミスやシステム障害が
非常に少ないという企業もあります。

そういうところは
エンジニア間のコミュニケーションが
抜群に良いんですよね。

チームとして意思疎通が取れていて、
スキルの共有もできているので、
設計ミスを早期に発見できるのです。

高い品質のシステムを作る!

という目的意識を持ちながら
開発チームでスキルを共有できる...

それが
最善であり基本となる
設計ミスを防ぐ方法なのかも知れません。

リスキルテクノロジー
松田

PS

プロになるためのプログラミングの講座はこちらから

統一モデリング言語-UMLとは?

From: リスキルテクノロジー 高坂

ソフトウェアの
開発現場においては、

さまざまな手法で
設計書が作成されています。

今回は
最も広く普及している
設計書の表現手法である...

「UML」

...についてご紹介しましょう。

設計書の表現はさまざま

言葉というものは
使い方や言い回しひとつで

さまざまな表現を
することができます。

言葉の使い方は
人によってさまざまですので

極端な話をすれば
100人いれば100通りの表現があります。

では、
プログラムの設計書の場合を
考えてみましょう。

設計書も同じく
100人書けば100通りの
設計書が生まれる可能性はあります。

しかし、
プログラムの設計をするのに
100通りの書き方が存在すると、

必ずしも期待通りの
プログラムが書かれるとは限りません。

プログラマーが読み違えて
設計で意図していない
プログラムが生まれる可能性もあります。

そしてこのような現象は
実際に開発現場で起きています。

さまざまな企業の
開発を経験するSIerや、

転職経験のある
エンジニアならご存知かと思いますが、

開発現場や企業によって
実際に設計書の書き方が
大きく違うというケースは多いのです。

このような

「違い」

...をできるだけ無くし、
統一された書き方が生まれました。

それが...

「UML」

...なのです。

表現を統一すれば理解しやすい

UMLとは

Unified Modeling Language

の略称で...

Unified(統一された)
Modeling(モデリング)
Language(言語)

...という意味です。

「統一モデリング言語」

と和訳されていますね。

オブジェクト指向開発における
統一された設計書の表現方法については

1990年代ごろから
さまざまな方法が考案されてきましたが、

検討を重ねて
それらのさまざまな方法を
ベースにして生まれたのがUMLです。

UMLには多くのメリットがあります。

たとえば
表現方法の統一されている点です。

設計書の表現方法が
統一されているので、

UMLの読み方を理解している
エンジニアであれば
設計仕様を正確に読み取りやすくなります。

また、
UMLは文字だけの仕様記述ではなく、

基本的に図(ダイアグラム)で
仕様を表現しているため、
エンジニアにとって理解しやすいですし、

設計変更が起きた場合でも
どのプログラムを変更する必要があるのかが
把握しやすくなります。

UMLのダイアグラム

UMLには用途によって
いくつかのダイアグラムがあります。

システム構造に関するダイアグラム

■1:クラス図

システムを構成している
クラスの関連性を表現したものです。

あるクラスが
どのクラスとどのような関係があるのか、
どのような変数を保持しているのかなどを
視覚的に理解することができます。

■2:パッケージ図

複数のクラスが集まって
ひとつのパッケージが構成されますが、

そのパッケージの関連性を
表現したダイアグラムです。

■3:オブジェクト図

クラス図ではクラス間の
関連性を把握することができますが、

オブジェクト図では
実際にプログラムが動作する際に
どのような状態になるかを表現します。

システムの振る舞いに関するダイアグラム

■4:アクティビティ図

プログラムの処理の流れを
表現するダイアグラムです。

「フローチャートのUML版」と言えば
理解しやすいかも知れません。

■5:ユースケース図

システムの利用者(アクター)が
システムの利用の仕方や、

システムがアクターに対して
提供する機能を表現します。

■6:ステートチャート図

システムがある処理を行う際、
オブジェクトの状態に
どのような変化が起きるのかを表現します。

ステートチャート図は

「状態遷移図」

と呼ばれることもあります。

システム間の相互作用に関するダイアグラム

■7:シーケンス図

オブジェクト間の連携や
動作の流れを表現するダイアグラムです。

イベントが起きた時に
どのような流れで処理が進むかなどを
表現しています。

■8:コミュニケーション図

オブジェクト間での
メッセージやデータのやりとりを
表現したダイアグラムです。

オブジェクト間で
実際にどのようなデータが
受け渡しされるのかを理解できます。

「コラボレーション図」

と呼ばれることもありますが、
これは古い呼び方です。

習得することをオススメします

この他にも
さまざまなダイアグラムがありますが、

主に使用されているのは
ここで紹介したダイアグラムになります。

これから
プログラムを学ぶ方にとって
UMLを学ぶことは大きなメリットがあります。

UMLはシステムの構成や動作を
俯瞰的に見ることができますので、

プログラムだけでなく
システム全体を理解しやすいのです。

しっかりとした
開発スキルを身に着けたいならば
UMLの習得することをオススメします。

UMLは、
あなたが実際に
プログラムを作る時だけでなく、
設計する時にも役立つ手法なのです。

リスキルテクノロジー
高坂

PS

UMLも学べるプログラミングのスクール

未経験からの育成制度も充実
IT講師に興味はありませんか?

リスキルテクノロジーでIT講師の積極募集を開始! 経験・未経験問わずご応募可能。育成制度で講師スキル向上も目指せます

IT講師に応募する