新宿本校にて、、、IT未経験の方には、どのような企業に就職・転職してどのように活躍したいかを試案されている方が多くいらっしゃいます。IT系企業と言えども企業によっては扱う業種はさまざま。一般的な企業と同じようにIT系企業にも取り扱う内容により業種があります。IT活用シーンの多様化により、その種類は年々増えて来ているのが現状。今回は数ある業種の中から...「パッケージベンダー」...についてご紹介しましょう。パッケージベンダーとは?パッケージシステムの開発・運用が主な業務パッケージベンダーとはパッケージシステムを開発・販売する企業を意味します。パッケージシステムとは特定の業種や業務で汎用的に使用可能なアプリケーションのこと。世の中には多種多様なパッケージシステムが存在します。人事、会計など企業業務に必要な機能を統合管理するERP(統合業務パッケージ)が有名。他にも特定の業務に特化した...・タクシー配送管理システム・浄化槽管理システム・介護支援システム・ホテルフロント支援システム...など、数え上げるとキリがありません。パッケージシステムは汎用的に使用できるように開発されているシステムです。そのまま使用する場合はオリジナルのシステム開発をオーダーするよりは安価に導入できます。機能をカスタマイズする場合にはカスタマイズ費用が必要。企業向けのパッケージシステムはカスタマイズするケースがほとんど。カスタマイズ費用が発生するとしてもオリジナルでソフトを作成するよりは安い費用での開発が可能です。開発期間を短縮でき、短期間で導入できるというメリットもあります。デメリットとしては、ある程度決められた機能しかないので、ユーザーがパッケージシステムに合わせないといけないケースがあったり、パッケージの改修・保守は開発元ベンダーに依存せざるを得ないという点です。開発だけでなくネットワークやサポート業務もあなたがパッケージ開発を行っているIT系企業で働くことになったとしましょう。主な業務内容はパッケージシステムのカスタマイズやバージョンアップに関する事がメインとなります。企業業務で使用するパッケージシステムの場合、カスタマイズしないでパッケージシステムを導入する例はほとんどありません。どのような業務でもその企業独特の運用方法があり、ユーザーからのカスタマイズ要望があれば対応する必要があります。次のバージョンアップの際の改良点として修正対応を行います。パッケージベンダーにもよりますが年1回の定期バージョンアップを行っている企業もあり、そのような企業では毎年、次期バージョンに向けての開発が発生します。パッケージベンダーに必要とされるIT技術者はプログラマやシステムエンジニアだけではありません。ベンダーによっては自社でデータセンターを保有、または契約データセンターでサーバーを管理している企業も。そのようなベンダーの場合ネットワーク設定もパッケージベンダーが行う為、ネットワーク技術者が活躍できる場があるのです。一つ大切なのは販売したパッケージシステムに対するサポート業務。小規模ベンダーの場合は開発者が兼務するケースもあります。ユーザーの声には耳を澄ませてください。新しいオプション機能として販売するチャンスも発生するのです。パッケージベンダーの技術者に求められるもの仕様把握とコミュニケーション能力は必須パッケージ開発技術者として求められるスキルは多々あります。自社が開発しているパッケージシステムの仕様を把握すること。パッケージ開発技術者になった場合、これが最優先事項です。......と、徐々にマスターしてゆかないと、なかなか難しいのも現状。自社が開発しているシステムの仕様を知らないとユーザーと話ができない為です。後々キャリアアップしてゆくに従って、ユーザーと話をする機会が多い業種。見込み営業と言って、システムを導入してくれる可能性のある企業に営業担当と同行して技術的な質疑応答を行う機会もあります。その時に...「いや~、その機能はまだよく知らないのですよ」...というのでは、ビジネスチャンスを逃してしまいます。実際には、もし不明な点があっても...「持ち帰って調査の後、ご返答させて頂きます」...という対応で多くのユーザーは納得してくださいますが...できればその場で返答して、ユーザーに対する心象を良くしておきたいところです。ひとつ必要なのがコミュニケーション能力。先ほどの話でも、ユーザーと話す機会が多いという事を述べましたが...見込み営業以外にもユーザーと機能改修の話をしたり、サポートの為に現地に赴いてユーザーと相談しながら対応したりと、ユーザーとコミュニケーションをとりながら業務を遂行することが多いです。新しいパッケージを開発した時や、システムをバージョンアップした時には、プレスリリースイベントやバージョンアップ内容の説明会をする企業もあります。いったイベントがあるのもパッケージベンダーならではの特徴で、イベント会場に行ってユーザーからの技術的な質疑応答を行ったり、バージョンアップ内容のプレゼンテーションを行ったりするケースもあります。入社当初からいきなりそのような業務を行うケースは少ないですが、ゆくゆくはそのような業務を行う事があるということを覚えておいてください。独特の苦労点もある業種だがパッケージ開発技術者ならではの醍醐味も!パッケージベンダーにも独特の苦労はあります。大幅にプログラム修正を改修しないといけない場合もあるのです。ベースが出来上がっているシステムですので改修することによって他のプログラムに影響が出ないかなど、パッケージシステムとしての影響調査や確認に時間がかかるケースも。バランスが取れているシステムに対しそのバランスを変えようとしてカスタマイズする訳ですから細心の注意をしつつ、カスタマイズ対応を行わなければなりません。法改正などがあった場合の対応も必要です。消費税の段階的導入が発表された時点でそれに対応可能なシステム変更を行う必要がありました。あるERPベンダーの話によると...法改正対応は月々のサポート費用で対応しているが、さすがに今回の段階的導入は影響範囲が大きすぎたので今回に限っては、若干費用を頂戴した上でご対応させてもらった。出来る限り柔軟にカスタマイズできる様なパッケージシステムを設計するという工夫も必要です。他にもユーザー別にどのようなカスタマイズを行ったかを管理する必要も。影響度はどれくらいかを判断した上で対応を行わなければなりません。さまざまな苦労点があるとは言え、パッケージベンダーにおける開発業務には、そういった苦労を払拭できる程の醍醐味があります。それは、上流工程から下流工程まで一貫して開発に携われる点。テスト・リリース・運用サポート...と、一連の開発の流れを経験できる点は技術者にとって大きな経験。業務コンサルタント的な視点からさまざまなアドバイスをすることも可能。「ゆくゆくは業務コンサルティングに挑戦したい!」...という方には、パッケージベンダーはオススメです。パッケージベンダーでなければ上流から下流までの開発業務に携われない、コンサルタントになれないという訳ではありません。チャンスというものは自分で掴むものです。残念ながら、ある程度環境に左右されてしまうというのも現状。IT技術を身に着けた後、どのような技術者になりたいか、どのようなキャリアパスを描いてゆくか...将来的な事も検討して就・転職活動を行い、あなたが活躍したい企業(環境)において、あなたの「なりたい!やりたい!」が可能なのかどうかを見極めてください。あなたが描く未来が叶えられることを最優先にして行動しましょう。今のうちから、そのことを自問自答するようにしてください。当校ではあなたの...「なりたい!」...をサポートする個別ガイダンスを随時受け付けています。新宿本校にて、、、あなたが住む家に戸締りが必要なように、システムにも戸締りが必要です。システムのセキュリティにはさまざまな方法がありますが...今回はセキュリティの基礎、ポートとポートスキャンについてお話しします。ポート=ネットワーク通信の為のゲート飛行場をイメージしてください。△△発成田便の飛行機は15番ゲートというように飛行機は着陸するゲートが決められています。決めておかないと飛行場は混乱し、事故にも繋がりかねません。これと同じことがシステムにも当てはまります。使用できるポートが決められています。代表的なポートとサービスを見てみましょう。このように、ポート番号ごとに使用できるサービスが割り当てられています。Protocol)とはデータ送受信の際に相手とコネクションを確立した信頼性の高い通信プロトコルのこと。Protocol)とは相手とのコネクションを確立せずに通信する信頼性を確保しない通信プロトコルのことです。この図の例で見ると、21番ポートのFTPではTCP方式のみ使用しますが...80番ポートのHTTPでは、TCP方式もUDP方式も使用可能という意味です。通信方式が少し違うという程度に覚えておいてください。自由に使用できるポートなど分かれています。Authority)というインターネットに関する番号を管理する組織によって管理されている番号帯。PORTにあたります。NUMBERS)IANAが登録を受けて公開しているポート番号帯。企業が作成した特定のアプリケーションで使用されるポートが多く存在します。PORTS)ユーザーが自由に使用できる番号帯。一時的なポート使用を行う際に使用されるポートです。最近メディアでも顧客情報の流出事件やシステムのハッキング・クラッキングというニュースが多く見られます。外部からの不正な接続により発生する事件も多くあります。悪意のあるユーザーが外部からシステムに接続する際、まず初めに行われるのは「ポートスキャン」です。このポートスキャンとはサーバーにどんなサービスが実行されているかを確認する方法です。空港の例で言えば...1番ゲート:閉鎖中2番ゲート:解放中(警備員なし)3番ゲート:解放中(警備員あり)...と言うように、空いている場所を特定し、2番ゲートのセキュリティが甘ければ、そこから侵入を企てます。悪意あるユーザーは開いているポートが見つかると、そのポートを通じて接続を試みます。接続される危険性が高まるのです。ポートスキャンは特別なソフトではなく、Linuxであればnmapというコマンドで実行できます。実行例を見てみましょう。PORT(ポート番号)、STATE(状態)、SERVICE(サービス)の項目があり、ポートの状態とサービスが一覧表示されます。STARE(状態)がopenとなっているポートは解放されており、closedとなっているポートは閉鎖されている状態です。この例で言えば23番ポートのTELNETがopen状態なのが危険(図1)。悪意あるユーザーがセキュアな接続を行わないTELNETで接続し、ユーザーIDやパスワードが盗まれるとサーバーが乗っ取られる可能性もあります。21番ポートのFTPサービスがopenなのも要注意(図2)。FTP)できる機能があり匿名接続可能なサーバーであれば誰でもファイル転送できるためウイルスファイルを送られる可能性もあります。あと、念のため...勘違いしないで頂きたいのですが、nmapはハッキング・クラッキングの為のコマンドではなく、あくまでシステムのセキュリティチェックを行う管理用ツールです。それが悪用されるケースもあるということですね。必要ないポートは「戸締り」しておく事が基本中の基本!悪意あるユーザーからシステムを守るための方法はいくつかありますが、その中でも基本的な事項として...「必要のないポートは解放しない」...という事が挙げられます。必要のないポートは解放しておく必要がありません。使用するOSやサービスのセキュリティホールがあるかどうかを予め確認しておく必要もあります。最新の修正プログラムを適用するなど、システムを守るために先手を打った対策が必要。企業などが行っているセキュリティ診断サービスを利用するのも効果的。第三者の視点と分析によるセキュリティ診断を受けることによりシステムにどのような弱点があるのかが判明し、どのような対策を行う必要があるのかがわかります。システムのセキュリティ対策にはこれ以外にも非常に多くの方法があります。それらは今後、ご紹介してゆきますが...いずれの方法も、ユーザーの資産を守るために必要なものであるという事を忘れないでいてください。松田PS戸締りはきちんとしておかないと泥棒に入られたらイヤですもんね。いって全てのドアや窓に3重ロックをかけるとかすると今度は使い勝手が悪くなってしまいます。使用に適した方法で行う必要があるのです。日本ではシステム開発の手法としてウォーターフォールモデルが広く採用されています。それ以外の手法も多々ありますがその中で特に、近年注目されている手法として...「アジャイル開発」...という開発手法があります。これは2000年頃に考案され、アメリカなどで広く採用されている開発手法です。今日はアジャイル開発手法の特徴などについてサラッとみていきます。和訳すると「機敏な、俊敏な」という意味で、その名のとおり機敏な対応を可能とする開発手法です。変更内容を全システムに反映させないといけませんが...アジャイル開発では以下の特徴により開発中にも仕様変更でも柔軟に対応することができます。(1)ユーザーとエンジニアの共同開発チームを編成システム開発を行う際、ユーザーと共同の開発チームを編成します。変更が発生してもエンジニアに変更内容が伝わりやすくなるのです。開発対象となる機能に優先順位をつけ、それらを1~4週間単位に開発可能な単位に分割します。開発対象となる機能が機能1~機能4まで4種類あった場合...優先度A:機能4(マスタ管理機能)優先度B:機能3(顧客管理機能)優先度C:機能1(案件管理機能)優先度D:機能2(入出金管理機能)...といった様に優先順位をつけて、それぞれを1~4週間など、定められた期間で開発するのが特徴です。開発は優先順位に従って進められます。定められた期間内に要件定義、製造、テスト、リリースまで全て行います。ウォーターフォールモデルでは最初に全機能の要件定義を行うのが特徴ですが、アジャイルでは定められた期間に要件定義~リリースまで実施します。全機能をプログラムして、一気に要件定義~リリースまで行うケースも。その場合、リリースするプログラムはプロトタイプや初期バージョン的な扱いになり、ユーザーの全要求を満たしているとは言えない場合が多いです。(4)リリース後の検討リリースしたプログラムをユーザーと共に検証し次に行うべき対応を検討します。迅速な仕様変更にも対応できるのです。アジャイル開発は(2)~(4)を優先順位で定められた順番に繰り返し開発することが特徴であり、これを「イテレーション(反復)」と言います。柔軟な仕様変更にも対応できる開発を行う事ができるのです。実際にはさまざまな開発手法があります。Development、ASD)...など、細かく分ければ手法はさまざま。それらの違いも明確になっているかというと、まぁ曖昧です。基本的には以下のように3つ共通点があります。開発範囲を分割し、小さな単位で開発を行うそしてもうひとつアジャイル開発において共通しているのはプロジェクトメンバー間のコミュニケーションを重視する点です。リスクで進めることが重要です。前述のように、チームメンバーにはユーザーも含まれています。ユーザーからのフィードバックやミーティングなどといったコミュニケーションを通じて、ユーザーが望むシステムを開発しやすいという特徴があるのです。日本ではあまりメジャーな開発手法であるとは言えません。各国におけるアジャイル開発の普及・成長状況を以下とおりまとめました。普及が拡大しているという調査結果ですが...日本ではまだ普及が遅れており、ようやく認知されるようになったとの結果です。苦笑)それには主に3つの理由があります。(1)開発チーム編成の問題アメリカではユーザー企業にIT技術者が多く、チーム編成しやすく、コミュニケーションを取りやすいのですが...日本ではIT技術者のほとんどがSIerやベンダーに所属しているため、チーム編成を行いにくく、またコミュニケーションも取りにくい。ユーザー企業にIT部門がある場合はユーザーをアジャイル開発チームに含めやすいですが...IT部門は人不足な状態が多く自社の通常業務で手一杯になってしまい、ユーザーをチームに含めたとしても連携しづらいのが現状です。(2)多重請負の問題2次請け、3次請けといった日本のIT業界の特徴とも言える多重請負により、アジャイル開発の特徴である迅速・柔軟な対応が行えないことも。柔軟な対応を行うことができない状況になってしまいます。元請→2次請け→3次請け...と多重構造を通して変更を行ってもらう必要があるため、スピード感に欠けるのです。(3)商習慣の問題ユーザー(発注側)は開発側(受注側)よりも立場が上という日本的な商習慣が普及を遅らせる原因にもなっています。欧米ではユーザーと開発側はビジネスパートナーとしてほぼ対等な形で取引されますが...日本では「お客様は神様です」的な考えがあり、ユーザーも開発チームの一員として迅速なフィードバックを可能にするアジャイルの特徴を活かしきれないケースもあるのです。これもサービスの質という意味では、いい面もあるのですが、考えどころですね。海外では小規模案件だけでなく、MicrosoftやIBMなどといった大企業による規模の大きな開発でも採用されている事例もあります。日本型開発におけるアジャイル活用の方法が研究されています。双方がアジャイル開発に精通している場合は柔軟な対応が可能となるのです。日本ではウォーターフォールモデルが主流ですが、それだけでは対応できない状況になりつつあるのは事実です。変化する経済情勢に柔軟に対応できるようなシステムの変更を行うことができるアジャイル開発は魅力的な開発手法。アジャイルを導入したからと言って全てがうまく進む!という訳ではありません。「その画面とこの画面を連携させて情報を表示したい」...などというユーザーからの意見が頻発することも。逆に迅速な対応ができなくなってしまうケースもあります。アジャイルに精通したエンジニアが少ないのも現状。逆にパフォーマンスが落ちるエンジニアが発生する可能性もあります。大切なのは...「ユーザー、案件、納期、チーム等を考慮し、最適な方法で開発を行う」...ということです。開発手法を選択できる立場になったとしても...特定の手法だけとらわれず、それぞれの手法の良い面を組み合わせるのも良いでしょう。アジャイルにはアジャイルの、ウォーターフォールにはウォーターフォールの良さがあります。エンジニアとして様々な開発経験を積んで、どのような案件でも柔軟に対応できるノウハウを身に付けましょう。松田PS日本のIT業界において、アジャイルはまだ黎明期。未経験の方や経験の浅い技術者が、全てを把握することは難しいです。ウォーターフォールから勉強しましょう。それが今のあなたにとって大切なことです。知り合いのSEがぽつりと漏らしたひとこと。愚痴っぽいことを言わない人なので、そのひとことに少し驚きました。彼はあるプロジェクトのリーダーを任されているようです。彼が担当する開発案件は小規模で彼をリーダーに、プログラマが3名の計4名のチーム。マネージャは他の案件と兼務しており実質的に顧客折衝や進捗管理も彼が担当しています。彼自身もユーザー業務をよく知っているので、それほど難易度は高くない開発案件でした。開発チームに所属するプログラマから頻発する「少し調べればわかる程度の質問」と「ギブアップ宣言」が原因でした。チームにいる3名のプログラマは、みな昨年~今年入社したばかりの新人エンジニア。・「できません」「わかりません」と、すぐにギブアップする...というエンジニアが揃ってしまった模様。結局彼らのしわ寄せがリーダーに集中して日中に自分が担当する業務ができず、終電帰宅となるようです。新人エンジニア達にも問題がありそうです。誰もが最初はわからないことだらけ。それはそれで、全く問題ありません。わからないからこそ、できないことも多い。彼らは新人とは言えプロなのです。問題なのは、プロであるにもかかわらず...「何が問題となって、自分が解らないのか?」...ということを理解しようとしない姿勢にあります。わからないことを質問するのは全く問題がありません。質問して早く問題が解決するならば積極的に質問して開発を進める方が良いでしょう。...1.プログラムが思う通り動かない2.とりあえず人に聞いてみよう3.それで動けば問題なし4.それでもできなかったらギブアップ...という考えであれば、プロフェッショナルの姿勢とは言えません。単なる流用はNG優れたノウハウをスキルアップに繋げることが大切プログラミングの際、インターネットなどでサンプルソースを検索してそれを参考にしてプログラミングする方も多いでしょう。開発業務を行ったという経験を持つエンジニアは多いです。心がけておくべきことがあります。それは...「単なる流用ではなく、仕組みを理解する」...ということ。変更すれば問題は解決するかも知れません。先ほどの新人エンジニアの事例と何ら変わりないのです。自分のノウハウに蓄える必要があります。自分自身のスキルアップにも繋がってゆきます。将来的な技術力に大きな差がつくのです。何か問題に直面した時に必要なことは...何が原因となって問題が発生しているか?...という現状を把握し、分析する能力です。プログラム系に関して言えば...・どこでどんなエラーが発生しているか・エラー発生前の処理はどのような処理か・関連クラスの処理や変数の内容は正常か・引数に問題はないか...など。ネットワーク系で言えば...・ルーティング設定に問題はないか・どの機器に問題があるか・断線や配線方法など物理的なことが原因になっていないか...など、自分で考えられる範囲で現状把握を行います。高スキル保有者に相談しましょう。開発期間には限りがあります。問題を自分だけで抱え込む時間が長すぎると、それは開発の遅れに繋がるケースもあるのです。相談する時は、わかりません、できませんではなく...・現状どのような事象が発生しているか・それに対し、どのような調査を行ったか・解決には至らないが、その調査で判明した情報...を必ず伝えるようにしましょう。...という理想的な解決パターンです。自分なりの解決策を説明できれば申し分ありません。簡単に言えば「回避策」の提案です。提案→検討→解決...という流れで、自らの発案によって問題回避できることも。言語的な仕様でどうにもならない!という問題が発生するケースもあります。いう時に回避策を提案できるエンジニアがいると重宝されます。業務に対してどのような姿勢で臨むか?受け身のエンジニアになるか?それとも...積極的な提案ができるエンジニアになるか?姿勢の持ち方次第で、エンジニアとして数年後に大きな差が開くのです。松田PS卒業した瞬間にプロとしての実力と姿勢が身に付く...私たちのプロフェッショナルとしての姿勢です。「アルゴリズム」あなたがプログラムを学習中なら、きっとどこかで一度は見たことがある言葉しょう。このアルゴリズムはプログラムを作成するにあたってとても重要なことです。これが実際なんなのか、よくわかりませんよね?そもそもアルゴリズムって何なの?...というところからこの記事ではお伝えしたいと思います。計算方法や処理手順などのことです。アルゴリズムという言葉を使うのは何もコンピューターに限ったことではありません。問題や課題を解くための処理手順としてアルゴリズムという言葉が使われています。算数とか数学とかを勉強したことがある人なら、だれでも一度はやっています。割り切れた時の割る数が最大公約数になります。これもアルゴリズムです。最大公約数を求めるのにいちいち数値を比較してゆくのは手間がかかります。そこでこのような...「効率の良い手順で処理を行う」という手法がアルゴリズムなのです。処理手順を表現するフローチャートとは?プログラムでアルゴリズムを表現するものとして...「フローチャート」...という図があります。フローチャートとは処理手順を表現するための流れ図のことです。押しボタン信号式の交差点を渡るプログラム(?)...のフローチャートを見てみましょう。ちなみに信号が赤の間はスマホを触って信号が青になるのを待ちます。赤信号が3分以上かかる場合は別の交差点を探しに行く処理を入れましょう。フローチャートで表現するとこのようになります。信号待ちループ処理に入ります。信号を見てみて青信号になっていたら交差点を渡って処理が終了。青信号になっていなかったら「スマホを触る」という処理で、別の処理を呼び出します。スマホを触る処理ではスマホで時間つぶしをするという処理が記述されています。処理が終われば待ち時間を確認。3分以上経っていたら別の交差点を探す処理を行って、このプログラムの処理は終了。信号を見る処理を行うという流れです。実はこのなかでも...「3分以上待ったか?」..という判断が非常に重要です。永久に信号が青になるのを待ち続けなければいけません。ループ処理が永久に繰り返されるのです。強制終了させて実行を停止するしか方法がなくなるのです。このような無限ループを避けるため、アルゴリズムでは「停止性」という定義があります。停止性とは...「プログラムは必ず終了しなければならない」...という意味です。終了させる処理を持たせる事が必要なのです。無限ループ(脱出不可能ゲーム状態)が続かない様にしましょう、ということです。効率よく処理できる...つまり高速なプログラムを作れます。処理が遅いと使いにくいと言われるケースも。ならないためにもプログラムの基本であるアルゴリズムのノウハウを必ず押さえておく必要があります。仕様書を見ながらフローチャートが頭に浮かぶそうです。処理効率の良いプログラムを作成できるノウハウを習得しているからだと言えます。今回はアルゴリズムの例としてユークリッド互除法をご紹介しましたが...プログラミングする上で役に立つ定番とも言えるアルゴリズムはたくさんあります。ソートや検索法などがそうですが、それらについてはまた別の機会にご紹介しましょう。松田PSプログラマーを目指すなら基本的なアルゴリズムは習得しておきましょう。基本的なものはほとんどのシステムで使用されます。自分でアルゴリズムを構築するケースも。基本はしっかりと押さえておきましょう。新宿本校にて、、、IT技術者にとって必要な事。設計スキルやプログラミングスキルなど直接システム開発に必要なスキルはもちろん必要です。一見するとITスキルとは直接関係がないようなスキルも必要になります。数え上げるとキリがない程あるのですが、まずはそのような間接的に必要となるスキルのうち...「ドキュメントスキル」...についてお話ししましょう。多くの技術者が苦手意識を持つドキュメントスキルドキュメントスキル!この名を聞いただけで嫌な顔をする技術者はかなり多いです(笑)多くの技術者はドキュメントの作成を苦手としています。「ドキュメント」とは資料的な文章を意味しますが、システム開発におけるドキュメントとしては以下の種類が挙げられます。要件定義書や基本設計書、プログラム定義書やテスト仕様書などシステムの仕様を定義するための文書群です。設計書に仕様不備や設計バグがあった場合にはプログラム作成やテスト等、下流工程に大きな影響を与えます。開発メンバーがいつ、どのタイミングで、何人必要なのかといった...内部的な開発計画(アサイン計画と言います)など、ユーザー向け、開発チーム内部向けなど、様々な計画書があります。既存システムの問題点などを解消する為の提案などを行うドキュメント。最近では新規システムの導入検討をしている企業が「RFP(提案依頼書)」の提示をシステム開発企業に求め傾向があります。多くの場合は営業担当が作成しますが、SEが作成する場合もあります。(4)ユーザーマニュアル新システムの使い方などをまとめたマニュアルです。各画面や帳票の説明、その他システムに関してユーザーが行わなければならない事項を手順としてまとめます。場合によってさまざまな報告書が必要となります。多くの文書を作成する必要がある事をおわかり頂けたでしょうか。ユーザーによって求められる文書の種類は異なりますが多くのドキュメントを作るとなると、かなりのマンパワーが必要です。基本的にSEやPGには...「きちんと動くシステムさえ作れば、ドキュメントは程々で良い!」...という考えを持った人が(残念ながら)多いです。そのためドキュメントについては必要最小限の労力をもって作成する傾向があり...必要最小限の労力しか費やさない為にドキュメントスキルが磨かれず、苦手意識を持つ人が多いのが現状です。作成負荷を減らしたいからドキュメントを簡素化それが逆に稼働負荷が掛かる結果を招く事も!開発案件によっては納期までのスケジュールが短いため...「ドキュメント作成量をできるだけ減らしたい!」そういった現場の声があるもの事実。全体的に開発稼働が余分にかかってしまうというケースもあります。以下の様な画面設計書があるとしましょう。顧客管理するシステムの、顧客情報を登録する画面です。顧客コードを入力します。っぽく見えなくはないですが正直言って、この設計書を渡されたプログラマーは困惑します。顧客コードは何ケタなのか?顧客名は何バイトまで入力できるのか?顧客名カナは全角なのか半角なのか?このような確認事項が増える事により開発時間がズルズルと遅れてしまうケースもあります。先ほどの顧客情報登録画面を以下の様にしたとしましょう。顧客コードを入力する。全角文字であれば全て入力可能。入力内容を破棄し、「キャンセルしますがよろしいですか?(はい/いいえ)」ダイアログを表示して「はい」が押下された場合はメニュー画面に戻る。先ほどの例と比べると各段に質問の量は減ります。ドキュメントを作成するにあたり簡素にできる部分は簡素にして構いません。1~100まで記述すればドキュメントの作成稼働だけについやされて他の作業を行うのに支障をきたします。「時間がないから」という理由で本来記述しておくべき内容を書かないというのは...あなたにとってもチーム全体にとっても、そしてシステムにとっても良いことではありません。ドキュメントは開発者を守るものIT技術者の中には...「とりあえず動くプログラムがあれば良いのでは?」...という発言をする方もいます。「ソースがその処理内容の仕様なのだから」...という意見から出ています。残念ながら正しいとは言えません。部署異動などであなたがそのシステムの保守担当から外れたとしましょう。後任の担当者があなたのレベルにまで該当システムに精通していない場合、コードから仕様を把握しろというには、現実的に無理があるのです。場合によっては10年以上使用されるシステムもあります。システムに不具合らしき事象が発生した場合、それが本当にユーザーが当初から求めていた仕様なのかどうか?ドキュメントに記載していないと判断がつかないのです。ユーザーはプログラムの中身までは見ません。設計書などユーザーが認証したドキュメントを見て判断します。現在起きている不具合らしき事象が設計書にも打ち合わせ議事録にも、どのドキュメントにも記載されていない場合、プログラムのバグとして扱われてしまうケースが多いです。バグ修正は基本的に無償で行う必要があり、またバグ修正の為のデータ修正や現地対応の費用、ユーザーへのバグ終息報告資料の作成など、多くの稼働が発生します。開発側に余計な稼働負荷を掛けない保険にも成り得るのです。専門性だけでなくビジネス力も身に着けるドキュメントを作成するにあたり守らないといけない大原則があります。それは...「誰が読んでも理解できるドキュメントを作る」...という事です。システムが扱う業界によっては専門用語の知識が必要な場合もあり、また基本的なITの知識も読み手には必要とされます。システムはひとりで作るものでもなく、ひとりで使用するものでもありません。設計書であれば...プログラマーにはプログラム作成の際に作りやすいように、ユーザーには処理内容をわかりやすく理解してもらうための工夫が必要。計画書であれば...どのような計画でプロジェクトを進め、どのタイミングでどのようなイベントが発生するのかなど誰が見ても理解できる計画書。費用やスケジュールなどを考慮した上で提案内容を実現する事によるメリットが伝わりやすい様に。ユーザーマニュアルであれば...たとえば新人のユーザーであってもマニュアルがあればある程度の操作ができるような操作方法や手順が明確に記載されている、読みやすいマニュアルを。報告するだけの書類ではなく、どう対処するかまで報告すること。誰が読んでも理解できる内容を心がける!これがドキュメント作成するにあたって肝心な事です。ドキュメントスキルを向上させる為にもうひとつ...ダラダラと文字だけを書き連ねる!...といったドキュメントは作成しないようにしてください。視覚的に把握しやすい資料があれば、それは読み手の印象に残りやすくなります。直接的な関連はなくとも、ドキュメントの印象付けとして画像を挿入するのも良いでしょう。プレゼンテーションで使用するドキュメントであればアニメーション効果や動画を使用するのも効果的です。最初はプログラム作成ばかり行うかも知れませんが...キャリアを積んで行くに従い、プロジェクトリーダーやプロジェクトマネージャーになると、さまざまなドキュメントを作成する機会が確実に増えます。多くのIT技術者が苦手としているスキルです。誰もが苦手にしているスキルだからこそ、あなたがドキュメント作成スキルを身に着ける価値があるのです。このスキルは、IT分野に限った事ではありません。あなたが独立して、起業するとした場合にもきっと役に立ちます。IT技術者にはもちろん専門性が必要です。総合的な「ビジネススキル」を磨くという事も忘れないでください。松田PSドキュメントの作成の仕方は、ひとりではなかなか学べません。新宿本校にて、、、システム開発の手法はさまざまありますが...「ウォーターフォールモデル」...という開発手法がほとんどの開発で採用されています。古くから開発手法であり他の手法もあるにもかかわらず、現在でも主流の開発手法です。詳しく説明しましょう。ウォーターフォールモデルとは?上流工程から下流工程までの特徴ウォーターフォールモデルは1970年に提唱されたソフトウェア開発手法。各工程における品質の確保を図ります。上流工程から下流工程まで流れる様に開発が行われます。細かく説明しましょう。(1)要件定義ウォーターフォールモデルにおける最上流工程。業務改善の為に何らかの対策をしたいという目的があるということ。その目的の認識がズレたまま開発が進むと下流工程に進むに従い、大きな認識違いが発生します。どのようなシステムにしたいか?システム化対象範囲やシステム導入によって業務がどう変わるか?システムと業務の具体的な分析が必要となるフェーズです。(2)基本設計システム開発をするにあたり要件定義フェーズで決定された事項を具体化するフェーズです。・システム内部で使用する区分の決定...などが挙げられます。画面や帳票などのサンプルを作成し、ユーザーに見てもらってフィードバックする場合もあります。プログラム単位などより詳細に機能分割して設計するフェーズです。・単体テスト仕様書の作成...などが挙げられます。基本設計では見えていない要件や基本設計段階ではまだ不完全なものがあれば詳細設計フェーズで修正を行い、仕様を確定させます。次の開発フェーズで実際にプログラミングが行われるのです。(4)製造(プログラミング)詳細設計書を元に実際にプログラムをコーディングします。共通的に使用するプログラムがある場合は、先にそちらを作成します。次のフェーズである単体テストを同時に行うケースが多いです。(5)単体テスト作成したプログラムに対し単体テスト仕様書を元にテストを行います。簡単なテストの場合はテストスクリプトを作成し自動テストツールでのテストを行って効率化を図ります。テスト結果で不具合があった場合は不具合内容をプログラマに伝えて修正して再テストを実施。次の結合テストフェーズに移ります。画面・プログラム・サブシステム間の連携が正しく行われているかどうかを確認します。具体的には業務フローを元に実際の業務を想定したテストシナリオを作成し...最初のインプットから想定できる結果が正しくアウトプットされるか等のテストを実施。連携方法や制御方法にバグがあった場合はこのフェーズで発見されます。(7)総合テスト(システムテスト)実際にユーザーの環境と同じかそれと同等の環境において行うテスト。実際の他システムと連携して正しく動作するかなどをテストします。要求機能を満たしているか、操作感はどうかなどを確認してもらうフェーズ。旧システムでインップットした内容が新システム側でも旧システムと同じアウトプットかなども確認します。(9)リリース新システムを本番環境にリリースします。以前ブログで書いておりますのでここでは割愛致します。(10)運用・保守システムの運用、保守を行うフェーズ。新しい機能要求が挙がった場合には追加開発などを行ってシステムの保守を行ったりします。説明が長くなりましたが、ウォーターフォールモデルは、このような流れで進行するのです。ウォーターフォールモデルのメリット・デメリットとは?ウォーターフォールモデルのメリットとデメリットをまとめると以下の様になります。事前に今後必要となる事項を想定しながら開発できる。・進捗管理のしやすさ全体を把握した上で工程別・タスク別に管理可能なことから、プロジェクト全体や、各開発要員の進捗管理を行いやすい。・成果物ベースでの開発ドキュメントなど成果物がある状態で開発を行うため、どのような開発者でも仕様書を読めば開発する事ができる。企業のスピード感が早い場合、仕様変更が発生する可能性が高くなります。変更内容によってはテストのやり直しなどが発生するケースもあります。成果物ありきで開発が進められるため、ドキュメントなどの成果物の作成・修正稼働に負荷がかかるのが特徴。ウォーターフォールモデルには、この様なメリット、デメリットがあるのです。ドキュメントによる品質・工程管理しかしそれは両刃の剣にも成り得る可能性が?ここで、メリットにもデメリットにも登場したウォーターフォールモデルにおける成果物(ドキュメント)管理について、もう少し詳しくお話ししましょう。ウォーターフォールモデルはドキュメントの作成量が多いことが有名です。各開発工程の最後には成果物として設計書やテスト結果報告書などさまざまなドキュメントをユーザーに提示します。開発側は次の工程に進むことができるのです。実際には納期が短く、ドキュメントは後から提出して、できるだけ早く工程を進めて行くというケースもありますが...ウォーターフォールモデルは前工程の成果物ありきで進められるのでドキュメントがないと先々の工程に進みにくい性質を持ちます。大規模なシステム程ドキュメント量が膨大な量になる傾向があり、その作成や管理稼働に大きな負荷がかかってしまうのです。後になって要求仕様が変更された場合には多くのドキュメントを修正する必要があります。ウォーターフォールモデルの特徴として計画の立てやすさ、進捗管理のしやすさがありますが、これらの管理資料の作成だけでも、かなりの稼働がかかってしまいます。開発計画や実績を把握できる資料を作成してプロジェクト管理を行います。作業項目単位で作成する必要があるためWBSを作成するだけでもかなりの稼働負荷がかかりますし...ユーザーの都合でスケジュール変更があった場合には、その変更内容を反映し、スケジュールを組みなおす必要が発生します。逆にドキュメントに対する稼働負荷が高いという特徴もあるのです。基礎力を身に付けておけば、他の開発手法でも対応可能ウォーターフォールモデルは大規模開発向けの開発手法と言われています。その理由は、きちんと何もかも整えた状態でプロジェクト全体や各開発者の進捗管理ができる為です。実際には規模の大小を問わずほとんどの開発案件で採用され続けている手法。それは一体なぜなのでしょうか。長年多くの技術者がこの開発モデルを経験しノウハウを持っている技術者が多いというのもありますが...もうひとつ...「成果物と一緒に費用を請求しやすい」...という点も挙げられます。全て納品してから請求・・・となると、運転資金が調達できません。そこで採られる方法が「分割検収」という方法。~詳細設計までの成果物を納品したら○万円請求......というように、フェーズの終了毎に請求を行います。資金繰りもしやすいこの手法が採られるケースが多いのです。実際には柔軟に仕様変更を行いたいユーザーが多いのも事実。ご説明したとおり、ウォーターフォールモデルには柔軟な仕様変更を可能とするスピード感に欠けるというデメリットがあります。最近ではウォーターフォールとアジャイルを組み合わせるようなハイブリッド型と呼ばれる開発手法も存在します。各フェーズで行う作業内容は把握しておきましょう。内容としてはウォーターフォールモデルの各フェーズを分解・再構築して手順を変えたものが多いです。ウォーターフォールモデルは、IT技術者になれば、必ず1度は経験する開発手法。習得しておきましょう。松田PSウォーターフォール型を実践できる開発演習を含んだコースが多数あります。視野の狭い技術者はとてもとても厄介です。前は、こうしていたから・・・この前携わった業界ではこれが常識だったから・・・この方法が一番いいに決まっているだろ!・・・などなど。必要なことがあります。さまざまなユーザーと話すことで技術者としての視野は広がるIT技術者と言っても、その役割はさまざまです。プログラマーやシステムエンジニア、プロジェクトリーダーやプロジェクトマネージャなどそれぞれに役割があり、扱う業務内容も異なってきます。小さな企業や個人事業主のIT技術者の場合は、それらの役割をほぼ全てこなさないといけません。ほとんどの技術者は、プログラマーから始まり、徐々にステップアップします。直接ユーザーと話す機会は確実に増えてゆきます。企業の幹部クラスの方々や経営者と直接話すことも。業界が同じでも企業課題としている内容が全く別ものであったりします。生の情報は実際に話す事により得られます。生の情報を知る事により、IT技術者の視野は広がってゆくのです。異業界の開発案件は視野を広めるチャンス前の業界の常識を持ち込むのはやめましょう。新しい業界には違った常識があり、ノウハウがあります。(これを、面倒だな、ではなくチャンスだと考えるべきです)幅広い業界のシステム開発を行うIT技術者の場合、それまで経験してきた開発案件によって、強みや弱みはあります。あなたが金融系システムは詳しくなったけど、それ以外はあまり経験がない技術者だとしましょう。会社の都合により開発要員がどうしても確保できない。物流系システムのプロジェクトリーダーを任されとしたら...物流系業務についてはほとんど業務知識がないため、かなり大変な思いをするでしょう。物流業界や業界用語を勉強し、システム開発を行わなければいけません。最終的にはユーザーの業務内容を知る事が必須要件。何度も打ち合わせを重ねた上で、ユーザー業務のノウハウを知る必要があるのです。物流業界の基本的な事について教えて頂くこともあります。「そんな事も知らなくて大丈夫か?」...とお叱りをうけることもあります。それでもユーザーと打ち合わせを重ね続け...どのようなシステムを作りたいか?どのような課題があり、どのように解決したいか?IT技術者として課題解決を可能とするシステムを構築する必要があります。並大抵のパワーでは達成することができません。それを乗り越えて自ら積極的にユーザーに働きかけてノウハウを身に着けることは、あなたを技術者としてより高みに押し上げてくれます。何も知らない状態からユーザー業務の知識を知るにはどうすればよいか?そのような「ノウハウを得る手法」を身につける事もできるのです。次回また、全く経験のない業界の開発案件を任されたとしても、あなたは既に...「ノウハウを得るにはどのようにすれば良いか」...という基礎能力を身につけています。何も異なる業界の案件を対応した時だけではありません。今度は、あなたが飲食系のパッケージシステム開発を行っているとしましょう。業界は飲食業に限られます。パッケージシステムはその業務を行うにあたって基本的な機能を備えているのですが...企業によって業務内容は異なりますので、ユーザーの要望によってカスタマイズを行うことがほとんど。重視している機能は異なります。とある複数チェーン店を展開する企業はお店の社員やアルバイトのカラ出勤が問題視されていました。カラ出勤とは、お店の同僚にメールや電話で...「遅れそうだからタイムカードを打刻しておいて!」...と連絡して、実際には出勤していないのに出勤したことにする事です。出退勤は静脈認証で登録するカスタマイズを実施するようにしました。別の飲食チェーン店では食べに来てくれるお客様とのコミュニケーションを強化する為、お店のポイントカードとシステムに含まれる顧客情報を連携させて、そのお客様の嗜好や来店頻度を管理するカスタマイズを行った例もあります。同じ業界であっても企業によって課題やシステムに対する要求はさまざま。ユーザーとの仕様検討段階でどのような課題があり、どう解決するかを検討するのですが...「A社ではこのような問題はなかったのに、B社では問題となっているのか」といった企業による差異はあなたの業界に対する知識を深めますし...「過去に開発したC社のノウハウを、B社にご提案したらどうだろう」といった新しい業務改善の提案にも繋がるケースもあります。同一業界についてのノウハウが深まる事によりコンサルタント的な立場でのユーザー課題改善を行う事も可能になるのです。得られる利益が大きくなります。コンサルティングほど利益率の高いビジネスはなかなかありません。脳みそ以外は不要ですから。本当に大切なことです。あなたはどのような技術者になりたいのでしょうか?IT技術者になりたての頃は「将来なれる技術者像」という選択肢はたくさんあります。業務系エンジニア、ネットワークエンジニア...プログラマーとして特化してゆくという方もいるでしょう。どのような技術者になろうとも自分の視野を広めるという努力だけは怠らないようにしてください。中にはそう言う方もいることでしょう。それも視野を狭めない為に行える、大切なことです。実際に自ら行動することによる生の体験ほど約に立つものはありません。苦労しつつもノウハウを習得した経験。ユーザーと何度も打ち合わせを重ねた経験。同業他社と協力してシステム開発を行った経験。そこには全て「人」の存在があり、コミュニケーションがあります。いった生の体験こそが、その人の視野を広げ、活躍できるフィールドを広げる事に繋がるのです。時には自ら行動して体験することが、あなたの視野を広げてくれます。先ほどの例で、プログラマーとして特化する道を選択する方なら...ワーキンググループなどに参加して同じ志を持つ人に出会える事により、プログラマーとしての視野は広まります。