日経SYSTEMSのレビュー一覧
-
Posted by ブクログ
もう9年になってしまった組込エンジニアですが，読みました．
全般的に非組込エンジニア向けですが，気になったところをいくらか．
1. ITテクノロジーは常に進化しているので，何年目のエンジニアであっても最新の技術動向に対する広いアンテナを張っておくことが非常に大切
2. UXを考えるイマジネーション力は必要（ボタン配置とか）
3. 物事の根本原因を考えるためになぜなぜしようを繰り返す
4. アクティビティ図は要件定義の合意形成だけでなくシステムテストでのテスト項目抽出にも使用
5. ユースケース図は要件定義でのユーザーへのヒアリングなどを通して明らかにしたシステムの使用整理
6. デシジョンテーブルは特定の入力データの組み合わせに対する動作の技術漏れ検出に使用
7. ロバストネス図は要件定義と詳細設計のギャップを埋めるために使用する
8. シーケンス図は特に大規模システムでは実装レベルの情報を可視化することに非常に有用
9. 空・雨・傘の論理で論理構成の組み立て
☞空をみると雨雲が覆い→夕方には雨が降ってきそうだ→傘を持っていくべきでは？
10. ビッグワード（人によって捉え方が異なる単語）は定量的表現に変更
11. 重複表現に注意
☞まず最初に→最初，約5分ほど→約5分
12. カタカナを避ける
☞サーチする→検索する，ローンチする→展開
13. なくても意味が通じる言葉を削除
☞稼働停止というかたちをとる→稼働を停止する
14. 受動・能動をはっきり
☞管理部門の調査は厳しく行われた→管理部門による調査は，厳しく行われた/管理部門に対する調査は，厳しく行われた
15. 資料に対して，時間がなくて/経験がなくてなど言い訳しない -
Posted by ブクログ
過去の日経SYSTEMSの記事を加筆・再掲載したもの。ジャンルや掲載時期はバラバラ。
要件定義やらExcelでのチェックシートやら、ザ・SEという感じ。雑誌特有の1ページで縦に3列に分かれる構成がなかなか慣れない。SPAについて急に出てきて驚いたが、そこは新鮮に読めた。
・誰もが認める本物のSE 合格ライン
・必要な機能を削り出す 要件定義の極意
・安・速・快の要件定義
・手戻りなし！業務フロー図作成の秘訣
・ビジネスモデリングのウソ・ホント
・システム要求仕様の固め方
・意図が伝わる設計書の作り方
・常識変わる Web 技術
・SE が知っておくべき UI デザイン
・千客万来のユーザー体験「UX」
・設計ミスをなくそう 現場を救うレビューの秘訣
・IT 現場のチェックリスト -
-
-
-
-
-
-
-
-
Posted by ブクログ
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)経路計算など場所や人の関係性管理が得意な『グラフデータベース』がある。」
・ありがちな七つの勘違い
?ウイルスをみつけたらソッコーで退治→ウイルスは保管しておき敵の戦略を探る
?開発会社が自主的に対策してくれる→発注者と開発会社の双方に対策の責任がある
?事故発生！セキュリティベンダーを呼んですぐ対処→セキュリティベンダーが多忙ですぐには来てくれない
?最新セキュリティ機器なら”穴”はない→機器にはそれぞれ防御できる範囲がある
?ログを取っているから調査できる→必要な情報を必要な期間記録していないことが多い
?怪しいメールを開かないよう教育→開封率の評価だけでなく、体制の確認につなげる
?インシデントの情報開示は最小限→情報を公開したほうが有利に働くことがある
-
-
-
-
-
-
-
-
Posted by ブクログ
提案書を作成する際の図解について書いている本。
基本的なことが多く、それほど目新しい情報はないが、
基本の振り返りとしてはタメになったかなあくらい。
【勉強になったこと】
・デザインの流れ
①伝えたいメッセージを決める
②データを収集し信頼性を確認する
③デザインコンセプトを考える
④伝えたいメッセージを改めて明確にする
⑤相手の目と心を引き付ける表現にする
⑥必要な情報だけに絞る
⑦視線の流れに沿うレイアウトにする
⑧文字がなくても理解できるようにする
・図解の構造は割と単純
過去→現在→未来
原因→問題→影響
改善策→効果
大分類−中分類−小分類 -
