日経SYSTEMSのレビュー一覧

いくつかの見積もり手法を知れてよかったです。
ただ、複雑で、作成とレビューに膨大な時間が必要になります。それに経験値が高くないと作れないです。
半自動化でもない限りやろうと思わないです...
それ以前に、作っても評価できるクライアントがまれで、ほとんどのクライアントにとっては大量の項目と数字と記号が...続きを読む並んでいて、ちゃんとしてる感じがするだと思います。

顧客、チーム、組織を動かすためにそれぞれに必要なタスクとスキルを紹介。調整力とあるが、ここでいう調整には一見する言葉以上に様々な意味が含まれている。

6つの視点から残業を減らすための事例盛りだくさん。本題とは関係ないこと。どのジャンルのものでもそうなのだけれど、どうもこのムック本という版型はどうにも苦手だ。読みづらくてどうにも頭に入ってこない。見開きで見える情報量が多すぎることが原因なのだと思う。

思ったより内容は濃いけど、広く全体を見るような感じ。
ベンダー側でSEやPGをやっているエンジニア向けな感じなので、ユーザー系企業のエンジニアは終盤のプロジェクトマネジメントとかヒューマンスキルぐらいしか参考にならないかも。

うーん、まぁそういう観点は大事だよね！ということが
書いてある。どこまで実践でやるか案件によって粒度を見極められる人が上級SEってことなのかな。

ざっくりと目を通した。
どちらかというと手順書っぽい感じがして公式ドキュメントでも良さげ。
実践例としても多少使えるが、ちょっと細かすぎるような印象

内容は比較的易しめで、基本的な部分を学んでいく感じです。
2015年の本をようやく読みましたが、定期的な更新の是非など、少し古くなっている部分も見受けられました。このあたりの世界は流れが速いですね…

日経コンピュータの2016年頃からのAI関連の記事をまとめたムック。ざっと、現在のトレンドを流すには良い本。ムックなので、若干の古さは否めない。

若手ではないのですが、読んでみました。
内容はテクノロジ、エンジニアリング、マネジメント、ヒューマンスキルと幅広く、若手でなくても、気づかされることがある。

私がメモしたいところ：
・ストレージ関連
　-SANとNASの用途の違い
　-ブロック単位アクセスとファイル単位アクセスの違い
・分野ごとの...続きを読むプログラミング言語の人気
・各人の特性に合わせたコミュニケーション使い分け

ITのお勉強。

「システム開発は本来、ユーザー企業の情報システム部門が主導して進めるべきものです。それができずにITベンダーに”丸投げ”してしまうことが、さまざまなトラブルの元凶であると10年ほど前から指摘し、解決策を模索してきました。
　最近は、小規模な開発ではユーザー企業が主導する事例も増えて...続きを読むきましたが、数億円超の大規模な開発ではいまだに丸投げが多く、失敗が相次いでいます。これを根本的に解決するために私が得た解は、ユーザー企業側にシステム全体を統括するITアーキテクト、いわば『エンタープライズアーキテクト』を置くというものです。」
「SaaS APIを”探して使う”とその機能はスクラッチ開発で作らずに済む。そのことは『安い』『早い』『うまい』という三つのメリットをもたらす。
　安いとは、初期コストの低さだ。…
　早いとは、システムの開発期間を短くできることだ。…」
　うまいとは、スクラッチ開発では難しい機能を実現できることだ。」
「面倒なのは非機能面の検証だ。セキュリティ、サービス継続性、サポート体制、利用規約などが主なチェック項目となる。…
　例えばセキュリティでは、認証方式の確認が必要だ。多くのSaaS APIは、エンドユーザーの操作で発行される文字列『トークン』を使って認証する。『SaaS APIの認証方式は種類が多い。主要なものだけでOAuth、OpenID Connect、API Keyの3種類がある。さらにそれぞれで複数の実装方法がある』」
・ハイブリッドクラウドのユーザ企業が続々
　全社的な業務システム→アンリツ、エイチ・アンド・エス、ガリバーインターナショナル、ソニー銀行、日本通運
　消費者向けWebサービス、社内業務システム→富士ゼロックス
「データ連携の壁は大きく三つある。すなわち、(1)連携、(2)コントロールできない停止、(3)API仕様、だ。」
「CAP定理とは分散システムにおける定理で、一貫性の『C』、可用性の『A』、ネットワーク分断耐性の『P』のうち、同時に満たせるのは二つに限られるというものだ。」
「DBの処理を分散し、アプリ側で『失敗したらやり直す』アプローチでデータの正しさを確保して速さを獲得するやり方をこの記事では『ゆるハヤ設計』と呼ぶ。」
「RDBMS以外の新たなタイプのデータベースには、高い拡張性や可用性を備えるものが多数ある。それらは『SQLだけではない』という意味から、『NoSQL』と呼ばれる。一般にNoSQLを扱うDBMSは、RDBMSが持つトランザクション処理機能、およびテーブルを突き合わせる機能(結合)を実装しない。これにより、分散処理を可能にし、高い拡張性や可用性を実現している。
　主なNoSQLには、(1)キー(標識)とバリュー(値)の組としてデータを管理する『KVS』、(2)テーブル構造の定義が不要な『ドキュメント指向DB』、(3)列単位での処理に特化した『列指向データベース』、(4)経路計算など場所や人の関係性管理が得意な『グラフデータベース』がある。」
・ありがちな七つの勘違い
?ウイルスをみつけたらソッコーで退治→ウイルスは保管しておき敵の戦略を探る
?開発会社が自主的に対策してくれる→発注者と開発会社の双方に対策の責任がある
?事故発生！セキュリティベンダーを呼んですぐ対処→セキュリティベンダーが多忙ですぐには来てくれない
?最新セキュリティ機器なら”穴”はない→機器にはそれぞれ防御できる範囲がある
?ログを取っているから調査できる→必要な情報を必要な期間記録していないことが多い
?怪しいメールを開かないよう教育→開封率の評価だけでなく、体制の確認につなげる
?インシデントの情報開示は最小限→情報を公開したほうが有利に働くことがある

日経BPで掲載された、ビッグデータの活用事例やビッグデータ周辺ツールの紹介記事を集めた内容。参考にはなるが正直タイトルの割には内容は薄く感じた。

図解本は数あるが、システム企画、提案書はその目的からもよく図解をするため、そのノウハウ本があるのは助かる。どちらかというと体裁や見た目を整理するために使える。

本自体が大きすぎて手軽に読めない。
手軽に読めないから繰り返し読みづらい。
手軽に読めるサイズだったらしばらく手元に置いておきたいかも。

調整力とあるが、人に対してどう影響力を発揮していくか、という話。個別には大事なことがたくさん書いてあるが、あちこちから拾ってきたノウハウ集の感が否めない。

作りながらAWS/サーバーの構造を学習することができる。ただ、これAWSではどうやるんだっけ？に対応する本であって、これでサーバーの勉強はできない。

導入事例が記載されている。
cloudにしたからと言って、契約やオプションによってはオンプレミスより安くなるとは限らないという点が注意というありきたりなことが分かった。
また、AWSように構築したシステムは、オンプレミスへの移行が難しいという点も、まあその通りだと思う。
そして、AWSは名前の通り、...続きを読むサービスを提供しているので、同時接続ユーザ２人とか、そういうものっていう、今までとは考え方を変える必要がある。
AWSのサーバは落ちる前提でっていうのも、納得。使いどころを間違えないように、費用対効果を考えるってことですね。

ほとんどこの分野について知らない人が
ざっくりとした雰囲気を知るにはいい本だと思った。
テーマはいいんだけど、一つ一つのトピックが浅くて、
すでに運用を始めようとしている段階の人が読むにはちょっと物足りないだろうと思う。

提案書を作成する際の図解について書いている本。
基本的なことが多く、それほど目新しい情報はないが、
基本の振り返りとしてはタメになったかなあくらい。

【勉強になったこと】
・デザインの流れ
　①伝えたいメッセージを決める
　②データを収集し信頼性を確認する
　③デザインコンセプトを考える
　④伝え...続きを読むたいメッセージを改めて明確にする
　⑤相手の目と心を引き付ける表現にする
　⑥必要な情報だけに絞る
　⑦視線の流れに沿うレイアウトにする
　⑧文字がなくても理解できるようにする

・図解の構造は割と単純
　過去→現在→未来
　原因→問題→影響
　改善策→効果
　大分類−中分類−小分類

20150621 システム企画・提案について分かりやすく説明されている。自分のものにするには真似でも良いのでやって見る事だと思う。やり方を通して毎回答えは変わってくるのがわかれば大丈夫。

システム発注を行う際にベンダーが提示する金額が妥当か？を見極めるために、見積もりの勘所が記載されたユーザ向けの本。

文章構成自体は読みやすく適宜図も挿んでいるのですが・・・具体的事例にかけるため、「なるほど！」とところどころあるものの実際に生かせる部分があるかはちょっと微妙。

ただしシステムの見...続きを読む積もりはどのような事が行われているか？という部分には、中々は発注する（ユーザ）側は見えないと思うのでそういった概略を掴むにはよいと思います。

あと参考資料として掲載されていた、生産性データや公開資料は知らなかったのでここは非常にためになりました。