ariyasacca

▼ [雑記][資格] 平成18年度秋期　情報処理技術者試験(AE)

今回も会場は、豪華な名城大学の新校舎ということで。しかも午前試験免除で重役出勤なり。

午後1試験の感想

出題内容は予想通り、業務分析やら何やら。合併に伴うシステム統合を問うものが、新しい分野なのかな？　初受験なんで、はっきりとは分からんけど。時間はマジで足りないよ。

午後2試験の感想

おい、オレの書けそうな論文のお題が1つも無いじゃないか！　といった感じ。とりあえず2時間で2,400字〜4,000字書くのは、腱鞘炎になり兼ねないなと。京極夏彦先生は偉大だなと。

試験終了ギリギリまで執筆していたけど、正直ここまでカロリーを消費するとは思わなかった。腹減った。

その他

試験が終わってから、同じ試験会場だったてーさくさんと合流して、世界の山ちゃんで反省会。

• 午後1ありえない。
• 午後2ありえない。
• プレモルの瓶は、飲んでいてとても幸せ。
• 幻の手羽先、旨過ぎるでかんわ。
• 同じヤマダ電機で証明写真撮るなよ。
• こんなしんどい試験を社員に受けさせておいて自分は何もしていない役員はｑあｗせｄｒｆｔｇｙふじこｌｐ

“分かっている人”と飲みに行って愚痴をこぼす、というのも、自分の、今の会社に対して満足している点、不満な点が見えて来て大事なことだなぁと。同期の人と飲んでいて、なかなかこういう発見は無いので。何か偉そうだな、こいつ。

しかし、非常に疲れた試験だったなぁ。今回は準備期間に残業も全然無かったし、落ちた時の言い訳の余地が無い。もしダメだったら、「甘く見ていて勉強が足りませんでした」ということ。

▼ [資格] 平成18年度秋期　情報処理技術者試験(AE) 午後1の解答

かなり間違いがありそうな解答だが、記しておく。こういうものは、臆せず書いてしまうことが大切だ。どうせ正解発表の頃には、頭から忘れられてしまうのだから。

選択問題の問3と問4は、残り時間が少なくて吟味する余裕も無かったため、問3を選択した。

午後1 問1

• 設問1
  • a カード番号
  • b 業務権限
• 設問2
  • (1) Webサーバ:5台 DBサーバ:1台
  • (2) Webサーバ:3年後 DBサーバ:5年後
• 設問3
  • (1)
    • 通信異常で売上を本部サーバに蓄積できないから。
    • 本部サーバの稼働時間外に、発注処理ができないから。
  • (2)
    • c 店舗
    • d 本部
  • (3) データファイルの二重送信を防止するため。
  • (4)e 本部サーバの売上、発注データに受信したデータを累積する。

午後1 問2

• 設問1
  • a 情報ヘッダに対応する試験結果情報を出力媒体作成ファイルに付加する。
• 設問2
  • b FD
  • c CD-R
  • d パスワード発行通知書
  • e 高校コード
  • f 暗号化したファイル
• 設問3
  • セキュリティ上のリスク ログイン後にそのままにしておくと、誰でもデータをダウンロードできてしまう。
  • 採用すべき対策 データダウンロードした後に、自動的にログアウトする処理を組み込む。
• 設問4
  • 内容 委託会社ごとに一つのユーザIDを使うと、開発メンバの特定ができない。
  • 対策 開発メンバごとにユーザIDを与え、アクセス履歴から特定可能にする。

午後1 問3

• 設問1
  • a EDIによる受注
  • b リードタイムの開示
  • c 顧客ごとに販売実績管理
  • d 原価計算
• 設問2
  • (1)
  • (2)
    • e 日次
    • f 日次
    • g 週次
    • h 日次
    • i 週次
• 設問3
  • 対象となる購買先 D社とE社で重複している購買先
  • 調整が必要な取引条件 単価、納期、支払方法
• 設問4
  • 変更が必要なシステム 購買システム

問3は、時間が足りなかったので、かなり自信が無い解答となっている。正直、設問1とか、問題の意図が分からなかった・・・。

▼ [資格] 平成18年度秋期　情報処理技術者試験(AE) 午後2の論文

• 問1 システム要件の確定について
• 問2 障害発生時の影響を最小限に抑えるためのシステム設計について
• 問3 移行計画におけるタイムチャートの事前確認について

どれを選んでも、ネタが無いという状況で泣きそうになった。無理矢理自分の業務の方向に引っ張ってきてしまえ！　と開き直って書くことにした。アドリブでくどくどと書いた論文を、記憶を頼りに再現してみた。多分、細かいところは違っているけど、大筋では試験で書いた内容となっている（こうやってデジタルデータとして記すと、それなりに立派に見えるかもしれないが、実際の論文はオレの字が汚すぎてかなりショボイ）。

１．１開発に携わったシステムの概要

論述の対象とするシステムは、携帯電話をクライアントとする勤怠管理システムである。システム構成は、Webサーバ、DBサーバ、各種携帯電話端末である。

線路の保守作業を業務とするA社は、ソフトウェア開発会社B社の勤怠管理システムパッケージを自社向けにカスタマイズして受け入れ、運営してきた。このシステムは社内イントラネット上での動作を前提としており、社内PCのブラウザをクライアントとして動作する。A社では、その業務の特性上、夜間に線路保守作業を行い、翌日は振替休暇になるという勤務パターンが多く、すぐに勤務実績の登録や時間外の申請ができないといった不満が多く挙がっていた。上記の理由により、A社からは、社員の持つ携帯電話を利用して勤務実績の登録や時間外の申請を行いたいとの要望が挙がっていた。

１．２システム要件の確定において発生した課題

私は、B社のリーダSEとして、勤怠管理システムの携帯電話からの登録が可能なシステムのシステム提案、システム設計、運用設計に参画した。A社総務部、B社プロジェクトマネージャ、私によるミーティグにおいて、次のような課題が発生してシステムの要件が確定しなかった。

• (1)B社では今回のシステム化の範囲を、社員の勤務実績の登録と時間外の申請と想定していたが、A社総務部で行っている勤務実績の集計や、時間外の申請の承認といった管理業務についても、ノートPCからWWWを経由して行いたいとのことであった。
• (2)A社の社員が使用している携帯電話の中には、購入時期がかなり古いものも多く含まれていたが、今回のシステム導入にあわせて新規に携帯電話を購入することは多大な負担となるため、古い機種でも動作が保証されるようにシステムを構築して欲しいとのことであった。

２．１システム化の範囲を確定するための提案

今回の案件は、社内勤怠管理システムの追加案件と位置付けられており、A社の要望を全て実現していたら、予算を超えてしまうことは明らかであった。私は、A社の携帯電話を新規に購入することは難しいといった主張から、予算の増額は難しいと考えた。よって、次のような提案を行った。

• システムへのアクセスを携帯電話に限定することで、セキュリティ上のリスクを軽減できる。なぜならば、システムを社外ネットワークに公開することで発生する、Webサーバソフトウェアのセキュリティホールの発見からパッチ配布までに攻撃されるゼロデイアタックや、大量のリクエストを送り付けるDDOS攻撃といったリスクは、携帯電話からのアクセスでないと判明した時点でパケットを破棄すれば、ほとんど防ぐことが可能となるからである。携帯電話からインターネットにアクセスする際に使用されるIPアドレス範囲は、国内主要キャリアのWebサイトで公開されており、アクセス制限は容易に設定できる。
• 上記の理由により、システムへのアクセスを携帯電話に限定する方が望ましい。そうになると、管理業務を携帯電話で実現することが難しくなる。なぜならば、勤務実績の登録や時間外の申請は、基本的に数字を入力するだけで処理が完了するが、勤務実績の集計や時間外の申請の承認は、画面に多くの情報を表示して管理者が確認したうえで、処理を完了する必要があるからである。近年の携帯電話のディスプレイは、サイズや解像度が向上したとはいえ、多くの情報を表示するにはまだまだ小さ過ぎると言える。

２．２古い機種でも動作が保証されるシステム設計

勤怠管理システムの処理フローとしては、社員に一意に割り当てられた社員IDと、社員自らが設定するパスワードを入力し、社員の正当性を確認したうえでログインを行う。一般的なWebアプリケーションにおいては、HTTPはステートレスなプロトコルであるため、この「ログインした状態」を維持するために、Cookieを利用したセッション管理を行っている。しかし、A社で利用している携帯電話には古い世代のものも多く、Cookieをサポートしていない機種もあった。このため、Cookieによるセッション管理では、動作を保証することができなかった。

私は、次のようなセッション管理を提案した。

• DBサーバの勤怠管理システムのRDBMSに、セッション管理情報を格納するテーブルを作成して、ログイン成功後に情報を登録して管理する。具体的には、社員ID、サーバ時刻、Webアプリケーションプログラム内で定義した秘密の定数の文字列を基にハッシュを求め、それをセッションキーとして利用する。画面ごとにPOSTリクエストでセッションキーを持ち回し、RDBMSに問い合わせることで、「ログインした状態」であるかどうかを判定する。ハッシュアルゴリズムには、衝突安全性と処理速度の観点から、MD5を採用する。
• 上記の方式により、古い機種でも動作が保証される点。しかし、画面ごとにRDBMSに問い合わせが発生するため、サーバの負荷が高くなる点を、A社総務部に説明した。

３．１提案した内容についての評価

私は上記の内容をプロジェクトマネージャの了承を得てA社総務部に提示し、双方が納得したうえでシステム要件を確定することができた。

A社総務部が納得したうえでシステム化範囲を縮小できたことから、提案は成功であったと考える。A社総務部からは、携帯電話を新規に購入せずに済んだ点が高く評価されており、現場からは、勤務実績の登録や時間外の申請が気軽に行えるようになったと好評である。

３．２今後改善したい点

A社社員からは、勤務実績の登録や時間外の申請を行う場合に、入力する項目は数字であることが明らかであるため、入力モードをデフォルトで数字モードにして欲しいとの要望があがっている。私は、このような携帯電話をクライアントとした場合に特有にユーザインタフェース上の問題点に配慮しながら、より使い易いシステムの改善を提案して行きたい。

以上（ここは、原稿用紙では右詰）