日経SYSTEMSのレビュー一覧
-
-
-
Posted by ブクログ
プロジェクト特性ごとのケーススタディ・傾向と対策をまとめた本。
どのケースも実際のプロジェクト内容を反映しており、
まさに現場を見てきた著者であることがよくわかる。
PM業務を行っているならどのトピックもまさに、
というものばかりであり、非合理なSIを続けないよう、
傾向と対策について自分なりの方針を考えたい。
PM業務に携わっており、以下のトピックについて
思う所があれば、読んで損はない良書。
個人的にも"あるある"が多く、ためになった。
■プロジェクト特性のトピック
1.小規模と大規模
2.パッケージとスクラッチ
3.アプリケーションと基盤 ※業務アプリとシステム基盤
4.保守と新規 ※保守開発と新規開発
5.内製と外注
6.既存ユーザーと新規ユーザー
7.立ち上げとクロージング ※プロジェクト
8.平常時と非常時 ※プロジェクト
9.専任と兼任 ※プロマネの関わり
10.提案・企画時と遂行時 ※商談フェーズと受注後フェーズ
11.育成モードと相談モード ※プロジェクト要員の扱い
12.プロジェクトとプログラム ※プロジェクトマネジメントとプログラムマネジメント -
-
-
-
-
-
Posted by ブクログ
ずっとこんな本を求めていた。アジャイル開発やDevOpsを進めるには、具体的なツールが必要であり、そのツールを実際の企業の事例を交えて豊富に解説してあり、実務上のイメージをしながら学ぶことができた。
・Dockerとは
仮想化技術の一種で、Linuxの環境を複数のグループに区切り、それぞれ独立したサーバーのように利用可能にする。区切ったグループを「コンテナ―」と呼ぶ。ハイパーバイザー型の仮想化とは異なり、Linuxカーネルは共用する。ゲストOSを起動する必要がないため、オーバーヘッドが小さく、素早く起動できる。
・Serverspecとは
サーバーの構成を確認するテストフレームワーク。対象サーバーにSSHでログインして、インストールされたソフト、ソフトやOSの設定、起動しているプロセスなどが仕様通りかどうかを確認し、その結果を出力する。対象サーバーにエージェントソフトをインストールする必要がない点、テスト対象サーバーの構築手段、環境構築ツールに依存しない点が特徴である。
・中部電力のグループ企業の基幹系システム開発・運用プロジェクト
開発プロセスには、大規模システム開発向けのアジャイル開発手法であるDAD（ディシプリンドアジャイルデリバリー）を採用。さらに仕組みとして、米IBMのALM（アプリケーションライフサイクル管理）ツール「Rational Team Concert」を2013年5月に導入した。…
RTCを本格運用して以降、チームに目覚ましい成果が出ている。例えば、ビルドを自動化した2013年9月は200本のプログラムを改修してリリースしたが、設定作業ミスなどによる障害が1件もなかった。
RTCチケット管理だけに利用していた同年5月は、追加開発のプログラム本数は60本にとどまり、しかもこのうち10本は後で修正作業や顧客からの問い合わせ対応が必要になった。月間の改修本数を単純計算すれば、生産性を3倍超に高めた計算になる。
・DevOpsツールが効果を発揮するシーン
保守開発の現場の開発プロセスを詳しく見ると、DevOpsツールが効果を発揮するシーンは六つ挙げられる。(1)リリース作業、(2)テスト、(3)稼働状況の監視、(4)メンバー同士の連携、(5)ソースコードに対応する文書類の管理、(6)利用部門の要望の把握・管理である。
・回帰テストを自動で実行（TIS）
回帰テストは、バージョンアップのたび、すべてのソースコードに対して同じテストを繰り返し実行する手法だ。CIツールである「Jenkins」などを使って静的/動的テストを自動化し、漏れなくテストを実行するようにした。
・アサヒグループの人材ローテーション
体制の統合が難しい場合、人材をローテーションすることで複数組織間の協業体制を作る。これを狙っているのが、アサヒグループのIT部門だ。前述の通り同部門は大きく三つの組織に分かれているが、期限付きの出向などを実施し、同じ組織に長く居続けないようにしている。「複数の組織で働いた経験があれば相手への配慮もできる。協業が進みやすい」
・ITの現場で見られる残念な光景の原因
一つは、利用部門が既存システム改善（保守開発）の要望を十分に吟味しないまま依頼してくること。もう一つは、開発担当あるいは運用担当が依頼された要望をそのままシステム化してしまうことだ。つまり、既存システム改善における要件定義のやり方に、大きな原因がある。
・CIとは
アプリケーション開発においてソフトウェアを日常的に結合（ビルド）すること。開発支援ツールを使って、コンパイルやテスト、統合テスト環境へのデプロイ（配信）作用を自動化できる。
・CIのサイクルを現場に根付かせる
もともとCIは、アジャイル型の方法論の一つである「XP」で提唱されたプラクティスである。このため短い期間で開発・テスト・実装を繰り返すアジャイル型の開発プロセスと相性がよい。というより、アジャイルではCIの導入はほぼ必須だ。とはいえ、ウォーターフォール型の開発プロセスには適用できないかといえば、そんなことはない。ウォーターフォール型でも導入は可能で、同様のメリットが得られる。
基本的に、アジャイル型とウォーターフォール型でCIのプロセスやルールに違いはない。ただしデリバリーまで含めたCDと呼ぶ手法を実践する場合はアジャイル型の採用が基本となる。
・CIとCDの違い
CIとCDの違いは、デリバリーまで含めるかどうかだが、この違いは極めて大きい。ソフトウェアプロセスエンジニアリングの岡氏は、「CDではアジャイルの採用は必須。ユーザーを巻き込んだ受け入れテストも頻繁に繰り返す必要がある」という。
CIはプログラミング、テストのフェーズで開発チーム内で回すサイクルである。これに対してCDは、要求通りのソフトウェアであることを検証するフェーズが加わる。それが受け入れテストであり、受け入れテストを頻繁に繰り返すには、ユーザーがプロジェクトに積極的に参加しなければならない。また受け入れテストの仕様をテストの前に記述するというテスト駆動開発も実践する必要がある。これらを実践すれば、必然的にアジャイルとなるのだ。
・先の見えないプロジェクト
開発するソフトウェアの仕様がなかなか固まらない場合です。発注者と受注者のコミュニケーションを活発にして、段階的な開発で失敗のリスクを抑えます。こうした開発を実施したい場合に活用できるのが、ウォーターフォールにアジャイルの要素を取り込んだ「アダプタブル・ウォーターフォール開発」です。
具体的には、ソフトウェア開発をいくつかのバージョンに区切って段階的に開発します。各バージョンにはチケットを関連付けます。Redmineにはチケットの状況をバージョン別に一覧する「ロードマップ」機能があります。マイルストーン（バージョンの期日）ごとに、チケットの進捗や新たなタスク（チケット）がないかといった状況をロードマップで管理します。
・DevOpsとは
開発者と運用担当者が協力し合いながら、ビジネスの価値を実現していくという概念です。概念なので、定まった方法論があるわけではないのですが、一般的には「人の観点」と「ツールの観点」の二つの側面から開発と運用の現場を改善していきます。人の観点とは、ゴールの設定やコミュニケーションの見直しによって、開発者と運用担当者の組織間の垣根を無くすことです。…
IT現場を改善するツールは多岐にわたります。本連載では、バージョン管理ツールの「Git」、CIツールの「Jenkins」、ビルドツールの「Maven」、テストツールの「Selenium」、仮想環境構築ツールの「Vagrant」、プロジェクト管理ツールの「Redmine」、サーバー構築・設定管理ツールの「Chef」、統合監視ツールの「Zabbix」、ログ収集ツール「Fluentd」を取り上げてきました。
-
-
-
-
-
-
-
Posted by ブクログ
・ソの音程で話す
・テンションはふだんの3倍で。
・上あごの歯一列をみせるようにする。
・新たな取り組みをメンバーに受け入れてもらうには、なぜ必要か、の意識を共有すること。
・相手から無理なことを言われた場合、「拒否」ではなく相談、のスタンスで対応する。
・またそのようなとき、ええ、そうですね、ただ、とか、ええそうですね、わたしもそう感じてました、でも今は、のようにいったん受け止める。
・謝るときは謝りに徹する。理由とか状況説明は含めない。そしてとくに相手にとってどんな障害が発生しているかを聞くようにして、相手を真剣に気遣ってることを示す。
・しかるときは1対1で。しかるポイントを絞る、結果よりプロセスを叱る、人格や存在を否定しない、叱りっぱなしにしない。
・言い訳させないようにしかるには、たとえば「こんなことがあったぞ、だめだろ」ではなくて「このようなことがあるとどうなるだろ？・・じゃないかな」のように。 -
-
-
-
