情報セキュリティ10大脅威 2016を読んで素人でも気をつけられること
3月末の公開された情報セキュリティ10大脅威 2016を読んで
むやみやたらに銀行口座やクレジットカードを作らない
―自分で把握できる範囲に留める
―使わなくなったら解約する
むやみやたらに銀行口座やクレジットカードの番号、電話番号等を利用しない(WEB上もお店でも)
―信用度が高い安全なサイトでの利用に留める
―プリペイドカードの購入やコンビニ支払いなども利用してみる
あやしいメールは無視する
―携帯電話やPCの迷惑メールフィルタを厳しめに設定して定期的に見直す
―知らない人からのメールの添付ファイルは絶対に開かない
―知らない人からのメールのリンクは絶対に開かない
―メールのアドレスを確認して変な文字列だったら無視する
メールの添付やリンクは用心して開く
―知り合いからのメールの添付ファイルやリンクを開く場合に心当たりのない内容であれば電話等で相手に確認する
―メールのリンクを開くときはURLがgoogleで検索して最初のほうに出てくる正規のサイトのURLと本当に同じか確認する
できれば手間とお金をかける
―セキュリティソフトはなるべく入れる(できれば有料のもの)
―OSなどのアップデートは定期的にする(アップデートの通知機能をオンにしておく)
―メールアドレスとパスワードのペアは使いまわさない(パスワードの文字数はなるべく長くする)
―インターネットバンクなどで認証方法や入力方法が複数ある場合は推奨されているかめんどくさいほうを選ぶ
―銀行口座やクレジットカードの入出金は毎月確認する
―利用サイトにログイン通知や課金通知の設定があればなるべくなら設定しておく
―気になることがあればパソコンに詳しそうな知り合いやインターネットから情報を入手する
―見逃したTV番組やHな動画は違法アップロードされているものではなく、お金を払って正規の配信サイトやレンタルビデオを利用する
分からないものには手を出さない
―よく分からないアプリをイストールしない(スマホアプリのレビューはさくらも多いので信用しない)
―あまり浸透していないサイトに入会する場合などはご利用規約に一応目を通す(～円請求しますと書いてないか？)
書いてある内容を鵜呑みにしない
―知らないメールの退会はこちら配信停止はこちらは信用しない(クリックすると相手に攻撃しやすくしてしまうだけ)
―あなたのパソコンが感染していますはいったんスルーする(クリックすると相手に攻撃しやすくしてしまうだけ)
また思いついたら追記
【勉強メモ】情報処理試験 プロジェクトマネージャ試験対策
試験まであと１週間
◼︎合格までの勉強時間目安
最低50〜100時間 ※個人差あり
◼︎問題を解くときのポイント
プロジェクトマネージャとしての立場から
１.スコープ マネジメント
２.タイム マネジメント
３.コスト マネジメント
４.品質 マネジメント
５.人的資源 マネジメント
６.コミュニケーション マネジメント
７.リスク マネジメント
８.調達 マネジメント
の何に関する問題を解決すればよいのか理解
本文を読むときは
・プロジェクトの概要
・プロジェクトの目的
・スケジュール
・プロジェクトの現在のフェーズ
・プロジェクトの体制
を意識する
発生した状況➡️リスク・問題・目標➡️取るべき対応の順に考えていく
◼︎午前１ マークシート30問(50分)
免除もしくは勉強０で突破可能だと望ましい
◼︎午前２ マークシート25問(40分)
参考書で基礎知識を学んだらひたすら過去問
常識的な考え方で結構解けるので人によっては勉強時間０でも突破可能
◼︎午後１ 記述式４問中２問(90分)
時間との戦い 先に設問を読んでから本文を読む
こういう場合はこう答えるというパターンは最低限抑えておいたほうがいい
◼︎午後２ 論文(120分)
必ず下地を準備しておく(最低３つくらい)
ある程度マネジメント対象ごとにシナリオを考えておく(時間がなければ対象を絞って準備する)
タイム、コスト、品質、人的資源あたりから
◼︎教訓
一担当者が勝手に変更要求を受けない
プロジェクトの実績や教訓は今後のプロジェクトに活かす
要員の追加で余計なコストも発生する(教育,資源,コミュニケーションなど)
納期に間に合わないときは段階リリースも検討
メンバーの進捗管理はルールを設け、報告を徹底させる
メンバーの進捗報告の裏付けとなる成果物を確認する
進捗遅れの予兆がないか監視し早期解決する
進捗遅れに対する選択肢は部分稼働、要員の追加、稼働時期の延期、ファスト・トラッキングあたり
ユーザ部門間の調整が難航しているときは、支援メンバーの派遣、顧客の上長や経営陣への調整依頼などで対応
ユーザの承認を得ず次工程へ進むのは、出戻りのリスクがあるのでなるべく避ける
進捗は必要に応じて、着手、◯％、作業完了、レビュー完了など細かく管理する
移行は可能なものは前倒しする、事前にリハーサルしておく、移行に必要な時間を見積もっておく
ツールの導入,再利用率で開発生産性が上がる
開発規模の拡大,要員のスキル不足,仕様変更の多さで開発生産性が下がる
性能テストで問題があった場合は設計変更やハード増強などで対応する。リリース直後にそこまでの性能が必要ない場合はリリース後に対応
レビューで顧客の理解が弱い場合、プロトタイプやパッケージの機能を使ったデモンストレーションを行う
テストの工数は新規または修正したプログラムの他プログラムを考慮した重み付けをする
障害密度が基準上限より高い場合は開発体制に問題がなかったか確認する
障害密度が基準下限より低い場合はテストケースに問題がないか確認する
特定の業務知識やスキルが要求される作業はできるメンバをアサインする
新バージョンの実績がない場合は旧バージョンの適用を依頼元と交渉する
様々な顧客が利用するシステムのバージョンアップは各環境での動作検証をする
インターフェイスの変更は極力ないように調整するのが好ましい。変更する場合は仕様書も同時に修正する
システム要件の性能目標は過去の実績から見積し、できるだけ早い段階で担当メンバーが検証できるのが望ましい
ドキュメントの書式は管理基準に明記し、各メンバーに遵守を徹底させる
設計書の記述不足は開発効率の低下に繋がるので早期に解決する(教育,サポート,要因交代など)
内部レビューは事前に資料配布。指摘事項は管理表に記入し、正しく修正された確認をする
顧客がパッケージに合わせた業務改革に抵抗する場合、上層部へ説得の協力を要請する
ユーザレビューの意見交換が不十分の場合は、議事録で決定事項の明記し認識を合わせたり、専門家を参加させ議論を活発になるよう働きかけてもらたりする
システムテスト開始をスムーズに行うため、前段階の結合テストフェーズなどから環境を構築し利用する
同じプログラムの複数のバクの修正はある程度一括で行うと効率がよいが、他プログラムから利用がある場合テストが滞らないか気をつける
新規開発と改修で品質管理基準を別に設定する
既存システムへの改修は修正箇所とは別に影響を受けるプログラム数に一定割合をかけたテスト工数を設ける
開発中システムを利用した別システムの開発案件は開発中システムが稼働して一定期間置いた後に着手するほうが望ましい
請負開発で責任範囲外のボトルネックが発生する可能性が考えられる場合は、契約書等に明記
サービスレベルは後から高いレベルを要求されないよう事前に最大接続数やレスポンスタイム等設定しておく
検討漏れがないようSLA検討委員のメンバーをプロジェクトに加える
メンバーが他業務と兼務している場合は当メンバーの優先順位をはっきりさせておく
開発会社の経験が乏しい場合は、経験豊富なメンバーを体制に加えてサポートさせる
開発会社の規模が小さい場合は、人員の確保に不安があるので規模の大きな会社からのメンバ動員なども準備しておく
開発会社が海外の場合は、文化言語時差による管理工数の増加を見込んでおく
業務要件が複雑で開発保守の難易度が高い場合は前工程のメンバーを後工程にアサインしたり、十分な引き継ぎ期間を設ける
顧客の拠点が遠隔地にあり、リモートでの対応が困難な場合は、拠点の近くの会社への保守業務の委託も選択肢に入れる
大量の個人情報を扱う場合は、経営陣に取り扱いの基本方針を決めてもらい、ルールの周知、監視、情報のマスキングなど行う。不要になった情報は破棄する
開発メンバーが企業特有の用語を理解していない場合は、用語集を作成する
ユーザがシステムを使いこなせるようリリース前にトレーニング期間を設ける
支援を受ける予定だったメンバーがアサインできずに進捗が遅れる場合は、該当メンバーの作業を他メンバーに振ることができないか検討する
部門を横断してチームが組まれているとき、作業場所を合わせた方が、連体感一体感が生まれ作業効率も上がりやすい
進捗回復の追加メンバーは、慣れるまで作業効率が上がらない前提で予定を組むとともに、実際の作業に入る前段階に業務を理解するための期間を設ける
定例会議や報告のルールは統一して明文化する。担当者の負担が大きくならないように決める
距離が離れていて直接の打ち合わせがあまりできない場合は、テレビ会議で意思疎通をしやすくしたり、成果物をネットワーク上のファイルサーバ上で共有して認識の違いがないか確認したりする
部門間で認識に差異がある場合は、経営会議でプロジェクト憲章を決定してそれに従って進めるとともに、情報システム化委員会を設置し部門間の意見を調整する
リスク管理はマネジメント計画 リスク識別 定性分析 定量分析 対応計画 監視コントロールの順序で進める
リスクコントロールは回避軽減、リスクファイナンスは転嫁受容に分類して考える
システムの利用部門が多忙な場合は、後で変更要求が多発してしまう可能性があるため、業務部門の上長に相談しレビューに参加する時間を確保してもらう
取引先の評価基準を明確にして広く募集をかける。評価基準はプロジェクトの特性に応じて重み付けする
取引先の評価で点数が他者に比べて極端に乖離している場合はベンダーに認識のずれがないかヒアリングする
請負契約を結ぶとき仕様や成果物は明確にするとともに後工程での変更については別契約と同意明記しておく
請負開発で顧客から直接指示を出すのは法律違反
依頼元企業に合併吸収など開発が中止になるリスクがある場合は、中断時までの費用をもらう契約を結んでおく
製造のみ請負開発で外出しした場合は設計ミス実装ミスで責任の押し付け合いになるリスクがある
◼︎キーワード
立上.計画.実行.監視.変更管理.終結
ステークホルダ
変更管理委員会
プロジェクト完了報告書
WBS(機能別,作業別)
ワークパッケージ
アクティビティ
スコープ記述書
アローダイアグラム
工程山積表
ファスト・トラッキング
クラッシング
マイルストーンチャート
類似法見積
ボトムアップ見積
ファンクションポイント法(入力画面数,参照画面数,超票数,TBL数,外部IF数)
標準値法
COCOMOモデル法
putnumモデル法
コスト・ベースライン
EVM(アーンドバリュー管理) 時間xコスト
PV planned value
AC actual value
EV earned value
CV cost variance (EV - AC)
SV schedule variance (EV - PV)
トレンドチャート 開発期間x予算消化率
ソフトウェアの品質特性(機能性,信頼性,使用性,効率性,保守性,移植性)
ウォークスルー
インスペクション
品質管理図と信頼性成長曲線
ゴンペルツ曲線(ロジスティック曲線)
QC７つ道具(パレート図,特性要因図,層別円グラフ,ヒストグラム,管理図,相関図,チェックシート)
RAM 責任分担表
マトリックス組織 タスクフォース組織 委員会組織 機能部門別組織
階層別チーム チーフプログラマチーム スペシャリストチーム 民主的チーム
テイラーの科学的管理法
メイヨのホーソン実験
ハーズバーグの動機付け衛生理論マグレガーのXY理論 マズローの欲求5段階説
軽重順序法
コンフリクト
インタビュー法
【読書メモ】ＩＴエンジニアにも重要な心の健康
ストレスと上手に付き合っていくためのアドバイズが満載です。
かなり昔の記事ですが、無料で読めるので
>Webサイト
http://jibun.atmarkit.co.jp/llife01/index/index_stress.html
http://www.atmarkit.co.jp/ait/articles/1412/03/news011.html
【日記】クラウド初心者AWSを少しさわってみた
© qwikLABS® '12-'16; は誰でも利用できるコンピュータラボです。
3月中は無料ということで初心者向きのラボを体験してみました。
ｐｄｆに沿って操作するだけで初めてＡＷＳを触る人でも簡単にＡＷＳの機能を体験できます。
ＡＷＳに限らずサーバー構築の勘所が学べてとてもよかったです。
～以下は本サイトよりコピペ～
▲サイト▼
▲体験したコース▼
Websites & Web Apps
Creating Amazon EC2 Instances (for Linux)（日本語版）
このラボでは、Amazon クラウド内で初めての仮想マシンを起動して設定する手順を紹介します。Amazon マシンイメージを使用して Amazon EC2 インスタンスを起動する方法、SSH 認証用にキーペアを作成する方法、セキュリティグループを使用して Amazon EC2 インスタンスへのネットワークアクセスを保護する方法、ブートストラップスクリプトを使用して Amazon EC2 インスタンスを自動設定する方法、および Amazon EC2 インスタンスに Elastic IP アドレスをアタッチして静的インターネットアドレスを指定する方法について学習します。このラボが終了すると、シンプルなウェブサーバーがデプロイされた状態になります。このウェブサーバーには情報ページが 1 つあり、この仮想ウェブサーバーインスタンスの詳細が表示されます。
Creating Amazon EC2 Instances with Microsoft Windows（日本語版）
このラボでは、Amazon クラウド内で Windows 仮想マシン（インスタンス）を起動して設定する方法について説明します。Windows Amazon マシンイメージ（AMI）を使用して Amazon EC2 インスタンスを起動する方法、PowerShell を使用してブートストラップする方法、認証用にキーペアを作成する方法、セキュリティグループを使用して Amazon EC2 インスタンスへのネットワークアクセスを保護する方法、および Amazon EC2 インスタンスに Elastic IP をアタッチして静的インターネットアドレスを指定する方法について学習します。
Introduction to AWS Identity and Access Management (IAM)
このラボでは、 AWSアイデンティティおよびアクセス管理（ IAM ）を使用してAWSサービスへのアクセスとアクセス許可を管理する方法を示します。 、グループにユーザーを追加パスワードを管理、 IAMが作成したユーザーでログインして、特定のサービスへのアクセスにIAM政策の効果を確認するための手順を練習。
Using Open Data with Amazon S3（日本語版）
このラボでは、データを Amazon S3 にアップロードして、ウェブブラウザから誰でもそのデータにアクセスできるようにする方法をデモンストレーションします。Amazon S3 バケットを作成する方法、ウェブサイトをホストするように Amazon S3 バケットを設定する方法、オブジェクトを Amazon S3 バケットにアップロードする方法、JavaScript を使用してそのオブジェクトをウェブページに表示する方法を学びます。さらに、オープンデータを作成するためのベストプラクティスについても学びます。このラボが終了すると、データへのアクセスを簡単にし、データの基本的な情報を提供する、シンプルなウェブサイトがデプロイされます。
Working with Elastic Load Balancing（日本語版）
このラボでは、Elastic Load Balancing (ELB) の概念を紹介します。このラボでは、ELB を使用して、アベイラビリティーゾーン内の一連のウェブサーバー間で負荷分散を行います。2 台の Amazon EC2 インスタンスを起動し、ブートストラップによってウェブサーバーとコンテンツをインストールしてから、Amazon EC2 DNS レコードを使用してインスタンスに個別にアクセスします。次に、ELB をセットアップし、インスタンスを ELB に追加してから、ELB DNS レコードにアクセスして、サーバー間でのリクエストの負荷分散を監視します。最後に、CloudWatch で ELB メトリックスを確認します。
Maintaining High Availability with Auto Scaling (for Linux)（日本語版）
このラボでは、Auto Scaling の基本を、Auto Scaling のいくつかのユースケースや Auto Scaling 設定に使うコマンドラインツールを取り上げながら紹介します。 このラボを完了すると、負荷に合わせてキャパシティーを自動的にスケーリングする伸縮自在なウェブファームを設定してテストできます。 さらに、Auto Scaling を使用して重要なリソースの高可用性を維持するという、安定状態のユースケースを調べてみることができるでしょう。
Building Your First Amazon Virtual Private Cloud (VPC)（日本語版）
このラボでは、プライベートサブネットとパブリックサブネット、ルーティングテーブル、およびプライベートサブネットがインターネットにアクセスできるようにするための NAT サーバーを含む Amazon Virtual Private Cloud (VPC) を作成する方法をデモンストレーションします。
【勉強メモ】情報処理技術者試験の勉強
1)やる気に頼らない
やるぞ！と思った気持ちは長く続かない。
やる状況を作る
・スケジュールを無理なく立てて、気分が乗らなくても机に向かう。やって当たり前の習慣を作る。
・やった記録を必ず取る。客観的に進捗を管理して試験範囲を満遍なく一通りやり切る。(重点的にやるとこ、手を抜くとこのメリハリは必要だけど)
・勉強時間をできるだけ多く捻出する。通勤時間などを有効活用する。仕事帰りに喫茶店に寄るなどルーチンワークにする。
2)学習効率を上げる
迷いながらあれもこれもやって時間の無駄になることもある。
他人の知恵に頼る
・合格体験記など見て、自分もできそうなところは真似する。
・学習素材をケチらない。お金をかけたらやらざるを得なくなる。お金をけちって、効率の悪い勉強をするのは逆に損になる。
時間配分を考える
・しっかり合間に頭を休める。
・余裕をもったスケジュールを立てる。教材を進めるよりも、学んだことが頭に定着することを優先させる。
・本番を意識して予行演習しておく。早く文章を読む、効率よく問題を解くコツを身につける。
アウトプットする
・テキストを目で追って終わりでなく、自分なりに理解したことをノートにまとめる。
・過去問も空で解くのではなく、書き出して採点するまでする。問題を解いたあと、出来なかったところは要点書き出すなどして、次までに必ず出来るようにしておく。
3)絶対受かるという気持ちで臨む
最近の傾向を見ると受かる気持ちで受ければ、合格できる
・特別高い能力は要求されない
・正しい手段でお金と時間をかければ、業務経験がなくても合格は可能(学習効率にはかなり影響あるけど)
・受からなくてもいい前提で手を抜けば、それなりの確率でしか合格しない
当たり前の準備を当たり前にすれば上手くいくけど、それがなかなか難しい...
階段が何段あるか数える
例えば100〜200段とかある階段で
いちにさんしごろくしちはちきゅう じゅう
いちにさんしごろくしちはちきゅう にじゅう
いちにさんしごろくしちはちきゅう さんじゅう
と数えてると、そのうち、50(ごじゅう)だったか60(ろくじゅう)だったか分からなくなってしまう。
頭の中に次から次へと数が浮かんでくるので、大事な◯じゅうの部分が記憶の海に埋もれてしまう。
たんたんたんたんたんたんたんたんたん じゅう
たんたんたんたんたんたんたんたんたん にじゅう
たんたんたんたんたんたんたんたんたん さんじゅう
と数えてみる。不思議なことにさっきの数え方より◯じゅうの部分を忘れなくなった。
リズム感よく
たんたんたんたんたんたんたんたんたん
を刻むと
意外と１〜９を数えるとこは口に出さなくて平気だった。
他にも何か応用きかないかな〜？
実になる読書
全部二番煎じというかどっかで聞いた話だけど、まとめ。
読む前に読む目的を考える
- エンタメとしてなら楽しんで読む。
- 何か今後活かしていきたいなら内容が定着する工夫をする。
さらっと内容に目を通す
- 部分部分で理解するより全体のなかのどういう位置付けか理解して読んだほうが実につきやすい。
- 読んでる途中でも、違うなと思ったら読むのやめる。良書でもまだ下地がない場合は改めて読む。我慢しても最後まで読んだほうがよい場合もあるから判断難しい。
読みながら
- 大事なとこは線ひく、紙に書き出す、人に説明できるレベルに要約するなどただ目で文字を追って終わりにせず、アウトプットを意識する。
- 実体験などに紐付けて考える。
読むために
- 効率も大事だけど、ちゃんと時間をかけないと結局時間の無駄になること多い。いかに読書の時間を捻出するか時間の使い方考える。早く読むのも人や本の内容によっては時間の無駄。
読んだ後に
- 時間をおいて読み返す。大事なとこだけとかでも一度読んで終わりより全然まし。すぐ(数日後)もう一度、時間を置いて(数ヶ月後)もう一度。
- 興味が湧いたら同じジャンルのものも読む。
- アウトプットする。人に話す。ブログに書く。文字から絵や図にしてみる。
ぼんやりして中身がないまとめになってしまったけど、見返し用に。
