日経SYSTEMSのレビュー一覧

いいね！

エンジニアからリーダーに昇格した時に読むと、良いと思う。助けられる事や、気付きにくいアンチパターンなどが書かれており、ためになります。

プロジェクト特性ごとのケーススタディ・傾向と対策をまとめた本。
どのケースも実際のプロジェクト内容を反映しており、
まさに現場を見てきた著者であることがよくわかる。

PM業務を行っているならどのトピックもまさに、
というものばかりであり、非合理なSIを続けないよう、
傾向と対策について自分なりの方...続きを読む針を考えたい。

PM業務に携わっており、以下のトピックについて
思う所があれば、読んで損はない良書。
個人的にも"あるある"が多く、ためになった。

■プロジェクト特性のトピック
1.小規模と大規模
2.パッケージとスクラッチ
3.アプリケーションと基盤　※業務アプリとシステム基盤
4.保守と新規　※保守開発と新規開発
5.内製と外注
6.既存ユーザーと新規ユーザー
7.立ち上げとクロージング　※プロジェクト
8.平常時と非常時　※プロジェクト
9.専任と兼任　※プロマネの関わり
10.提案・企画時と遂行時　※商談フェーズと受注後フェーズ
11.育成モードと相談モード　※プロジェクト要員の扱い
12.プロジェクトとプログラム ※プロジェクトマネジメントとプログラムマネジメント

マイクロサービスの粒度って、どう考えるの？が知りたくて手にした。ケースバイケースって事ね。では、そのケースがどんなものがあり、その時どういう粒度で分けるのかを勉強しよう。

薄い見た目からは想像できないほど、ボリュームがある内容。確かに若手ITエンジニアにはどれも必要な知識であるかもしれないが、到底全て頭に入らない。テクノロジーからエンジニアリング、マネジメントと幅広く扱っているので、自分が興味ある部分だけ読み込んで、他は軽く流すくらいでないとしんどい。最初は楽しく読み...続きを読む始めたが、途中からしんどくなってしまった。

上司の本。仕事と直結するし、既存資料の内容とも繋がる部分多し。本当の業務改革やる時や、提案書書くときの参考にしよう。

プロマネが陥り易いパターン毎に章立てされてます。
あるあるの場面すぎて、笑えない。。と言うか注意事項の
見直しに役立ちます

ずっとこんな本を求めていた。アジャイル開発や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」を取り上げてきました。

これはすばらしい。図・イラストが分かり易い。豊富な実例、それも失敗が載っているので参考になる。網羅性も高い。最新性もある。寄稿者の目線も高く元気も出る。

すべてのサービスが出てくるわけでは無いものの初めてAWSに触れるに人には良いと思う。公式のドキュメントのボリュームが多いので、初心者が全体を把握する取っ掛かりとして読みましょう。

ビッグデータの活用について、事例も交えて、技術、組織体制、データマネジメントなど様々な角度から書かれています。
若干技術よりであるところ、分析についての記述が少ないところから、読む人を選んでしまうかもしれません。
技術を中心に知りたい人には良。

IoTの市場がどうなっているのか全体像を把握するために購読。かなり網羅的に色々なトピックが扱われていて、満足の一冊。

読者の求めているものが何かによって感想は異なるでしょうが、個人的には良かったです。特にブレードサーバ、ストレージ、ディスク装置、テープ装置、ＵＰＳ、マルチコアなど、社内教育やe-learingなどでは意外と抜け落ちがちな部分が図解でカバーされている点が助かりました。他にもマルチコア、ＯＳ、ファイアウ...続きを読むォール、ディレクトリサービス、生体認証なども、分かっているようでちゃんと習うこともなかった部分なので、概略とはいえ通り一遍のことを知ることができて良かったです。

・ソの音程で話す
・テンションはふだんの3倍で。
・上あごの歯一列をみせるようにする。
・新たな取り組みをメンバーに受け入れてもらうには、なぜ必要か、の意識を共有すること。
・相手から無理なことを言われた場合、「拒否」ではなく相談、のスタンスで対応する。
・またそのようなとき、ええ、そうですね、ただ...続きを読む、とか、ええそうですね、わたしもそう感じてました、でも今は、のようにいったん受け止める。
・謝るときは謝りに徹する。理由とか状況説明は含めない。そしてとくに相手にとってどんな障害が発生しているかを聞くようにして、相手を真剣に気遣ってることを示す。
・しかるときは1対1で。しかるポイントを絞る、結果よりプロセスを叱る、人格や存在を否定しない、叱りっぱなしにしない。
・言い訳させないようにしかるには、たとえば「こんなことがあったぞ、だめだろ」ではなくて「このようなことがあるとどうなるだろ？・・じゃないかな」のように。

ヒューマンスキルは本を通じてではなく経験を通じて身につくものとは思うが、少しでもマシにしたいならば本を読むことも悪くない。

タイトルに「プロマネ」「ヒューマンスキル編」とあるが、「プロマネ」以外でも知っておくと役に立つビジネス上のスキルも書かれている。

自分のスキルを向上させるためのアドバイスも...続きを読む書かれており、プロマネになる以前に読んでおいても役に立つ内容であった。

よくある事例というか、こういう問題がどれも当てはまらない現場はないような気がする。外的要因も結構多くて未然に防ぐのは限界があるので、発生した時への備えや、傷を大きくしない緩和策を考える方が大事かも。

クラウド設計についての流れが載っており、通常の業務システム開発との違いが知れる意味でも一読の価値あり。
個人的にはクラウドのテクノロジーにすら触れられていなかったので、知った気になれた。
また、どういった企業がクラウドにどのようなシステムを乗せているかが一覧になっていて、興味深かった。

もう9年になってしまった組込エンジニアですが，読みました．
全般的に非組込エンジニア向けですが，気になったところをいくらか．

1. ITテクノロジーは常に進化しているので，何年目のエンジニアであっても最新の技術動向に対する広いアンテナを張っておくことが非常に大切
2. UXを考えるイマジネーション...続きを読む力は必要（ボタン配置とか）
3. 物事の根本原因を考えるためになぜなぜしようを繰り返す
4. アクティビティ図は要件定義の合意形成だけでなくシステムテストでのテスト項目抽出にも使用
5. ユースケース図は要件定義でのユーザーへのヒアリングなどを通して明らかにしたシステムの使用整理
6. デシジョンテーブルは特定の入力データの組み合わせに対する動作の技術漏れ検出に使用
7. ロバストネス図は要件定義と詳細設計のギャップを埋めるために使用する
8. シーケンス図は特に大規模システムでは実装レベルの情報を可視化することに非常に有用
9. 空・雨・傘の論理で論理構成の組み立て
　☞空をみると雨雲が覆い→夕方には雨が降ってきそうだ→傘を持っていくべきでは？
10. ビッグワード（人によって捉え方が異なる単語）は定量的表現に変更
11. 重複表現に注意
　☞まず最初に→最初，約5分ほど→約5分
12. カタカナを避ける
　☞サーチする→検索する，ローンチする→展開
13. なくても意味が通じる言葉を削除
　☞稼働停止というかたちをとる→稼働を停止する
14. 受動・能動をはっきり
　☞管理部門の調査は厳しく行われた→管理部門による調査は，厳しく行われた/管理部門に対する調査は，厳しく行われた
15. 資料に対して，時間がなくて/経験がなくてなど言い訳しない

過去の日経SYSTEMSの記事を加筆・再掲載したもの。ジャンルや掲載時期はバラバラ。

要件定義やらExcelでのチェックシートやら、ザ・SEという感じ。雑誌特有の1ページで縦に3列に分かれる構成がなかなか慣れない。SPAについて急に出てきて驚いたが、そこは新鮮に読めた。

・誰もが認める本物のSE...続きを読む　合格ライン
・必要な機能を削り出す　要件定義の極意
・安・速・快の要件定義
・手戻りなし！業務フロー図作成の秘訣
・ビジネスモデリングのウソ・ホント
・システム要求仕様の固め方
・意図が伝わる設計書の作り方
・常識変わる Web 技術
・SE が知っておくべき UI デザイン
・千客万来のユーザー体験「UX」
・設計ミスをなくそう　現場を救うレビューの秘訣
・IT 現場のチェックリスト