今日から新しい職場
転職して 3/1付けで新しい会社に入社することになったので、今日が初出勤日。SEやめて開発に戻ることにした。また開発することができてとても楽しみ。いわゆる上流工程もやってみたけど自分にはちょっと合わなかった。地道に手を動かしてモノ作っているほうが楽しいし、やっぱり技術に近いところにずっと居たいし。
こんどの職場は残業時間が少なめなのもうれしい。SEやってたときは悲惨な状態だったしなあ。
メールが遅い(2)
/カテゴリ: workその後、色々調べてみると送受信が遅いのではなく、受信だけが遅い模様。さらに pop3d再起動直後は問題ないけど、送受信ボタンを連打しているとそのうちロックがかかったみたいになって反応が返ってこなくなる。反応が返ってくるまでの時間はきっかり 1分。pop3dを再起動するとまた正常に戻る。なんかサーバ側の最大コネクション数を使い果たしてしまって解放されるのを待たされている雰囲気。
本当はこのへんまでの切り分けをユーザサイドでやってもらえるとありがたいのだけど。製品サポートに解析を依頼する際にも切り分けの精度でその後の調査スピードが全然違ってくるし。「メールの送受信が遅いです」だけではなんとも苦しい。
メールが遅い
/カテゴリ: workと言われたので現場を確認させてもらったら確かに遅い。Outlookの送受信ボタンを押してから受信が完了するまで 1分くらいかかる。試しにメールサーバに POP3コマンドを直接投げてみると USERコマンドは即反応が返ってくるのに PASSコマンドがなかなか返ってこない。QUITコマンドも同様。メールサーバから自分自身に投げた場合は PASSも QUITもすぐ応答が返ってくる。
なんだろう。ルータがなんかやっているのかな。時間がかかるけど結局繋がるってパターンは DNSの設定ミスが思い浮かぶけどこの件とは関係あるのかな。でも USERコマンドはうまくいっている訳だしな。DNSが原因だったら初めからだめそうだし。来週ちゃんと調べよう。
PMBOK研修
/カテゴリ: workPMBOKの研修に参加してきた。PMBOKをきちんと勉強する機会はこれが初めてだったんだけど，あまりに概念的すぎて(というかそもそも PMBOKとはそういうもの)正直これをどうやって実務に取り入れるのよ，というのが一番の感想。言ってることはもっともなんだけど，「それ全部やっていたらものすごいコストがかかるんですけど。お客さんがその分も負担してくれるなら別ですが」と言いたくなる。内容によっては勉強して PMPでも取得しようかと思ったけど，ここまで現実とかけ離れている内容だとその気も萎えた。いや現実が間違っていて，PMBOKの世界があるべき姿なのかもしれないけど。でもあまりに離れすぎているよ，やっぱり。以下受講メモ。自分なりの解釈も入っているので間違っているかもしれません。
- PMBOK。正式には PMBOKガイドという。A Guide to the Project Management Body of Knowledgeの頭文字をとったもの。
- 5つのプロセス群，9つの知識エリア，44個のプロセスから構成される。
- 5つのプロセス群とは次の通り。
- 立ち上げプロセス群
- 計画プロセス群
- 実行プロセス群
- 監視コントロール・プロセス群
- 終結プロセス群
- よくある PDCAとの対応は Pが計画，Dが実行，CAはまとめて監視コントロールに相当する。監視コントロールはサイクル内の 1プロセスというより，サイクル全体を監視，コントロールする位置づけになる。そういう意味では PDCAの CAよりは守備範囲が広いのかもしれない。
- 立ち上げと終結はそれぞれサイクルを開始，終了させるもの。
- プロセス群は複数のプロセスから構成される。このプロセスが全部で 44個。
- 全部は書かないけど，例えば「スコープ計画」「コスト見積もり」「アクティビティ所要期間見積もり」といった感じのプロセスが並ぶ。
- 各プロセスでは，そのプロセスで最終的に得られる成果物である「アウトプット」，アウトプットを得るために必要な材料となる「インプット」，その際に必要となる道具「ツールと技法」がそれぞれまとめられている。
- この 44のプロセスは「知識エリア」と呼ばれる 9つの領域に分類される。プロジェクトマネージメントで要求される作業をもう少し実作業よりの観点で分類したものだと思う。9つの知識エリアは以下の通り。
- 統合マネジメント
- スコープ・マネジメント
- タイム・マネジメント
- コスト・マネジメント
- 品質マネジメント
- 人的資源マネジメント
- コミュニケーション・マネジメント
- リスク・マネジメント
- 調達マネジメント
Microsoft .NET開発実践講座(第 1回)
/カテゴリ: work今回から実機を使ったハンズオン形式に。場所も笹塚になった。
今回のテーマは
- モデリング言語
- オブジェクト指向開発実習
勤怠管理システムを題材に，シナリオ，ユースケース図，クラス図，シーケンス図の作成を Visioを用いておこなった。以下雑感とメモ。
- シナリオ
- 業務を作文形式で書き連ねたもの。
- 形式は自由だが箇条書きはあまりお勧めしない。勝手に要件を丸められる傾向があるので(そうとも思えないが…。作文だと長くなるので要件がぼけてしまう気がする)。
- 次の 2種類に分けて書く。
- 基本シナリオ。正常系のみを自由にまとめたシナリオ。
- 2次シナリオ。異常系をまとめたシナリオ。基本シナリオの 1.5倍くらいのボリュームで。
- このフェーズでは完成度は 80%程度でよい。といっても最初から80%を目標にするとそれ以下になるので，100%を目指していくとちょうどいい具合に 80%になるとのこと。
- ユースケース図
- シナリオはユースケース単位にまとめる。
- 視点はアクター方向から。逆方向からは見ない。
- アクターからアクターへのデータの直接的なやりとりはない。必ず間に業務が入る。
- クラス図
- 正直，ここだけは経験とセンスの問題だと思う。この通りやれば必ずいいクラス図ができる，という手法はないし，講師からもそのような解説はなかった。
- 今回は開発の早い段階でクラス設計をおこなったが，どうしても実装を意識せざるを得なくなり業務分析がおろそかになる気がする。この段階では業務ごとにサブシステムに分割する，くらいのレベルで止めておいたほうがいいのではと感じた。
- テーブル設計の時にクラスを意識することになるので，テーブル設計をまじめにやれば大きな間違いにはならないと思うけど。
- シーケンス図
- これは難しくない。クラスが決まれば淡々と書ける。
ユースケース図，クラス図，シーケンス図だけあれば十分かな。他の UML図はわかりづらい。図で書いてわかりづらいというのは，そもそも図で書こうとすること自体が間違っているわけで。