細川義洋のレビュー一覧

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

システム開発を依頼する側の視点から描いた一冊。「欲しいシステムを手に入れる」ことの難しさを、ストーリー仕立てで説明・解説している内容。

物語仕立てで進むため読みやすく、理論一辺倒にならない点が印象的でした。業務フローの資料には仕組みだけでなく「それを実現することで何が良くなるのか」まで示すこと、依頼して終わりにせず最後まで伴走することなど、どれも基礎的ながら、忙しさの中で傍に追いやっていたかもな点が多々ありました。

特に、今は直接プログラムを書かない立場にいる私にとっては、主人公の戸惑いや葛藤がどこか他人事に思えませんでした。システム開発は技術だけでなく、人間関係や思いの共有が土台にあるという当たり前のことを、あらためて思い出した気がします。

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

･ユーザ企業側の心構えみたいな必要なものがつかめた
･ストーリー仕立てでわかりやすいけど、こんなにうまくことは運ばない(解決しない)だろうな、きっと

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

・感想
小説チックにシステムの要件定義のイロハをまとめている書籍。
とてもわかりやすくてとても良い本だなと思います。
新卒や入門編としてとてもおすすめ。

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

素人がシステム開発プロジェクトを担当した際にはどんなことが起きるのか何に注意したらよいかについての基礎知識として一読しておくと良いかもしれません。開発の全体像が物語形式で把握でき、ユーザーがベンダー任せではいけない理由がよく分かります。

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

読み終わった
最初、「登場人物がすんごい変人ばっかりだな…マジか？世の中こんな人なの？」
ってなった。読み進めるうちに
「あるな、こういうの。」
ってなった。
休み明けに部署内に紹介しよう

システムを「外注」するときに読む本

小説仕立てで様々な失敗しそうなITプロジェクトの例をあげながら改善ポイントを主に発注側の視点で、時には受注側の気持ちも織り交ぜつつ解説する。ストーリーの後にサマリーが合ってまぁ分かりやすい。

ただ小説の内容があまりにチープ...今どきそんなキャラいないだろ...昭和のおっさんのファンタジー。若い20代女性社員を「お前」とか呼んだらコンプライアンス違反ですよ...

成功するシステム開発は裁判に学べ！ ～契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

会社のシステム変更の勉強のため購入。

ベンダー、ユーザー、両方に通じる内容なので役に立った。
基本的な知識、心構えなど。

システムを「外注」するときに読む本

要件定義過程において必要なポイントをストーリー形式で解説。先回りしてのリスク管理とリスクをユーザーとベンダで共有できる仕組みが必要。ベンダ側の注意点として気をつけなければいけないのは、合意なく成果物の開発に着手すること。成果物は随時合意することが重要。ユーザーのPJ目的に照らして、本件を超えた全社的な目標を頭に入れつつ会話をすることが+αに繋がるか。

システムを「外注」するときに読む本

導入企業側からITシステム構築プロジェクトのマネジメントのトラブルになりがちなところをストーリー仕立てで紹介した本。
入門書としては悪くない。実際の判例にも触れて、どのようなトラブルが起きうるか紹介している。顧客とのやり取りに慣れてない人だと得るものが多そう。
以下、参考になった点。
業務フローには業務を行う上で懸念事項や疑問点も書き込む。業務フロー図に、現状の問題点だけじゃなくて、自分たちのいいところとか残したい業務も書いて貼っておく。

システムを「外注」するときに読む本

小説仕立てで読みやすい。Sl業界の知識が薄くてもすんなり読める。
ストーリーに陳腐な部分もあり、そこに気を取られてしまうこともあったが・・・。
各章の始まりと終わりにポイントがまとまられており、その部分で理解が深まる。
システム開発が実際どうやって進んでいくのか？というイメージも持てる。
逆にエンジニアの方が読むには物足りないのではないかと思う。

全体を読んでの感想としては、システム開発は関係者全員が我が事感を持って分け隔てなく意見を言い合って進めましょう、ということだと思う。
それを行う上で、目指すべき姿、改善しなければならない点、どうやって進めていくかという計画やアクションにおけるプロトコルを事前にしっかり決めておくことが大事なのだと感じた。

なぜ、システム開発は必ずモメるのか？

池袋のジュンク堂で気になりかなり前に買った。
キャラクターとのやり取りを通して、システム開発の難しさを学べる。理想ではあるが、分かりやすく為になる。
何箇所か絵に誤植があった。

・・・・・・
■要件定義
要件定義と契約が結びついてないと
ユーザー「自分たちの希望を全て叶えてくれるはず」
ベンダー「費用と期間でできるところまでやる」
って争いになり泥仕合になる
→大事なことは要件と契約書をちゃんと繋げておくこと
→でも要件は開発中に変わるから、契約書の別紙にしておいた方が良い

IT紛争って、お互いの責任分担のモレやちょっとした理解不足、確認不足が原因のものが多い

業務プロセスから業務要件におとしても
例外プロセスが抜ける可能性があるから注意
→オペレータから学ぶ

■テスト
システムの品質を守る最後の砦は、受け入れテストではなく、それに向けたテストケースやテストデータのレビューだと思ってる。
→要件定義直後とテスト直前に行う

ベンダのテストは網羅的でしっかりしてるけど、セキュリティや時間の都合で実データを使わずに行うことが多いから、想定外のデータへの漏れが見つかることがある

テスト計画書
・体制、要員
・テストに必要な資源
・使用ツールと仕様と使用法
・進捗把握方法
・開始、完了基準
・テストデータの準備
・結果の検証方法、明確、妥当
・前提条件、環境
・テスト計画に影響するような大きな設計変更がないか
・十分なロングラン、耐久テスト
・リグレッションを計画したか
・パフォーマンスを計画したか
・ストレステスト（入力量、処理量、処理時間）
・見やすさ、使いやすさ
・ユーザとベンダの役割分担、協力事項
・テストデータ・本番データの管理方法は明確か

■プロ管
→リスク管理こそプロ管で最も重要
プロジェクト管理はベンダの責任
リスクの抽出や対応策の検討らユーザがやる
→ガイドしてあげるのはベンダ

・進捗は着手と完了で管理する
→記述、コードレビュー、後修正、単体テストと修正

PMの上司の役割
→体調管理や、PMの能力を図ること
→→足りなければ新規参画者をつけたり、指導したりする
→継続的にやる
→1日一度は会話する時間を取る

破綻したプロジェクトほど、苦しいため
「この会議だけは無事におわりますように」と目先だけ考えがち
目的は、安く早くうまくやり、企業の生産性向上や、コスト低減を実現すること
→プロジェクト中、ユーザーに笑顔でいてもらうことじゃない

・ステアリングコミッティ
→双方トップの会議
→スケジュール変更、中止、再開などを決める権限を持っている

・思考の継続性
→その人しかやれない仕事はその人にやってもらう

SPI =ev/pv
→一以下なら遅延、一以上なら前倒し

ユーザーは綺麗なプログラムが欲しくて
多額の投資をするわけじゃない
システムによってもたらされる経営的なメリットを求めているのよ。

世界初のコンピュータ
→諸説あるが
→ENIAC 1946年間
→アメリカの陸軍の大砲の弾道計算のために設計された
→プログラムを組み替えることでさまざまな計算ができた

最初の自動車
→1769年にフランスで作られた
→フランス陸軍の技術大尉キュニョー
→時速約3キロしか出なかったらしい笑

外字
→元々コンピュータに登録されていない特別な文字

・錦の御旗
→戊辰戦争の際薩長軍が、自分たちこそ官軍であると示すために、朝廷に頼んで作らせてもらったものが有名。
→精神的な効果が大きく、旧幕府軍は大いに動揺したと言われる

システムを「外注」するときに読む本

小難しい要件定義に関する本かと思っていたら、物語調で大変読みやすい。
システムを外注するというのは、決してシステム部門だけに降りかかってくる話ではないので、知っておいて損はないです。
分厚くみえますが物語調なのでサクッと読める。おすすめ。

システムを「外注」するときに読む本

生産管理システム構築の過程でシステム構築のポイントを整理したくて読んでみた書籍。
小説風のストーリー仕立ては、それほど面白くないが、要件定義のポイント整理やベンダとの向き合い方、リスク管理など各章のまとめページは、今後のシステム構築で迷ったときの立ち返るポイントリストとして使えるものだと感じた。

成功するシステム開発は裁判に学べ！ ～契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

一般的に世の中に出てこない話題だし、ちょっと調べてみてもなかなか情報を得づらい内容が一冊にまとまっているので、ITに関わる身としては知っておいたほうがいいなと思う一冊。

そういえば、この間の7pay問題は開発元とまるくおさまったのだろうか・・・。

システムを「外注」するときに読む本

システムを外部のベンダーさんと一緒に開発したことは何度か経験あるけども、
外注をしておまかせすれば、思った通りに夢を叶えてくれるわけではない。
注文した側も、きちんと責任と役割を分担して進めていかないと、いけないんだよね。

これって、システムに限らず人にものを頼むときもそうだと思う。
丸投げして、あとでチガーウ！と言われても、頼んだ方の責任も大きいよね。

システムを「外注」するときに読む本

　「業務フローに社員の感情を書き込め」にはハッとした。全体最適を考えるとどうしても負荷が増える部門が発生してしまうが、特に経営陣に説明するときに使えると感じた。他にも「ベンダー内のトラブルも言ってもらえるような関係性を構築する」などシステムを外注している情報システム部門担当者は一読しておくと良い。,　当然、ストーリー通りにいかないケースは多数あるが、この本を「基本」とすると良いのではないか。

システムを「外注」するときに読む本

情報システム構築を発注する側の人間が奮闘する内容でオムニバス形式のストーリ仕立てになっています。（ただしメインの登場人物は同じ）

世の中に出回っている情報で、発注側の視点に立ったときに参考になるものは意外と少ないのが現状です。
本書は、システム企画や構築を外部に発注する経験が少ない人や、経験はあるけれどなかなか上手くいかずモヤモヤを抱えている人向けに、システム導入プロジェクトを推進するにあたって重要なポイントが提示されています。
また、発注側だけでなくベンダーが果たすべき義務についても触れており、ベンダー側の人が読んでも得るものは多いと思います。

ただ、本書はあくまで要点を紹介しているだけなので、プロジェクトを回すための実務レベルの情報については、それ相応の書籍等をあたることをお勧めします。

システムを「外注」するときに読む本

業務要件定義：新しくシステムを導入して、どんな業務を実現するのかを決める作業
システム要件定義：業務要件定義書に書いたことを実現するために、システムが持つべき機能を書き出す作業
いずれも発注者が行う作業
特に業務要件定義は、発注者自身が全面的にリードしないといけない。社外ベンダには分からないことが多いため
業務要件定義書を書くより前にやらないといけないこと、社内全体の業務を俯瞰して、全体最適の視点から、業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成すること。
業務フロー図を作成すること。業務フロー図には、さまざまなメモ書きをしていかないと、最終的には役に立たないシステムになる

機能要件：システムができること・できないことを具体的に明らかにする作業。この不備はトラブルの原因のワースト1

まずは現状のながれ、As- Isと、その問題点を明らかにして、それを解決する業務の姿、T o-Beを書く、２つの業務フロー図並べて見ることで、業務のプロセスや組織をどう変えるのか、そしてどの業務をシステム化すべきかが初めて明らかになる

業務を行う上での懸念事項や疑問点も書く
業務フロー図の段階でシステム化する範囲を決めてしまうと、本当はシステム化すべきではない業務を範囲に入れてしまったり、逆にシステム化すべき部分が未検討になる
その他は使わない
システム化するのは、効果が明確に説明できるところだけ
システム化する範囲は、本当にそこをコンピュータでやるべきか、何度も考えて決める
会社は各部門が有機的につながってこそ機能するということが、この1枚の図でよくわかる

社員やお客様さんがどんなふうに喜ぶのか、ちゃんとイメージして作ったか
自社の最大の強みにもっとこだわる
大事なことは社長かはも言うべき
サイトを使う人全員の立場になりきって、喜びとか苛立ちとかの感情を含めて全部共有しないと、本当に役に立つサービスを作ることはできない
業務フロー図には目的を書き込んでおく
懸念と理想も出来る限り書いておく

第1章まとめ
・システムを導入する目的を忘れないように書き留めておく
・業務フロー図には、懸念事項や課題とモレなく書き込む
・システムを導入して誰が喜び、誰が困るのかも書き込む
・システム化の範囲は、効果が明確に説明できる部分に限る
・システム担当者自身が、業務をどのように改善するかという「意識」を持つ
・システム担当者となったからには、自分の思いは隅に置いて、改善の推進者になりきる

要件定義で最低限確認すべきチェックリスト
134p135p
フィーリングマップ
139p

第2章まとめ
・システム担当者にはシステム化する対象業務の知識が必要
・発注者側の責任で頓挫したプロジェクトの賠償責任は発注者にある
・システム担当者がモチベーションを上げるにば、経営者の視点でシステム導入の意味や目的を考えてみるとよい

プロジェクト管理には、全体の工数の10％程度を見込んでおくべき
176〜179p
第3章まとめ
・ベンダの示すプロジェクト管理項目と管理工数が十分かを見極める
・信頼できるベンダは、自社内リスクも含めて、ユーザーと共有する
・要件の変更や追加を、ただ承諾するベンダにはプロジェクト管理義務違反の恐れがある
・ベンダの示すリスクを、まずは傾聴する

第4章まとめ
・システム担当者は、往々にしてエンドユーザーの協力が得られず孤立する
・エンドユーザーにヒアリングするときには、最低限の業務知識を得ておくこと
・難解なIT専門用語を使わない
・相手が忙しい中、時間を割いてくれていることに感謝する
・システム担当者が他部門と調整するときには、その上司がフォローと支援をする
・エンドユーザーの協力を得るには、システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
・経営陣は、システム開発も社員全員の本業であるという意識づけとしくみの改革をすること

264〜269p
第5章まとめ
・ベンダにリスクを開示させるために、発注者側は真摯に聞く姿勢を忘れない
・ベンダのリスクもプロジェクトのリスクと同じように、発注者側が知るべきことと認識する
・ベンダのリスクは発注者側から引っ張り出す
・定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、プロジェクトに合わせて設定した評価軸でベンダのリスクを評価する

287p
第6章まとめ
・期限までに要件を決めきれないことは日常茶飯事
・要件定義工程完了前に、「今後、どうすべきか？」を改めて話し合う、チェックポイント会議を開く
・ベンダへの質問に遠慮は不要。
技術でも業務でもどんどん聞くべき。
そうすることで、ベンダ側の知識が醸成されることもある
・たとえパッケージソフトを使うときでも、どうしてもこだわりたい自社の長所は捨てずに入れ込む
・発注者とベンダは、お互いに「自分たちのほうが損している」と思う程度がちょうどいい

システムを「外注」するときに読む本

前著と同様にITシステムを発注するときのトラブルを物語形式で紹介している本。典型的なケースがいくつか取り上げられている。ITシステムの発注に特有なことも多いが、開発やデザインを外注するときにも該当することが多い。社内では、自分ではりかいできないようなことでも、とにかく金を払って外注すればやってくれる、のような考え方がいまだに多く、相変わらずトラブルが続発している。

システムを「外注」するときに読む本

「なぜ、システム開発は必ずモメるのか？」の著者と同じということに気づかず、タイトルのみで手に取った。
前回が訴訟ベースで深掘りが浅い部分が多かったが、本書では事例ベースの話で、よりわかりやすかった。APPENDIXの内容は、プロジェクト発足当初に皆で意識合わせしておいた方がよいものが多く、プロジェクトマネージャーを任せられた方が最初に読むにはいいボリューム感の本だと感じた。
ただ、前書と同じく、ラノベ形式でストーリーが進行するので、ベンダーとの契約内容など、もう少し詳しい部分は別の本で補完する方がよさそうである。