日経SYSTEMSのレビュー一覧
-
Posted by ブクログ
もう9年になってしまった組込エンジニアですが，読みました．
全般的に非組込エンジニア向けですが，気になったところをいくらか．
1. ITテクノロジーは常に進化しているので，何年目のエンジニアであっても最新の技術動向に対する広いアンテナを張っておくことが非常に大切
2. UXを考えるイマジネーション力は必要（ボタン配置とか）
3. 物事の根本原因を考えるためになぜなぜしようを繰り返す
4. アクティビティ図は要件定義の合意形成だけでなくシステムテストでのテスト項目抽出にも使用
5. ユースケース図は要件定義でのユーザーへのヒアリングなどを通して明らかにしたシステムの使用整理
6. デシジョンテ -
Posted by ブクログ
過去の日経SYSTEMSの記事を加筆・再掲載したもの。ジャンルや掲載時期はバラバラ。
要件定義やらExcelでのチェックシートやら、ザ・SEという感じ。雑誌特有の1ページで縦に3列に分かれる構成がなかなか慣れない。SPAについて急に出てきて驚いたが、そこは新鮮に読めた。
・誰もが認める本物のSE 合格ライン
・必要な機能を削り出す 要件定義の極意
・安・速・快の要件定義
・手戻りなし！業務フロー図作成の秘訣
・ビジネスモデリングのウソ・ホント
・システム要求仕様の固め方
・意図が伝わる設計書の作り方
・常識変わる Web 技術
・SE が知っておくべき UI デザイン
・千客万来のユーザー -
-
-
-
-
-
-
-
-
Posted by ブクログ
ITのお勉強。
「システム開発は本来、ユーザー企業の情報システム部門が主導して進めるべきものです。それができずにITベンダーに”丸投げ”してしまうことが、さまざまなトラブルの元凶であると10年ほど前から指摘し、解決策を模索してきました。
最近は、小規模な開発ではユーザー企業が主導する事例も増えてきましたが、数億円超の大規模な開発ではいまだに丸投げが多く、失敗が相次いでいます。これを根本的に解決するために私が得た解は、ユーザー企業側にシステム全体を統括するITアーキテクト、いわば『エンタープライズアーキテクト』を置くというものです。」
「SaaS APIを”探して使う”とその機能はスクラッチ -
-
-
-
-
-
-
-
Posted by ブクログ
提案書を作成する際の図解について書いている本。
基本的なことが多く、それほど目新しい情報はないが、
基本の振り返りとしてはタメになったかなあくらい。
【勉強になったこと】
・デザインの流れ
①伝えたいメッセージを決める
②データを収集し信頼性を確認する
③デザインコンセプトを考える
④伝えたいメッセージを改めて明確にする
⑤相手の目と心を引き付ける表現にする
⑥必要な情報だけに絞る
⑦視線の流れに沿うレイアウトにする
⑧文字がなくても理解できるようにする
・図解の構造は割と単純
過去→現在→未来
原因→問題→影響
改善策→効果
大分類−中分類−小分類 -
