最近Redmineというプロジェクト管理ツールに興味を示している。

Redmineがどういうものかは下の記事を読んでほしい。
Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう！

恥ずかしながら、私がRedmineの存在を知ったのはつい最近のことだ。今の会社へ転職してからはいちプログラマ兼SEとしての役割しかなかったので、保有しているPM資格も単なる飾りでしかなく、持てる力を発揮する機会もなく平凡な日々を過ごしていた。
ところが先月、本社で事業部全体会議が行われ、その際取締役から支社の役割として開発拠点という位置づけが示された。開発拠点というくらいだから現在のように自分の課の案件の製造をこなすだけではなく、他の課の案件の製造もこなすことになる。そして私は支社の管理・運営を仰せつかった。

支社の管理・運営は単なるプロジェクト管理ではなく組織経営に近いものがある。やらなければならないこと、考えなければならないことは山ほどある。プロジェクト管理うんぬんのレベルではない。しかし、残念なことに、現在の会社にはプロジェクト管理のノウハウが全くと言っていいほどないのだ。そのことを現在のプロジェクトで嫌と言うほど思い知らされた。だから、まずは簡単にとはいかないまでも手軽にプロジェクトを管理する方法を見つける、編み出さなければならない事情があった。そこで開発の進捗や問題点、品質等を管理するよい手だてはないものかと思案していると、本屋でプロジェクト管理ツールのRedmineに関する書籍が目についたのである。

以下の本である。





なかなかわかりやすくてよい。
インストール方法から、管理者としての設定方法、プロジェクト参加者としての使用方法など、役割に応じて章が分かれているので自分の役割に応じた章だけ目を通せばよいのも助かる。(ただし、Redmineを導入する担当の方は、全章に目を通して、何ができ、どうやればよいかは把握しておく必要があろう)

使用してみての感想等は後日。

プロジェクトマネージャが自らプログラムのテストを行うことはないと思いますが、テストの手法等は知っておくべきでしょう。

今回ご紹介するのはHAYST法という手法です。”ヘイスト法”と読みます。




品質工学の手法をソフトウェアテストへ応用したもので、副題にあるように品質と生産性をアップさせる直交表の使い方を詳しく解説しています。

ソフトウェアが大規模化・複雑化していくなかで品質を確保・保障するために行うテスト項目の数はますます膨大になっています。そのような時代の流れの中でソフトウェアの品質を高めつつ生産性アップを図るためには効率のよいテスト計画が必須です。

品質工学や実験計画法、直交表は、少ない実験回数でいかに効率よく実験（テスト）を実施していくかを教えてくれます。HAYST法は、多機能間の交互作用によるバグ検出をあきらめる代わりに、２機能間、あるいは、３機能間のテスト網羅率を高めることで効率性と品質確保を目指します。




直交表や実験計画法という言葉を初めて聞いた方には少しとっつきにくいかも知れません。
まずはこの本を購入される前に「ソフトウェア・テスト PRESS Vol.2」の記事を書店で立ち読みしてみるのもよいかも知れません。




実験計画法とは何か知りたい方は下記の本が取り付き易いと思います。



品質工学の本はたくさんありますが、数式がたくさん出てきたり、直交表の理論的背景を説明することに頁を割いたものが多く、私がお勧めできる本はありません。ソフトウェアテストにおける直交表の使い方に関する説明は、「ソフトウェアテスト HAYST法入門」が一番親切丁寧です。

放送大学の専門科目で、「コンピュータのしくみ（'08）」という科目がある。昨日からこの科目を観始めて、今日で第５回まで観た。結構わかりやすい。

私はPM資格を持っているくらいだから、コンピュータの基本の基本は勉強したが、正直言って私のコンピュータの知識は大したことない。元々は半導体のエンジニアだったのに、物性屋だったため、コンピューターの動作原理や論理回路のことはほとんど知らない。

そんな私でも、この講義はとてもわかりやすく、わくわくして観ている。
皆さんもご覧になってはいかがでしょうか？

 

コンピュータのしくみ('08)
シラバス

第01回　ディジタルとアナログ(第1章)
第02回　スイッチ素子 (第2章 - 第3章 3.2節)
第03回　基本論理回路と組合せ論理回路(第3章 3.3節 - 第4章 4.3節)
第04回　組合せ論理回路の構成法 (第4章 残り)
第05回　状態遷移図、状態遷移表とシークエンス回路(第5章 5.2節まで)
第06回　遅延回路とパストランジスタ (第5章 残り)
第07回　二進加減算(第6章 6.3節まで)
第08回　二進乗除算とデータの内部表現(第6章 残り)
第09回　コンピュータの概要 (第7章)
第10回　プログラム (第8章)
第11回　データ処理部1 (第9章 9.5節まで)
第12回　データ処理部2 (第9章 残り)
第13回　制御部1 (第10章 10.3節まで)
第14回　制御部2 (第10章 残り)
第15回　今後の発展 (第11章)

 テキスト

 

私がプロジェクトマネージャを目指して勉強したときにお世話になった本はこの本です。



以下、私がこの本をどのように活用してプロジェクトマネージャー資格を取得したかをご紹介します。

　私はこの本を午後２対策として活用しました。
　制限時間内で規定字数を書き上げるための速度[文字/分]を体感するために、私は事例論文を写本することから始めました。写本と言っても、事例論文を読みながら自分の経験と照らし合わせ、理解しながら書き写しましたので、制限時間内で写本するのはとても大変な作業でした。始めの1・2本の論文は制限時間内で写本することすらできませんでした。これを各分野最低１論文、全部でおよそ12論文程度こなしました。

　写本と言う単純な作業ではありますが、このおかげで、どれくらいのペースで論文を書かなければならないか体感できたので、本番では高望みせず、最低規定字数+200字程度を目標することをあらかじめ決めて試験に臨むことができました。また、各分野を万遍なく写本したことで、自分の得意な分野、不得意な分野がだいたいわかるようになり、問題３題の中から自分の得意分野をすぐに選ぶことがきるようになりました。

 

 

CiNii(論文情報ナビゲータ　国立情報学研究所)でプロジェクトマネジメント学会研究発表大会予稿集を参照した。

少し古いが1999(秋季)の予稿集にある、
「A-53 C/S型受発注システム開発におけるプロジェクト管理事例」
を読んでみた。

これはC/S型受発注システムのリプレースを扱った事例だが、当初のプロジェクト計画が甘く、本稼動に間に合わず、プロジェクト実態把握と建て直しを図るためプロジェクト管理体制を再編成している。
再編成した結果、コストは当初予定の4倍、納期は6ヶ月遅れとなったとのこと。

論文の最後に課題として以下の点があげられている。
１　見積り
（1）対象作業項目を全て洗い出す。
（2）作業項目単位の成果物を整理する。
（3）成果物を生成する作業工数を見積る。
（4）未決定項目は、前提条件として明記する。

２　仕様の確定
（1）詳細な機能仕様までを明確にして、ユーザの合意を得ておく。
（2）仕様の確認では、必ず仕様書やドキュメントにて行なう。

３　進捗管理
（1）作業スケジュール(線表)は、工程毎に詳細な作業項目に分解し、担当者のスキルを加味して作成する。


要はWBS(work breakdown structure)を事前にきちんと作成しなさいと言うことだ。