室脇慶彦のレビュー一覧
-
-
-
-
Posted by ブクログ
「2025年の崖」問題に対して、老朽化したシステムの維持保守に多くのランニングコストを支払う必要がある現行の日本企業の体制を、どのように変革していくのか、ということを書いた本。
いわゆるＤＸ本だが、かなり読みやすく、またモノリスシステムからマイクロサービスへの移行を目指している企業の中で理解する場合には、有用な知識が詰まっている。
いわゆる技術者向けではなく、経営向けに書いているように思われ、基礎的な用語（TCP/IPやウォーターフォールなど）も含めて簡単な補足説明がつけられていることから、DXに関わるすべての人の入門書向けにおすすめ。
この本で、かなり5年後・10年後のIT業界のあるべき姿というのは想像出来た。
技術的な研鑽の方向性というよりは、キャリアの振り方としてどうするかに、個人的には参考となった。
事業部門の情シス社員は、以下の3パターンで身を振ることになると感じた。
①マイクロサービスによって成立し、大幅に人員が削減されたあと、多種多様なシステムの全体ガバナンスの守護者として残る情シス部員
②フロントサービス開発のため、内製開発要員として残る情シス部員
③従来のウォーターフォールモデルの開発経験を活かして、事業部門にＤＸ推進人材として転置される情シス部員
自分が今後もし情シス部門の中で頑張っていく場合、どのポジションを目指したいと思うのか、あるいは目指したくないかというのは、キャリアを積んでいく中で常に意識する必要があるだろう。
※この予想が5年後どうなったか、答え合わせはしてみたい。 -
-
-
-
-
Posted by ブクログ
以下抜粋～
・「ソフトウエア」の特質で重要なことは、品質が堅牢であることだ。
「ソフトウエア」はハードウエアと異なり、暦年劣化を起すことはない。酸素にも水にも温度にも強いのである。バグが無い限り、基本的な部品は、理論的には永遠に利用可能である。
「主役はハードウエアからソフトウエアに変わる」
・米国では、ITベンダーとの契約は時間制である。ITベンダーは成果物の責任を負わない。
・システム形態は、①バッチ型、②オンライン型、③ゲートウエイ型、④Web型（インターネットでのシステム形態）の４種類である。
・SOE側の体制は、これまでのように要件を確定させることが困難であるため、ユーザー企業の社員がコミットするケースが非常に多くなり、ベンダー社員の比率を下げていく必要がある。せいぜい１対１。
・最も効果的なのは、社内でのサービス活用である。社内であれば、基本的には利用料は発生しない。
AWSでは、サービスをどうやって有効活用しているのか？必ず社内サービスを活用する強い動機が働く。
・この方式は、既にエストニア政府で実現されている方式である。エストニアでは、企業も個人情報を持つことなく、国のX-roadにアクセスする。国全体で最適化と個人情報の管理を行っている。
・マイクロサービス化によりAPI管理などが必要となるが、これに関しては、API-GWなどのマイクロサービスを支援するツール群がどんどん提供されているのが現状である。
・DXに対応した新たなビジネスモデルの構築とDXを支える既存ITシステムの再構築、この２つを実行していくことが、今の日本の経営企業者に求められている。
前者については、①現状を認識する、②新たな経営ビジョンを明確にする、③組織を変革する、の３つを実行することである。
・「自責化マインド」があって、初めて人間は成長する。
・ITベンダーのビジネスモデルは、①SI事業、②維持保守事業、③システム運用アウトソース事業、④ITサービス事業である。
キーワードは「ソフトウエア開発のサービス化」ではないかと考えている。 -
-
-
-
Posted by ブクログ
ＰＭのお勉強。関連図書では久しぶりのヒット。実務を担当している人は、目から鱗の金言が多かったのでは。ちなみに本書は、中規模クラスのプロジェクトを想定している。
・プロジェクト計画後の優先順位
Ｑ＞Ｄ＝Ｃ
・プロジェクトのクリティカルパスは「基盤」
・たとえ違う会社の製品であっても、ちゃんと自分で理解し、自分で確認して、顧客がわかる言葉で説明する。それがＰＭの仕事です。
・独立した疎のタスクに落とす
分解のポイントは、それぞれが独立していることです。隣にＡさんがいないと仕事ができないというのは、詳細化されているとは言わない。
・ＰＭＢＯＫの不十分な領域
どうやってバグを出すか書いていない
現行システムを想定していない
ＰＭＢＯＫのメンテナンスは品質維持
・ＩＴプロジェクトの「三種の神器」
サブシステム構成図
→サブシステムが疎になっているかどうかが大事
→人の能力の範囲を超えるとシステムは作れない
スケジュール
体制図
・課題の優先順位は3つの項目のバランスで決める
「緊急度」「重要度」「拡大傾向度合い」
→ケプナー・トリゴー法
・ＩＴ部門だけでオーソライズした最初の概要設計では、リリース品質に至らず、プロジェクトは大混乱に陥っていた
・ＰＭはアプリケーションの主要なアーキテクチャ―を理解し、テストとメンテナンスの生産性を担保する
・パラメータ化のわな
パラメータ化は巨大化するとトラブルへの体制が非常に低くなる
・日々エンハンスしているシステムにおいても、その歴史を整理しておくことをお薦めしたい。新規構築後の大幅なシステム化案件を年表形式で整理しておくのです。システム化のトリガーとなったビジネスの歴史と並べて整理しておくとわかりやすい。この年表は新規のメンバーがそのシステムを本質的に理解するのに役立つし、次の再構築において重要なインプット情報となります。 -
Posted by ブクログ
PMの指南本。久々にこういう内容の本を読んだ
気がします。
経験としては、著者の規定しているところの大規模の
プロジェクトは経験ありませんが、億～十数億程度規模
のPMを何度か経験させてもらいました。
PMの経験としては、数回１・２回以外は失敗していない
と思います。
この本を読むと、失敗しなかったProjectの時には、
書かれてあるいろいろな助言や考え方、PMの要点
みたいなところについて、大体が気にしていたような
気がします。ただし実行できたものばかりではなく、
こういうことが大事だよなあと思いながら、
できていない時もありますが。
それで、これについては自慢ではなくて、そういう要点
みたいなことは、ほとんどが、上司であったり、
プロジェクトのメンバであったり、パートナー企業の方であったり、から言われたこと、サポートして
もらったこと、サジェッションしてもらったことばかり
でした。
または、お客様からも指摘をいただいたり、お客様が
独自に(勝手に）そういう方向にもっていって
いただいたり、してもらったこともありました。
ということで、私の場合、PMの経験で得たのは
回りのサポートによってノウハウや経験をいただけた
ことばかりだったような気がします。
非常にラッキーであり、運がいい道筋を歩いてきたの
だと思います。
とてもありがたいことで、なんとか、この経験を
後ろに引き継いでいかなければと思っています。 -
-
-
-
-
Posted by ブクログ
自分なりにこの本をざっくり整理すると、
①ほとんどの日本企業のレガシーシステムは、維持だけでお金を使い尽くすだけでなく、今後付加価値を上げることができない、負債といっていい代物である
②その状態を打開していくこと、つまり2025年の崖を越えるには、企業内IT人材のマインドが変わらなければならず、その第一歩としてベンダー丸投げ体質から脱却することが必要である。そして、それに伴いITベンダーのスタンスも変わるべきである
③現在日本企業が抱える課題を克服できる技術は確立されつつあり、それをかたちにしたアプリケーションアーキテクチャが「マイクロサービス」である。マイクロサービスを導入すれば、技術的負債は解決され、DXに対応できる
と言ったところか。
よくわかるのだが、特に③が強引で、やや根拠に欠けるように思う。もちろん疎結合であるべきなのは同意。
加えてIT負債を放置するとDXは進まない論旨は、もっともに聞こえるのだが、それだけを理由として到底日本企業をIT投資へは動かせない。筆者は、IT負債→DXは進まないということを少し当然と捉えすぎてはいないだろうか。強いてこの論旨を深掘りすると、IT負債下の日本企業＝維持だけでお金が無い、データが汚く使いものにならない、よってDXは無理、と言うことか。やはりやや強引。IT負債はIT負債、DXはDX、という部分もあるのでは？と思うのだが。
名著『プロフェッショナルPMの真髄』を前著にもつ筆者は、マイクロサービスとかは実はどうでもよく、この本で日本のITパーソン、エンジニアにただエールを送りたかったんだ、と邪推してみる。 -