事後報告?

ある先生に撮影してもらったビジネスマナー講座の画像のデータを
先ほど,いただいたので,アップしておきます。

ビジネスマナー講座の様子です

これは最終日の,ビジネス文書についての講義を行っているところです。
(本当はもっと実践してるっぽい感じの画像が良かったのですが…)

昨日,終わったばかりなはずなのに,
なんとなく懐かしい気が…(汗)

————— キリトリセン 8X —————

さてさて,サマーコースも落ち着いてきたので,
そろそろ本格的に,勉強にも身を入れていかないとなぁ…と思う今日この頃。

とりあえず,第 3 章の自分メモをば。

★ RAID について
 RAID とは,安価な磁気ディスク装置を複数組み合わせることで,
 全体として高い安全性を得る手法のことです。
 用途に応じて,RAID0 ~ RAID7 までの様々な段階があります。

 ・RAID0
  → 信頼性の向上ではなく,性能の向上を目的としたもので,データを
    複数のハードディスクに分散して配置する「ストライピング」により,
    高速な読み書きを実現します。
    ただし,1 台でもディスク装置が故障すると読み書きが不能になるため,
    全体としての信頼性は逆に低下します。

 ・RAID1
  → 2 台のハードディスクにまったく同じデータを書き込みます(ミラーリング)。
    片方の装置が壊れてもそのまま業務を継続することができますが,
    実質的な記憶容量はハードディスク全体の 2 分の 1 となります。

 ・RAID2
  → RAID0 にエラー修正データを付加して,ディスクが壊れた際のデータ復元が
    できるようにしたものです。
    エラー訂正データにハミング符号を利用するため,ディスクが 2 台同時に壊れても
    データを復元できるのが特徴です。
    ただし,コスト効率が悪いため,あまり利用されていません。

 ・RAID3
  → RAID2 のエラー訂正のしくみを簡略化させたものです。
    エラー訂正のデータに,パリティビットを利用するので,
    2 台同時に壊れるような事態には,対応できません。

 ・RAID4
  → RAID3 で行われるビット/バイト単位でのストライピングを,RAID4 では
    ブロック単位で行います。

 ・RAID5
  → 3 台以上のハードディスクを使用して,各ハードディスクにデータとパリティを
    分散配置する方法です。

 ・RAID6
  → RAID5 にパリティディスクを追加して,2 台以上のディスクが故障した場合でも,
    データの読み書きが行えるようにする方法のことです。

RAID は何回も覚え直している,苦手な部分の 1 つなのですが,
こうやって書き出しても,やっぱりなかなか覚えられません…(汗)

うーん。

記憶は苦手。

comments

ビジネスマナー講座・最終日

いよいよ,サマーコース第 2 クールの最終日。

今日は,ビジネス文書とEメールのマナー,席次と酒席・宴席でのマナー,
テーブルマナーを講義しました!

特に,後半のテーブルマナーは,スプーン(ナイフの代わり)とフォークを使って,
ステーキに見立てたカステラ?のおかしを実際に,食べてもらいました!

その後は,これまでの成果を見るために,
最終試験と初日に行ったマナーチェックを行い,授業終了という流れでした。

毎回やってもらっていた 90 秒スピーチ(実際には時間の関係で 60 秒)を,
今回は「この講義を受講した感想」というテーマでやってもらいました!

皆さん,思い思いに感想を話してくれたのですが,
その中でも一番印象的だったのは,人前で話すのが苦手な学生さんが,
一生懸命話そうと,頑張ってくれていたことです。

それが,この講義の成果かどうかは,定かではありませんが,
ちょっとでも,お役に立てていたのなら,幸いだなぁ…と思う次第です!

正直,初めての講義ということもあり,準備など,なかなか大変でしたが,
今となっては,この講義をできてよかったと,心底思っています!

受講してくれた学生の皆さんも,1 日 1 ~ 3 限で 5 日間という,
ハードなスケジュールの中,最後までついてきてくれてありがとうございます!

また,今回一緒に講義をやってくれた M 先生には,
結果として,いろいろと迷惑をかける形になってしまい,
申し訳ない気持ちでいっぱいです…(汗)

いろいろとありましたが,
皆さん,本当にお疲れ様でした!

comments

ビジネスマナー講座・4 日目

今日は,昨日の準備を元に,
学生の皆さんに,ディベートを行ってもらいました!

それぞれのチームによる,主な意見は,以下のとおり。

★ 愛とお金,大切なのはどっち?:「愛チーム」VS「お金チーム」

 ・「愛チーム」の意見
  → 生きていくのに,お金は必要だけれども,
    そもそも,この世に生まれて,今生きているのは,
    両親の愛があったからこそ。だから,愛のほうが大切。

 ・「お金チーム」の意見
  → 愛があっても,生活ができない。生きていくのには,お金が必要。
    生まれてから今まででも,莫大なお金がかかっている。
    だから,お金の方が大切。

★ レジ袋は有料と無料,どちらにすべき?;「有料チーム」VS「無料チーム」

 ・「有料チーム」の意見
  → 無料のままだと,レジ袋のゴミが増え,環境に影響が出る。
    有料にして,少しでもゴミを減らす必要がある。
    だから,レジ袋は有料のほうが良い。

 ・「無料チーム」の意見
  → レジ袋は,ゴミ袋の代わりにしたり,いろいろな使い道がある。
    しかも,燃やしても有害なガスは出ないので,環境にも影響が出にくい。
    そもそも,最初は無料だったのだから,無料のままで良い。

これは,あくまで要約で,もちろんこれ以外にも,
いろいろな意見が出ていて,予想以上に白熱したディベートでした。

学生さんも,ほとんどディベートをした経験がない…という人が多く,
こういう機会は,新鮮だったようで,
「改めて,違うテーマでやってみたい」という感想もあり,
やってよかったなぁ…と感じました。

案外,基礎情報活用(ホームルーム的な授業)の時間にでも,
やってみると良いかもしれません(笑)

comments

ビジネスマナー講座・3 日目

本日の講義では,「世の中のあれこれ」ということで,
選挙や年金・保険といった内容についての講義でした。

その後に,明日のディベートに備えて,
討論を行うテーマを決めた後,情報収集を行ってもらいました!

ちなみに,ディベートのテーマは,以下のとおりです。

 ・愛とお金,大切なのはどっち?
 ・レジ袋は有料と無料,どちらにすべき?

学生さんたちの多数決により,選ばれたものなのですが,
特に,愛かお金か…というあたりは,
明確な答えもなく,なかなか興味深いディベートになるのでは? と
密かに期待しています。

学生さんを「愛チーム」,「お金チーム」,「有料チーム」,「無料チーム」と
4 つのグループに分け,それぞれ「愛チーム」VS「お金チーム」,
「有料チーム」VS「無料チーム」に分かれて,ディベートを行う…という形です。

また,討論で,どちらが優勢であった(説得力があった)かは,
ディベートを聞いている,残り 2 つのチームの投票によって,
最終的に決定する,という方法をとっています。

チーム分けについては,今回はこちらで強制的に行ったので,
中には,自分の意見とは異なるチームに属してしまった学生さんもいて,
情報収集含め,どのように討論するか,かなり苦戦しているようでした。

実際のディベートは,明日なので,
どのような討論が行われるのか,楽しみです!

————— キリトリセン 8X —————

引き続き,第 3 章のテキストを読んでいます。
進捗状況は,あと半分…という感じ。

頑張れ,自分!

comments

宇宙花火

先日の皆既月食のリベンジもかね,本日は,宇宙花火というものを見るために,
夜の 7 時頃から,京都駅の大階段の上(屋上?)で,張り込みを決行しました!

西日本側だったら,観測できるだろう…ということだったので,
Web を参考に,南南西の空を凝視していたのですが,ちょうどその部分だけ雲がかかっていて,
花火どころか,星すらも思うように見れないという状態でした(涙)

とはいえ,この宇宙花火。
初の試みなのか,本当に見れるかどうかも分からないし,
たとえ見れなかったとしても苦情は受け付けません,ということだったので,
「見れたらラッキー!」くらいの感覚ではあったのですが…。

とりあえず,他の地域では,こんな感じに見えていたらしいです。

あまり,天体観測?には恵まれていないようなので,このウップンをはらすべく,
帰りがけに京都駅の八条口で,大盛り(LL サイズ)のパスタをたいらげてきちゃいました!

パスタのLLサイズです

↑豚肉と九条ねぎの和風パスタ

このお店,名前はパスタモーレ(PASTA MORE)というのですが,
パスタのサイズが,M サイズと L サイズと LL サイズとあり,
どのサイズを注文しても,なんといっさい値上げはナシ!
すべて同じ値段(780 円)で食べられるのです!

いやー,実にすばらしい!!

ガッツリ食べたいよ,っていうときにオススメです!

————— キリトリセン 8X —————

さらに。

いつまでも 第 6 章をやり続けているわけにも行かないので,
今日からようやく第 3 章を読み始めました!

第 3 章の内容は「ハードウェア」ということで,
学生時代から何回もやってきている範囲でもあるのですが,
さらなる知識の定着を目標に,頑張っていきたいと思います。

comments

9 月になりました

当初,9 月中に午前の範囲を終える予定だったはずなのですが,
見事に,スケジュールを押しています。
現時点で残っているのは,第 3 章 ~ 第 5 章と第 7 章 ~ 第 8 章です。

正直,終わっている範囲の方が少ないという…(汗)

どうあがいてもそれが現状なので,
とりあえず,今後はもう少し巻き気味でいきたいと思います!!

ちなみに。

第 6 章の間違った問題をもう 1 度解き直してみました。

全問正解できなかったのが残念ですが,
なんとか 1 問間違いまでに押さえることができたので,
最低でも現状維持を目標に…ということで。

————— キリトリセン 8X —————

余談ですが,せっかくのお休みにもかかわらず,
ムカデに続いて,今度はクモが出ました。

朝に出るクモは良いクモだ,というジンクスを聞いたことがあるので,
今回もやはり見なかったことにしようと思います。

小指の先ほどのサイズだったのが,せめてもの救い…(汗)

comments

ビジネスマナー講座・2 日目

…というコトで,今日のサマーコースでは,
まず,名刺交換のマナーに関する講義を行ってから,
その後,昨日決めてもらった仮想の会社と役職を元に名刺を作り,
それを使って,実際に名刺交換を行いました!

それが終わった後は,各会社ごとに「みんながなりたい人物像」というテーマで,
ブレーンストーミングと KJ 法をやってもらい,結果を発表する…という流れでした。

特に,授業後半のブレーンストーミングと KJ 法については,
私も過去にやって,かなり苦戦した思い出があったので,
どんな結論に至るのか,そもそも収拾がつくのか,いろいろと不安だったのですが,
各会社とも,きちんと発表できていて良かったです!

私の貧相なボキャブラリーでは,良い言葉が思いつきませんが,
なんというか,学生さんの底力を見たような気がします(笑)

————— キリトリセン 8X —————

さてさて。

サマーコースがスタートしたことにより,そちらの準備にかまけすぎて,
ここ 2 日間,ソフトウェア開発技術者試験の勉強をまったくしてません…。

俗に言う,中だるみってヤツでしょうか?(ちょっと違う気もしますが)

しかし,おかげさまで,ストック(第 6 章の間違った問題)がまだあるので,
昨日を含め,更新作業は続けられています。

嬉しいような,悲しいような…(涙)

そんなこんなで,以下がストックされていた第 6 章の問題とその解説。

[問題1]
工数が 500 人日と見積もられたプロジェクトで開発を 5 人で開始したが,開発に遅れが出てきた。あと 40 日を残すところで,まだ 300 人日の工数が必要と見込まれるので,プログラマを増やすことにした。次の条件がある場合,予定どおり,40 日でプロジェクト開発を完了するには,少なくとも何人のプログラマを増やせばよいか。

 <条件>
  1. 最初からプロジェクトに参加しているプログラマのうちの 1 人が,増やしたプログラマ全員に対して
    5 日間の教育を行う
  2. 作業の再分割のために,さらに (0.5a + 6) 人日の工数が必要となる(a は増やしたプログラマの人数)
  3. プログラマを増やしたことによるその後のコミュニケーションのオーバーベッドは無視できる

 (ア) 3   (イ) 4   (ウ) 5   (エ) 6 

この問題の答えを導くには,最初に今の時点でどれだけの遅れが出ているかを求め,
次に,その遅れ分を追加の人員,何人でカバーすれば良いかを考えます。

このまま 5 人で 40 日間作業を行うとすると,
この人数でこなせる作業量は,以下のようになります。

 5 × 40 = 200 (人日)

しかし,問題文にあるように,まだ 300 人日分の作業が残っているので,
以下の分だけ,追加人員でカバーしなければならないことが分かります。

 300 - 200 = 100 (人日)

ただし,実際には,作業の再分割と追加人員への教育を行っている間は作業が行えないので,
この 100 人日とあわせて,それらについても,追加人員がカバーする必要があります。

ここまでをふまえると,新たに追加されたプログラマが担当しなければならない作業量は,
残りの作業作業の再分割中に行えたはずの作業教育中に行えたはずの作業」なので,
問題分の条件より,

 100(0.5a + 6) 5   … (*)

となります。

また,残りの 40 日間で追加人員 a 人が作業できるのは,
教育を受けている 5 日を引いた 35 日間で,この間の追加人員の作業量は,

 (40 - 5) × a (人日)

となり,これが (*) と等しければよいので,以下のような式が成り立ちます。

 100 + (0.5a + 6) + 5 = (40 - 5) × a

これを解くと,

 100 + 0.5a + 6 + 5 = 35a
       (35 - 0.5)a = 111
              a = 111 ÷ 34.5
               = 3.217391304  ← 3 よりも大きいので,3 人だと足りないことが分かります  

よって,答えは (イ) となります。

comments

ビジネスマナー講座・初日

いよいよ今日から,サマーコースの第 2 クールが始まりました!

以前のブログにも匂わせていた?とおり,私も,仲良しのある先生と一緒に,
「素敵な大人になるために ~手取り足取りビジネスマナー講座~」なるものを開講しています。

ビジネスマナーというと,ものすごくお堅いイメージがありますが,
この講座の目的は,マナーそのものを身につけることももちろん大切ですが,
それよりも,社会人として必要となる社交性とか積極性とか,
どちらかというとそちらに重きを置いて,「講義 + 実技」という形で授業内容を組んでいます。

初日の今日は,現時点でのマナー度を知ってもらうためのマナーチェックと簡単な講義を行ってから,
学生さんをくじ引きでランダムに振り分けて,仮想の会社を作り,
会社の名前はもちろん,グループのメンバー内で,役職(社長・部長・係長)を決めてもらいました。

やはり最初は,校舎も学科も学年も違う社員(グループのメンバー)同士,お互いに遠慮がちでしたが,
学生さんたちに,より仲良くなってもらうために行った「会社対抗・ビジネスマナークイズ」の後は,
わりと打ち解けてくれていたようで,安心しました!

ちなみに,この講義では,授業開始後すぐに,
人前でしゃべることに慣れるのを目的とした 60 秒間スピーチ(時間は少しずつのばします)を
受講者全員にしてもらっています。

今はまだ話す内容にとまどっている感じですが,
最終日に,皆さんがどれくらい話せるようになるのかが,すごく楽しみです!

————— キリトリセン 8X —————

前置きが長くなってしまいましたが,第 6 章の間違った問題の続きです!

[問題1]
システムインテグレーションに関する記述のうち,適切なものはどれか。

 (ア) システムインテグレーション事業を行うためには,経済産業省に届出が必要である
 (イ) システムの企画からシステム構築,運用,保守までに必要となる業務を一貫して
    請け負うサービス形態であり,一定基準を満たす事業者に対して優遇税制もある
 (ウ) ユーザが,情報システムの開発,運用,保守などに関するすべての作業,
    または一部の作業を外部の専門企業に発注し,トータルなコスト削減を
    図ることである
 (エ) ユーザの問題を解決するために,システム統合パッケージを利用した総合的な開発を
    行うことである

[問題2]
TCO(Total Cost of Ownership) に関する記述のうち,適切なものはどれか。

 (ア) システム上にデータベースを独占的に構築しているユーザが負担すべき費用の総和である
 (イ) 情報システムについて,導入から維持管理に至るまでの費用の総和である
 (ウ) ソフトウェアについて,企画から保守に至るまでの費用の総和である
 (エ) パソコンの購入に関して,ユーザが負担する機器およびソフトウェアの費用の総和である

以下,問題の解答と解説です!

[問題1] (イ)
システムインテグレーションとは,システムの企画からシステム構築,運用,保守までに
必要となる業務の一部,あるいはすべてを一貫して請け負う事業(サービス)のことを
いいます。
 (ア) システムインテグレーション事業を行うために,経済産業省への届出は必要ありません
 (イ) SI 事業者としての一定基準を満たした業者は経済産業省が認定し,情報サービス企業台帳に
    登録され公表されるという SI 登録制度(有効期間は 2 年間で,2 年ごとに更新が必要)が
    あります
 (ウ) アウトソーシングに関する記述です
 (エ) システムインテグレーション事業は,「開発」のみを請け負うことではありません
    また,システム統合パッケージの利用は条件としていません

[問題2] (イ)
TCO(Total Cost of Ownership) は,運用。保守費用はもちろんのこと,教育研究費,
ユーザサポート費など,情報システム部門や利用者部門で発生するすべてのコストであり,
「システムの導入から維持管理に至るまでのすべての費用の総和」を意味します。

comments

まだまだ暑いですね

今日も暑いなぁ…と思い,何気に部屋のエアコンのリモコンを見たら,
設定が「暖房」になっていました。

エアコンのリモコンです

…どおりで,暑いはずです。

ちなみに,明日から,私の担当するサマーコースが,
いよいよ開講になりますが,暑さに負けずに頑張りたいと思います!

————— キリトリセン 8X —————

なんだかんだで,第 6 章の間違った問題も,とうとう第 4 弾!

さすがに 16 問も間違えると,問題をアップする作業も
なかなか骨が折れます…。

[問題1]
ファンクションポイントの長所,短所を示すものはどれか。

 (ア) 長所:小規模のシステムでは制度の高い見積もりができる
    短所:単位作業までの分解がプロジェクトの初期では困難
        妥当な基準値の設定のために実績データの収集・評価が必要
 (イ) 長所:ソフトウェア規模から工数・工期を見積もるので,
       担当者の経験にあまり左右されない
    短所:プロジェクトの初期には適用が困難である
       開発規模の見積もりはできない
 (ウ) 長所:ソフトウェアの大局的な性質から,プロジェクト全体にかかる
       インテグレーションやマネジメントなどのコストを効率的に
       見積もることができる
    短所:個々の技術的な問題が見落とされやすい
 (エ) 長所:プロジェクトの比較的初期から適用できる
        ユーザとのコンセンサスをとりやすい
    短所:妥当な基準値の設定のために実績データの収集・評価が必要

[問題2]
ベームが開発した見積もりモデルである COCOMO について,適切な記述はどれか。

 (ア) 開発工程における WBS ごとに作業工数を積み上げるコスト見積もりモデルである  (イ) 開発の専門化が過去の経験から類推してソフトウェアの規模を見積もる
    モデルであり,デルファイ法によってその見積もり値を収束していく
 (ウ) ソフトウェアの機能を入出力の数やマスタファイルの数でとらえ,難易度を
    考慮しながらソフトウェアの規模を見積もるモデルである
 (エ) ソフトウェアの規模を入力変数として,コスト誘因とそれに対する係数を
    考慮しながら開発工数を計算するコスト見積もりモデルである

ここまでの解答と解説!

[問題1] (エ)
ファンクションポイント (FP) 法とは,システムがユーザに提供する
機能(ファンクション)を規定の方法により定量化し,ソフトウェア開発工数の
見積もり尺度とする方法です。特徴は,以下のとおり。
  ・ユーザから見える画面や帳票などを単位として見積もるため,
   ユーザにとって理解しやすい
  ・機能を定量化するため,過去の多くの実績データが必要となる
  ・見積もりを適用する際の,解釈の標準化が必要である

[問題2] (エ)
COCOMO(COnstructiv COst MOdel)は,ベームによって提唱されたコストモデルで,
プログラムの行数(KLOC:Kilo Lines Of Code)から統計的なモデルを用いて
開発工数(人月),開発期間を算出します。
     開発工数 P = a × K の b 乗 × 努力係数(人月)
     開発期間  = 2.5 × P の c 乗

上式の a ~ c は,見積もり対象の難易度,開発要因の構成といった対象の
システムの特徴,そして,見積もりレベルによって決定される定数です。
なお,(ア) は標準タスク法,(イ) 類推(概算)法,(ウ) はファンクションポイント(FP)法の説明です。

comments

皆既月食

今日は 6 年に 1 度の皆既月食が見られる…ということで,
なかなかウキウキしていたのですが,肝心の天候があいにくの曇天!

月食どころか,空自体が見えるか否かという,そんなレベル。
まだ生まれてこの方 1 度も見たことがなくて,
楽しみにしていただけに,かなりショックです(涙)

ただ,天気ばかりはどうしようもないので,
おとなしく ネット上のニュース画像 で我慢しておきます…。

————— キリトリセン 8X —————

さてさて。

第 6 章の間違った問題も,早くも第 3 弾…ということで。

[問題1]
内部設計書のデザインレビューを実施する目的として,適切なものはどれか。

 (ア) 外部設計書との一貫性の検証と要求定義の確認
 (イ) 設計記述規約の遵守性の評価と設計記述に関する標準化の見直し
 (ウ) テストデータ仕様の確定とテストケースの網羅性の評価
 (エ) 要求定義の内容に関する妥当性の評価と外部設計指針の見直し

[問題2]
2 つの独立したテストグループ a,b が,あるシステムについて一定期間並行してテストを行い,それぞれ Na 個および Nb 個のエラーを検出した。このうち,共通のエラーはNab 個であった。グループ a,b のエラーを検出する能力および効率は等しいものと仮定する。このシステムの総エラー数 N を予測する式はどれか。ここで,Na > 0 ,Nb > 0,Nab > 0 とする。

 (ア) N = Na + Nb – Nab   (イ) N = Nab × Na × Nb
 (ウ) N = (Na + Nb) / Nab  (エ) N = (Na × Nb) / Nab

[問題3]
ソフトウェア品質特性に関する記述のうち,保守性を表しているものはどれか。

 (ア) 運用管理が容易である  (イ) 故障しても容易に回復できる
 (ウ) スループットが高い     (エ) プログラムの解析が容易である

ここまでの解答と解説!

[問題1] (ア)
内部設計では,外部設計で定義された各機能をプログラムに分割し,
プログラム間の関連や,データや処理の流れを明確にします。
また,内部設計書のデザインレビューのポイントは,以下のとおりです。
   ・外部設計書との整合性(機能がもれなく設計されているか,など)
   ・プログラム間インタフェースの誤り,論理的な矛盾はないか,など
   ・設計書(ドキュメント)が標準に準拠しているか
   ・次工程であるプログラム設計へ配慮された内部仕様書となっているか

[問題2] (エ)
2 段階エディット法は,まったく独立した 2 つのテストグループ a,b が
テストケースやテストデータをそれぞれのグループで用意し,一定期間
並行にテストを行います。その結果,グループ a が検出したエラー数が Na 個,
グループ b が検出したエラー数が Nb 個であり,そのうち Nab 個が
共通するエラーであった場合,システム総エラー数 N は下記の式によって
推定できます。
           N = (Na × Nb) / Nab

[問題3] (エ)
保守性とは,システムの変更・拡張がどれくらい容易に行えるかということであり,
保守性を高めるためには,以下の事項が重要となります。
   ・解析性:バグの修正作業の際,設計書やプログラムの解析が用意に行える
   ・変更性:システムの変更や拡張がしやすい
   ・安定性:システムの一部の修正がほかの部分に影響を与えない
   ・試験性:修正後のテストが容易である
なお,(ア) は使用性(運用性),(イ) は信頼性(回復性),(ウ) は効率性(時間効率性)を表します。

[問題3] は,「保守」って,「運用」とセットでよく聞くので,
ついつい (ア) が答えかと思ってしまいました…。

案の定,それで間違えたわけですけども(涙)

comments