sho992 note

システム屋になって自分が一番成長したと思える点は「日本語が使える」ようになったこと。

学生時代、国語が大嫌いだった。
文法などは特にダメダメ。

システム屋になり人にシステムの説明を文章で伝えようとしていった結果、文書校正、主語、述語の使い方など、日本語らしい文章が書けるようになってきたと思う。

今更ながら日本語を正しく読み書きできることは大事だと思う。

【独り言】
「お会計1000円になります。」はやっぱりおかしい。
（「お前、今から「お会計1000円」になるんだな！」と突っ込みたくなる。）

2007.07.10：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その９：紙に書く。

人に説明するときに簡単でもいいから紙に纏めてから説明する。

紙に纏めると、自分の中でも整理できるし、纏めたものを資料として説明すると相手にも思いが伝わりやすい。
それに、そのときに思っていたことが後に残る。
後から、「あの時どう思っていたんだっけ？」ということがなくなる。

とにかくめんどくさがらずに紙に纏めることを心掛けよう。
その後が楽です。

【独り言】
ちょっとした紙が歴史的価値になるかも知れません。

2007.04.21：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その９：「RASIS（レイシス）」※新車の名前ではありません。

「RASIS（レイシス）」新車の名前ではありません。

「RASIS（レイシス）」まったく日常生活に関係ない言葉。
システム屋でもなかなか使わない。
ただ、システム屋として初心を忘れないためにも覚えておきたい言葉である。

【RASIS】とは
RASISは、コンピューターシステムが安定性や信頼性を得るための要素となる「信頼性」「可用性」「保守性」「保全性」「安全性」の5項目を、それぞれの頭文字をとって表現したもの。

・Reliablity（信頼性）―故障しにくいことである。
・Availavility（可用性）―稼働率が高いこと。
・Serviceability（保守性）―障害が起きた場合に復旧しやすいこと。
・Integrity（保全性）―データが矛盾を起こさず一貫性を保つこと。
・Security（安全性）―機密性が高く、不正なアクセスがなされにくいこと。

【独り言】
初心は大事です。

2007.04.04：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その８：フォルダをあさる。

現場に入ったらまずやること。

①設計書が入っていそうなフォルダを探す。
②見つかったらそのフォルダの中をあさりまくる。
　そうすれば必ずシステムを知る資料が存在する。
③そしてそれを読む。

【独り言】
探究心を成長させる。

2007.04.03：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その７：人に聞く前に。

人に聞く前に自分で調べられる範囲は全部調べたか改めて考える。

分からないことを質問するのは当然です。
ただ、質問する前に分からない事柄を自分なりに調べましょう。
調べると結構自分の中で解決することがあります。

以前された質問。
「このプログラムどうやって作るんですか？」
・・・あなたは何屋さん？

【独り言】
生まれ変わったら調査会社に就職だ！

2007.03.28：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その６：仕事をする基準

仕事をする基準は「簡単」か「めんどくさい」が基準ではなく「やる必要がある」か「やらなくてもいいか」のどちらかです。

【独り言】
めんどくさくても必ず何時かは終わります。

2007.03.25：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その５：設計書に思いを込める。

たいがいどこの現場に行っても設計書のフォーマットは決まっていて、そのフォーマットに沿って設計書を書くことが大半である。
じゃ～、フォーマットに合わないが、どうしても書かなければならない内容があったらどうするか？

①フォーマットに書く場所がないので書かない。
②「補足」とかを付け足してそこに書く。

当然②が正解。
でも実際に仕事をしていると①の人が結構いる。

とにかく思ったことはとりあえず書く。そうすれば誰かに思いは届きます。

【独り言】
書けー！書くんだ！。ジョー！！。

2007.03.22：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その４：「プログラマ」と「システムエンジニア」の違い

プログラマ=詳細設計を元に開発をする人。
システムエンジニア=要件定義以降のすべての工程をシステム観点から理解してこなせる人。

最高のプログラマになるには、日々生まれてくる技術を自分で吸収していくこと。

最高のシステムエンジニアになるには、不便な点を見つけて、どうやったら楽になるか考えられるようになること。

自分がプログラム得意ではないので、もう少しプログラミング能力を磨きたい。

【独り言】
ドラえも～ん、プログラミング能力があがる道具を出して～。

2007.03.19：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その３：「思い」を引き出すには。

要件定義時にユーザから要件を引き出したかに思えても、後から「こんなことはできるか？」とか「こうしてほしい。」とか今更そんなこと言う？的な要件が後から出てくることある。

正直これはしょうがない。

じゃ～、それをなるべく減らすにはどうしたらいいか自分なりに考えてみた。

一番は「やっぱり相手の立場に立ってよく考える。」しかない気がする。
それと「ユーザと仲良くなること。」
なんでかというと、世間話から軽い気持ちで「こんなことできんかね～」という話が結構出てくる。
やっぱり信頼関係だとつくずく思う。

【独り言】
思いを打ち明けられる関係は重要。

2007.03.16：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その２：「システム化する=すべてが楽になる」ではない。

最近はあまりないが、システム化すると「何でも自動になって仕事が楽になる。」と思っているユーザが多い。
システム化すると確かに今まで「手」で行っていた作業が自動化され、楽になる部分が多々ある。

しかし、今まで行わなくて良かった作業も発生する。

いい例が「入力画面」。

今まで紙やEXCELなどに打ち込んでいたデータを、システム構築後は入力画面を使ってデータを打ち込まなければならなくなる。
「データを入力する。」ということだけ考えれば果してどちらが楽か・・。

システム化する際、楽になる部分と大変になる部分が必ず出てくる。
なのでシステム化する際、システム屋は必ず「楽になる」ところと「めんどくさくなるところ」きちんと整理してユーザに伝えることが必要だ。

また、ユーザも「めんどくさくなるところ」をきちんと理解して、システム構築後の自分の作業を意識してほしいと思う。

【一言】
アナログがいいこともある。

2007.03.15：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言～その１：システム開発の概要

システム開発の概要を纏めてみた。

システム開発の概要

１．要件定義
　①要件定義書を作成する。
　　ユーザの「こんなシステムがほしい」という要望を元に、
　　・必要機能
　　・作業工数
　　・システムで使うハードウェア
　　・システムで使うソフトウェア
　　・作業工数
　　・作業にかかる見積もり
　　を纏め、要件定義書を作成する。
　
　　ここで、いい人ぶって安く見積もったり、できない機能を盛り込んだりすると後で失敗する大きな要因となる。
　　できることをちゃんと纏めることが大事！！

　②必要あらば現状分析を行う。
　　要件定義を行う上で、システム屋の方がユーザ業務の現状分析を行い、システム化できそうな箇所を提案することもある。

２．基本設計・レビュー
　①機能毎の入出力部分を纏める。
　　要件定義で定められた必要機能について
　　・データ入力部（画面、紙、DB、他機能からの受け渡し等）
　　・加工部（入力データの加工）
　　・データ出力部（画面、紙、DB、他機能への受け渡し等）
　　・制限事項
　　・機能毎の作業工数
　　を纏る。
　　
　②作成する処理（プログラム）を洗い出す。
　　①で纏めた内容を元に必要な処理（ユーザ画面、紙、加工ロジック等）を洗い出す。
　　
　③基本設計書を作成する。
　　①、②の内容を纏め基本設計書を作成する。
　　
　④基本設計書をレビューする。
　　第3者と以下の観点でレビューする。
　　・要件定義で定められた内容を満たしているか。
　　・機能内の処理が正しいか
　　・機能間、システム間の連携が正しいか。

　⑤問題点を浮き彫りにする。
　　基本設計書の作成・レビューを行うことで要件定義で見えなかった問題点を浮き彫りにする。
　　→ここで気が付いた問題等は「問題点管理表」を作成し、後の工程で埋もれないよう工夫する。
　
３．詳細設計・レビュー
　①処理（プログラム）毎に以下の内容を決定する。
　　・項目レベルでの入力→加工→出力を明確にする。
　　・データや処理タイミングでの処理条件を明確にする。
　　・正常、エラーの処理を明確にする。

　②詳細設計書を作成する。
　　①の内容を纏め詳細設計書を作成する。

　③詳細設計書をレビューする。
　　第3者と以下の観点でレビューする。
　　・要件定義で定められた内容を満たしているか。
　　・処理が正しいか。

　④問題点を浮き彫りにする。
　　詳細設計書の作成・レビューを行うことで基本設計で見えなかった問題点を浮き彫りにする。
　　→ここで気が付いた問題等は「問題点管理表」を作成し、後の工程で埋もれないよう工夫する。
　　
　この時点である程度、要件定義で見えなかった問題点が見えてくる。
　問題点は大きく分けて２つになる。
　　・ユーザへの確認が必要なもの。
　　・システム開発内で調整すれば解決するもの。
　解決できるものから解決していくよう勤める。

４．プログラム開発
　詳細設計書を元にプログラムを作成する。
　

５．単体テスト
　①単体テスト試験項目表作成
　　詳細設計書に書かれている内容を元に「単体テスト試験項目表」を作成する。
　　作成観点は、
　　・項目レベルでの出力内容があっているか。
　　・データや処理タイミングでの処理内容があっているか。
　　・正常、エラーの処理が正しく行われているか。

　　詳細設計書がうまくかけていれば、詳細設計書に確認番号を振る程度で終わる。

　②単体テスト実施
　　①で作成した「単体テスト試験項目表」を元に単体テストを行う。

６．結合テスト
　①結合テスト試験項目表作成
　　基本設計書に書かれている内容を元に「結合テスト試験項目表」を作成する。
　　作成観点は、
　　・機能間の連携が正しく行われるか。
　　・正常、エラーの処理が正しく行われているか。

　②結合テスト実施
　　①で作成した「結合テスト試験項目表」を元に結合テストを行う。

７．運用設計
　①誰が、何時、どこで、何をするかフローに纏める。
　 →システム想定外（停電、天災等）の動きも考慮する。
　②データのバックアップタイミングや戻しの方法も検討する。

８．運用テスト
　①運用設計書を元に実際にシステムを使ってみる。
　②システムダウンした場合に、正しく復旧できることなども確認する。

９．リリース
　めでたくシステムリリース

2007.03.14：sho992：コメント(0)：[メモ/システム屋の独り言]

システム屋の独り言

今までの自分のしてきたシステム屋の仕事を振り返り、良かったこと、悪かったこと纏めていければと思っています。
まぁ～悪かったことを反省し、次につなげていこうという目論見です。

2007.03.14：sho992：コメント(0)：[メモ/システム屋の独り言]