室脇慶彦のレビュー一覧

SIer の目線で IT システム開発や DX について色々と語られた本ですが、終盤は国や顧客への提言も含んでいます。このため、正直このタイトルで良かったのかなという気はする本です。
（まぁ、業界内部の人が読んで、そこから広めたいのかもですが）

業界内部の人間として色々と共感する部分は多く、ボリュ...続きを読むームはありますが読んで刺激になった本です。

「2025年の崖」問題に対して、老朽化したシステムの維持保守に多くのランニングコストを支払う必要がある現行の日本企業の体制を、どのように変革していくのか、ということを書いた本。

いわゆるＤＸ本だが、かなり読みやすく、またモノリスシステムからマイクロサービスへの移行を目指している企業の中で理解する場...続きを読む合には、有用な知識が詰まっている。

いわゆる技術者向けではなく、経営向けに書いているように思われ、基礎的な用語（TCP/IPやウォーターフォールなど）も含めて簡単な補足説明がつけられていることから、DXに関わるすべての人の入門書向けにおすすめ。

この本で、かなり5年後・10年後のIT業界のあるべき姿というのは想像出来た。
技術的な研鑽の方向性というよりは、キャリアの振り方としてどうするかに、個人的には参考となった。
事業部門の情シス社員は、以下の3パターンで身を振ることになると感じた。
①マイクロサービスによって成立し、大幅に人員が削減されたあと、多種多様なシステムの全体ガバナンスの守護者として残る情シス部員
②フロントサービス開発のため、内製開発要員として残る情シス部員
③従来のウォーターフォールモデルの開発経験を活かして、事業部門にＤＸ推進人材として転置される情シス部員

自分が今後もし情シス部門の中で頑張っていく場合、どのポジションを目指したいと思うのか、あるいは目指したくないかというのは、キャリアを積んでいく中で常に意識する必要があるだろう。
※この予想が5年後どうなったか、答え合わせはしてみたい。

SI業界の成り立ちの話が印象的でした
どんな背景でいまの多重請負構造ができあがってきたのか
多重請負構造自体が悪だと思ってきましたが、そんな単純な話ではないと思い直しました。

レガシーIT資産が日本で問題となりつつある背景のストーリーを整理するのにちょうど良い内容の本だった。展望や提言としては、主にDX推進にフォーカスが当てられていたため経営者の意識や企業体制といった話が少し多めだった印象。

基幹系システムの問題点をまとめた本が少ない中で、本書は日本のシステムが置かれた状況を踏まえて、今後のDX実現に向けてシステムがどの方向に進むべきかを鋭く突いている。今後の自分の検討に大いに参考になる内容だった。
ただ、誤字や、文章構成が少し乱れているところがあったのは気になった。

以下抜粋～
・「ソフトウエア」の特質で重要なことは、品質が堅牢であることだ。
「ソフトウエア」はハードウエアと異なり、暦年劣化を起すことはない。酸素にも水にも温度にも強いのである。バグが無い限り、基本的な部品は、理論的には永遠に利用可能である。
「主役はハードウエアからソフトウエアに変わる」

・米...続きを読む国では、ITベンダーとの契約は時間制である。ITベンダーは成果物の責任を負わない。

・システム形態は、①バッチ型、②オンライン型、③ゲートウエイ型、④Web型（インターネットでのシステム形態）の４種類である。

・SOE側の体制は、これまでのように要件を確定させることが困難であるため、ユーザー企業の社員がコミットするケースが非常に多くなり、ベンダー社員の比率を下げていく必要がある。せいぜい１対１。

・最も効果的なのは、社内でのサービス活用である。社内であれば、基本的には利用料は発生しない。
AWSでは、サービスをどうやって有効活用しているのか？必ず社内サービスを活用する強い動機が働く。

・この方式は、既にエストニア政府で実現されている方式である。エストニアでは、企業も個人情報を持つことなく、国のX-roadにアクセスする。国全体で最適化と個人情報の管理を行っている。

・マイクロサービス化によりAPI管理などが必要となるが、これに関しては、API-GWなどのマイクロサービスを支援するツール群がどんどん提供されているのが現状である。

・DXに対応した新たなビジネスモデルの構築とDXを支える既存ITシステムの再構築、この２つを実行していくことが、今の日本の経営企業者に求められている。

前者については、①現状を認識する、②新たな経営ビジョンを明確にする、③組織を変革する、の３つを実行することである。

・「自責化マインド」があって、初めて人間は成長する。

・ITベンダーのビジネスモデルは、①SI事業、②維持保守事業、③システム運用アウトソース事業、④ITサービス事業である。

キーワードは「ソフトウエア開発のサービス化」ではないかと考えている。

「2025年の崖」に代表される現在の基幹システムや従来型開発方式の限界など、日本のシステム開発に関わる課題を把握できる。また今後のトレンドとしてマイクロサービスが照会されている

日本の企業における現状の課題と、その課題解消のためどのようにDXを実践するか、ということについて述べられた本。
著者自身が大手SIerでPMとして活躍していた経験などから、日本のシステム開発の課題や、海外の状況はどうかなど広い視野で話が展開される。

マイクロソフトが、過去に大成功を収めた超巨大企業...続きを読むでありながら、変革に成功しているという話は非常に興味深かった。
また、マイクロサービスにより具体的にどのようにシステムを構築していくのかは、あらためて勉強していきたいと感じた。

示唆は多かった。今は心地よい慣れたやり方も、それに浸かって新たな波に乗り遅れると気づいたら死んでるイメージが付いた。

大規模プロジェクト、ウォーターフォール、管理マネージャーの終焉。小規模、アジャイル、プレイングマネージャーの誕生。SORからSOEへの人材シフトとそれに伴う組織変更の必要性。請負か...続きを読むら時間ベース準委任へのベンダーの関わり方の変化。準委任が主流になるが、受託契約における成果責任を除くなどの法整備の必要性。

　ＰＭのお勉強。関連図書では久しぶりのヒット。実務を担当している人は、目から鱗の金言が多かったのでは。ちなみに本書は、中規模クラスのプロジェクトを想定している。

・プロジェクト計画後の優先順位
　Ｑ＞Ｄ＝Ｃ

・プロジェクトのクリティカルパスは「基盤」

・たとえ違う会社の製品であっても、ちゃんと...続きを読む自分で理解し、自分で確認して、顧客がわかる言葉で説明する。それがＰＭの仕事です。

・独立した疎のタスクに落とす
　分解のポイントは、それぞれが独立していることです。隣にＡさんがいないと仕事ができないというのは、詳細化されているとは言わない。

・ＰＭＢＯＫの不十分な領域
　どうやってバグを出すか書いていない
　現行システムを想定していない
　ＰＭＢＯＫのメンテナンスは品質維持

・ＩＴプロジェクトの「三種の神器」
　サブシステム構成図
　　→サブシステムが疎になっているかどうかが大事
　　→人の能力の範囲を超えるとシステムは作れない
　スケジュール
　体制図

・課題の優先順位は3つの項目のバランスで決める
　「緊急度」「重要度」「拡大傾向度合い」　
　→ケプナー・トリゴー法

・ＩＴ部門だけでオーソライズした最初の概要設計では、リリース品質に至らず、プロジェクトは大混乱に陥っていた

・ＰＭはアプリケーションの主要なアーキテクチャ―を理解し、テストとメンテナンスの生産性を担保する

・パラメータ化のわな
　パラメータ化は巨大化するとトラブルへの体制が非常に低くなる

・日々エンハンスしているシステムにおいても、その歴史を整理しておくことをお薦めしたい。新規構築後の大幅なシステム化案件を年表形式で整理しておくのです。システム化のトリガーとなったビジネスの歴史と並べて整理しておくとわかりやすい。この年表は新規のメンバーがそのシステムを本質的に理解するのに役立つし、次の再構築において重要なインプット情報となります。

PMの指南本。久々にこういう内容の本を読んだ
気がします。
経験としては、著者の規定しているところの大規模の
プロジェクトは経験ありませんが、億～十数億程度規模
のPMを何度か経験させてもらいました。
PMの経験としては、数回１・２回以外は失敗していない
と思います。
この本を読むと、失敗しなかった...続きを読むProjectの時には、
書かれてあるいろいろな助言や考え方、PMの要点
みたいなところについて、大体が気にしていたような
気がします。ただし実行できたものばかりではなく、
こういうことが大事だよなあと思いながら、
できていない時もありますが。

それで、これについては自慢ではなくて、そういう要点
みたいなことは、ほとんどが、上司であったり、
プロジェクトのメンバであったり、パートナー企業の方であったり、から言われたこと、サポートして
もらったこと、サジェッションしてもらったことばかり
でした。
または、お客様からも指摘をいただいたり、お客様が
独自に(勝手に）そういう方向にもっていって
いただいたり、してもらったこともありました。

ということで、私の場合、PMの経験で得たのは
回りのサポートによってノウハウや経験をいただけた
ことばかりだったような気がします。
非常にラッキーであり、運がいい道筋を歩いてきたの
だと思います。
とてもありがたいことで、なんとか、この経験を
後ろに引き継いでいかなければと思っています。

PMBOK 的な細かい話ではなく、より実践的な話が多かった。
自分はいわゆるプロマネではないのだけど、リーダー的な立ち位置でも参考になる部分は多いと感じる。

マイクロシステムの優位性を学べた。特にエストニアのX-Roadの事例（ワンスオンリー・個人情報の分離）は参考になった

まあそうだよねって内容だったので、SE.PMとしての感覚が外れてないようで良かった。逃げてはいけない、とか持ち帰るって言えない、とかは気をつけないとなあと思った。

SoE（システムエンゲージメント＝顧客ロイヤリティ向上）とSoR（システムレコード＝従来の基幹システム）に関する記載や、2025年の崖、マイクロサービス、技術的負債に該当するオープンソースへの移行の必要性など、多岐に渡って昨今のIT関連ワードが描かれています。

自分なりにこの本をざっくり整理すると、
①ほとんどの日本企業のレガシーシステムは、維持だけでお金を使い尽くすだけでなく、今後付加価値を上げることができない、負債といっていい代物である

②その状態を打開していくこと、つまり2025年の崖を越えるには、企業内IT人材のマインドが変わらなければならず、そ...続きを読むの第一歩としてベンダー丸投げ体質から脱却することが必要である。そして、それに伴いITベンダーのスタンスも変わるべきである

③現在日本企業が抱える課題を克服できる技術は確立されつつあり、それをかたちにしたアプリケーションアーキテクチャが「マイクロサービス」である。マイクロサービスを導入すれば、技術的負債は解決され、DXに対応できる

と言ったところか。
よくわかるのだが、特に③が強引で、やや根拠に欠けるように思う。もちろん疎結合であるべきなのは同意。

加えてIT負債を放置するとDXは進まない論旨は、もっともに聞こえるのだが、それだけを理由として到底日本企業をIT投資へは動かせない。筆者は、IT負債→DXは進まないということを少し当然と捉えすぎてはいないだろうか。強いてこの論旨を深掘りすると、IT負債下の日本企業＝維持だけでお金が無い、データが汚く使いものにならない、よってDXは無理、と言うことか。やはりやや強引。IT負債はIT負債、DXはDX、という部分もあるのでは？と思うのだが。

名著『プロフェッショナルPMの真髄』を前著にもつ筆者は、マイクロサービスとかは実はどうでもよく、この本で日本のITパーソン、エンジニアにただエールを送りたかったんだ、と邪推してみる。

いい内容、ためになることが書いてあるのだと
思います。いまリアルにあるプロジェクトで苦戦している
状況では正直にす～っと入ってくる内容ではありませんでした。
耳に痛い内容ばかりといえばそういうことかも
しれませんが。