コンピュータ関連の参考文献

 

プロジェクトマネージャのためのKindle本!

ベテラン技術者による実践的な内容です。

《Kindle本》

Kindleへ

プロジェクトマネージャのための

スキルアップ読本 統合編

楽しく読み進められるプロジェクトマネジメントのヒント集。

初めてプロジェクトマネージャになる人から中堅の人までのスキルアップのために。

特定の理論や技法の解説ではなく、今日からでも役立つような具体的で実践的な内容。

なお、この本は、当初はKindle本だけを想定していたので、手軽に読めるように前編と後編に分けていました。その後、ペーパーバックにも対応しました。そして、ペーパーバックの場合は1冊にまとめた方が印刷コストの面でずっと有利になることから、前編と後編を合本し、「統合編」として出版することにしました。 したがって、既に前編と後編を読まれた方は、この「統合編」を読む必要はありません。

本書の目次は、以下のとおりです。

はしがき

目次

Ⅰ. プロローグ:プロジェクトマネージャは、広い視野を持つことが大切です

(ⅰ)【プロローグ ①】:視野を広げて、担当プロジェクトを客観的に把握しましょう。

(ⅱ)【プロローグ ②】:理論firstでなく、現場firstで進めましょう。

(ⅲ)この本の表記法について。

第1章 プロジェクトの計画について

(1)日程計画は、大日程、中日程、小日程等に分けて段階的に作る。

(2)大日程では、プロジェクト外部の予定との関係を明確にする。

(3)計画時には、工程の重なりを避ける。

(4)中日程では、大工程の移行時期に注意する。

(5)小日程では、図表は形式にこだわらずに目的に応じて作成する。

(6)日程における作業項目は、WBSのタスクに対応させるが、両者の考え方の違いに注意する。

(7)工数計画には、適切な余裕を持つ。

第2章 進捗管理について

(8)進捗管理のサイクルは、週次を基本としてプロジェクトの状況に応じて決める。

(9)ガントチャートは、進行中の作業についての進捗状況が見えるように作成する。

(10)ガントチャートでは、イナズマ線を大いに活用する。

(11)テスト工程では、バグの発生件数も進捗管理の指標として注目する。

第3章 課題管理について

(12)進捗が遅れている作業については、その原因を課題として管理する。

(13)課題管理表には、項番、内容、発生日付、期限、担当者、ステータス及び状況を必ず記載する。

(14)課題管理表は、どんどん書いてどんどん消す。

(15)課題管理とリスク管理とは、はっきり区別する。

第4章 EVMについて

(16)EVMでは、特にSPIとCPIに注目する。

(17)EVMは、発注者への月次の概況報告に活用する。

(18)高度に抽象化した図表は、日常のプロジェクト管理の現場では利用しない。

(19)EVMに基づく指標は、会計目的での利用を避ける。

第5章 テストについて

(20)テストの工程の分け方は、プロジェクトの特性を良く考えて決定する。

(21)結合テストでできることは、システムテストに持ち越さない。

(22)システムテストには、ユーザ側も関与する。

(23)システムテストは、本番と同等の環境で行うように最大限努力する。

第6章 仕様変更への対応について

(24)システム開発途中での仕様変更は、発生する前提で考えておく。

(25)仕様変更には、一定の期限を設ける。

第7章 プロジェクトの立上げについて

(26)プロジェクトは、一つの情報システムの完成までを単位とする。

(27)プロジェクトメンバの選任には、いろいろな人の力を借りる。

(28)ユーザ側とベンダ側の役割分担については、現実的かどうかに十分注意する。

(29)公的機関では、予算確保や調達には担当部署の力を借りる。

(30)プロジェクトの立上げ時には、標準化についての大方針を決める。

(31)コンサルタントを使う場合は、その方向性を明確にしておく。

第8章 プロジェクトの体制とプロジェクトマネージャの役割について

(32)10人までのプロジェクトの体制では、プロジェクトマネージャは、プレイングマネージャとして積極的に開発実務を分担する。

(33)十数人規模のプロジェクトの体制では、プロジェクトマネージャは、チームリーダへの信頼感の醸成に努める。

(34)数十人規模以上のプロジェクトの体制では、プロジェクトマネージャは、メンバから顔が見えるようにコミュニケーションの維持に努める。

第9章 プロジェクトのコストについて

(35)ユーザ側では、仕様の膨張をできる限り防ぐように努める。

(36)ベンダ側では、要件定義の段階で開発規模ができる限り決まるように努める。

(37)必要な費用は、臆せずタイムリーに支出する。

第10章 要員の外注について

(38)要員の外注に際しては、とにかく積極的に動く。

(39)外注先に対しては、契約形態にかかわらず、ある程度の口出しは行う。

(40)民間企業の場合は、外注先との普段からの関係の構築を大切にする。

(41)外国との共同プロジェクトでは、とにかく視野を広く持つ。

(42)分割発注は、取りまとめ力を大前提とする。

第11章 リスク管理について

(43)リスク管理は、一つの「よりどころ」と考える。

(44)リスクは、転嫁するのでなく、回避又は低減を目指す。

(45)リスクの保有(受容)とは、関係者の意思統一のことと理解する。

第12章 プロジェクトの状況報告について

(46)ユーザ側のプロジェクトでは、進捗状況を報告し、主要課題を共有する。

(47)経営陣に直接報告する場合は、進捗状況を報告し、リスクを共有する。

(48)ベンダ側のプロジェクトでは、自社の上司には損益の見通しを中心に報告する。

第13章 本番切替えとトラブル対応について

(49)本番切替え時には、関係者を総動員した臨戦態勢をとる。

(50)切替え手順書作成に際しては、切戻し手順を慎重に検討する。

(51)本番切替え後のトラブル対応では、オーバーアクションを恐れずに大きめに動く。

(52)トラブルの原因追究では、誰が悪いかを「追及」するのではなく、何が悪いかを「追究」する。

Ⅱ. 背景知識:いろいろな情報システム・いろいろなプロジェクト

(ⅳ)【背景知識 ①】:情報システムの用途(使われ方)のいろいろ。

(ⅴ)【背景知識 ②】:情報システムの形態(開発方式及び稼働環境)のいろいろ。

(ⅵ)【背景知識 ③】:プロジェクトの性格(位置づけ)のいろいろ。

(ⅶ)【背景知識 ④】:必要な信頼性とセキュリティレベルのいろいろ。

Ⅲ. エピローグ:プロジェクト成功の鍵は、「人の和」です

(ⅷ)【エピローグ ①】:仲の悪いグループをまとめるには、プロジェクトマネージャが双方から信頼を得ることが大切です。

(ⅸ)【エピローグ ②】:プロジェクトの外部には悪口を言う人が必ずいますから、そういう悪口がプロジェクトメンバに広がらないように守ることが大切です。

(ⅹ)【エピローグ ③】:プロジェクトが成功すれば全員が幸せになり、失敗すれば全員が不幸になります。

著者について

本書について


官公庁の情報システム開発についてのKindle本!

何が問題か、どうすればよいのかを考えます。

《Kindle本》

Kindleへ

官公庁の情報システム開発は何が問題か

官公庁の情報システム開発は、とかく評判が良くありません。なぜでしょう。

私は、これまで、民間企業と官公庁の両方で、情報システム開発プロジェクトのプロジェクトマネージャを務めてきました。この経験を元に、デジタル庁への期待も込めて、次の7個の問題点を取り上げました。

問題点①:使い勝手を考えないシステム設計

問題点②:行き過ぎた分割発注

問題点③:技術力を軽視した業者選定

問題点④:「官公庁ではできない」という思い込み

問題点⑤:実質的なプロジェクトマネージャの不在

問題点⑥:ガイドラインによる過度の束縛

問題点⑦:あまりにも大きなマイナンバー取扱い上の制約

本書の目次は、以下のとおりです。

はしがき

目次

序章 背景:民間企業の仕事と官公庁の仕事

(序‐1)民間企業の仕事は、利益を得ること

(序‐2)官公庁の仕事は、法令を執行すること

(序‐3)補足:官公庁にも、素晴らしい情報システムがある

第1章 システム設計における問題

(1‐1)[ケーススタディ]:VRS(ワクチン接種記録システム)

(1‐2)[問題点①]:使い勝手を考えないシステム設計

(1‐3)[改善策]:システム設計においては、「使われ方」から考えることが必要

第2章 調達における問題

(2‐1)[ケーススタディ]:特許庁システム全面刷新プロジェクト

(2‐2)[問題点②]:行き過ぎた分割発注

(2‐3)[問題点③]:技術力を軽視した業者選定

(2‐4)[改善策]:調達においては、発注元と発注先の役割を十分意識することが必要

第3章 官公庁における「制度上の制約」に関する問題

(3‐1)[ケーススタディ]:ある官公庁における「制度上の制約」

(3‐2)[問題点④]:「官公庁ではできない」という思い込み

(3‐3)[改善策]:官公庁における「制度上の制約」に関しては、それを逃げ口上とせずにどう乗り越えるかを考える発想が必要

第4章 プロジェクト体制に関する問題

(4‐1)[現状]:多くの官公庁で見られるプロジェクト体制

(4‐2)[問題点⑤]:実質的なプロジェクトマネージャの不在

(4‐3)[問題点⑥]:ガイドラインによる過度の束縛

(4‐4)[改善策]:プロジェクト体制に関しては、実質を伴うプロジェクトマネージャを任命し、十分な裁量の余地を与えることが必要

第5章 マイナンバーに関する問題

(5‐1)[現状]:マイナンバーの取扱い

(5‐2)[問題点⑦]:あまりにも大きなマイナンバー取扱い上の制約

(5‐3)[改善策]:マイナンバーに関しては、行き過ぎた政治論から脱却して適切な活用を進める姿勢が必要

著者について

本書について


コンピューター関係の豆知識を集めたKindle本!

広い分野からのトピックスを集めています。

《Kindle本》

Kindleへ

コンピューター豆知識

コンピューターに関する幅広い分野について、様々なトピックスをまとめました。

「コンピューター豆知識」というタイトルから想像できるとおり、「豆知識」、つまり専門書とは違った角度からのトピックス(トリビア)が中心です。

ですから、勉強モードで読むよりも、「ああ、そうなのか。」と軽い気持ちで読んでいただきたいと思います。そうすれば、コンピューターの世界の面白さを見つけるための一つのきっかけになることと思います。

本書の目次は、以下のとおりです。

はしがき

目次

序章 身近になったコンピューター

(序‐1)当初のコンピューターは、「電子計算機」と呼ばれていた。

(序‐2)パソコンは、「コンピューター」とは呼ばれたが、「電子計算機」とは呼ばれなかった。

(序‐3)スマホは、「コンピューター」とさえも呼ばれない。

【表記について】:「コンピューター」と「コンピュータ」

第1章 コンピューターの仕組みについて

(1‐1)ストアドプログラム方式について

(1‐1‐1)私たちがコンピューターに対して持っているイメージの多くは、実は「ストアドプログラム方式」に由来する。

(1‐1‐2)コンピューターを立ち上げることを「ブートする」というのは、靴ひもから連想した言い方であり、これもストアドプログラム方式に由来する。

(1‐1‐3)ストアドプログラム方式は、大変に便利である一方、マルウエアの活動の余地を生じさせた。

【解説】:ストアドプログラム方式でないコンピューター

(1‐2)記憶装置について

(1‐2‐1)主記憶装置は、必ずしも最も高速な記憶装置とは限らない。

(1‐2‐2)主記憶装置は、電源を切ると中身が消える。

(1‐2‐3)外部記憶装置は、必ずしも「外部」にあるとは限らない。

(1‐2‐4)パソコンでは主記憶容量が大切だが、スマホでは外部記憶容量の方が重視される。

【表記について】:kB(キロバイト)とMB(メガバイト)

(1‐3)ネットワークについて

(1‐3‐1)「インターネット(the Internet)」という名前は、ネット間通信規約のことを「internet protocol」と称するところから発生した。

【解説】:ハブとルーター、L2スイッチとL3スイッチ

(1‐3‐2)ややこしいが、家庭用のルーターは、実はルーターとハブが合わさったものである。

(1‐3‐3)「専用ネットワーク」でも、拠点と拠点を結ぶ通信回線は、他のユーザーと共用している。

(1‐3‐4)当初のコンピューターには「ネットワーク」という概念がなく、中心のコンピューターに通信回線をつなぐという発想だった。

(1‐4)仮想化について

(1‐4‐1)仮想化その1「仮想記憶」:ハードウエアはソフトウエアより速い。仮想記憶では随分と複雑な処理を行うが、ハードウエアで行うのでほとんど遅くならない。

(1‐4‐2)仮想化その2「仮想マシン」:クラウドサービスで割り当てられるサーバーは、仮想マシン、つまり孫悟空の毛の一本である。

【解説(Advanced)】:ハイパーバイザーの動作

(1‐4‐3)仮想化その3「仮想ネットワーク」:仮想ネットワークには、VLAN、IP-VPN、IPsec-VPN、SSL-VPNなど、紛らわしい名称のものが多い。そして、使われる利用局面もそれぞれ異なっている。

第2章 IT業界での製品・サービスの移り変わりについて

(2‐0‐1)ソフトウエアは、当初はハードウエアのおまけだった。ソフトウエアがそれ自身で独立した価値を持つようになったきっかけは、System/360シリーズだった。

(2‐0‐2)SEサービスは、ハードウエア、ソフトウエアのおまけだった。そもそもサービスなのだから無料と考えられていた。

【解説】:「メインフレーム」と「オープン」

(2‐0‐3)「クラウドサービス」という商品が登場し、コンピューターは買うものから使うものになってきた。

(2‐0‐4)IT業界は、長らく企業を相手にしてきたが、最近では個人を相手にするようになっている。

第3章 コンピューターの応用分野について

(3‐1)数値計算について

(3‐1‐1)世界最初のコンピューターは、「スーパーコンピューター」だった。

(3‐1‐2)微分方程式:本来、微分方程式を解いた答えは、数ではなくて関数である。しかし、コンピューターでは、数値を扱う。

(3‐1‐3)常微分方程式と偏微分方程式:月食が起こることは10年前からでも正確に予測できるが、その時に晴れているかどうかは前日になっても正確には分からない。

(3‐2)Webシステムについて

(3‐2‐1)世の中のWebシステムには、情報を表示するものとデータ入力を行うものの二つのタイプがある。対応する技術者も異なる。

(3‐2‐2)最近のWebサイトでは、通信内容を暗号化することが既に当たり前になっている。

(3‐3)AIについて

(3‐3‐1)最初のAIブームのキーワードは、「LISP」だった。この時代の人工知能では、その知恵・知識は、あらかじめプログラムされるものだった。

(3‐3‐2)2回目のAIブームのキーワードは、「知識工学」だった。この時代の人工知能では、その知恵・知識は、人間が作り出してコンピューターに与えるものだった。

(3‐3‐3)今のAIのキーワードは、「ディープラーニング」である。今の人工知能では、その知恵・知識は、コンピューターが自ら作り出す。

第4章 組込み系システムについて

(4‐0‐1)「マイコン」:マイコンを組み込んだ機械は、従来よりもずっと複雑な動作ができるようになる・・・鉄道の切符の自動販売機は、当初は運賃ごとに別々だった。

(4‐0‐2)「制御用コンピューター」:制御用コンピューターは、プラントを安全・効率的に制御し、省力化に貢献する。・・・圧延機の制御用コンピューターは、業務系システムとも連携する。

(4‐0‐3)組込み系システムは、スマホ、自動車、家電で急拡大した。

第5章 業務系システムについて

(5‐1)座席予約システムについて

(5‐1‐1)旧国鉄が開発した座席予約システム(MARS)ができる前は、座席の予約は回転テーブルを使って管理していた。

(5‐1‐2)航空機の座席指定法:当初の航空予約システムでは、座席は予約時に決めず、チェックイン時に決めていた。

(5‐1‐3)日米の航空予約システムの違い①:米国の当初の航空予約システムは、情報システムに起因する意図しないオーバーブッキングを容認する設計だった。

【解説(Advanced)】:排他制御

(5‐1‐4)日米の航空予約システムの違い②:初期の航空予約システムは、その形態が日本と米国で異なり、日本では、旅行代理店には航空会社ごとに別々の端末が置かれていた。

(5‐2)銀行システムについて

(5‐2‐1)銀行の勘定系システムは、全銀システム、日銀システムと連携して仕事をしている。

(5‐2‐2)銀行の勘定系システムはオンラインリアルタイムシステムの代表格だが、夜間バッチでの処理も大切である。それには業務的な意味合いがある。

(5‐2‐3)業務系システムは、背景としての文化・社会の違いを反映する:米国のある銀行では、週末にATMでお金をおろしても残高が週明けまで減っていないことがあった。

(5‐3)課金システムについて

(5‐3‐1)課金システムは、単なる事務処理だけでなく、企業における戦略的な意味も持つようになってきた。

(5‐3‐2)業務系システムは、背景としての文化・社会の違いを反映する:日本の課金システムは請求ごとの支払の有無を管理し、米国の課金システムはcurrent balanceを管理する。

第6章 高性能化の歴史について

(6‐0‐1)コンピューターは、1980年代半ばから急速に小さくなった。

(6‐0‐2)スーパーコンピューターの計算速度は、40年で7億倍になった。

(6‐0‐3)IBM360アーキテクチャでは、記憶場所を表すアドレスは3バイト、つまり実装できる主記憶装置は16MBだった。

第7章 暗号とセキュリティについて

(7‐1)公開鍵暗号について

(7‐1‐1)公開鍵暗号の登場:公開鍵方式では、暗号鍵を公開しても暗号通信ができる。

(7‐1‐2)Webサイトでの公開鍵暗号の使われ方①:公開鍵方式の暗号は処理速度が遅いため、Webサイトでは共通鍵方式の暗号と組み合わせた方式を使用する。

(7‐1‐3)Webサイトでの公開鍵暗号の使われ方②:公開鍵が本人のものであることを確認するため、Webサイトではサーバー証明書を使用する。

【表記について】:「暗号化」と「復号」

(7‐2)セキュリティについて

(7‐2‐1)パスワードは、多くのシステムでは暗号化されて保持されており、システムといえども暗号化されたパスワードを復号することはできない。

(7‐2‐2)高いセキュリティが必要なシステムでは、二要素認証が必須である。このことは、自然な感覚として身に付けておくことが大切である。

(7‐2‐3)社内ネットワーク、メール、予定表、リモート会議等を行うシステムでは、セキュリティについての適切な設計が最重要の検討ポイントになっている。

第8章 プログラミング言語について

(8‐1)1960年代の大きな失敗:PL/Iについて

(8‐1‐1)PL/Iは、COBOLとFortranを包含した非常に大きな言語だった。そして、大きすぎたことが使いづらさの原因となった。

(8‐1‐2)PL/Iは、予約語がないことを特徴とした。

(8‐1‐3)PL/Iコンパイラは、優れた最適化の機能を持っていた。

(8‐2)1970年代の小さな成功:Pascalについて

(8‐2‐1)「文脈自由文法」とは、自由奔放な文法という意味ではない。

(8‐2‐2)「再帰呼出し」を使うプログラムは、少し敷居が高いが、これを自然に読めることは、一人前のプログラマーへの第一歩である。

(8‐3)その後のプログラミング言語について

(8‐3‐1)1980年代の失敗例:Adaは、鳴り物入りで登場したが普及しなかった。

(8‐3‐2)1980年代の成功例:C言語は、広く使われてC++やJavaの土台となった。

(8‐3‐3)JavaとJavaScriptでは、使われる環境が違う。JavaScriptのプログラムは、パソコンで動作するので、サーバーの場合ほど性能が厳しく要求されない。

(8‐3‐4)「マークアップ言語」は、データのやり取りに使われる言語であり、普通のプログラミング言語とは少し異なる。

おわりに

著者について

本書について


以上3冊のKindle本の著者(潮 哲也)の紹介


数独解法プログラム!

数独(ナンプレ)の強力な解法プログラムです。

解法の説明書(PDF)を御提供しています。

数独解法プログラム

数独(ナンプレ)の強力な解法プログラムです。

・盤面のマスをピックすると入力パネルが現れるので、それを使って数字をセットしていきます。セットが終わったら、Goボタンで実行します。

・解法プログラムは、まず、盤面に配置済みの数字に基づいて、新たな数字を一つずつ決めていきます。この方法で盤面を全て決めることができれば、それが唯一の答です。

・難易度の高い問題では、この方法では新たな数字が決められなくなることがあります。そときは、仮置きを行って答えを探します。仮置きの結果、答えが一意に決まらない場合(可能な答えが複数ある場合)は、その旨を警告したうえで、可能な答えのうちの一つを表示します。

・解法プログラムは、Javascriptです。ソースプログラムを御希望の方は、左下の「連絡先」までメールで御連絡ください。

・解法プログラムは、Web上でも使えます。Webでは、セットした盤面をサーバのデータベースに一時的に退避しておくこともできます。

・Web上のプログラムは、無料で使えます。ユーザ登録も不要です。ただし、盤面に入力した盤面をデータベースに一時的に退避するためには、他のユーザが退避した盤面と区別するため、ユーザ登録が必要になります。

連絡先: メールアドレス