技術とか戦略とか

IT技術者が技術や戦略について書くブログです。

自社を中心に外部環境を俯瞰する思考フレームワーク「SWOT分析」「3C分析」

自社サービスを展開しているIT企業では、自社のサービス展開に関する戦略を練る必要があります。
優れた戦略を作る上では、それぞれ異なった立場や知見を持つ関係者が集まって、関係者間で思考をまとめるのが有効です。
そして、思考をまとめるのをサポートする手段として、思考フレームワークが数多く発表されています。
 
今回の記事では、自社を中心に外部環境を俯瞰するのに適した思考フレームワークである、「SWOT分析」と「3C分析」について、紹介していこうと思います。
例として、地方銀行向けにレガシーな機関システムを広く提供している企業を挙げます。
 
----
 
SWOT分析
SWOT分析とは、経営環境を分析するために、内部要因(自社)の強み(Strength)・弱み(Weakness)と外部要因(市場)の機会(Opportunity)・脅威(Threaten)を表に書き出す手法です。
 
例としては以下の通りです。

f:id:akira2kun:20220326215158j:plain
 
----
 
【3C分析】
3C分析の「3C」とは、「Company(自社)」「Competitor(競合)」「Costomer(顧客(市場))」の頭文字を取ったもので、この3者について分析することで経営環境を分析する、という手法です。
 
例としては以下の通りです。
 
■自社
地方銀行でも手が出しやすい価格でサービスを提供している
地方銀行の業務に関する独自のノウハウを持っている
 
■競合
地方銀行向け市場に参入しようとする競合他社は今の所は少ない
都市銀行向け市場は他社に既に抑えられてしまっている
パッケージソフトやローコードを用いられた場合はより安価にサービス提供される
 
■顧客(市場)
地方銀行には自社サービスを使ってもらえるが、統廃合で銀行の数が減りつつある
都市銀行は既に自社独自のサービスを抱えている
地方銀行都市銀行に比べて地元密着であり、都市銀行ほど保守的な体質でもない
 
----
 
このように状況を整理すると
「ジリ貧の市場で価格競争をしている」
という危うい現状が見えてくると思います。
 
この現状を抜け出すためには、先端ITを用いて地方銀行の競争力を向上させることが有効です。
地元に特化したサービスで地元での顧客を増やしたり、先進的なサービスで都市部の顧客を増やしたりできれば、地方銀行の競争力を向上させることができます。
 
…このような判断を導きやすくするのが、「SWOT分析」「3C分析」という思考フレームワークです。
思考フレームワークの使い方が重要であるため、思考フレームワークを使ったからと言って適切な判断ができるわけではありませんが、関係者が集まって協議する上で役に立つでしょう。

クリティカルパスとは

この記事は、以前に投稿した下記の記事の焼き直しです。
 
情報処理技術者試験対策「クリティカルパス
https://akira2kun.hatenablog.com/entry/2018/07/08/184908
 
----
 
この記事では、クリティカルパスの説明とその重要さを説明していきます。
 
クリティカルパスの用語説明と重要性】
クリティカルパスとは、プロジェクトを予定通り進める上で最も重要となる作業のことです。
具体的に言うと、少しでも遅れるとプロジェクト全体が遅延する作業のことを指します。
 
プロジェクトを進行する上では様々な作業が発生しますが、遅延してもリカバリーが効く作業と、クリティカルパスとなる作業が存在します。
プロズエクトの遅延を防ぐためには、クリティカルパスとなる作業に対して重点的に遅延対策をすることが重要になりますし、遅延対策を効率的に行う上ではクリティカルパスの特定が欠かせません。
 
クリティカルパスの例】
例えば、「自動発注機能」を開発するプロジェクトを考えます。
 
「自動発注機能」は「在庫確認プログラム」と「需要予測プログラム」と「発注送信プログラム」の3つのプログラムで成り立ち、プログラム開発後のテストも必要だとします。
そして、以下の作業が発生するとします。
 
①在庫確認プログラム 7人日
②需要予測プログラム 10人日
③発注送信プログラム 5人日
④テスト 21人日
 
①②③は並行作業可能でそれぞれ1名、④の作業開始は①②③の3つの作業の終了が前提で3名で作業をするとします。
 
以上の前提の場合、このプロジェクトは17日で完了する予定であり、作業の流れを整理すると以下の図のようになります。

f:id:akira2kun:20220318201246j:plain

 
この場合、クリティカルパスは②と④になります。
①と③はクリティカルパスではありません。
例えば、①の作業で3日完了が遅れても②の作業と同時に終わるので、全体のスケジュールに遅延は発生しません。
また、③の作業の開始が5日遅れても②の作業と同時に終わるので、全体のスケジュールに遅延は発生しません。
しかし、②や④の作業は、予定通りに作業が進まなければ、全体のスケジュールが遅延します。
 
クリティカルパスの作業については、重点的な遅延対策が必要になります。
例えば、こまめに進捗確認して遅延をすぐに検知できるようにする、遅延を引き起こすリスクを前もって対策する(例えば、難易度が高い部分だけスキルが高い要員をヘルプで割り当てる)、要員の作業調整を入念に行う、といった対策が考えられます。
このような遅延対策をピンポイントで行うために、クリティカルパスを特定することが重要になります。

サクラエディタのマクロで大量のコマンドを実行した場合の予期せぬ挙動

この記事は、以下の2記事をまとめたものになります。
 
サクラエディタのマクロ(置換処理記述)をバッチから並列実行すると処理が競合する
https://akira2kun.hatenablog.com/entry/2019/03/11/234403
 
サクラエディタのマクロに大量(500以上)のコマンドを記述すると一部コマンドが実行されなくなる(推測)
https://akira2kun.hatenablog.com/entry/2019/03/12/231720
 
----
 
サクラエディタの Ver2.2.0.1 にて、マクロで大量の処理を行った場合に、以下の2つの事象が発生することを確認しています。
1.サクラエディタのマクロをコマンドラインから並列実行すると処理が競合する
2.サクラエディタのマクロに数百以上のコマンドを記述すると一部コマンドが実行されなくなる可能性がある
 
大量の処理が必要な場合は、C#Java等のプログラミング言語で処理を実装することをお勧めします。
 
以下、事象の詳細です。
 
----
 
【事象1】
■事象名
サクラエディタのマクロをコマンドラインから並列実行すると処理が競合する
 
■事象内容
サクラエディタのマクロは、コマンドラインから実行することができる。
また、コマンドライン実行は、複数のプロセスで行うこともできる。
しかし、複数のプロセスでこれを行うと、お互いのプロセスで処理が競合し、あるプロセスの処理が他のプロセスの処理に影響を与えてしまう。
 
■再現手順
1.以下のように、1000個の置換処理をマクロに記載する。
S_ReplaceAll('hoge1000', 'fuga1000', 62); // すべて置換
S_ReplaceAll('hoge999', 'fuga999', 62); // すべて置換
S_ReplaceAll('hoge998', 'fuga998', 62); // すべて置換



S_ReplaceAll('hoge3', 'fuga3', 62); // すべて置換
S_ReplaceAll('hoge2', 'fuga2', 62); // すべて置換
S_ReplaceAll('hoge1', 'fuga1', 62); // すべて置換
S_ReDraw(0); // 再描画
FileSave( ); // 上書き保存
WinClose( ); // 閉じる
 
2.1で作成したマクロを以下の記事の要領でバッチから起動可能にする。
サクラエディタのマクロをバッチファイルで複数ファイルに対して実行 
https://cyzennt.co.jp/blog/2019/04/13/%e3%82%b5%e3%82%af%e3%83%a9%e3%82%a8%e3%83%87%e3%82%a3%e3%82%bf%e3%81%ae%e3%83%9e%e3%82%af%e3%83%ad%e3%82%92%e3%83%90%e3%83%83%e3%83%81%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%81%a7%e8%a4%87%e6%95%b0/
 
3.処理対象のファイルを用意する
workフォルダ内に、以下のように置換対象の文字を含むファイルを格納する。
hoge1000
hoge999
hoge998



hoge3
hoge2
hoge1
 
4.2~3のフォルダ構成を複数作成する。
tmpフォルダをコピーしtmp2フォルダを作成する。
(バッチファイルの1行目・5行目の記述もフォルダ名に合わせて変更する)
 
5.4の各々のフォルダで同時にバッチファイルを起動させる。
 
6.workフォルダ内のファイルを開き、競合の発生を確認する。
(実行例)
fuga1000
fuga999
fuga998



fuga3
fuga2
fuga1
 
とならず、「hoge951」が「fuga920」になる等不正な結果になる。
 
----
 
【事象2】
■事象名
サクラエディタのマクロに数百以上のコマンドを記述すると一部コマンドが実行されなくなる可能性がある
 
■事象内容
サクラエディタのマクロに600以上のコマンドを記述し、最後に"WinClose( );"を記述した場合、"WinClose( );"が実行されない場合があることを確認した。
コマンド数が多ければ多いほど、PCのスペックが高ければ高いほど、事象が発生する確率が高いと思われる。
 
参考までに、下記のスペックのPCの場合、コマンド数1003で事象が発生することを確認している。
 
・OS:Windows8.1 64bit
・CPU:Inter(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40GHz
・メモリ:8.00GB
・ディスク:SSD 128GB
 
■再現手順
前述のスペックのPCの場合の再現手順である。
 
1.1003個のコマンドをマクロに記述する。
S_ReplaceAll('hoge1000', 'fuga1000', 62); // すべて置換
S_ReplaceAll('hoge999', 'fuga999', 62); // すべて置換
S_ReplaceAll('hoge998', 'fuga998', 62); // すべて置換



S_ReplaceAll('hoge3', 'fuga3', 62); // すべて置換
S_ReplaceAll('hoge2', 'fuga2', 62); // すべて置換
S_ReplaceAll('hoge1', 'fuga1', 62); // すべて置換
S_ReDraw(0); // 再描画
FileSave( ); // 上書き保存
WinClose( ); // 閉じる
 
2.1で作成したマクロを以下の記事の要領でバッチから起動可能にする。
サクラエディタのマクロをバッチファイルで複数ファイルに対して実行 
https://cyzennt.co.jp/blog/2019/04/13/%e3%82%b5%e3%82%af%e3%83%a9%e3%82%a8%e3%83%87%e3%82%a3%e3%82%bf%e3%81%ae%e3%83%9e%e3%82%af%e3%83%ad%e3%82%92%e3%83%90%e3%83%83%e3%83%81%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%81%a7%e8%a4%87%e6%95%b0/
 
3.処理対象のファイルを用意する
workフォルダ内に任意のファイルを格納する。
 
4.2で作成したバッチを起動する
 
5.サクラエディタで開かれた3のファイルが"WinClose( );"により閉じられないことを確認する。

IT業界におけるメンタルヘルス対策

IT業界は、メンタルヘルス不調が出やすい業界であると言われます。
メンタルヘルス不調者が出てしまうと事業に悪影響がありますし、何より心情的に心が痛むものがあります。
 
この記事では、IT業界の特殊な背景と、IT業界でのメンタルヘルス対策について、簡単に書いていきたいと思います。
デリケートな話題ですので、特定の人のメンタルヘルスを悪化させる可能性がある内容は極力控え、客観的な記述を心がけます。
 
1.IT業界でのメンタルヘルス不調の多さ
2020年に「過去1年間におけるメンタルヘルス不調による連続1か月以上の休業をした労働者及び退職者割合(https://www.e-stat.go.jp/stat-search/files?page=1&query=%E3%83%A1%E3%83%B3%E3%82%BF%E3%83%AB%E3%83%98%E3%83%AB%E3%82%B9%E4%B8%8D%E8%AA%BF&sort=year_month%20desc&layout=dataset&stat_infid=000032177262&metadata=1&data=1)」という政府統計が取られました。
この統計によると、1年間でメンタルヘルス不調により1か月以上休業する社員の割合が、インターネット附随サービス業は1.5%、通信業は1.1%、情報サービス業は0.9%あるとされています。100人いれば1人はメンタルヘルス不調により長期休暇を取っているという計算です。
(職場によってはこれより高いこともありますし、長期休暇を取らないまでもメンタルヘルスが不調のまま踏ん張っている社員がいることも予想されます)
これは全業界で1位・2位・3位であり、平均の0.4%と比べるとその高さがわかると思います。
 
2.IT業界にメンタルヘルス不調が多い理由
IT業界に限らず、一般的に「仕事の責任が重くプレッシャーを感じる」「仕事の裁量が少なく自分の仕事を自分でコントロールできない」といった環境では、メンタルヘルス不調が発生しやすくなります。
勿論、各種ハラスメントが横行している職場の場合は、それはメンタルヘルス不調を引き起こす主因になります。
そして、IT業界特有の理由としては、以下のようなものが考えられます。
 
■不規則な勤務が多い仕事である
 IT業界では、長時間残業や深夜作業・休日作業を余儀なくされることがあります。
 開発では納期前に「デスマーチ」と呼ばれる追い込みを強いられることがあります。
 36協定の範囲内でも、1ヶ月100時間弱の長時間残業を強いられる可能性があります。
 また、保守・運用では、システムの都合に合わせた勤務が必要になることがあります。
 システムがサービス時間外となる時間帯でないとできない作業があるためです。
 そのため、深夜作業や休日作業が必要になることがあります。
 更に、緊急のシステム障害の場合は、そのような勤務が予定外で発生します。
 このような不規則な勤務は、プライベートの充実や睡眠時間の確保を難しくさせます。
 当然、メンタルヘルス不調を抱えるリスクは高まります。
 
■孤独感を感じやすい仕事である
 IT業界はPCの前に座っていることが多い仕事であり、直接会話する機会は少ないです。
 また、IT業界に多い客先常駐という形態は、孤独感を強める要素になり得ます。
 客先常駐では自社の社員が居ない・少ないという環境で仕事をするため、
 良く知っている人とのつながりを感じながら仕事をするという形にはなりにくいです。
 コロナ禍でIT業界に浸透したテレワークも、孤独感を強める要素になり得ます。
 テレワークでは非公式のコミュニケーションが発生しにくいため、
 人となりを知りにくくなったり、どう思われているのかわかりにくくなったりします。
 人との繋がりを感じにくく孤独感があるというのは、メンタルヘルスにマイナスです。
 
■褒められることが少ない仕事である
 特に保守・運用に言えることですが、この仕事は縁の下の力持ちな面があります。
 また、システムは動いて当たり前と思われやすいです。
 そのため、システム稼働を維持していたとしても、褒められることは少ないです。
 そして、システム障害を発生させてしまうと怒られてしまいます。
 仕事の中で自己肯定感を感じることが少ないので、メンタルに厳しい仕事と言えます。
 
■変化が激しい業界である
 IT業界で使われる技術は変化が早く、次々と新しい技術が生まれます。
 また、若年者は知識の習得が早い上、教育機関で新技術を学んでくることもあります。
 そのため、現場で最前線に立ち続けるには勉強の継続が欠かせません。
 このことは余暇の時間を減らすことになりますし、プレッシャーにも悩まされます。
 出世やステップアップにより、現場仕事から管理側の仕事へ移行することもあります。
 この場合は、技術の変化に悩まされることは少なくなります。
 しかし、仕事内容が変わることで、人によってはやりがいを失うことがあります。
 
メンタルヘルス不調を抱えやすい社員が多い
 IT業界の技術者には、高い論理的思考力が求められます。
 また、ある種の発達障害の人は論理的思考力が比較的高いとされています。
 そのため、発達障害の人にお勧めの職業として技術者が挙げられることが多いです。
 (実際、従事者も比較的多いと思います)
 しかし、発達障害の人は人とのコミュニケーションに難を抱えることが多いです。
 そのことにより、メンタルヘルス不調を併発することが少なくありません。
 コミュニケーションが少ないIT業界といえども、チームワークは必要です。
 職場に発達障害への理解が無い場合は、メンタルヘルス上リスクとなります。
 発達障害でないとしても、メンタルヘルス上のリスクが高い性格が求められます。
 コンピューターを動かす上では論理性が求められ、曖昧さは許されません。
 そのため、完璧主義な性格が求められる面が出てきます。
 しかし、完璧主義は、メンタルヘルス不調のリスクが高い性格でもあります。
 
3.メンタルヘルス不調の影響
メンタルヘルス不調になった社員は、パフォーマンスが悪くなります。
そして、最終的には休職や退職をせざるを得ない状態になります。
(休職・退職があまりにも多い場合、悪評が立ち採用活動が困難になることがあり、最悪の場合は健康被害のために訴訟に発展することもあります)
 
具体的には、メンタルヘルス不調になった社員には以下の症状が発生します。
 
■前兆となる症状
・勤怠が乱れ始める(遅刻や突休をするようになる)
・声のトーンが暗くなる、ネガティブな発言が増える等、明らかに元気がなくなる
・頭痛が増える、風邪を引きやすくなる等、体調不良が増える
 
■IT業界で良く目にする病名
メンタルヘルス不調の病院での診断名は以下の通りです。

f:id:akira2kun:20220306011228j:plain

なお、メンタルヘルス不調の症状により通常の就労が困難になった場合、精神障害者保健福祉手帳の交付を受けるケースもあります。
日常生活を自力で送れるが就労が困難、という程度の場合は、精神障害2~3級となります。
 
メンタルヘルス不調の治療と経過
メンタルヘルス不調を病院で治療する場合、治療で即効性が高いのは投薬です。
しかし、投薬治療には副作用もあり、眠気といった仕事のパフォーマンスを落とす副作業もあります。
また、病院から診断書をもらい休職を余儀なくされるような強い症状が現れた場合、休職期間を終えて復帰しても再び休職してしまう可能性が少なくありません。復帰を急ぐ場合は特にその傾向が強くなります。
仕事の中で強いストレスを感じる経験をしてしまっており、仕事をする中でその経験が想起されるので、周囲の理解とサポートがなければ復帰は難しいものになります。
 
4.メンタルヘルス不調の対策
一般的に、メンタルヘルス不調への対策は以下のようなものになります。
 
■セルフケアの推進
研修を通して、各々の社員に以下の知識を身につけさせることで、メンタルケアを各々の社員自身で行うことができるようにし、メンタルヘルス不調の減少に期待できます。
研修で伝える内容は、厚生労働省医療機関等の信頼できる機関が発信する情報に準ずることが望ましいです。
・ストレスやメンタルヘルスに関する正しい知識
・ストレスマネジメントやメンタルケアの方法
 
■職場でのメンタルヘルス対策の実施
メンタルヘルス不調を招くような要素を取り除いたり緩和したりする対策を職場で行うことも重要です。
例えば、深夜の労働時間が長くなりすぎないように勤務時間をシフトするのは良い対策です。
ただし、良かれと思った対策に効果が無い/逆効果となることも良くあるので注意が必要です。少なくとも、他人の気持ちがわかることを前提とした対策は厳禁です。見た目や口先だけで他人の内面を知ることは極めて困難ですし、本当にメンタルヘルス不調の場合は自尊感情が損なわれているケースが多くデリケートな対応が必要だからです。
コミュニケーションを活発にしたり本音を聞き出したりするためにメンタルヘルス不調対策のつもりで飲み会に誘う、というのは日本の職場では見られがちですが、飲み会でストレスを感じるやりとりがされたり睡眠時間が削られたりして逆効果になる可能性があります。
職場で適切な対策を行うためには、上長にメンタルヘルスに関する正しい知識が必要です。
 
■会社全体でのメンタルヘルス対策の実施
メンタルヘルスは敏感で難しい分野ですので、職場での自助努力だけではなく、外部の専門家や社内の専門担当者、例えば、産業医や衛生管理者、保健師、人事・労務担当者が支援することも重要です。
全社的な施策や、長時間労働者へのヒアリング、職場でのメンタルケアのサポート、外部機関との連携等は、このようなポジションの人物でないと実施が難しいです。
 
■社外機関を用いたメンタルヘルス対策の実施
厚生労働省中央労働災害防止協会、商工会議所、健康保険組合といった社外の機関もメンタルヘルス対策を推進しています。
具体的には、産業保健情報の提供、健康相談窓口の開設、アドバイザーや講師の個別訪問、といった活動に取り組んでいます。
社内だけではリソースやノウハウが足りない場合は、こういった社外機関によるサポートを得ることも重要でしょう。
下記のような助成金制度を利用することもできます。

f:id:akira2kun:20220306011248j:plain

 

for文を書けない・使いこなせない方に向けて

for文は意外と理解が難しく、ここで躓いた経験がある人は決して少なくありません。
for文の文法を理解していたとしても、for文を使うべき箇所で使えていないこともあります。
 
プログラムの基本は「順次」と「分岐」と「反復」ですが、for文は最後の「反復」にあたります。
今回の記事では、「反復」について、その使い所を一つずつ順を追って説明していきます。
説明の際には、画面に特定の文字を出力する例を挙げていきます。
 
----
 
まず、以下のように文字を出力する例を考えてみます。
☆★
 
これは、以下のようにプログラミングすれば出力できます。
「☆」を出力する
「★」を出力する
 
----
 
次に、以下のように文字を出力する例を考えてみます。
☆★☆★☆★☆★☆★
 
先ほどと同じ要領で、以下のようにプログラミングすれば出力できます。
「☆」を出力する
「★」を出力する
「☆」を出力する
「★」を出力する
「☆」を出力する
「★」を出力する
「☆」を出力する
「★」を出力する
「☆」を出力する
「★」を出力する
 
----
 
しかし、この書き方では、出力する文字数だけプログラミングする量が増えてしまいます。
仮に100文字出力する場合、100行書く必要が出てきてしまいます。
 
このような場合、「反復」の出番です。
「反復」を用いることで、プログラミングする量を減らすことができる場合があります。
「プログラミングする量を減らすことができる場合」とは、「法則がある場合」です。
 
今回の例で言うと
・最初に「☆」を出力する
・次に「★」を出力する
というパターンが繰り返されている、という法則があります。
 
この法則を「反復」というパターンでプログラミングすると、以下のようになります。
繰り返し開始
 「☆」を出力する
 「★」を出力する
繰り返し終了
 
----
 
しかし、先ほどのようにプログラミングしてしまうと、以下のように出力されています。
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★…(以降繰り返し)
 
本当は10文字分、つまり5回分だけ繰り返して欲しいのですが、そうはならずに、処理が繰り返され続けてしまいます。
これは、「無限ループ」と呼ばれるバグであり、実務でも良く見るバグです。
 
これを防ぐためには、「反復」を止める条件を書く必要があります。
イメージとしては、以下のようにプログラミングする必要があります。
繰り返し開始(5回分だけ)
 「☆」を出力する
 「★」を出力する
繰り返し終了
 
----
 
「反復」を止める条件、先ほどの例で言うと「5回分だけ」という部分に関しては、いくつか書き方があります。
for文の場合は、以下の式を使って条件を指定します。
・初期化式…繰り返しを始める前の処理
・条件式 …繰り返しを続ける条件
・変化式 …1回の繰り返しが終わる度に実行される処理
 
これらの式を記述する上では、「ループカウンタ」と呼ばれる値を用いることが多いです。
ループカウンタとは、今が何回目の繰り返しなのか、というのを示す値です。
1回目の繰り返しなら「1」、2回目の繰り返しなら「2」…といったように増えていく値です。
 
これらの式を使って「反復」を止める条件を書くと、以下のようになります。
繰り返し開始
初期化式:ループカウンタを1にする
条件式 :ループカウンタが5以下なら処理を続ける
変化式 :ループカウンタを1増やす
 「☆」を出力する
 「★」を出力する
繰り返し終了
 
このようにプログラミングした場合、以下のように処理が行われます。
・繰り返しの最初でループカウンタが1になる
・繰り返しの中の処理で「☆」と「★」を出力する
・繰り返しが終わる時にループカウンタを1増やして2にする
・ループカウンタが5以下なので繰り返しを続ける
・繰り返しの中の処理で「☆」と「★」を出力する
・繰り返しが終わる時にループカウンタを1増やして3にする
・ループカウンタが5以下なので繰り返しを続ける
・繰り返しの中の処理で「☆」と「★」を出力する
・繰り返しが終わる時にループカウンタを1増やして4にする
・ループカウンタが5以下なので繰り返しを続ける
・繰り返しの中の処理で「☆」と「★」を出力する
・繰り返しが終わる時にループカウンタを1増やして5にする
・ループカウンタが5以下なので繰り返しを続ける
・繰り返しの中の処理で「☆」と「★」を出力する
・繰り返しが終わる時にループカウンタを1増やして6にする
・ループカウンタが5以下ではないので繰り返しを終える
 
----
 
ループカウンタは、繰り返しの中の処理で使うこともできます。
そうすることで、より複雑な処理を書くことができるようになります。
 
例えば、最初の繰り返しだけ「☆」と「★」の代わりに「□」と「■」を出力したいとします。
出力のイメージは以下です。
□■☆★☆★☆★☆★
 
このように出力したい場合、以下のように繰り返しの中でループカウンタを使って分岐条件を書くことで、上手くプログラミングすることができます。
繰り返し開始
初期化式:ループカウンタを1にする
条件式 :ループカウンタが5以下なら処理を続ける
変化式 :ループカウンタを1増やす
 もしループカウンタが1の場合は
  「□」を出力する
  「■」を出力する
 そうではない場合は
  「☆」を出力する
  「★」を出力する
繰り返し終了

コーディング中のバグ対応の一般的な手順

コーディングにおいては、実行時に見つかる些細なバグの対応がつきものです。
バグの対応を素早く行うことができれば、コーディングも早く行うことができるようになります。
 
今回の記事では、バグ対応の一般的な手順を説明しようと思います。
手順を大まかに書くと、以下のような手順になります。
1.バグの発生箇所を特定する
2.バグの原因を確認して取り除く
 
例として、「0~9の範囲の値を実行する度にランダムに表示する」というプログラム(モジュール)をJavaでコーディングしながら説明していきます。
 
----
 
まず、コーディングを一通り済ませてみました。
このソースコードにはバグがあり、実行すると「NullPointerException」という例外が出力され、処理が途中で止まってしまいます。
以降で、バグの原因を特定して、バグを取り除いてみます。
 
【サンプルコード1】
・NullPoTest.java
import java.util.Random;

public class NullPoTest {

    public static void main(String args) {

        // Randomクラスのオブジェクトを生成する
        Random random = null;

        // ランダムな値を生成する(0~9)
        int outputValue = random.nextInt(10);

        // 生成した値を表示する
        System.out.println(outputValue);

    }

}
 
【実行結果】
Exception in thread "main" java.lang.NullPointerException
    at NullPoTest.main(NullPoTest.java:11)
 
----
 
まずは、「1.バグの発生箇所を特定する」の手順を実施していきます。
 
実装や環境を問わずに実施できる方法としては、「デバッグ表示の行を入れ込み、どこまで通っているのかを確認する」という方法です。
今回の例では、この方法で「Random random = null;」まで処理が通っており、「int outputValue = random.nextInt(10);」が通っていないことを確認することができます。
また、今回の例では実施していませんが、デバッグ表示の行の中で変数の値を出力し、変数がどのような値を取っているのかを確認するのも良い方法です。
 
なお、実装や環境は問いますが、以下のような方法も有効です。
スタックトレースに表示される行数を手掛かりにする(実は、今回の例では、エラーメッセージ中に「NullPoTest.java:11」と出ているので、それを手掛かりにすることもできます)
IDEEclipse等)のデバッグ機能を用いる
ソースコード中でエラーメッセージの文言を作っている場合は、その文言でソースコード中を検索する
 
【サンプルコード2】
・NullPoTest.java
import java.util.Random;

public class NullPoTest {

    public static void main(String args) {

        System.out.println("チェックポイント1");

        // Randomクラスのオブジェクトを生成する
        Random random = null;
        System.out.println("チェックポイント2");

        // ランダムな値を生成する(0~9)
        int outputValue = random.nextInt(10);
        System.out.println("チェックポイント3");

        // 生成した値を表示する
        System.out.println(outputValue);

    }

}
 
【実行結果】
チェックポイント1
チェックポイント2
Exception in thread "main" java.lang.NullPointerException
    at NullPoTest.main(NullPoTest.java:14)
 
----
 
バグの発生箇所を特定できたので、次は「2.バグの原因を確認して取り除く」を実施していきます。
 
NullPointerException」をWebで調べてみると「参照先が無い(nullを示している)参照型変数を参照した場合に発生する」という類のことが出てくると思います。
オブジェクト指向言語に慣れていないと説明だけ読んでもわからないかもしれませんが、Webの記事の中にサンプルコードが併記されていることも多く、それを読むと理解の助けになると思います。
今回のソースコードでは、「Random random = null;」という箇所で参照型変数「random」にnullを代入しているのが原因のため、ここを修正し、新たなオブジェクトを割り当ててそれを代入することで、バグを解消することができます。
 
これはJavaの言語がエラーメッセージを出している場合の調査方法ですが、他のバグの場合は調べ方が変わってきます。
例えば、出力される値が期待する値と異なる場合は、計算がどこで間違っているのかをソースコードを追ったり変数の値をデバッグ表示でこまめに出力したりしながら確認していくことになります。
また、ソースコード中でエラーメッセージの文言を作っていてそれが出力された場合は、そのエラーメッセージが何を示しているのかを仕様書等を参考に確認していくことになります。
 
知識や経験が少ないと、調べても原因の特定に至らない場合があります。
類似処理を別のソースコードで行っている場合は、その類似処理と見比べることで原因を特定できる場合もあるので、それを試してみましょう。
それでもわからない場合は、無理をせずに他の人に聞いてみると良いでしょう。既に、発生箇所を特定し、原因調査も途中までは済ませているため、あまり時間を取らせずにスムーズに回答を得ることができます。
 
【サンプルコード3】
・NullPoTest.java
import java.util.Random;

public class NullPoTest {

    public static void main(String[] args) {

        // Randomクラスのオブジェクトを生成する
        Random random = new Random();

        // ランダムな値を生成する(0~9)
        int outputValue = random.nextInt(10);

        // 生成した値を表示する
        System.out.println(outputValue);

    }

}
 
【実行結果】
5

情報処理技術者試験対策:DNSキャッシュポイズニング・カミンスキー型攻撃

この記事では、「DNSキャッシュポイズニング」と呼ばれる攻撃手法と、その発展型である「カミンスキー型攻撃」について説明します。
これは情報処理技術者試験では頻出のキーワードであり、特に情報処理安全確保支援士試験を受験する際には内容を抑える必要があります。
 
----
 
DNSキャッシュポイズニング」と呼ばれる攻撃手法を理解するためには、まずDNSの仕組みを理解する必要があります。
Webの世界ではサーバーにアクセスするためにアクセス先のIPアドレスを知る必要がありますが、URLで良く使われるのはドメイン名です。
ドメイン名からIPアドレスを得るためには、ドメインを管理しているDNSサーバーにアクセスする必要があります。
DNSサーバーは階層型になっており、自身で管理していないドメインについては上位のDNSサーバーにアクセスすることでIPアドレスを得る仕組みになっています。

 
ここで、DNSサーバーは、上位のDNSサーバーへのアクセスの頻度を減らすために、上位のDNSサーバーから得た応答結果は、一定期間、キャッシュに保持します。
再度同じ問い合わせが来た場合は、キャッシュを見て応答することになります。

 
----
 
ここからが「DNSキャッシュポイズニング」の説明になります。
 
DNSキャッシュポイズニングは、上位のDNSサーバーからの応答を攻撃者が偽装する、という攻撃手法です。
応答を偽装することで、攻撃者が意図するサーバーにアクセスさせることが可能となり、当該ドメインを当該DNSサーバーへ問い合わせた利用者に被害を与えることができます。

 
そして、この問い合わせ結果は、DNSサーバーのキャッシュに保持されます。
このキャッシュが残っている限り、後の利用者にも被害を与えることができます。
DNSキャッシュポイズニング」という名の通り、DNSサーバーのキャッシュを汚染することで、攻撃が成立します。

 
----
 
しかし、DNSキャッシュポイズニングを仕掛けるのは現実的には困難です。
上位のDNSサーバーへの問い合わせが発生する瞬間、つまりキャッシュの有効期限が切れた瞬間を狙って攻撃しなければならないため、DNSキャッシュポイズニングを仕掛ける機会がなかなか訪れません。
 
ここで、情報セキュリティ研究者のカミンスキーが公開した「カミンスキー型攻撃」と呼ばれる発展型の攻撃手法が使用されることになります。
この攻撃手法では、攻撃者自身が攻撃対象のDNSサーバーに対して、ランダムで生成したドメイン名(キャッシュに保持されていないはずのドメイン名)を問い合わせることで、上位のDNSサーバーへの問い合わせを発生させます。
この攻撃を繰り返すことで、DNSキャッシュポイズニングを仕掛ける機会を増やすことができてしまいます。
この攻撃に成功してもランダムに生成されたドメインがキャッシュに保持されるだけですが、キャッシュに保持された情報を利用することで、DNSサーバーの利用者に実質的な被害を与えられる可能性があります。

 
----
 
カミンスキー型攻撃を含むDNSキャッシュポイズニングの対策としては、DNSサーバー側に以下の手段を講じることが有効です。
 
DNSサーバーが問い合わせを受け付ける範囲の限定する
 自ネットワーク以外からの問い合わせを拒否することで、
 外部の攻撃者からの攻撃されることを防ぐ。
 
・ソースポートランダマイゼーションを行う
 上位DNSサーバーへの問い合わせには、通常はTCP/UDPの53番ポートが使われる。
 このポート番号をランダムなものに変更することで、
 攻撃が成立する可能性を減らすことができる。
 
・DNSSECを導入する
 DNSSECとは、DNSサーバからの応答が正当かを確認する方式を定めた規格である。
 これを導入することで、応答の偽装を困難にする。
 
----------------------
 
情報処理技術者試験に関する記事の目次
https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM