システムのトラブルシューティング

From: リスキルテクノロジー 松田航
新宿本校にて、、、

システムの開発中やリリース後に
何らかのトラブルが起きることはあります。

特にリリース後であれば
本来あってはいけないことですが...

トラブルが発生した場合は、
早めに問題を修正するのが重要なポイントです。

トラブルの原因を調査して解決することを
トラブルシューティングと言います。

今回はトラブルシューティング方法について
お伝えしましょう。

トラブルの原因は必ずどこかにあります

システムは思った通りに
動いてくれないことがよくありますが、

作った通りにはきちんと動いてくれるものです。

作った通りに動くということは
トラブルの原因は必ずどこかにあるのです。

プログラムの例で言えば
バグの種類は大まかに分けて2種類あります。

ひとつは
エラーが発生してシステムが動かなくなるケースで、

特定の処理ができなくなったり
最悪の場合はシステム全体が止まってしまいます。

そしてもうひとつは
エラーは発生しないけど
システムが誤った結果を出してしまうケースですが、

実はこちらの方がトラブルとしては怖いのです。

例えば消費税の計算で
8%で計算しないといけないところを
5%で計算してしまっている場合、
請求書の金額やデータベースの登録内容が間違ってしまいます。

このような場合はエラーが出ないので、
バグに気付くのが遅くなってしまうのです。

プログラムでもサーバー構築でも、
テストをしっかりと行うことが大切ですが…

それでも起きてしまったトラブルは、
どうやって解決してゆくのでしょうか?

トラブルシューティングってどうやるの?

プログラムの場合は、
エラーが発生している場合は
エラーメッセージやログファイルを見ます。

これらには、どこでどのような原因で
エラーが発生したのかが詳しく記録されており、

その情報をもとに
エラーの原因を解析するのが基本です。

しかし、

エラーの発生場所と
エラーの原因を生み出している場所が
必ず同じという訳ではありません。

エラーが発生するもっと前の処理で
エラーの原因を作ってしまっている場合もあります。

その時に行うのが
「ステップ実行」という開発ツールの機能で、

プログラムを1行ずつ実行させて、
データの内容や処理結果を確認しながら実行できます。

エラーが発生しない種類のバグだと、
ステップ実行で確認しないと原因がつかめません。

サーバートラブルの場合も、
基本的にはログファイルの解析から始まります。

例えば...

Webサーバーがうまく動かない!
メールを送っても送信されていない!

...などといった場合、
Webやメールサービスのログファイルを確認します。

プログラムの場合と同じで、
ログファイルにエラー内容が書かれていますので
そこから原因を調査してゆくのが基本です。

ただし、サーバーの場合は
物理的なトラブルが原因となる場合もあります。

ハードディスクが破損したとか、
電力不足でサーバーダウンするなど、
物理的な原因も含めて調査しなければいけません。

原因不明のトラブルの場合はどうする?

プログラムや設定ファイルを見ても、

特に問題がない...

一見すると原因不明の
トラブルが発生する場合もあります。

プログラムの場合だと
AさんのPCだと問題なく動くのですが、
BさんのPCだと計算結果が違うといったケースですね。

そのようなケースでは
OSやサービスのバージョンが、
正しいものを使っているかどうか調べましょう。

バージョンが違っていると
動きが変わってくるケースもありえます。

他にも調査ポイントはありますが、
それでも原因不明の場合は
ベンダーにサポートを依頼して原因を究明しましょう。

しかし、ベンダーにサポートを依頼した場合、
原因がわかるまでに時間がかかります。

特にリリースしている
システムのトラブルであった場合は、
早急にトラブルを解決しなければいけません。

原因がわかるまでに時間がかかる場合は、
一時的なプログラムの修正や、
代わりのサーバーを用意するなどの対策が必要です。

エンジニアの価値を高める
トラブルシューティングスキル

バグやエラーの対処方法は
エンジニアが習得しておきたいスキルのひとつ。

トラブルシューティングのスキルが
高いのと低いのでは、
エンジニアとしての価値が格段に変わってきます。

さまざまなトラブルは
開発者の作業やユーザーの業務を途中で止めてしまう、

つまり、

発生するだけで損失を与えてしまっているのです。

損失を最小限に抑え、
トラブルをできるだけ早く解決して
通常の業務を進めてもらう...

それが生産性の向上に繋がるのです。

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

PS

どんな機械でも
使っているとあちこち痛んできます。

システムでもそれは同じこと。

トラブルがない方がもちろんいいのですが、
万一の時は素早く対処できる方がいいですし、
ユーザーの信頼も失わずに済みます。

システムエンジニアになるならリスキルテクノロジー

ハイブリッド型開発とは? (WF + アジャイル)

From: リスキルテクノロジー 松田航
新宿本校にて、、、

これまで、
ウォーターフォールモデル開発(以下「WF」)と
アジャイル開発(以下「アジャイル」)についてご紹介しました。

それぞれに特徴はありますが
ではどのような点が異なっているのでしょうか?
今回はWFのアジャイルの違いについて説明しましょう。

また、最近では
WFとアジャイルそれぞれのメリットを活かせる...

「ハイブリッド型開発」

...という開発手法も注目されています。

ハイブリッド型とはどのような開発手法なのでしょうか?

ウォーターフォールとアジャイルの違い

WFとアジャイルの違いについて表にまとめました。

アジャイルとウォーターフォール

1.開発文化

WFはプロジェクトの制御や命令系統を重視しますが
アジャイルはプロジェクトチームの協力を重視します。

組織的な統制を重視するのがWFであり
協業による自由な結合を重視するのがアジャイルです。

2.計画・管理

WFは統制を重視するため、
開発計画を立てやすくプロジェクト管理が行いやすい。

対してアジャイルは柔軟な変化に対応すべく
案件や規模に応じての管理を行うため、管理方法には工夫が必要です。

3.仕様変更

WFは基本的に仕様変更しないことが前提。
変更が発生すると後工程に大きな影響を与えますが、
アジャイルは柔軟な仕様変更にも対応できるような手法です。

4.ドキュメント

WFは工程別に成果物として
ドキュメントの作成が必須要件になっています。

対してアジャイルでは
不必要なドキュメントは極力作りません。

「アジャイルではドキュメントを全く作らない」

という誤解を持っている方もいるのですが
実際には開発において最低限必要なドキュメントは作成します。

というより、きちんとしたアジャイル開発では、
ドキュメントは必須です。

5.ユーザー承認

開発費用の支払は
ユーザー承認のタイミングで行われる事が多いですが、
WFはドキュメント等の成果物をもって承認を受けます。

対してアジャイルでは
実際に動作するアプリケーションをもって承認を受けます。

6.プログラム

WFでは要件定義~詳細設計の上流工程で設計された
全機能を一気にプログラミングします。

アジャイルではあらかじめ
優先順位で定められた機能を順番にプログラミングします。

ただ、小規模な開発案件の場合は
一気にプログラミングを行うケースもあります。

7.リリース

WFでは原則的に全機能を一度にリリースします。

ただし、リリース計画によっては
サブシステム単位にリリースするケースも。

アジャイルではイテレーション毎にリリースを行い、
ユーザーからのフィードバックを受け、次のイテレーションに移ります。

8.開発規模

WFは計画、管理のしやすさや
指揮系統が重視されることから大規模開発に向いています。

アジャイルは小規模開発向きですが
最近では管理方法なども工夫されつつあり
大規模なシステム開発にも採用される傾向にあります。

見える開発、見えない開発

WFとアジャイルの違いをまとめましたが
もうひとつ大きな違いとして...

「ユーザーから見える開発・見えない開発」

...という特徴があります。

WFでは要件定義や基本設計、
そして総合テストやユーザーテストなど
上流工程と下流工程においては開発の動きが見えやすいですが...

詳細設計や製造、単体テストなど
開発チームが主体となってしまうフェーズでは
どのような開発を行っているのかユーザーからは見えにくいのです。

対してアジャイルでは
原則的にユーザーも開発チームの一員とすることから、
開発中でもどのような開発を行っているのかが見えやすい。

大型の長期案件ともなると
WFで開発されることが多いのですが、
製造などの中流工程になるとユーザーによっては...

「ちゃんと開発は進んでいるのだろうか?」

...といった不安を抱くケースも。

不安を払拭する為に
定期的な進捗報告などは行うのですが、
開発やテスト内容が見えないというのは変わりありません。

ユーザーは後から成果物で
開発結果やテスト結果を知るのみです。

では、アジャイルの方が
ユーザーにとって安心かというと、そうでもありません。

確かに開発中の動きが見えるのは良いのですが...

WFの様に最初から綿密に要件定義などを行うのではなく、
優先順位別に開発・リリース・フィードバックを繰り返すため...

見えるからこそ、
変更が頻発して要件が膨れすぎたり、
他機能との整合性が取れなくなったりするケースも。

また、システムの最終形が完成するのは
複数回のイテレーションを繰り返した後になることから、
総合テストなど、他機能と連携したテストを行いにくいという特徴も。

このような理由により、
アジャイルは小規模開発向きと言われているのです。

それぞれのメリットを最大限に発揮する
ハイブリッド型開発とは?

WFは上流工程と下流工程、
アジャイルは中流工程における変化に強い。

最近では、
それぞれのメリットを活かした手法として...

「ハイブリッド型開発」

...という開発手法があります。

これは要件定義や基本設計、総合テストなど
WFが得意とする上流工程や下流工程はWFで行い...

詳細設計や製造、単体テストなど、
アジャイルが得意とする中流工程はアジャイルで開発するというもの。

ハイブリッド型開発の流れを簡単に説明すると...

(1)要件定義
(2)基本設計
(3-1-1)機能A 詳細設計
(3-1-2)機能A プログラミング
(3-1-3)機能A 単体テスト
(3-1-4)機能A ユーザーフィードバック
(3-2-1)機能B 詳細設計
(3-2-2)機能B プログラミング
(3-2-3)機能B 単体テスト
(3-2-4)機能B ユーザーフィードバック
 …
<(3)は必要に応じてイテレートを行う>
 …
(4)結合テスト
(5)総合テスト・ユーザーテスト
(6)リリース

...といった流れで開発が進みます。

WFのデメリットである...

・フィードバックが少なく、変更対応に弱い
・開発内容が見えにくい

アジャイルのデメリットである...

・開発管理を行いにくい
・上流工程、下流工程に弱い

ハイブリッド型においては
このようなWFとアジャイルのデメリットをカバーし、
それぞれのメリットを活かした開発を行えるのが特徴です。

開発手法にのみ捉われてはいけない
トータル的なシステム開発サービスの品質が大切

企業における
ビジネススピードは加速しており、
システム開発側もそのスピードに対応すべく、
さまざまな開発手法が検討されています。

ハイブリッド型も
そのような風潮から生まれた手法のひとつであり、
アジャイル体制を構築しにくいと言われる
SIerでも注目されています。

しかし、
WFが良い、アジャイルが良い…というように
開発手法にばかり目が行ってしまうのも問題です。

開発の進め方については
ユーザーに提案し、きちんと説明することが大切。

そして開発中には
ユーザーに不安を抱かせず、
不透明な部分ができるだけないように進めることも重要です。

自社のアプリケーションであれば、
内部のエンジニアの総意を汲み取って決めるべきでしょう。

アジャイルはひとりが理解していないと、
その時点で崩壊しがちです。

手法も確かに大切ですが、
エンジニアが考えるべきは...

・ベストプラクティスなシステム
・アプリケーションの品質
・柔軟性
・スピード

...などといった...

「トータル的な品質」

であるという事を忘れないでください。

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

PS

どの業界でもそうですが
ユーザーに提供するのはトータル的な品質です。

いくら品物が良くても
売り手の対応が良くなければ、
それはユーザーにご提供するサービスとして
品質が低いと言わざるを得ません。

講師・テキスト・環境 すべてが揃ったシステムエンジニア研修

デスマーチとは?

From リスキルテクノロジー 松田航
新宿本校にて、、、

『デスマーチ』という言葉は知っていますか?
今回はデスマーチについて話をしましょう。

IT業界だけではない
社会問題化しているデスマーチ

「デスマーチ」というのは
アメリカのプログラマーが提唱した
プロジェクトマネジメントに問題が発生している状態。

日本では略して「デスマ」とも言われています。

日本語にすれば、文字通り...

「死の行軍」

を意味し、
進んでも進んでも解決しない...

つまり、どれだけ開発を行っても
なかなかシステムが完成しない状況を意味します。

具体的に言えば、以下の様な状況に陥っています。

・残業時間が極端に多く、月間労働時間が300~400時間にも

・休日出勤は当たり前で、休みが取れない

時間がいけないというよりかはこれだけ働いても、
進まないことが問題でしょうか。

また、自らの意思がないことも。

私自身は上記2つとも、
常にやっていますね。
好きで。

個人的な話はおいておき、
このような状態が長期間続くことにより
プログラマーを始め多くの開発者が心身共に疲労しきってしまい...

体調不良で出勤できない者、
翌日から連絡なしに急に来なくなる者、
心の病になってしまう者など、脱落者が出るケースも。

まず、最初にお断りしておきますが、
この事象はIT業界に限ったものではありません!

むしろ業界は関係ありません。

どちらかというと
昔はIT業界でこのような状態が目立った為、
最近のIT業界ではデスマーチを避ける努力が行われています。

業界を問わず、
企業によってデスマーチと同様の事象が起きており、
社員が過重労働が強いられて労災問題にまで発展するなど、
近年、重大な社会問題とされているのです。

デスマーチはなぜ起こるのか?

デスマーチが発生する理由はさまざま。

ですが、最も簡単に表現するなら...

「安請け合いと状況把握能力の欠如」

...という言葉が妥当な表現になります。

IT業界において
デスマーチが発生する原因をいくつか挙げてみましょう。

(1)開発期間不足の問題

本来開発に1年は必要な案件を...

「3か月でできます!」

...と顧客に応えて受注してしまった。

つまり開発期間が圧倒的に足りていない。

(2)人的要員の不足

どう少なく見積もっても
SE2名、PG5名はプロジェクトに必要であるが、
実際にはSE兼PGが1名と初級PG2名しか要員が確保できない。

つまり開発に必要な人手が足りない。

(3)予算が足りない

開発に対する予算がなく
外部から開発要員を雇おうにも雇えない。

また開発するには
特殊な機器や必要となるが
それらを購入・レンタルする予算がない。

つまり開発に必要な運転資金がない。

(4)ユーザーニーズが多すぎる

ユーザーが開発システムに対し、
あの機能もほしい、この機能も欲しいと
多くの機能的な要求を提示してくることにより、
対応しなければいけない機能が膨大な量に膨れ上がる。

また、一度作った機能に対しても...

「やっぱりこうしてほしい!」

...と、頻繁に仕様変更を行うため、プログラム変更が頻発する。

つまり開発期間や開発要員、開発費用など、
それらに見合うもの以上の要求がユーザーから発生している。

デスマーチという状態は
これらの要素が複雑に絡み合って発生します。

共通しているのは、
ユーザーと話す立場の者(営業やプロジェクトマネージャなど)が...

・受注さえすれば何とかなる
・ユーザーの要求を鵜呑みにする
・現場の状況を把握できていない

...という傾向がある場合に
デスマーチは発生しやすくなります。

戦略案件という名のデスマーチ

しかし、あえてリスクを理解した上、
デスマーチ覚悟で案件を受けるケースもあります。

それは「戦略案件」と呼ばれる案件を
受注する場合です。

戦略案件とは、
今まで取引のなかった企業から
何とかしてシステム開発を受注したい場合や、
その企業と取引を開始することによって、
今後も継続的な受注が見込めそうな場合に言われる名称です。

例えば全国展開する
大手量販店の人事システム改定案件があったとしましょう。

システムの老朽化により
大手量販店がシステム改定を検討しており、
できるだけ安く、早くシステムを導入してくれる企業を探しています。

営業担当が何度か足を運び
SEも技術的はサポートとして営業同行し、
競合他社も多数ある中、最終候補企業にまで残ることができました。

大手量販店から要求された
予算と開発期間は、開発に必要な費用と開発期間を
大幅に不足していました。

今後のお付き合いができるなら!
運用保守まで当社にお任せいただけるなら!

いろいろな条件交渉をしつつ、
開発期間不足や赤字を覚悟した条件で
受注してしまうケースもあるのが現状です。

ここからがデスマーチの始まり。

要員の確保、
予算や運転資金の問題、
開発期間不足にともなう不十分なテストなど...

自らリスクを
わざわざ多くしているようなものです。

プロジェクトマネージャの手腕や
開発チームのスキルなどにもよりますが、
何らかのトラブルが発生するのは目に見えています。

もちろん、うまく納品できれば
戦略案件としては成功で万々歳なのですが...

だいたい何かしらの問題が発生します。

それでも取るのが、営業です。
また経営者もこちら側でしょう。

どちらの立場もわかる身としては、、、
うーん、でもまぁ取るでしょう。

やっぱり。

しかし、

ただ突き進むのだけはNG!
常に分析・提案を意識しながら進みましょう

一回経験しておいた方が、
確実に力はつきます。

なので、まだまだ経験が浅いうちは、
とりあえず頑張りましょう。

しかし、これが恒常的になると
よくありません。

IT技術者の飲み会などでは
デスマーチの経験自慢が聞かれることが
ままあります。

「あのプロジェクトでは月400時間いった」
「ええ!?400は行き過ぎでしょう?」
「負けた!俺は300時間程度しか経験ないや」

過酷な労働状況や
難しい案件を乗り切った場合、
困難を克服した達成感に満たされ、
このような話も出るのでしょう。

しかし、
働く時間が自慢の種になっている時点で
アウトです。

また、デスマーチは
マネジメントの観点から見ると、
明らかに失敗している状態であると言えます。

もし、あなたがIT技術者になって
デスマーチを迎えてしまった時には...

・何が原因となったのか?
・被害を最小限に抑えるにはどうすれば良いのか?
・人、物、金、時間のどれがボトルネックになっているのか?
・顧客に別の提案することで、被害を少なくできないか?
・開発チーム内だけで解決できない場合は全社問題として検討できないか?

...このような現状分析や提案事項の検討を
怠らないようにしてください。

ただあふれ出る作業に対応して乗り越えるだけでなく、
次に同じような状況を出さない為にはどうすれば良いか?

常に考えながら対応することを心がけてください。

常に考え続けることにより、
トラブルの対応方法を知ること、
トラブルを未然に防ぐ方法を知ること、
それこそが、何百時間働いたという充実感に勝るあなたの力になります。

あなたは今だけの技術者ではありません。

今後も技術者として活躍してゆく未来があるのです。

楽しく働いてゆきましょう。

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

PS

繰り返し言いますが
IT業界にデスマーチが多い訳ではありません。

近年では、
むしろ残業させないような、
休日出勤させないような仕組み作りに注力している企業が多いのです。

時代は変わって行きますね。

エンジニア研修の資料請求はこちらから

プロトコルとネットワークシステムの基本的な概念とは

From: リスキルテクノロジー 松田航
新宿本校にて、、、

ネットワークにおいて
コンピューター同士が通信する際、
取り決められた規格によって通信する必要があります。

その規約を「プロトコル」と言い
コンピューター通信において鍵となる規約です。

今回はプロトコルと通信の基本をご紹介しましょう。

そもそもプロトコルとは?

人と人が会話する際、
実際にはさまざまな規約の上で
会話が成り立っています。

まず会話する側は...

(1)会話内容や話題を決める
(2)言葉のイントネーションで感情を加える
(3)文法的な表現内容を決める
(4)使用する言語を選ぶ
(5)実際に発声して言語を伝える

...という手順で相手に話します。

そして話しかけられた側は...

(1)耳から言語を聞きとれたか
(2)言語を正しく理解できたか
(3)表現方法を理解できたか
(4)イントネーションから感情が伝わったか
(5)会話内容、話題を正確に理解できたか

...という手順で話を受け取ります。

人と人の会話であれば、
多少言葉が聞き取りにくくても
ニュアンスが伝われば会話が成立しますが、
コンピューターではそうはゆきません。

コンピューター同士の会話(通信)では
プロトコルによって取り決められた方法で
通信を行う必要があります。

通信プロトコルは
ISO(国際標準化機構)やITU-T(国際電気通信連合)など
いくつかの標準化期間において定められています。

これらで定められていない
プロトコルを独自に作成することも可能ですが、
基本的に受け側がそのプロトコルを理解できなければ
通信は成り立ちません。

ほとんどのネットワークでは
このような標準化機関が定めたプロトコルを用いて
通信が成り立っているのです。

OSI参照モデルとは?
ネットワークシステムの基本的概念

OSI参照モデルとは
ISOによって定められた通信機能を分類化した、
ネットワークシステムの基本的な概念。

プロトコルはOSI参照モデルに則って作成されるため、
異なる機器やメーカーのコンピューター同士でも通信できるのです。

OSI参照モデルは一見すると複雑です。

ですが、
先ほどの会話の例と同じ様に考えれば
理解することは可能です。

できるだけ解りやすく説明しましょう。

OSI参照モデル

OSI参照モデルは
7つの層(レイヤー)に分かれており、
7~5層を上位層、4~1層を下位層と言い、
各層で取り扱うプロトコルはおおよそ定められています。

それぞれの層の役割は以下の通りです。

・第7層:アプリケーション層

最も上位に位置するこの層では、
ユーザーが使用するアプリケーションの動作を下位の層に渡したり、
相手から受け取ったデータを
アプリケーションに表示したりする役割を持ちます。

例えば...

・送信側がファイルを送信し、
 受信側がそのファイルを正しく受け取って
 アプリケーションで開ける。

・送信側が「こんにちは」と入力し、
 受信側が自分のコンピューターで受信し
 「こんにちは」と表示させる。

...などです。

送信側が送信する内容によって
受信側でどのようなアプリケーションで
動作をさせるのかといった情報を渡す役割があります。

・第6層:プレゼンテーション層

プレゼンテーション層では
コンピューターで通信しやすいように
通信したいデータの表現形式を変換します。

文字コードやファイル形式などを識別し、
「0110001110」といったビット化したデータに変換して
下位の層にデータを渡します。

受信側はビット化されたデータを受け取り、
文字コードやファイル形式などといった情報を
上位層であるアプリケーション層に渡します。

・第5層:セッション層

セッション層では
プレゼンテーション層でビット化されたデータを送信します。

受信側では逆に
ビット化されたデータをプレゼンテーション層に渡します。

それ以外にも、
相手側コンピューターとの接続(コネクション)の確立や、
送受信における通信開始と終了のタイミングを管理する役割があります。

・第4層:トランスポート層

トランスポート層では
実際に通信を行っている際に
伝送エラーが発生しているかどうかを管理します。

データはパケットと呼ばれる単位で
分割された状態で送信されるのですが...

このパケットを送信する際、
通信エラーが発生してパケットが欠けてしまうと
受信側に正しい内容が伝わりません。

このためトランスポート層では、
パケット送信エラーがあるかどうかを監視しており...

送信エラーが発生している場合は
送信側にデータ再送の要求を行う事によって、
正しくデータを同期できる役割を持っているのです。

・第3層:ネットワーク層

ネットワーク層では
異なるネットワークでも通信できるように
IPアドレスによってデータの送信先を識別します。

トランスポート層で送信する
パケットにヘッダー(宛先情報のようなもの)を付与し、
パケットヘッダーに送信先IPアドレスを設定。

ネットワークでは
ルーターによってデータを送信する経路を特定し、
IPアドレスで指定されたコンピューターにデータを届けますが、
ルーターはこのネットワーク層で送信経路を識別するのです。

なお、受信側では、
受け取ったパケットからヘッダー情報を削除して
上位階層にパケットを渡します。

・第2層:データリンク層

実際のネットワークでは
複数のルーターや通信機器により構成されていますが...

データリンク層ではデータを送信する際、
次に通信する必要がある通信機器を管理する機能を持ちます。

パケットヘッダーに加えて、
フレームヘッダーと呼ばれるヘッダーが付与され
次にパケットを送信する通信機器などの情報が管理されるのです。

・第1層:物理層

物理層では文字通り
通信に必要となる物理的な面を管理します。

データリンク層から受けとった
ビットデータを電気信号に変換したり、
受信した電気信号をビットデータに変換したり機能があります。

他にも、ケーブルの形状や
コネクタに関する情報も管理しています。

OSI参照モデルに則った
ファイル送受信のイメージは以下の様になります。

ファイル送受信のイメージ

イメージできましたでしょうか?

TCP/IPモデルとは?
インターネットの普及により広がった概念

OSI参照モデル以外にも、
TCP/IPモデルというネットワークシステム概念もあります。

OSI参照モデルがISOにより定められたのに対し、
TCP/IPモデルはアメリカ国防総省が作成したモデルであり...

仮に戦争が起きたとしても存続できるネットワーク設計を!

...という思想の元に作成されました。

TCP/IPモデル

OSI参照モデルが7層あるのに対し、
TCP/IPモデルは以下の4層で構成されています。

・第4層:アプリケーション層
・第3層:トランスポート層
・第2層:インターネット層
・第1層:ネットワーク・インターフェース層

インターネットの普及により広がり、
実装面で優れていることから現在はこちらのモデルが主流。

しかし、TCP/IPモデルは
OSI参照モデルの概念をベースとしており、
各層の役割はOSI参照モデルとほぼ同等です。

ここではOSI参照モデルとTCP/IPモデルの対比図のみ掲載します。

プロトコルや通信の仕組みを知ることは
セキュリティの必須条件

プロトコルやOSI参照モデル、
そしてTCP/IPモデルを紹介しましたが、いかがでしたか?

ややこしく思えますが、
基本的にはコンピューターの通信は
冒頭で説明した人間同士の会話とそれほど変わりありません。

今回、プロトコルや
このOSI参照モデルなどを説明した目的は...

「ネットワークセキュリティにおいて必要な知識」

...であるからなのです。

コンピューターでは
さまざまなサービスが、
さまざまなプロトコルを用いて通信を行いますが...

通信を行う上で、
通信を常に許可しているプロトコルがあると
ネットワークセキュリティ的に問題が発生する場合も。

例えばファイル転送する必要がない場合、
サーバーやネットワーク設定でFTPが有効になっていると、
悪意あるユーザーからウィルスが送信される場合もあります。

また実際にコンピューターを
遠隔操作できるTELNETサービスなどが動いていると
サーバーを不正に操作される可能性もあるのです。

ルーターでは
パケットフィルタリングという機能を使用して
特定のプロトコルの通信許可/通信拒否という設定を行う事ができます。

Linuxでも
iptablesというコマンドを使用することにより、
パケットフィルタリングの設定を行うことができます。

このパケットフィルタリングを行うには、プロトコルの知識は必須。

サーバーやネットワークで
使用するサービスやプロトコルを制限することにより
セキュリティ性の高い、堅牢なシステムを築くことができるのです。

プロトコルやネットワークの仕組みを知ることは
ユーザーの資産や悪意あるユーザーからシステムを守ることに繋がります。

サーバーエンジニアや
ネットワークエンジニアを目指す方は、
これらセキュリティの基本事項をしっかり覚えておいてください。

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

PS

当校のLinux/CCNA系のコースでは
セキュリティに関する実践的な講義を取り入れております。

セキュリティ対策は
全てのシステムにおいて必要な分野であり、
ノウハウを知るエンジニアはどの企業も欲しがる人材。

そんな人材を目指すのであれば、ぜひ資料請求を。

ネットワークのエンジニアなるならリスキルテクノロジー

トータル的に開発に携われる パッケージベンダーの魅力とは?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

IT未経験の方には、
どのような企業に就職・転職して
どのように活躍したいかを試案されている方が多くいらっしゃいます。

IT系企業と言えども
企業によっては扱う業種はさまざま。

一般的な企業と同じように
IT系企業にも取り扱う内容により業種があります。

IT活用シーンの多様化により、
その種類は年々増えて来ているのが現状。

今回は数ある業種の中から...

「パッケージベンダー」

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

パッケージベンダーとは?
パッケージシステムの開発・運用が主な業務

パッケージベンダーとは
パッケージシステムを開発・販売する企業を意味します。

パッケージシステムとは
特定の業種や業務で汎用的に使用可能な
アプリケーションのこと。

家電量販店の店頭などで見かける
会計ソフトやはがき作成ソフトなど
一般的なユーザーに使用されるものから...

企業の営業担当が売り込むような
数百万円以上する業務用途で使用するソフトまで、
世の中には多種多様なパッケージシステムが存在します。

業務用途のパッケージシステムとしては、
人事、会計など企業業務に必要な機能を
統合管理するERP(統合業務パッケージ)が有名。

他にも特定の業務に特化した...

・タクシー配送管理システム
・浄化槽管理システム
・介護支援システム
・ホテルフロント支援システム

...など、数え上げるとキリがありません。

パッケージシステムは
汎用的に使用できるように開発されているシステムです。

ですので、そのまま使用する場合は
オリジナルのシステム開発をオーダーするよりは安価に導入できます。

しかし、
導入企業の希望により、
機能をカスタマイズする場合にはカスタマイズ費用が必要。

店頭で販売しているような
ツール系パッケージシステムは
カスタマイズできない事が多いですが、
企業向けのパッケージシステムはカスタマイズするケースがほとんど。

カスタマイズ費用が発生するとしても
オリジナルでソフトを作成するよりは安い費用での開発が可能です。

また、パッケージシステムという
ベースとなるシステムがあらかじめ出来上がっている為、
開発期間を短縮でき、短期間で導入できるというメリットもあります。

デメリットとしては、
ある程度決められた機能しかないので、
ユーザーがパッケージシステムに合わせないといけないケースがあったり、
パッケージの改修・保守は開発元ベンダーに依存せざるを得ないという点です。

幅広い業務内容が特徴
開発だけでなくネットワークやサポート業務も

あなたがパッケージ開発を行っている
IT系企業で働くことになったとしましょう。

主な業務内容はパッケージシステムの
カスタマイズやバージョンアップに関する事がメインとなります。

企業業務で使用するパッケージシステムの場合、
カスタマイズしないでパッケージシステムを導入する例はほとんどありません。

どのような業務でも
その企業独特の運用方法があり、
ユーザーからのカスタマイズ要望があれば対応する必要があります。

また、パッケージシステムを使用しているユーザーから...

「こういう点を改良してほしい」

「こんな機能が欲しい」

...と、基本機能に関する改良要望が多くあった場合には、
次のバージョンアップの際の改良点として修正対応を行います。

パッケージベンダーにもよりますが
年1回の定期バージョンアップを行っている企業もあり、
そのような企業では毎年、次期バージョンに向けての開発が発生します。

また、
パッケージベンダーに必要とされるIT技術者は
プログラマやシステムエンジニアだけではありません。

ベンダーによっては
自社でデータセンターを保有、
または契約データセンターでサーバーを管理している企業も。

そのようなベンダーの場合
ネットワーク設定もパッケージベンダーが行う為、
ネットワーク技術者が活躍できる場があるのです。

そしてもう一つ大切なのは
販売したパッケージシステムに対するサポート業務。

ほとんどのパッケージベンダーの場合は
サポート専用の部署を設けていますが、
小規模ベンダーの場合は開発者が兼務するケースもあります。

ユーザーの声には耳を澄ませてください。

サポートで挙がる声を通じて次の機能改良に繋がり、
新しいオプション機能として販売するチャンスも発生するのです。

パッケージベンダーの技術者に求められるもの
仕様把握とコミュニケーション能力は必須

パッケージ開発技術者として
求められるスキルは多々あります。

まずは自社が開発している
パッケージシステムの仕様を把握すること。
パッケージ開発技術者になった場合、これが最優先事項です。

ERPなどといった
大規模なパッケージシステムの場合は...

まずは会計、次に原価管理、人事、営業管理…

...と、徐々にマスターしてゆかないと、
なかなか難しいのも現状。

それでもできるだけ
まずは仕様を把握しないといけないという理由としては、
自社が開発しているシステムの仕様を知らないと
ユーザーと話ができない為です。

パッケージベンダーは
最初はパッケージシステムのカスタマイズ業務が主業務であっても、
後々キャリアアップしてゆくに従って、ユーザーと話をする機会が多い業種。

見込み営業と言って、
システムを導入してくれる可能性のある企業に
営業担当と同行して技術的な質疑応答を行う機会もあります。

その時に...

「いや~、その機能はまだよく知らないのですよ」

...というのでは、ビジネスチャンスを逃してしまいます。

実際には、もし不明な点があっても...

「持ち帰って調査の後、ご返答させて頂きます」

...という対応で多くのユーザーは納得してくださいますが...

できればその場で返答して、
ユーザーに対する心象を良くしておきたいところです。

そしてもうひとつ必要なのがコミュニケーション能力。

先ほどの話でも、
ユーザーと話す機会が多いという事を述べましたが...

見込み営業以外にもユーザーと機能改修の話をしたり、
サポートの為に現地に赴いてユーザーと相談しながら対応したりと、
ユーザーとコミュニケーションをとりながら業務を遂行することが多いです。

他にも、
新しいパッケージを開発した時や、
システムをバージョンアップした時には、
プレスリリースイベントやバージョンアップ内容の説明会をする企業もあります。

そういったイベントがあるのも
パッケージベンダーならではの特徴で、
イベント会場に行ってユーザーからの技術的な質疑応答を行ったり、
バージョンアップ内容のプレゼンテーションを行ったりするケースもあります。

もちろん、入社当初から
いきなりそのような業務を行うケースは少ないですが、
ゆくゆくはそのような業務を行う事があるということを覚えておいてください。

独特の苦労点もある業種だが
パッケージ開発技術者ならではの醍醐味も!

パッケージベンダーにも独特の苦労はあります。

パッケージシステムの特徴として
短期間での導入が可能という点が挙げられますが...

カスタマイズ要望によっては、
大幅にプログラム修正を改修しないといけない場合もあるのです。

既にベースが出来上がっているシステムですので
改修することによって他のプログラムに影響が出ないかなど、
パッケージシステムとしての影響調査や確認に時間がかかるケースも。

既にバランスが取れているシステムに対し
そのバランスを変えようとしてカスタマイズする訳ですから
細心の注意をしつつ、カスタマイズ対応を行わなければなりません。

また、法改正などがあった場合の対応も必要です。

最近の話で言えば、
消費税の段階的導入が発表された時点で
それに対応可能なシステム変更を行う必要がありました。

あるERPベンダーの話によると...

法改正対応は月々のサポート費用で対応しているが、
さすがに今回の段階的導入は影響範囲が大きすぎたので
今回に限っては、若干費用を頂戴した上でご対応させてもらった。

...という例も。

法改正の内容にもよりますが、
出来る限り柔軟にカスタマイズできる様な
パッケージシステムを設計するという工夫も必要です。

他にもユーザー別に
どのようなカスタマイズを行ったかを管理する必要も。

ユーザー毎に導入システムの
バージョン管理やカスタマイズ内容の管理を行い...

万一システムに不具合が発生した際には、
該当ユーザーに不具合修正を行う必要があるか、
影響度はどれくらいかを判断した上で対応を行わなければなりません。

さまざまな苦労点があるとは言え、
パッケージベンダーにおける開発業務には、
そういった苦労を払拭できる程の醍醐味があります。

それは、上流工程から下流工程まで一貫して開発に携われる点。

開発工程やテスト工程のみを下請けする業務ではなく...

・ユーザー折衝
・要件定義
・設計、開発、テスト
・リリース
・運用サポート

...と、一連の開発の流れを経験できる点は技術者にとって大きな経験。

そして長年対応すればするほど
パッケージ仕様に精通し、経験ユーザー数も増えるため...

新しくシステムを導入するユーザーに対しては、
業務コンサルタント的な視点からさまざまなアドバイスをすることも可能。

「トータル的にシステム開発に携わりたい!」

「ゆくゆくは業務コンサルティングに挑戦したい!」

...という方には、パッケージベンダーはオススメです。

もちろん、
パッケージベンダーでなければ
上流から下流までの開発業務に携われない、
コンサルタントになれないという訳ではありません。

チャンスというものは自分で掴むものです。

しかし残念ながら、
ある程度環境に左右されてしまうというのも現状。

IT技術を身に着けた後、
どのような技術者になりたいか、
どのようなキャリアパスを描いてゆくか...

将来的な事も検討して就・転職活動を行い、
あなたが活躍したい企業(環境)において、
あなたの「なりたい!やりたい!」が可能なのかどうかを見極めてください。

あなたが描く未来が叶えられることを
最優先にして行動しましょう。

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

PS

未経験者の方は...

「まずはIT技術者になる!」

...という想いが強いのが実状なのですが...

「どんな技術者になりたいか?」

今のうちから、
そのことを自問自答するようにしてください。

未経験だから
わからないことも多いと思われますが、

当校ではあなたの...

「なりたい!」

...をサポートする個別ガイダンスを随時受け付けています。

リスキルテクノロジーの資料請求はこちらから

セキュリティの基本 ポートとポートスキャンとは?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

あなたが住む家に戸締りが必要なように、
システムにも戸締りが必要です。

システムのセキュリティには
さまざまな方法がありますが...

今回はセキュリティの基礎、
ポートとポートスキャンについてお話しします。

ポート=ネットワーク通信の為のゲート

飛行場をイメージしてください。

○○発羽田便の飛行機は5番ゲート、
△△発成田便の飛行機は15番ゲートというように
飛行機は着陸するゲートが決められています。

決めておかないと
飛行場は混乱し、事故にも繋がりかねません。

これと同じことが
システムにも当てはまります。

インターネット等のネットワークにおいては、
TCP/IPという通信プロトコルによって通信しますが...

通信時に使用するサービスによって、
使用できるポートが決められています。

代表的なポートとサービスを見てみましょう。

ポート番号表

このように、ポート番号ごとに
使用できるサービスが割り当てられています。

なお、TCP/UDPと言う列がありますが...

TCP(Transmission Control Protocol)とは
データ送受信の際に相手とコネクションを確立した
信頼性の高い通信プロトコルのこと。

UDP(User Datagram Protocol)とは
相手とのコネクションを確立せずに通信する
信頼性を確保しない通信プロトコルのことです。

この図の例で見ると、
21番ポートのFTPではTCP方式のみ使用しますが...

80番ポートのHTTPでは、
TCP方式もUDP方式も使用可能という意味です。

通信方式が少し違うという程度に覚えておいてください。

使用できるポートの数とその種類

コンピュータが使用するポートは
0番~65535番まで存在しており、
番号帯によって既にサービスで予約済のポートや、
自由に使用できるポートなど分かれています。

・0番~1023番:一般的なポート番号
(WELL KNOWN PORT NUMBERS)

一般で使用される主要なポート番号で、
IANA(Internet Assigned Numbers Authority)という
インターネットに関する番号を管理する組織によって
管理されている番号帯。

使用目的が定められたポート番号で、
先ほどの図で出たポートは
全てこのWELL KNOWN PORTにあたります。

・1024番~49151番:登録済ポート番号
(REGISTERED PORT NUMBERS)

IANAが登録を受けて公開しているポート番号帯。

企業が作成した
特定のアプリケーションで使用されるポートが
多く存在します。

・49152番~65535番:動的・プライベートポート番号
(DYNAMIC AND/OR PRIVATE PORTS)

ユーザーが自由に使用できる番号帯。

業務アプリケーションなどで使用する場合や、
一時的なポート使用を行う際に使用されるポートです。

ポートスキャンとは?
悪意あるユーザーが最初に行う行為

最近メディアでも
顧客情報の流出事件や
システムのハッキング・クラッキングという
ニュースが多く見られます。

このような事件は
内部の人間の手引きによる事例もありますが、
外部からの不正な接続により発生する事件も多くあります。

悪意のあるユーザーが
外部からシステムに接続する際、
まず初めに行われるのは「ポートスキャン」です。

このポートスキャンとは
サーバーにどんなサービスが実行されているかを
確認する方法です。

空港の例で言えば...

1番ゲート:閉鎖中
2番ゲート:解放中(警備員なし)
3番ゲート:解放中(警備員あり)

...と言うように、空いている場所を特定し、
2番ゲートのセキュリティが甘ければ、そこから侵入を企てます。

コンピュータの場合も同様で、
悪意あるユーザーは開いているポートが見つかると、
そのポートを通じて接続を試みます。

ユーザーIDとパスワードが
容易に想像できるようなセキュリティの甘さや、
そのサービスのセキュリティホール(不具合やバグ)がある場合、
接続される危険性が高まるのです。

ポートスキャンは特別なソフトではなく、
Linuxであればnmapというコマンドで実行できます。

実行例を見てみましょう。

nmap_example

PORT(ポート番号)、
STATE(状態)、
SERVICE(サービス)の項目があり、
ポートの状態とサービスが一覧表示されます。

STARE(状態)が
openとなっているポートは解放されており、
closedとなっているポートは閉鎖されている状態です。

この例で言えば
23番ポートのTELNETがopen状態なのが危険(図①)。

悪意あるユーザーが
セキュアな接続を行わないTELNETで接続し、
ユーザーIDやパスワードが盗まれると
サーバーが乗っ取られる可能性もあります。

21番ポートのFTPサービスがopenなのも要注意(図②)。

FTPには匿名接続(anonymous FTP)できる機能があり
匿名接続可能なサーバーであれば誰でもファイル転送できるため
ウイルスファイルを送られる可能性もあります。

あと、念のため...

勘違いしないで頂きたいのですが、
nmapはハッキング・クラッキングの為のコマンドではなく、
あくまでシステムのセキュリティチェックを行う管理用ツールです。

それが悪用されるケースもあるということですね。

必要ないポートは「戸締り」しておく事が
基本中の基本!

悪意あるユーザーから
システムを守るための方法はいくつかありますが、
その中でも基本的な事項として...

「必要のないポートは解放しない」

...という事が挙げられます。

先ほどの例で言うと、
SSHというセキュアなリモート接続が可能なのだから
TELNETは不要といったように、
必要のないポートは解放しておく必要がありません。

使用するOSやサービスの
セキュリティホールがあるかどうかを
予め確認しておく必要もあります。

セキュリティホールがある場合は、
最新の修正プログラムを適用するなど、
システムを守るために先手を打った対策が必要。

企業などが行っている
セキュリティ診断サービスを利用するのも効果的。

第三者の視点と分析による
セキュリティ診断を受けることにより
システムにどのような弱点があるのかが判明し、
どのような対策を行う必要があるのかがわかります。

システムのセキュリティ対策には
これ以外にも非常に多くの方法があります。

それらは今後、ご紹介してゆきますが...

いずれの方法も、
ユーザーの資産を守るために必要なものであるという事を
忘れないでいてください。

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

PS

戸締りはきちんとしておかないと
泥棒に入られたらイヤですもんね。

だからといって
全てのドアや窓に3重ロックをかけるとかすると
今度は使い勝手が悪くなってしまいます。

家の戸締りもセキュリティも、
使用に適した方法で行う必要があるのです。

PPS

セキュリティに関しての知識もつく、
ネットワークエンジニア・サーバエンジニアになるならリスキルテクノロジー

柔軟なシステム変更を可能とするアジャイル開発とは?

From: リスキルテクノロジー 松田航
新宿本校にて、、、

日本ではシステム開発の手法として
ウォーターフォールモデルが広く採用されています。

それ以外の手法も多々ありますが
その中で特に、近年注目されている手法として...

「アジャイル開発」

...という開発手法があります。

これは2000年頃に考案され、
アメリカなどで広く採用されている開発手法です。

今日はアジャイル開発手法の特徴などについて
サラッとみていきます。

アジャイル
柔軟な変更を可能にする開発手法の特徴とは?

アジャイル(agile)とは、
和訳すると「機敏な、俊敏な」という意味で、
その名のとおり機敏な対応を可能とする開発手法です。

開発中に仕様変更が発生した場合、
変更内容を全システムに反映させないといけませんが...

アジャイル開発では以下の特徴により
開発中にも仕様変更でも柔軟に対応することができます。

(1)ユーザーとエンジニアの共同開発チームを編成

システム開発を行う際、
ユーザーと共同の開発チームを編成します。

チーム内にユーザーがいることにより、
ユーザーニーズに迅速に対応できる体制となり、
変更が発生してもエンジニアに変更内容が伝わりやすくなるのです。

(2)開発範囲を分割

開発対象範囲全体から
開発対象となる機能に優先順位をつけ、
それらを1~4週間単位に開発可能な単位に分割します。

例えば開発対象となる機能が
機能1~機能4まで4種類あった場合...

優先度A:機能4(マスタ管理機能)
優先度B:機能3(顧客管理機能)
優先度C:機能1(案件管理機能)
優先度D:機能2(入出金管理機能)

...といった様に優先順位をつけて、
それぞれを1~4週間など、定められた期間で開発するのが特徴です。

(3)開発業務

開発は優先順位に従って進められます。
上記の例では機能4(マスタ管理機能)から開発を始め、

定められた期間内に
要件定義、製造、テスト、リリースまで全て行います。

ウォーターフォールモデルでは
最初に全機能の要件定義を行うのが特徴ですが、
アジャイルでは定められた期間に要件定義~リリースまで実施します。

ただし、開発規模が小さい場合は、
全機能をプログラムして、一気に要件定義~リリースまで行うケースも。

その場合、リリースするプログラムは
プロトタイプや初期バージョン的な扱いになり、
ユーザーの全要求を満たしているとは言えない場合が多いです。

(4)リリース後の検討

リリースしたプログラムをユーザーと共に検証し
次に行うべき対応を検討します。

この検証を行うことにより、
ユーザーからのフィードバックを素早く受けることが可能になり、
迅速な仕様変更にも対応できるのです。

アジャイル開発は(2)~(4)を
優先順位で定められた順番に繰り返し開発することが特徴であり、
これを「イテレーション(反復)」と言います。

イテレーションを実施することにより、
ユーザーからのフィードバックが反映されやすく、
柔軟な仕様変更にも対応できる開発を行う事ができるのです。

多くの種類が存在するアジャイル開発手法
そこに見られる3つの共通点とは?

アジャイル開発とひとことで言っても、
実際にはさまざまな開発手法があります。

代表的な手法としては...

・エクストリーム・プログラミング(Extreme Programming、XP)
・スクラム(Scrum)
・フィーチャー駆動型開発(Feature Driven Development、FDD)
・クリスタルファミリー(Crystal Family)
・リーンソフトウェア開発(Lean Software Development)
・適応的ソフトウェア開発(Adaptive Software Development、ASD)

...など、細かく分ければ手法はさまざま。

それらの違いも明確になっているかというと、
まぁ曖昧です。

それぞれで、
重視する内容や細かい点は異なりますが、
基本的には以下のように3つ共通点があります。

(1) イテレーションによる柔軟な変化に対応可能
(2) 短期間での開発が可能
(3) 開発範囲を分割し、小さな単位で開発を行う

そしてもうひとつ
アジャイル開発において共通しているのは
プロジェクトメンバー間のコミュニケーションを重視する点です。

制限や制限などにより開発を進めるのではなく、
チームメンバー全員の相互作用を活性化させることにより、
システム開発を高効率、高品質、低リスクで進めることが重要です。

前述のように、
チームメンバーにはユーザーも含まれています。

ユーザーからのフィードバックや
ミーティングなどといったコミュニケーションを通じて、
ユーザーが望むシステムを開発しやすいという特徴があるのです。

日本でアジャイルが普及しない3つの理由

このように一見すると
メリットの多いように見えるアジャイル開発ですが、
日本ではあまりメジャーな開発手法であるとは言えません。

IPA(独立行政法人 情報処理推進機構)が
2012年に6カ国を対象にアジャイル普及度に関する調査を行った際には

欧米では既に主流な開発手法であり、
普及が拡大しているという調査結果ですが

日本ではまだ普及が遅れており、
ようやく認知されるようになったとの結果です。

今ではアメリカでは約30%のIT企業が
アジャイルを採用するほど普及しているのですが、
アジャイル開発が日本で普及しない理由はなぜでしょうか?

(アジャイルもどきは多いですけど 苦笑)

それには主に3つの理由があります。

(1)開発チーム編成の問題

アメリカではユーザー企業にIT技術者が多く、
チーム編成しやすく、コミュニケーションを取りやすいのですが...

日本ではIT技術者のほとんどが
SIerやベンダーに所属しているため、
チーム編成を行いにくく、またコミュニケーションも取りにくい。

ユーザー企業にIT部門がある場合は
ユーザーをアジャイル開発チームに含めやすいですが...

IT部門は人不足な状態が多く
自社の通常業務で手一杯になってしまい、
ユーザーをチームに含めたとしても連携しづらいのが現状です。

(2)多重請負の問題

2次請け、3次請けといった
日本のIT業界の特徴とも言える多重請負により、
アジャイル開発の特徴である迅速・柔軟な対応が行えないことも。

ユーザーとの直接交渉が
元請のエンジニアしか行えない場合、
開発側とユーザーの意思疎通が迅速に行うことができず、
柔軟な対応を行うことができない状況になってしまいます。

また変更が発生した場合も、
元請→2次請け→3次請け...と多重構造を通して
変更を行ってもらう必要があるため、スピード感に欠けるのです。

(3)商習慣の問題

ユーザー(発注側)は開発側(受注側)よりも
立場が上という日本的な商習慣が普及を
遅らせる原因にもなっています。

欧米ではユーザーと開発側は
ビジネスパートナーとしてほぼ対等な形で取引されますが...

日本では「お客様は神様です」的な考えがあり、
ユーザーも開発チームの一員として迅速なフィードバックを可能にする
アジャイルの特徴を活かしきれないケースもあるのです。

これもサービスの質という意味では、
いい面もあるのですが、考えどころですね。。

開発手法にとらわれすぎず、
柔軟に行こう!

アジャイル開発は小規模開発向けと言われており、
日本ではスマホアプリ開発などで一部採用されていますが、

海外では小規模案件だけでなく、
MicrosoftやIBMなどといった大企業による
規模の大きな開発でも採用されている事例もあります。

最近は日本の企業にも
アジャイルを積極的に取り入れようとする動きが見られ、
日本型開発におけるアジャイル活用の方法が研究されています。

海外でもアジャイル開発の取り組みを行う企業は多く、
たとえオフショア開発(海外委託開発)であったとしても、
双方がアジャイル開発に精通している場合は柔軟な対応が可能となるのです。

日本ではウォーターフォールモデルが主流ですが、
それだけでは対応できない状況になりつつあるのは事実です。

ユーザーのスピード感が非常に高くなり、
変化する経済情勢に柔軟に対応できるような
システムの変更を行うことができるアジャイル開発は魅力的な開発手法。

ただし、
アジャイルを導入したからと言って
全てがうまく進む!という訳ではありません。

イテレーションによる開発と
ユーザーからのフィードバックは確かに良い手法ですが...

「この機能もつけたい」
「あの機能はもう少しこうしてほしい」
「その画面とこの画面を連携させて情報を表示したい」

...などというユーザーからの意見が頻発することも。

仕様が膨らみ続けて止められず、
逆に迅速な対応ができなくなってしまうケースもあります。

そして、アジャイルに精通したエンジニアが少ないのも現状。

急激にアジャイルを導入した場合、
逆にパフォーマンスが落ちるエンジニアが
発生する可能性もあります。

大切なのは...

「ユーザー、案件、納期、チーム等を考慮し、最適な方法で開発を行う」

...ということです。

あなたがもし、
開発手法を選択できる立場になったとしても...

特定の手法だけとらわれず、
それぞれの手法の良い面を組み合わせるのも良いでしょう。

アジャイルにはアジャイルの、
ウォーターフォールにはウォーターフォールの良さがあります。

エンジニアとして様々な開発経験を積んで、
どのような案件でも柔軟に対応できるノウハウを身に付けましょう。

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

PS

日本のIT業界において、アジャイルはまだ黎明期。

どのようなものか知っておくのは良い事ですが、
アジャイル開発は更に数種類に細分化されるので、
未経験の方や経験の浅い技術者が、全てを把握することは難しいです。

ウォーターフォールから勉強しましょう。
それが今のあなたにとって大切なことです。

PPS

開発手法を含めて勉強できるJavaの研修

プロフェッショナルエンジニアとして求められる姿勢

From: リスキルテクノロジー 松田航
新宿本校にて、、、

「最近、終電帰宅ばかりで疲れたわ...」

知り合いのSEがぽつりと漏らしたひとこと。

あまり愚痴っぽいことを言わない人なので、
そのひとことに少し驚きました。

彼はあるプロジェクトのリーダーを
任されているようです。

軽く話を聞いてみたところ、
小規模プロジェクトの割に納期は長く、
それほど難易度の高いプロジェクトでは
なさそうなのですが...

一体、彼に何が起こったのでしょうか?

終電の理由は
すぐにギブアップするプログラマのフォロー

彼が担当する開発案件は小規模で
彼をリーダーに、プログラマが3名の計4名のチーム。

マネージャは他の案件と兼務しており
実質的に顧客折衝や進捗管理も彼が担当しています。

しかし、
ユーザーからの要件はほぼ固まっており、
彼自身もユーザー業務をよく知っているので、
それほど難易度は高くない開発案件でした。

彼が終電帰宅になる理由...

それは、
開発チームに所属するプログラマから頻発する
「少し調べればわかる程度の質問」と
「ギブアップ宣言」が原因でした。

チームにいる3名のプログラマは、
みな昨年~今年入社したばかりの新人エンジニア。

新人エンジニアでもプロ意識をしっかりと持ち、
スキル的なポテンシャルが高い人も多いのですが...

彼のチームのエンジニアの場合...

・プログラムでつまずくと、簡単なことでも調査せずにすぐ質問
・「できません」「わかりません」と、すぐにギブアップする

...というエンジニアが揃ってしまった模様。

彼はリーダーとして
解決方法をアドバイスするのですが、
結局彼らのしわ寄せがリーダーに集中して
日中に自分が担当する業務ができず、終電帰宅となるようです。

問われるプロフェッショナルエンジニアとしての姿勢

リーダーとしての彼の指導方法にも
何らかの問題がある可能性も否定はできませんが、
新人エンジニア達にも問題がありそうです。

誰もが最初はわからないことだらけ。

それはそれで、全く問題ありません。

そしてわからないからこそ、
できないことも多い。

しかし、彼らは新人とは言えプロなのです。

問題なのは、プロであるにもかかわらず...

「何が問題となって、自分が解らないのか?」

...ということを理解しようとしない姿勢にあります。

わからないことを質問するのは
全く問題がありません。

むしろ、
質問して早く問題が解決するならば
積極的に質問して開発を進める方が良いでしょう。

ただし...

1.プログラムが思う通り動かない
2.とりあえず人に聞いてみよう
3.それで動けば問題なし
4.それでもできなかったらギブアップ

...という考えであれば、プロフェッショナルの姿勢とは言えません。

単なる流用はNG
優れたノウハウをスキルアップに繋げることが大切

プログラミングの際、
インターネットなどでサンプルソースを検索して
それを参考にしてプログラミングする方も多いでしょう。

実際に他の人が作った優れたソースを参考にして、
開発業務を行ったという経験を持つエンジニアは多いです。

しかし、
優れたソースを参考にする場合、
必ず心がけておくべきことがあります。

それは...

「単なる流用ではなく、仕組みを理解する」

...ということ。

単純にサンプルをコピペして、
少し変更すれば問題は解決するかも知れません。

しかしそれでは、
常に他人のスキルに依存してしまうため、
先ほどの新人エンジニアの事例と何ら変わりないのです。

優れたサンプルソースを参考にして...

・どのような仕組で動作するのか?
・自分では解決できなかった問題はどこにあるか?

...ということを理解し、
自分のノウハウに蓄える必要があります。

優れたノウハウを自分のものにすることで、
自分自身のスキルアップにも繋がってゆきます。

単に流用して解決するエンジニアと比較すると、
将来的な技術力に大きな差がつくのです。

姿勢次第で大きな差がつく!
現状把握と分析力に加えて提案力があればベスト

エンジニアだけに限らず、
何か問題に直面した時に必要なことは...

何が原因となって問題が発生しているか?

...という現状を把握し、分析する能力です。

プログラム系に関して言えば...

・どこでどんなエラーが発生しているか
・エラー発生前の処理はどのような処理か
・関連クラスの処理や変数の内容は正常か
・引数に問題はないか

...など。

ネットワーク系で言えば...

・ルーティング設定に問題はないか
・どの機器に問題があるか
・断線や配線方法など物理的なことが原因になっていないか

...など、自分で考えられる範囲で現状把握を行います。

そして考えられる対処法を検討・実施し、
それでも原因が解決しなければ、
高スキル保有者に相談しましょう。

開発期間には限りがあります。
問題を自分だけで抱え込む時間が長すぎると、
それは開発の遅れに繋がるケースもあるのです。

そして相談する時は、
わかりません、できませんではなく...

・現状どのような事象が発生しているか
・それに対し、どのような調査を行ったか
・解決には至らないが、その調査で判明した情報

...を必ず伝えるようにしましょう。

これが...

問題発生→現状分析・調査→相談→解決

...という理想的な解決パターンです。

さらにもう一歩踏み込んで
問題を解決する為に調査・検討した、
自分なりの解決策を説明できれば申し分ありません。

簡単に言えば「回避策」の提案です。

そうすれば...

問題発生→現状分析・調査→相談・回避策の提案→検討→解決

...という流れで、自らの発案によって問題回避できることも。

プログラム言語で言えば、
言語的な仕様でどうにもならない!
という問題が発生するケースもあります。

そういう時に
回避策を提案できるエンジニアがいると重宝されます。

業務に対してどのような姿勢で臨むか?

受け身のエンジニアになるか?

それとも...

積極的な提案ができるエンジニアになるか?

姿勢の持ち方次第で、
エンジニアとして数年後に大きな差が開くのです。

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

PS

卒業した瞬間にプロとしての実力と姿勢が身に付く…

私たちのプロフェッショナルとしての姿勢です。

詳細はこちらから
エンジニアになるならリスキルテクノロジー

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

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

IT講師に応募する