色々
今日学んだことをまとめていきたいと思います。
まず一つ目。ペネトレーションテストです。
こちらは昨今話題となっているサイバー攻撃に対するものになります。
システムは構築して終わりではなく、そのシステムの安全性を高めなければなりません。
その中で使うツールの一つがペネトレーションテストです。ツールというより、人がやる部分が多いみたいですが。
ペネトレーションテストは日本語に訳すと侵入テストとなるそうです。
どういうものかというと、システム全体の観点でサイバー攻撃に耐性がどれくらいあるかを試すために、悪意のある攻撃者が実行するような方法に基づいて、実践的にホワイトハットハッカー（公認の仕事をするハッカー達）がシステムに模擬的にハッキングするというものみたいです。
ペネトレーションテストの流れ
まず顧客にヒアリングをします。
テスト対象となるシステムのネットワーク構成を知り、個人情報や機密情報の保管状態、アクセスログの取得状況を考慮して、どのようなテストを行うかシナリオを作成します。
そしてそのシナリオに従って侵入テストを行い、結果を記録します。
自動、手動様々ですが手動の部分が半分はあるみたいです。
で、テスト結果を基に報告書を作成します。
テストの方法
内部の構造を把握して、顧客のシステムに合わせた内容で行う
内部構造を考慮せず外部から把握できる機能を検証します
攻撃者がシステムの外部から攻撃することを想定したテスト
内部に攻撃者が侵入していることを想定したテスト
コスト
システムの規模やシナリオによってだが数十万から数千万かかる
メリット
安全な環境で調査することができる
システムに応じたテストを行うことができる
報告書を得ることができ具体的な対策が可能
デメリット
規模によって膨大なコストがかかる
行う人間のスキルやツールの操作の習熟度によって成果が異なる
何故必要か？？
脆弱性を明らかにし具体的対策を取らなければ行けないから
脆弱性診断との違い
自動化ツールと手動プロセスの組み合わせである脆弱性診断に比べ主導中心
脆弱性診断はホストあたりで数分程度で終わることが多い
ペネトレーションテストはテスト範囲や台数によって数日から数週間かかる
脆弱性診断は悪用された場合の脆弱性の特定、ランク付け、報告まで
ペネトレーションテストはセキュリティ機能がどのように回避され無効化できてしまうか具体的に知ることができる
以上です
株式の注文方法
最近株の勉強を始めました。
今回は注文方法について書いていきたいと思います。
基本となる三つの注文方法について書いていきます。
成行注文（なりゆきと読むみたいです）
売買を行うときに値段を指定せず注文する
成立した相手によって値段が決まる
成行売り注文をしていた場合
一番高く買い注文していた人と成立
成行買い注文していた場合
一番安く売り注文していた人と成立
実際の発注は、「A株を成行で１０００株買い注文する」みたいな感じ
売り手が５００、４５０、４００円の人がいたら４００円の人と成立する
昨日の株価が３５０円だったから成行買い注文したら３５０円くらいで買えるかなーと思って実際の最安値が４００円だったらまずい、っていうのがデメリット
指値より早く決まって約定率が高いのがメリット
板情報や気配をよく見ることが大事っぽい
指値注文
希望する売買価格を自分で指定する方法
「A株を５００円で１０００株買いたい」という感じ
株価が５００円以下になれば成立
自分の決めた価格で売買できるのでリスク回避ができる
約定前なら注文のキャンセルも可能
デメリットとしてはその価格にならないと注文できないのでチャンスを逃す
逆指値については次回以降で。
以上です
ビジネスマナー
先日会社にお客様が来ました。
マナーは守れている方だと思っていたので特に何も考えず上司についていればいいと思っていました。
しかしいざお客様が来ると、名刺を渡す順番、ご案内の仕方、お見送りの仕方、お茶の出し方、席次がハッキリわからずドギマギしてしまいました。
忘れていたこともありましたし、何より準備不足でした。しっかり上司に注意されました。
そして上司は私にマナー本を渡してくれました。なんとも情けないことですね。
なので今回はこちらにビジネスマナーについて書いていきたいと思います。
訪問していただいたら、まずお相手の会社名と名前を確認し、お待ちしておりましたとご案内する。
すこし斜め前を歩き、何階の何室にご案内いたしますと言いながら、ここを曲がりますとか案内していきます。
つきまして、ドアが閉まっていれば一応ノックをし、外開きであれば開けて先に入ってもらう。内開きであればお先に失礼しますといい開けて入ってもらう、という形です。
奥の上座から偉い人に入ってもらい、だいたいここで名刺交換です。
名刺交換は、訪問してくれた人の偉い人からそれぞれ渡していくのが基本。
もらった名刺は胸より下げず、席に着いたら一人であれば名刺入れの上、複数であれば並べておく。（席順に）
お茶出しは相手の奥から席に置いていく。
私何故か手渡ししました（ペットボトルだし）
で、終了後は同じくらいのタイミングでドアの方へ行き、開けて案内。その後は銭湯を歩く。
エレベーターのご案内をしたことがなく、先に行ってボタンを押し、入ってもらい、全員入るまでボタンを押しておき、こちらで失礼いたします、といって終わり。
社外の人がエレベーターに乗ろうとしていたら、私が仮に全然関係ない人だとしたら一緒に乗らない。これも教わりました。
マナーは色んな場面で色々あって大変ですが経験して学んでいこうと思います。
以上です。
要件定義書 続き2
今日はいきなり本題から行きます。
要件定義書とは、顧客が開発側に実装する機能を整理したものを記載する書類です。
要件定義書をもとに開発者は説明していくわけですね。何度も言ってる気がしますが。
で、要件定義書は顧客の要望を満たす為に顧客からしっかりヒアリングして、細かく内容を打ち合わせて、わかんないところはRFPから情報を得て作り上げるわけです。
では要件定義書に最低限必要な情報を載せて行きたいと思います。
まず一つ目はシステムの概要です。
どの機能を備えたシステムなのか。
業務要件として、使用者が何をするためのシステムなのか。
システム要件としてどう言った内容のシステムなのかを明記します。
次にシステムを導入する目的です。
この機能を導入することでどういった課題を解消できるかです。
次はシステム導入後に業務フローがどうなるか。自動になるのかとかです。
次は機能要件。
これは大事っぽいです。今日は簡単に書きますが、システム導入によって何ができるようになるか具体的に書くもの。予算内で、システムがどういうことをできるようにするか。データの種類や構造はどんなものか。
次が非機能要件。
これはシステムの機能面以外の要件。システムの性能や効率性、セキュリティや保守・運用サービスなどについて記述するもの。
実際にどんなものが書いてあるのか見て、またこのブログに書いて行きたいと思います。
以上です。
要件定義書 続き
1日家から出ない日が自分の中で結構あるのですが、自分が人生最後の日を迎えたとき、こんな日を多く過ごしたことを後悔するのでしょうか。もっと多くの場所へ行き、多くの人と出会うべきだったと思うのでしょうか。無理してそういう生き方をする方が後悔する気がしますが。
ということで。
まとめ切れていない要件定義書及びRFPについてまた書いていきたいと思います。しつこくいきます。
まずRFPです。
RFPは、具体的なシステム提案を行うよう要求する書類になりますね。
で、今回は中身について書いていきたいと思います。
まず一つ目。そのプロジェクトに至った背景です。なぜこのプロジェクトを行うことになったかですね。
このシステムは現在こういう状況で、この辺に支障が出ていて、こういう風に伸ばしていきたくて、これを解決するためにはこういうシステムを導入した方がいいと思っています、というのを明示する、といった感じです。かみ砕くと素直に理解することができますね。
で二つ目が、現在抱えている主な課題です。この業務ではこんなことがあって負担がかかっている、遅いし使いづらいしこれからこういうことがしたいのに全然いうこと聞きません、みたいなことを書く。
三つ目は目的です。
このシステムとこのシステムを連動して、こんな風に稼働させるようにする。個々のシステムは入れ替えなきゃいけませんね、みたいな。
次はプロジェクトのゴールですね。
何秒以内で処理が終わり、使用者が稼働と同時にスムーズに使えるようにという品質の部分。
見積金額以内でプロジェクトを終わりにしてね、という費用の部分。
いつまでに設計し、リリースしてかどうさせるかという納期の部分。
次にプロジェクトの範囲です。（スコープっていうみたいです）
システム開発のどの部分か、（プロジェクトの）
サーバの購入もお願いするのか
運用ルールはだれが決めるのか
人材教育はだれがするのか
この辺を明示すると。
次にプロジェクトの方針です。ここ大事っぽい感じがしますね。
オンプレなのかSaaSなのか。
コストによって判断しますよーみたいに書いてもいいみたいです。
ハードウェア構成はどうしましょうとか。
アドオン（機能拡張用のソフトウェアを合体させ本体のソフトウェアのできることを増やす）やカスタマイズ（ソフトウェアのデフォルトの機能に変更や追加を加えて使いやすくする）はどうしようかとか
インターフェース連携はどうするかとか
メリットデメリット色々考えて判断します、って感じで書くと。
後は会社情報。
うちは現在こんな人数でシステム利用者はこれくらいで年商こんなもんでどこにあります、みたいな。あとこんなもの売っててこういう仕事してます、っていう
で、システムはこういう構成で、なまえはどこどこのこのシステムっす、って感じ。
あとＰＣやサーバはこんなん使っててこういう状況です、っていう感じですね。台数やスペックが重要みたいです。ちゃんと伝えないと後で入れ替えたりするのが面倒
RFPも要件定義書もそうですが、システムなのかWebサイトなのかとかでだいぶ変わってくるみたいなので、まだ触れてない現段階ではこんなかんじでいいかなと。
次回は要件定義書についてこんな感じで書いていきます。
以上です。
怒られた時は
2日目になります
怒られた時って、怒られたことに腹が立ったりモヤモヤするっていうよりかは、その人が怒ってしまうようなことを自分がしたっていう評価になっていることが気に入らないのだということに気づきました。
やはり人間周りの目や評価を自然と気にするものです。気にして当然だとも思っています。自分で自分は見れませんからね。少しでも良く見られたいという思いは、持っておくべきだと感じる時もありますし、こだわりすぎてもよくないな、と感じています。
私が常に思うのは人の気持ちにも自分の気持ちにも常に気を配っていたいということですね。逆に人の気持ちを察知してあえて触れないようにしたり。そこら辺は丁寧に生きていたいな、と思っています。
冒頭は今頭に思っていることをそのまま文にしているのでわけがわからない事になっていると思います。ちなみにこっぴどく怒られたとかではありません。
では、本題へ。
今日は前回の記事に書いた要件定義の詳細です。
学んだ結果、私は要件定義というのは、発注側に対して開発側が、「こんな課題をあなたたちは持ってて、今後はこうなっていきたくて、これくらいまでに作りたくて、こんな費用でこんなシステム、Webサイトを作りたいんですよね？」っていうものを提示するということだという風に認識しました。
そして用件定義書という書類を発注側に見せ、お互いの認識を合わせた上で発注をお願いするといった流れのようです。
色々なサイトを見た中で共通していたのは、まずこの要件定義の前に開発側に対して発注側がRFPなるものを提示するのだそうです。
提案依頼書です。
発注側から開発側に対して、「こんな課題があって、こんなシステム作りたいんです。何か良い条件で提示してくれませんか？」っていう依頼の書類です。
それを見て開発側が要件定義書を書くみたいですね。
なのでそもそもRFPにどんなものが書いてあるのかを理解しなければいけないと感じましたので、次回あたりでRFPの内容について書いて行きたいと思います。
こんなシステム開発の基本がわかっていないような人間がシステム周りの提案の資料を作っています。情けないですね。
少しずつですが頑張って知識をつけていかなければ、、毎日戦いです。
IT関連はとにかく横文字が多いのでその辺も少しずつ載せて解説したいなと思っています。一個一個丁寧にやるとものすごく時間がかかりそうですが。
あ、学んだことも書きますがただ書きたいことを書くだけのこともあると思います。自由に生きます。
以上です。
アウトプットの為に
先日インプット大全という本を途中まで読んだところ、インプット大全を読んだのにアウトプットが重要ということの方が強く印象に残りました。
インプットは質が重要。そのためにはアウトプットを意識したインプットが必要ということで、これから読んだ本や得た情報をこのブログに書いていく前提でインプットしていけば質良くインプットできるのではないかと。
インプットする為には目標を定めたり二週間に3回以上アウトプットしたりと色々あるみたいですが、発信することを意識してインプットすることが一番自分に合っているような気がしたので。
私がこのブログで発信するトピックは様々だと思いますが、中心は仕事となっていることになるでしょう。ITに関する記事が多いと思います。
自分にプレッシャーをかけるのもありますが、毎日投稿できるといいと思っています。
また、個人情報になりかねないものはもちろん載せません。
それでは早速今日学んだことを。（今日学んだことに関してはアウトプット前提で得たものではありませんが）
皆さんは要件定義というものを知っていますか。私はこの業界に来るまで全く言葉すら知りませんでした。
要件定義とは、システム開発などのプロジェクトを始める前の段階で、必要な機能や要求をわかりやすくまとめていく作業のことです。 企画の進行とともに要件定義に立ち返ることも多く、目的の脱線を防止する役割も果たします。
とのことです。用はこんなものにしようね、こんなものにするにはこんな機能が必要だよね、こんなスケジュールでこんなメンバーでやった方がいいよね、っていう確認みたいな感じだと今は認識しています。
で、私が何を学ばなければいけないかというと、この中身です。出てくる用語やシステムの内容について詳しく説明する必要があるんですね。
という感じなので明日からはアウトプット前提で色んな情報を取り入れて行きたいと思います。（アウトプット前提とさっきから言ってますが、要は人に教えたり書いたりする前提で聞いたり読んだり見たりしますよ、ってことです）
以上です。
