2012年03月10日
無理をしない
身の丈に合わない高い目標設定により、逆に本来持っている力さえも発揮できないということは、よく耳にします。企業のTOPがかわり、「身の丈に合った仕事をしよう」という方針を出しただけで、業績がよくなったという事例を聞いたことがあります。
サラリーマンは仕事、家族があり、勉強だけに専念することは不可能です。無理をすると他にも悪影響が出ます。
2012年03月04日
論理的な文章
国語が弱かった私が書いておりますので、専門的には多少違う部分もあるかと思います。そういう上で読んでください。
■文１
A社のシステムは性能がよくお客様から好評であり、業績がとてもいい。
何気ない一文であろう。これを、接続詞を入れてみるとどうなるか。
■文２
A社のシステムは性能がよい。だからお客様から好評である。その結果、業績がとてもいい。
接続詞を入れずに文章を考えると、論理性があいまいのままでの気にならない。最初の文章は接続詞無しで文章をつなげているため、細かな論理性に関する部分はぼやかして逃げているとも考えられる。
※接続詞を丁寧に入れる文章がきれいで読みやすい文章ではない。あくまでも論理性を考えるために入れているのでご理解いただきたい。
文２に関して、論理性はいかがであろうか。「お客様から好評」と、「その結果、業績がとてもいい」というのは、論理的な文章だろうか。好評だから業績がいいと思う人もいるだろうが、安価に提供していると利益はでない可能性がある。
■文３
A社のシステムは性能がよい。だからお客様から好評である。そのおかげで高価格でも受注ができる。その結果、業績がとてもいい。
接続詞というかつなぎの文章が多いから読みにくさはあるが、「高価格でも受注ができる」という補足説明を入れると、論理的につながる。
多くの方の論文を読んでいて、このような論理が不足している気がする。接続詞を意識して入れて考えてもらい（くどいが、実際の文章に入れるかは時と場合による）、論理性を高めていただきたい。
2012年02月25日
一問一答
Q1.テストデータの作成方法のうち、「プログラムの流れ図から、分岐条件に基づいたテストデータを作成する（H21NW午前�玉�24不正解選択肢）」のは何テストか。
A1.ホワイトボックステスト
Q2.テストデータの作成方法のうち、「「機能仕様から同値クラスや限界値を識別し、テストデータを作成する（H21NW午前�玉�24不正解選択肢）」のは何テストか。
A2.ブラックボックステスト
Q3.「取得者（発注者）と供給者（受注者）の二者間取引を明確化するためのものであり，業務分析，業務設計，ソフトウェアを中心としたシステムの企画，要件定義，開発，運用，保守及びそれらにかかわる諸活動を対象としており，国際規格に適合しているもの（H21NW午前1問17）」
A3.共通フレーム（またはSCLP）
Q4.「品質マネジメントシステムに関する国際規格」は？（H20NW午前問18より）
A4. ISO9000シリーズ
Q5.「システムの調達に際して，調達側から技術的要件やサービスレベル要件を提示し，ベンダに対して，指定した期限内で効果的な実現策の提案を依頼する文書（H21NW午前1問25不正解選択肢より）」
A.RFP
Q6.「ユーザ要件を実現するために，現在の状況において利用可能な技術・製品，ベンダにおける導入実績など実現手段に関する情報提供をベンダに依頼する文書（H21NW午前1問25より）」
A.RFI
Q7.「プログラム実行中の特定の時点で成立する変数間の関係や条件を記述した論理式を埋め込んで，そのプログラムの正当性を検証する手法（H22NW午前1問15より）」は何か？
アサーションチェック
Q8.「ソフトウェアの違法複製を防止するため，法人，団体などを対象として，ソフトウェアを使用するに当たって実行されるべき事項をとりまとめたもの」は何か（H22NW午前1問22不正解選択肢より）
ソフトウェア管理ガイドライン
Q9.
2012年01月12日
合格復元論文（H23問2）
ありがとうございます。
◆こどらんさんの感想
本試験で極度に緊張してしまい、
設問イの文字数もぎりぎり、しかも
やや矛盾を含む内容となってしまっています。
たとえば、
「過去の類似のシステム構築案件から、わかっていた」と
経験豊富なことを匂わせておきながら、
「私はツールを使用するのが、初めてであったが・・・」
などと、書いたり…。
でも、実際には、これでA判定でしたので、
この程度？の矛盾なら、合否に影響しない証しとも言えます。
◆復元論文（H23問2）
１． 対象業務とシステム及び、期間・費用の制約について
１−１．対象業務と対象システムの概要
Ａ社は健康食品の製造メーカである。一般消費者から電話・ＦＡＸで注文を受付け、健康食品を販売している。注文を受付けると、Ａ社のオペレータは注文受付システムに注文内容を入力する。A社の売上が下降気味であった為、早期の売上回復、顧客サービス向上を目的に、今回、注文受付システムをＷｅｂ化し、インターネットから直接注文できるよう、注文受付システムの再構築を行うこととなった。（以下Ｗｅｂ注文受付システムという）Ｗｅｂ注文受付システムは、ログイン（利用者認証）、商品検索、注文受付、出荷、請求の各機能を有する
システム形態は、A社のWebサーバ、データベースサーバ、アプリケーションサーバが連携して稼働する、３層クライアント・サーバシステムである。
私はこのシステムの構築を受託したソフトウェアベンダの社員であり、システムアーキテクトとして要件定義・システム設計・開発・テストまでの一連のプロセスに携わった。
１−２．期間や費用などの制約について
今回の開発は、システムテストの工程に入るまでの進捗が遅れ気味になっており、進捗を取り戻す為に、同等規模の開発案件のシステムテストの７０％程度の期間で、システムテストを実施しなければならなかった。テスト環境においても、ハードウェアスペック、端末台数は本番環境と大きく異なっているが、テスト環境を本番環境と同じ構成として構築する費用もなかった。
このように、期間と費用に制約がある中で、システムアーキテクトである私は、次に述べるようにして、効率よくシステムの品質を確保するシステムテスト計画を策定した。
２． テストの重点確認項目について
２−１．システムテスト計画策定の際の重点確認項目の設定
Ｗｅｂ注文受付システムは、インターネットを介したシステムである。インターネット上の利用者は、レスポンスの悪いWebサイトへは次第にアクセスしなくなってしまう傾向がある。そうなると、Ｗｅｂ注文受付システム構築の目的である、A社の売上回復に寄与しなくなる。
また、注文の最終確認である[申込ボタン]を押下後、中々画面が切り替わらないと、利用者は“遅い”と考え、[申込ボタン]を何回も押し、多重の申込みトラブルを引き起こす可能性があることを、私は、過去の類似のシステム構築の経験からわかっていた。こうした業務上のトラブルを未然に防ぐために、テストの重点確認項目として、即時性を考慮することが重要であると私は考えた。
次に、どの程度の即時性を確保すればよいかが問題である。Ｗｅｂ注文受付システムは、インターネットを介したシステムである為、インターネット上や利用者側の遅延も全体的なレスポンスに影響する。そこで、私はA社担当者と協力して、同業他社が運営する健康食品のWebサイトの商品検索画面にアクセスし、必要となるレスポンスタイムを見極めることとした。その結果、Ｗｅｂ注文受付システム単独のレスポンスタイムが３秒以内であれば、インターネット上や利用者側の遅延を加味しても、十分な即時性が得られると判断した。
以上の考察をもとに、Ｗｅｂ注文受付システムの重要度、業務特性を考慮して、システムテスト計画を策定する際、私が設定したテストの重点確認項目は次のとおりである。
「平常時、高負荷時において、Ｗｅｂ注文受付システム単独のレスポンスタイムが３秒以内となる即時性を確保すること。」
３．重要と考え、工夫した点
３−１．制約のある中で効率よく品質を確保する為に、重要と考え、工夫した点
システムテスト計画の策定において、期間・費用の制約がある中で、効率よく品質を確保する為に、私が重要と考え、工夫した点は、「本番環境とは環境が異なるテスト環境においても、できるだけ正確・適切なテスト方法を策定する」ことであった。まず、私は、本番環境とテスト環境の差異を分析し、テスト環境のハードウェア性能は本番環境の５０％程度であると判断した。次に、過去の電話・ＦＡＸでの注文実績、過去の類似の開発案件での運用実績を元に、本番環境の高負荷時の状況を、注文入力は１０００件／時間、商品検索は、３０００件／時間と見積もった。ここで見積もった負荷を効率よくテスト環境にて実現する為、私は端末シミュレータのツール導入を検討した。
私はこのツールを利用するのがはじめてであったが、開発メンバ２０人のうち、５人が利用経験をもっていた。私はプロジェクトマネージャの許可を得て、ツールの利用経験者を中心に評価会議を実施した。結果、「使える」という判断がでて、私はツールの導入に踏み切った。決め手は、業務の種類に合わせて、発生するトランザクション数を設定できるなど、機能面が豊富なことだった。
ハードウェアスペックの違いを考慮し、見積もった負荷を端末シミュレータで発生させて、システムテストを行うことした。さらに正確性を期すため、本番環境とテスト環境で、稼働するプロセスを一致させることとした。また、今後の注文増加も考慮し、１５％程度の安全係数を乗じるなどの工夫も取り入れた。
期間・費用に制約がある中で、以上のようにして、システムアーキテクトである私は、効率よくシステムの品質を確保する、システムテストの計画を策定した。
（以上）
2012年01月11日
論文はわかりやすくよみすさが大事
それらの合格論文に共通しているのが、分かりやすい身近なテーマで書いていることである。かなり詳しい人が、自分の専門分野をアにて詳細に解説している論文の合格率は厳しいと感じる。シンプルに分かりやすく書くことも求められているだろうし、採点者にとっても、それが正しいか間違っているのかの判断ができないことも要因ではないかと思う。
自信がないから難しく書いてごまかそうというのは、思わずやってしまう人もいるかもしれないが、最悪である。良く分からないから○にする採点者はおらず、×をつけるしかないとかんがえてもらったほうがよい。