revamping

2部構成になっており、前半はアジャイル開発の基本的な考え方、後半はスクラム・XP・UP・Evoの各開発スタイルについて記述されています。

アジャイル開発というと、契約が分割されてないと無理、とか、顧客が付きっきりで開発に参加してもうらうのは無理、とよく言いがちです。僕も最初はよくそう思ってました。

例えば、本書の中に『「予想可能な製造」というパラダイムは、ソフトウエアには合わず、そのパラダイムに根ざしたプラクティスや価値はあまり役に立たない』という部分があります。

確かに実際は思うように行かないことが多いのも事実なのですが、ビジネスを行っていく上で計画は必要であり、それに根ざしているITが予想不可能というわけにもいかないので、うまく合わせていく必要があります。

そういった溝がある中で、顧客に対して価値を提供できることが自分たちのビジネスの根幹であり、その溝を小さくする為の手法の1つがアジャイル開発だと考えています。

だから、最近は自分たちの開発が「アジャイル開発」かどうかは気にならなくなりました。ただ、良い手法は取り入れたい、それだけです。

• 「予想可能な製造」というパラダイムは、ソフトウエアには合わず、そのパラダイムに根ざしたプラクティスや価値はあまり役に立たない
• イテレーションが始まる直前に最善の判断にもとづいて適応型計画(状況に適応した計画)を立てること
• イテレーションのタイムボックス化とは、イテレーションの終了日を固定し、変更させないというプラクティスである
• 反復型ではこの不確実性に対応するため、費用や工数やスケジュールの詳細な見積りを、2,3回のイテレーションが終わるまで待って(おそらくプロジェクトの10%から20%が終わる頃に)作成する
• 固定価格の入札で進化型の見積りを行う場合に関して、IID手法の中には(UPなど)、プロジェクトを2つの契約フェーズに分けて実行し、それぞれタイムボックスを適用したイテレーションを複数回行うよう、進めているものがある
  • 最初のフェーズは、比較的短い固定時間・定額の契約であり、2,3回のイテレーションを行って、早期のうちに部分的なソフトウエア開発および進化型の要求分析を行うことが目標である
  • フェーズ1の成果物を確認して行う為、フェーズ2の見積りに役立つ質の高いデータが集まり、しかもプロジェクトのソフトウエア開発も進む
• アジャイル宣言
  • プロセスやツールよりも、個人相互作用
  • 包括的なドキュメントよりも、動作するソフトウエア
  • 契約交渉よりも、顧客との協調
  • 計画に従うことよりも、変化に対応すること
• アジャイル原則
  • 最も重要なことは、価値のあるソフトウェアを早い段階から継続的に納品し、顧客を満足させること
  • たとえ開発が進んだ後であっても要求の変更を歓迎する。アジャイルなプロセスとは、顧客の競争優位のために変化を生かすもの
  • 動くソフトウエアを頻繁に納品する。その間隔は2、3週間から2、3ヵ月月の単位で、短いほど良い
  • ビジネスサイドの人間と開発者が、プロジェクト全体を通じて毎日一緒に仕事をする
  • やる気のある個人を中心にプロジェクトを構築する。環境を整え、必要なものを提供し、仕事をやり遂げてくれる信じること
  • 開発チームに対して、あるいは開発チーム内で情報を伝えるために最も効率的かつ有効な方法は、直接の対話である
  • 動くソフトウエアこそが進捗を測る一番の尺度である
  • アジャイルなプロセスは、継続的な開発を促進する。スポンサー、開発者そしてユーザが一定のペースを無期限に保たなければならない
  • 技術卓越性と優れた設計に常に注意を払うことが、アジャイルさを向上させる
  • 簡潔性(できるかぎり作業をしないですませる術)こそ本質である。
  • 最も優れたアーキテクチャ、要求、設計は、は自己組織化されたチームから創発されるものである
  • チームは定期的に、より効果的な方法を検討し、自分たちのやり方を調整し適合させる
• アジャイルプロジェクトマネジメント
  1. クライアントにとって有用なものを出荷する。何が重要視されるかを確認する
  2. 利害関係者が熱心に参加するように育てる
  3. リーダーシップ-コラボレーション方式を採用する
  4. 有能且つ協調的なチームを作り上げる
  5. チームが意思決定できるようにする
  6. タイムボックスを短く区切ったイテレーションを行って、早期にユーザ機能を出荷する
  7. 適応性を高める
  8. 技術的卓越性を擁護する
  9. プロセスに準拠するための作業ではなく、出荷するための作業を重視する
• オーガスティンとウッドコックの6つのプラクティス
  • 指針となるビジョン: プロジェクトの指針となるビジョンを打ち立て、言葉と行動の両方から継続的に補強する
  • チームワークとコラボレーション: 関係とコミュニティを通してコラボレーションとチームワークを活性化する
  • シンプルなルール: スクラムやXPなどのようにチームの指針となる一連のプラクティスを設定し、サポートする
  • 情報の公開: プロジェクトマネジメントなどの情報を公開してアクセスできるようにする
  • 軽いタッチ: 自律的チームの創発的な振る舞いを促進するために最低限の管理だけを行う
  • アジャイルな自戒: ビジョンを補強し、ルールをそのまま、あるいはカスタマイズして適用し、人の言うことに耳を傾ける
• 健全な開発チームは複雑適応系である。一羽一羽の鳥は限られた中の単純なルールに従って振舞っているが、マクロの視点では、群れは秩序と集団の創発的振る舞いを示す
• プロジェクトの要求変更の割合は、中規模で25%、大規模では35%を超える
• スプリントバックロググラフ(タスクの推定残作業時間をグラフに纏めたもの)を用いる
• 広域デルファイ法を使った見積りを検討する
• ムーア式ビジョン記述
  • (ニーズや機会の記述)であるところの
  • (対象顧客)向けに作られた
  • この(製品/システム名)は(製品/システムカテゴリ)である
  • これによって(主な利点、つまり購入せざるをえない理由の記述)が得られる
  • 主な競合製品/システムとは異なり
  • この製品/システムは(主な差異の記述)という点で優れている

初めてのアジャイル開発　～スクラム、XP、UP、Evoで学ぶ反復型開発の進め方～
	日経BP社 2004-09-09 売り上げランキング : 23894 おすすめ平均 はじめて手にしたアジャイル本 アジャイル開発してないの？ 本当のソフトウェア開発者に必要なもの Amazonで詳しく見る by G-Tools

SIの仕事をしていく中で、歳を重ねる毎に様々なことを経験していきます。反面、プログラムをジックリ書くというのが年々難しくなってきていると感じてます(プログラマとしては、もう定年を過ぎているので:-))。だからこそ生産性には拘らなければなりません。

個人的にはどちらかというとツールに拘らないスタンスを取ってきました。あまりツールと生産性の相関を気にしてきませんでしたし、何より、ツールに拘らないで仕事をしている人達の仕事に憧れた、というのが単純な理由でした。

ただ、『ソフトウェア職人気質』にて「欠けているのは、既存のツールを使う為のスキルと能力」といった趣旨の記述があり、何となく気に留めていました。

そんな中で本書が紹介されているサイトを見て、偏った考え方を直す為にも一回は読んでみようと思い、購入しました。(ペンホルダーのついでですが)

結果として、本書内で紹介されているツールを導入したり、または別のツールを使って実現したりすることで、色々と整理することができました。特にデスクトップが。それだけでも読んだ甲斐がありました。

前半はツールの話が中心で、後半はコードデザインやコーディングについて記載されていますが、これはこれで別の書籍として纏められている方が良いと思いました。

• 気をちらす要因を排除する
• 「沈黙の時間」を作る
• ナビゲーションより検索
• ルートビューを使う
• 仮想デスクトップを使って、作業毎にデスクトップを切り替える
• 自動化する為にスクリプトを書く
  • Excelで複数のワークシートを開く
• Webアプリケーションの操作記録にSeleniumを利用する
• バッチファイルではなくWindows PowerShellを使う
• コードを基に図を生成する
• コード解析を使う
  • PMD
  • Panopticode
• Calendarの代わりにJodaライブラリを使う
• DSLを導入する(Neptune)

プロダクティブ・プログラマ -プログラマのための生産性向上術
	島田 浩二 (監訳) オライリージャパン 2009-04-27 売り上げランキング : 34387 おすすめ平均 Javaに偏っているのが -1 気軽に読めて役に立つ、中級？ソフトウェア開発者向けの良書 Amazonで詳しく見る by G-Tools

近所の図書館にあったので読んでみました。

アジャイル系の開発プロセスを解説した本よりも一段上から、ソフトウェアの品質やプロセスについて記載されています。トヨタの話も出てきますが、トヨタ式が素晴らしいとかそういう話ではなく、製造と開発の違いも踏まえた上で良い部分をソフトウェア開発に用いようというスタンスで、面白かったです。

• 「原則」が、ある分野についての指針となる考えや洞察であるのに対し、「プラクティス」は、原則を実行するために、何をするか
• ソフトウェア開発の7つの無駄
  • 未完成の作業のムダ
  • 余分なプロセスのムダ
  • 余分な機能のムダ
  • タスク切り替えのムダ
  • 待ちのムダ
  • 移動のムダ
  • 欠陥のムダ
• プロジェクトのトラッキングが複雑なら、おそらくそのシステムには、ほかの種類のムダが大量にある
• 開発(レシピを設計する)
  • 実践利用に適していることが品質の基準
  • バリエーションがある結果は善
  • 反復は価値を無味出す
• 高レベルの設計と詳細な解法の間を行き来する
• フィードバックを増やすことが、問題のあるソフトウェアプロジェクトや環境に対処する唯一の効果的な方法
  • 欠陥をためこまず、コードを書いてすぐにテストすること
  • ドキュメントや詳細な計画を増やすのではなく、コードを書くことによって考えが正しいことを確認する
  • 多くの要求をユーザから集めるのではなく、どのようなことができるかをユーザに見せ、ユーザから入力を得ること
  • どのツールを使うかを入念に調べるのではなく、組織内での候補を3つ選び、それらを試してみる
  • システム全体を一度に置き換える方法を見つけようとするのではなく、レガシーシステムにウェブインターフェースをつける、という新しいアイデアを試してみる
• あきらかに多くのリソースを費やして、多数のコンセプトを検討する。それにより、開発プロセス全般に渡って多数のオプションを選択できる状態に保ち、サブシステムのプロトタイプを多数作り出す
• ウェブサイトの構造について合意できない場合、2,3バージョンを用意し、それぞれ異なる画面遷移やページレイアウトを行うようにして、最終的に最高の機能を寄せ集めることで、優れたユーザビリティの点数が取れる
• 深さ優先のシーケンシャル開発と、広さ優先のコンカレント開発がある
• ソフトウェア開発でのコミットメントを遅らせるための戦略
  • モジュールを使う
  • インターフェースを使う
  • パラメータ化する
  • 抽象化を使う
  • シーケンシャルプログラミングを避ける
  • フレームワークは成功した実装を集めた中から抽出されるべきで、推測で作らない
• ソフトウェア開発の7つのシンプルルール
  1. ムダをなくす
  2. 学習効果を高める
  3. 決定をできるだけ遅らせる
  4. できるだけ速く提供する
  5. チームに権限を与える
  6. 統一性を作り込む
  7. 全体を見る
• チームでプロセスをチェックする
  1. 何があなたをスピードダウンささているのか、また、何がいい仕事をするじゃまをしているのか
  2. もっと速く、よく、安くするためには、何が役立つか？いいプラクティスと悪いプラクティスを作ること

リーンソフトウエア開発～アジャイル開発を実践する22の方法～
	平鍋 健児 日経BP社 2004-07-23 売り上げランキング : 22163 おすすめ平均 和訳が酷過ぎ ムダを排除する 自分で考えるための本です Amazonで詳しく見る by G-Tools

『熊とワルツを』が面白かったので、もうちょっと専門的な書籍にチャレンジしてみることに。

ソフトウェア開発プロジェクトの、ということで踏み込んだ内容を期待したのですが、別の分野でもそのまま当てはまるような一般的な内容でした。

ただ、リスク特定の手法や分析方法については『熊とワルツを』よりも詳しく紹介されており、その点で実践寄りです。

• プロジェクトの主要な原因は、管理的課題65%、技術的課題35%
• 組織でリスクを管理する仕組みを作る
• リスク軽減シナリオ
  • プロジェクトの範囲を定める
  • 初期のシナリオを作成する
  • シナリオを分析する
  • 問題と課題を位置づける
  • 主要リスク領域
  • 軽減戦略を作成し、公表する
• リスクパラダイム
  • 特定
  • 分析
  • 計画
  • 追跡
  • 制御
• 計画を策定する
  • リスク発生時の不測事態態対応計画を作成してリスクの影響を軽減する
  • 製品の設計あるいは開発プロセスを変更することによりリスクを回避する
  • リスクを受容する。問題が発生した場合は受け入れ、特別な行動をとらない
  • 多くの情報を取得し、リスクの特性をさらに研究する
• リスク特定の手法
  • プレーンストーミング
  • SWOT分析
  • マップ
  • チェックリスト
  • ピアインタビュー
• リスク対応にかかわる3つの重要な要因
  • 要員数、期間、費用、影響部門数などのプロジェクト規模
  • 技術的熟練レベル、用いられる新技法、設計の技術的困難性や類似プロジェクトの経験等
  • 明確な要求、確定的で確定な成果、プロジェクト期間中における仕様変更がないなどのプロジェクト構造
• リスクレビューのタイミングは早い方が良いが、リスクについて十分に考察されていない時点で行ってもいけない
• デシジョンツリー分析の6つの基本ステップ
  1. なされるべき決断とその決断により起こりえ結果を示す
  2. 各不確定事象に発生確率を指定する
  3. 起こりえる結果に対して価値を割り振る
  4. それぞれの代替案について期待値を計算する
  5. なされるべき決断に関連するソフト要因を解く手する
  6. 最善の代替案を決定する
• 定量市場調査
  • リスクについて、どのようなデータを収集する必要があるか
  • データをどのように取得すべきか
  • どのように実行するか
  • 結果をどのように解釈するか
  • 結果をどのように利用するか

ソフトウェア開発プロジェクトのリスク管理
	富野 壽 構造計画研究所 2006-05 売り上げランキング : 389288 Amazonで詳しく見る by G-Tools

前に読んでいた本の中で『ピープルウェア』について記述があって、確か会社にあったなぁと思って探すものの見つからず、手近にあった本書を読んでみました。

• 目の前にある証拠をもとに、そのスケジュールが可能だと信じる権利があったのか
• リスクのないプロジェクトには手をつけるな
• リスク管理は、問題が発生する前の、抽象的な概念の段階で対策を考えるプロセス
• リスク管理の反対を「危機管理」といい、問題が発生した後に何をするべきかを考えることを意味する
• リスク管理の各構成要素
  • リスク発見: まずリスクに関するブレストを行い、次にリスクを選別する。さらにプロセスを継続する仕組みを導入する
  • エクスポージャー分析: それぞれのリスクが発生する確率と、それによる影響を数量化する
  • 危機対応管理: リスクが実現した場合に、何をするべきかを計画する
  • 軽減: 計画した危機対応措置が必要な時に実行でき、効力を持つように、移行前にとるべき対策をとる
  • 継続的な移行監視: 管理するリストを追跡し、実現しないかどうかを監視する
• 不確定性を口に出すことができない企業文化の中では、リスク管理はできない
• リスクについてできること
  • 避ける
  • 抑制する
  • 軽減する
  • かわす
• リスクを評価するツールを使う(RISKOLOGY)
• ソフトウェア・プロジェクトのコアリスク
  • 内在的なスケジュールの欠陥
  • 要求の増大(変更)
  • 人員の離脱
  • 仕様の崩壊
  • 生産性の低迷
• リスクを特定するためのプロセス
  • 破滅的結果についてのブレスト
  • シナリオの構築
  • 根本原因の分析
• インクリメンタル開発
  • 開発計画及び詳細設計と、インプリメンテーションが時間的に重複しないようにする
  • 作業分割を最低レベルまで行い、進捗メトリックを計測する
• ショーストッパー(権限を越えたリスク)を見極める

熊とワルツを - リスクを愉しむプロジェクト管理
	日経BP社 2003-12-23 売り上げランキング : 45937 おすすめ平均 リスク管理のコア。スッキリ理解したい方に リスク管理とは リスクを理解するなら、これ１冊で十分！ Amazonで詳しく見る by G-Tools

以前『ソフトウエア開発プロフェッショナル』を読んだ際に、amazonでレコメンドされていて、レビューの内容が良かったので読んでみました。

「55の真実」としつつも、その内容には否定的な表現が多く、改善方法等について明確に記載されているケースがあまり無く、個人的には忙しい時間を使ってまで読むことをお勧めしません。まだ目の前の問題に対する改善方法を考えた方が有意義でしょう。

• ソフトウエアの世界は、人的資質の研究が最も重要
• 人がじっくり考えた結果の見積りは、かなり精度が高い
• 実現できそうもない工程を何とか間に合わせるあまり、プログラムの完全性や品質を犠牲にする
• プログラマを制御することに重点を置くマネジメントでは、最高のプロジェクトになりえないし、生産性も低くなる
• 「成功したプロジェクトとは何か」を定義できないならば、整理が必要な大問題が残っていることになる
• 大規模な再利用は当分うまくいかない。本来、この問題は、ソフトウエアの多様性に根ざした解決困難な問題なのである
• 非常に狭いドメインでは、大規模な再利用が成功する確率は大きくなる。色々なプロジェクトをまたがったり、異なるドメインを横断するような再利用は、失敗する可能性も高い
• 対象となる問題の複雑度が25%増加するたび、ソフトウエアによる解法の複雑度は100%上昇する
• インスペクションをしっかり実施すれば、実機でプログラムを走らせる前に、最高90%の不良を摘出できる
• 優れたプログラムが備えるべき7つの属性
  1. 移植性
  2. 信頼性
  3. 効率
  4. 人間工学(UI)
  5. 検証性(プログラムを容易にテストできる特性)
  6. 理解容易性
  7. 変更容易性
• 規模が大きく、基幹ソフトウエアの開発において、プロジェクト内の規則をきちんと定めたケースでは、アジャイル開発よりも効果があるケースもある

ソフトウエア開発 55の真実と10のウソ
	日経BP出版センター 2004-04-08 売り上げランキング : 44755 おすすめ平均 ソフトウェア開発の暗黙知を明文化 一人の技術者としての魂 ソフトウェア開発に携わる方は必ず読むべき名著 Amazonで詳しく見る by G-Tools

以前、仕事でマルチスレッドで動くアプリケーションを開発していたのですが、同期化の部分が思っていた以上に難しく、改めて勉強しなおせねば、と思っていました。

特に困難なのは、どういう構造で同期を取るのが良いかを決めること。同期を取る部分はもちろん言語(Java)にその機構があるので簡単なのですが、全体を考えた上で同期化の構造をスッキリした形で持たせるのはスキルが必要です。

今回はそのあたりを学習するのに最適な本として、『Java言語で学ぶデザインパターン入門【マルチスレッド編】』を選びました。

序盤は結構簡単で、今までスレッドプログラミングをしたことがあれば経験的に知っていることがパターンとして記載されています。後半は、概念は知っているけど実装したことはなかったり、概念自体もよく知らなかったり、というものが大半を占めていました。

他にもJava言語に備わっているスレッドや同期化の詳細な説明や、java.util.concurrentを使った場合の解決方法、Swingのイベントディスパッチまわりの話など、色々と勉強になります。

• Single Threaded Execution
  • クリティカルセクションを見極める
• Immutable
  • finalを使った宣言
  • インスタンスフィールドがimmutableかどうか
• Guarded Suspension
  • Spin Lock
  • ガード条件が満たされていなければスレッドを待たせる
  • ガード条件のテストにwhileを、待たせる為にwaitを使う
• Balking
  • ガード条件が満たされていなければ実行を中断
  • ガード条件のテストにifを、balkにはreturnかthrowを使う
• Producer-Consumer
  • Channel役を配置する
  • データの安全性をChannelが管理する
  • 安全にデータを受け渡しする部分では、Guarded Suspentionを使う
  • executionのキャンセル可能
• Read-Write Lock
  • Readのみであれば排他は不要
  • Readしている時はWriteできない
  • Writeしている時はRead/Writeができない
  • Writeしている時はRead/Writeができない
  • Read/Writeを管理するReadWriteLock役を置く
• Thread-Per-Message
  • 処理の順序を気にしないときに使う
  • 戻り値が必要な場合はFutureを使う
  • スレッドは要求の度に起動する
• Worker Thread
  • 処理を実行するスレッドを予め起動しておく
  • ワーカスレッドに渡すリクエストは継承を意識する
  • リクエストをワーカスレッドに安全に渡す(Producer-Consumer)
  • invocationとexecutionの分離
• Future
  • 処理の実行結果を後から取得する
  • 処理が非同期(Thread-Per-MessageやWorker Threadの場合に用いる
  • 実行結果取得時にはGuarded Suspensionを使用する
• Two-Phase Termination
  • どこで処理が中断されても安全に終了する
  • Thread#stopを使わない
  • Thread#isInterruptedを使わない
  • 終了要求が来たことをラッチを使って判断する
• Thread-Specific Storage
  • Thread Localの他に、スレッドの属性として保存する方法もある
  • スループットに主眼を置かれているというよりも、
    • プログラムの構造を変えずにすむ
    • 排他制御が表に出てこないので、誤りをおかす危険がすくない
    という再利用性に主眼を置いている
  • コンテキストは処理に本当に使われている情報が何かが曖昧になる危険性がある
• Active Object
  • 自分固有のスレッドを持つ
  • 非同期メッセージの実現
  • Scheduler役を置く

  増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編
  	ソフトバンククリエイティブ 2006-03-21 売り上げランキング : 29630 おすすめ平均 デザインパターンとは型紙（かたがみ）のことです。 分かりやすさがいい マルチスレッドを利用するなら事前に読んでおくべき本 Amazonで詳しく見る by G-Tools

レビューの時間を有効活用したい、という動機から読んでみました。というのも、レビューの時間はなかなか効果的に時間を使えていないと感じるからです。

正しいレビューの仕方を知ることがその一番の近道だと考えたのですが、読み進めていくうちに、レビューの意義は多様な側面(品質保持の他に、情報伝達、教育、意識統一等)があって、実施意義を品質保持のみをターゲットとした場合のROIという切り口だけでは捉えきれないと考えるようになりました。

まずはレビューの時間を意識的に捉え、時間当たりの成果をより多く出せるようなプラクティスを身に付けていきたいと思います。

• 手戻りは総開発工数の40～60%を占める
• ROIは、データが十分蓄積されて自分自身のROIが示せるようになるまでは、ある程度信じるしかない
• 欠陥修正のコストは増幅効果があるため、最大のレバレッジ効果が得られるのは、初期フェーズのプロジェクト成果物のレビュー
• 「今、時間が無いと言うなら、いつ再び時間があるのだろうか？」
• レビューをプロジェクトのスケジュールもしくはWBSに組み込むようにする
• 成果物全てをインスペクションするのは無理なので、最も効果の出そうなところにインスペクションのリソースを振り分ける
• 作業成果物が大きくて全体を調べることができない場合、あるいは時間が限られている場合は「選択的サンプリング」が妥当である
• ミーティング中に欠陥をどうやって修正するかを決めるのに、約1分以上かけてはいけない

ピアレビュー―高品質ソフトウェア開発のために Karl E.Wiegers 日経BPソフトプレス 2004-02 売り上げランキング : 86489 Amazonで詳しく見る by G-Tools

正直、あまりタイトルには惹かれなかったのですが、思ったよりも面白かったです。

ソフトウエア開発についての本なのですが、技よりも工程や品質にフォーカスしており、十分な品質を持つソフトウエア開発を行う為のエンジニアリング、さらにプロセスや組織だけでなく資格・免許といった仕組みまで提唱されています。

記述されていることはソフトウエア開発を行っていれば一度は聞いたことがあるようなことなのですが、日々開発をしているとどうしてもこういった部分に意識が向かなくなってしまうので、こういう本を読み返すのも大事。

• 「作ってから直す」開発方式は、どんな分野のプログラムでも、ごく小規模のプロジェクトでない限り、効率は上がらない
• プロとしてのソフトウエア開発は「エンジニアリング」であるべき
• ソフトウエア・エンジニアリングを適用すれば、バグを作り込まなくなるし、バグが潜り込んでも、早く、簡単に見つけて修正できる
• エンジニアリグの欠乏こそが、美的可能性を制約する
• ソフトウエアをエンジニアリングの専門分野として扱うことは、ソフトウエア開発を真のプロのレベルに引き上げる、効果的な方法である
• 再利用可能なプロジェクトの成果物の一部
  • アーキテクチャそのものと、ソフトウエアの開発手順
  • デザイン・パターン
  • 要求定義そのものと、そのエンジニアリング手段
  • ユーザ・インターフェース要素と、その設計手段
  • 見積もり値そのものと、見積もり手段
  • 計画するためのデータ、プロジェクト計画、および設計手順
  • テスト計画、テスト・ケース、テスト・データ、およびテスト手順
  • 技術的レビューの手順
  • ソース・コード、システム構築手順、およびシステム統合手順
  • ソフトウエア構成管理手順
  • プロジェクト完了報告、およびプロジェクト・レビュー手順
  • 組織の構造、チームの構造、および管理手順
• プロジェクト成果物の目標
  • バグの数を最小にする
  • 顧客満足度を最大にする
  • レスポンス・タイムを最小にする
  • プログラムの保守性を上げる
  • プログラムの拡張性を上げる
  • システムの堅牢性を上げる
• プロジェクトの目標
  • 工程の短縮
  • 出荷日程の予測精度向上
  • 低コスト
  • プロジェクト人員数の最小化
  • 開発途中での仕様変更に対応できる柔軟性

スティーブ・マコネル 日経BP社 2005-01-20 売り上げランキング : 62161 おすすめ平均 アバウトな契約に悩める技術者へ 「トム・デマルコ本が難解に思えるならこちらから読んでみては」 問題の解析に優れている Amazonで詳しく見る by G-Tools

先週から今週にかけて、クラウドに関する書籍を3冊読みました。

このところ社内外でクラウドに関する話をよく聞くようになり、実際にどういったことができるのか、どういうメリットがあるのかを、SIerのエンジニアである自分の立場から他のエンジニアや顧客に対して話ができる必要があると考えています。

クラウドという言葉は抽象的ですが、この3冊を読んだ後に感じたのは、クラウドをHaaS、SaaS、PaaSの3つの軸で考え、それらをどのようにソリューションの中で活用していくか掘り下げていくことが、これからのSIerのエンジニアにとって必要であると考えました。

1つは、インフラコストをサービスの規模や品質により見極める力を持つこと。Amazon EC2のようなHaaSを利用した方がコスト面、リソース面で有効なケースは出てくると思います。

1つのサービスに必要なシステムを全部作成するのではなく、SaaSを活用することにより作るモノ/作らないモノを分け、作るモノについて注力する、という姿勢も重要になってくると思います。その為には、ソフトウェア開発という括りではなく、自分達にとって何が得意なのかを提示できなければなりません。

PaaSは正直まだ分かりませんが、今回読んだ本の中ではGoogle App EngineとSalesforceのForce.comがよく出てきました。これらのプラットフォーム上でアプリケーションを構築することがユーザ企業によって価値を生むようになってきていると思います。まずは何ができるのかを知る為に手を出していこうと思います。

クラウド化する世界
	村上 彩 翔泳社 2008-10-10 売り上げランキング : 3591 おすすめ平均 この世界観が参考となった。 時代の流れを感じることのできる一冊 類書の中ではダントツにいい Amazonで詳しく見る by G-Tools

クラウド グーグルの次世代戦略で読み解く2015年のIT産業地図
	石田 晴久 國領 二郎 インプレスR&D 2009-02-26 売り上げランキング : 2464 おすすめ平均 クラウドの全貌というよりかはクラウド時代までのいきさつになっている ICT業界のマーケター向きかなと思います。 良い本だと思います。 Amazonで詳しく見る by G-Tools

クラウドの衝撃――IT史上最大の創造的破壊が始まった
	野村総合研究所 城田 真琴 東洋経済新報社 2009-02-06 売り上げランキング : 570 おすすめ平均 デファクトスタンダードになるのかも ■最新の業界動向に短時間でキャッチアップできます！ 世の中が変わるかもしれませんね Amazonで詳しく見る by G-Tools

和田秀樹の“最終最強”知的生産術 (Mainichi Business Books)
	和田 秀樹 毎日新聞社 2008-06-28 売り上げランキング : 289498 おすすめ平均 相変わらずの「単一的」価値観は健在の様子です 今までのまとめ 満足な1冊 Amazonで詳しく見る by G-Tools

最近はビジネス書よりも技術に関する書籍(特にタイトルに「クラウド」とついているもの)を優先的に読んでいます。

そんな中で、たまたま目に留まったのがこれ。ということで、気になったところを。

• 頭がいい
• 問題解決能力が高いかどうかで決まる。より幅広いシチュエーションの問題に対して、より妥当な答えが出せる人こそ頭がよい。

• 記憶のプロセス
• 第一段階 - 理解と注意
• 次の段階 - 貯蔵(保持)
• 次の段階 - 出力(想起)

• 推論の幅を広げる
• 他人の立場に立ってものを考えてみる
• 今の考えと逆を考えてみる

• メタ認知
• メタ認知的知識 - 自分の知識状態(得意・不得意)を知る
• メタ認知的活動 - 自分の認知パターンをモニターし、自分の思考や知識状態を修正する
• メタ認知力をつけるには、習慣や態度がもっとも大切

• 理系発想
• 実験や統計的な裏づけのほうが大切だという考え方をすること。試しにやってみてうまくいけば、それを全店でやってみる。駄目ならすぐにやめて別の仮設を試してみる

• 傾向と真の命題を区別する
• 100%そうなのか(真の命題)、単なる傾向や確率の高さを示すものなのかを区別する

• 知的体力の三要素
• 仮説や提案をいくつも思いつける知性
• 実際にあれこれと試してみる体力
• うまくいかない際に、それでも続けられる精神力

• 不安
• 振り回されるのではなく、それとつきあっていればいいのだという逆転の発想があれば、そう怖いものではない

• 感情のコントロール術
• 食事において、より多くの品目を取る
• 肉を取らなさ過ぎると、セロトニン不足になりやすい
• うまくいかない際に、それでも続けられる精神力

• 自分なりに知識を加工して得られた新たな知識は、自分のオリジナルの引き出しとなる
• スキマ時間にやれる仕事を持つ
• 時間あたりの効率性を意識する
• 外面を変える、行動を変えることは予想以上に人間を変える
• 一冊の本を速読するのではなく、一部を熟読する
• 出力できる知識を増やす方法としては、それを実際に出力してみることである
• 自分の長所を前面に出せば、できるように見せるのはそう難しくない
• 負けから学ぶ
• 相手の自己愛を傷つけない、相手の顔に泥を塗らない