ここでは日々思いついたこと、かつて経験したことなどをランダムに記述していきます
2025年01月22日
＜アジャイルというバズワード＞
繰り返しますが、アジャイル開発とプロトタイピングは異なります。プロトを適当に作って組み合わせてアジャイル開発と言う人がいますが、その後のメンテナンスを担当する方が地獄を見ます。
アジャイルで重要になるのはサービス間のインタフェース、APIです。変更を柔軟に行うためにはサービス、機能をある程度細かくわけておかないといけません。様々な変更が様々な機能に適用されても全体として動くことを保証するためには機能間の規約が明確に決まっていて、無断で変更されないこと、というのが必要条件になります。
プロトタイプは全体の動きを見るために機能の一部を省略して作るものであり、省略した部分が将来的に作られた場合、スパゲッティ化する可能性が高くなります。なぜならプロトタイプは動作を見るために作るという目的から、ドメイン分割など行う必要がなく、スピード重視で作るため、妥協を余儀なくされるからです。
プロジェクトにおいては、まず全体構造、機能の流れを合意したら、サービスの分解粒度を決め、機能、サービス間のインタフェースを決めます。この時点でのインタフェースが固定されることはよほどのベテランでもいない限りないですが、変更の際には影響範囲が特定できるドキュメントを作成しておくことは必要ですし、当然バージョン管理とその共有は必須です。
最初の時点でその後の変更をいかに少なくするか、というのが鍵になりますが、ドメインとかクラスとかの検討において、アーキテクチャのセンスが問われます。設計は誰がやっても同じ、とはなりません。それは自動車でも戦闘機でも同じで最初の概略設計の良否が後々まで響きます。
ここまで来たら安心とはなりません。いよいよ詳細設計、実装に入っていくのですが、アジャイルが提唱されてからプロジェクトの進め方がかなり変わってきました。以前はガントチャートというものがプロジェクト進捗管理につかわれていましたが、今はタイムラインの確認くらいにしか使いません。その代わりに主流になったのがタスクを分解して「カンバン化」するやり方です。トヨタのかんばんとは全く関係ありませんが、こちらのカンバンも結構有用なものです。
何が違うかというと、プロジェクト進捗をアナログ的にとらえるか、デジタル的にとらえるか、というところです。ガントチャートでは進捗35％、なんて話が進捗報告で聞かれますが、翌日に聞くと36％とか言われて何が違うかわからないケースも多くあります。カンバン化されたタスクは「仕掛前」「仕掛中」「完了」「テスト済み」などのステータスしかなく、各タスクはLTが1日から1週間という単位で切ることが必要になります。
これの粒度を揃えるというのもセンスと経験が必要になります。粗すぎるとLTが長くなっていつまでも「仕掛り中」になります。朝の15分ミーティングで全タスクの報告は出来ないので、進捗は自己申告が基本です。出来る限りプロジェクトは現地で行い、進捗を壁に貼るなどによる可視化、情報共有は重要です。次に実際のプロジェクトの進め方ですが、ここで一旦切ります。（２に続く）
2024年09月20日
＜システム開発方法論の課題-1＞
＊本論は一昨年某社でお話ししたことをまとめたものです。この2年の変化を織り込み再掲することにしました
「導入構築する側の問題点」
日本でITプロジェクトを行うベンダーは多くいます。私もそのいくつかに勤務したことがあります。USにおいても大規模プロジェクトの成功率は50％と言われていますが、日本ではこれを大幅に下回るというのが私の現場における感覚です。もっとも失敗プロジェクトにリカバリー要員として突っ込まれることが多いのでそう感じるだけかもしれませんが、もろ手を上げて大成功、とお客様と一緒に宴会をしているチームはあまり見たことがありません。
プロジェクトマネジメントとは何ですか、とPMに聞いて、日程進捗管理と答えるPMは避けたほうがいいでしょう。予算管理が抜けてるぞ、とか課題管理もあるよね、という話以前の問題としてPMはプロジェクトの成功に全責任を持ちます。だからメンバアサイン権もあれば予算管理権限もある。
ではプロジェクトが成功するとはどういうことか？システムにバグ無いこと、という話はやめましょう。バグゼロでも役に立たないシステムというのはあります。これを成功と言うでしょうか？実際、「これ成功なの？」と判断に困るケースも多くあります。そんな印象になるのも、プロジェクトの最初に作る憲章があまりに抽象的すぎるケースが多いからではないでしょうか？
例えば業務のデジタル化、などというのは典型的です。デジタル化が何か定義していない状態ではゴールがわからない。憲章は簡潔にゴールを共有し、迷った時にそこに戻るためのものです。少なくとも私はそういう意図で憲章を作ってきました。
話を戻すとゴールが曖昧ということはプロジェクトが一方向に向かないということとほぼ同義です。これはたとえばトレードオフ案件が発生した場合に判断がしにくい。たとえばAとBという二つの業務があったとします。Aという第1段階とBの第一段階をどちらを優先するか、という話になったとき、「とりあえずAにしよう」と決めたとします。しばらくたって、Aの第2段階とBの第3段階のどっちを優先しようかと考えたときに第3段階の担当者の声が大きく、Bに決まったとする。となるとAもBもシステムが虫食い状態になることがあります。また前提が矛盾していることもあり、運用ができず結局手作業などということにもなります。しかし憲章に何も書かれておらず、バグが無ければこれでも「成功」
これは何も経理システムとか購買システムに限った話ではなく、例えば工場の工程制御とか自動車の組み込みソフトでも同じ話が出ます。重要なのは「何を実現したいか」です。これが明確になっていないと「どんな機能が必要か」がブレまくります。
組み込みSWは昔はアセンブラなどで書かれていたため、ITプロジェクトとは事情が違うと思っている方も多いですが、プロジェクト管理に差はありません。憲章は作る必要がありますし、それに沿ってユーザテストが全体の機能テストという名前に変わるくらいです。WaterFallにせよ、Agileにせよ、要求事項＝何を実現したいか、が決まったらそれを検証（ダジャレではありませんが）するテストケースを作るのは常識です。これが端末から叩いて検証するか、実際にラインを動かして検証するか、自動車に載せてみて検証するかの違いだけです。これがプロジェクトの根幹を成すのですが、残念ながらこれを作っていないプロジェクトが実に多い。
もっとも目的目標が明確でないからテストケースなど書けないわけで、なぜ目的や目標が明確にならないか？というところに行きつきます。ITプロジェクトについてまず解説していきましょう。お客様側の事情は次章にゆずるとして、プロジェクト遂行側の都合を見ていきましょう。よくある話が「売れたからあとよろしく」とPMに丸投げされてくるケース。お客様は営業の「このシステムさえ入れればOK,あとはPMがやってくれます」というのはかなり（でもない）極端なケースですが、PMに渡されたときにはろくに目的も決まっていないケースが大半です。
私の経験でも「あの50億の予算がほしい。うるさいこと言うな」と無理やりとって2年以上迷走したあげく失敗して訴訟になったケースもあります。目的も方法論も明確になっていない中で、パッケージはこれ、スコープは全業務とか滅茶苦茶な話で契約してくる営業に対しては、どんなスーパーPMでもどうしようもない。金額だけを評価基準にした弊害です。
もう一つは時間的余裕があるにもかかわらず、お客様からの要求をまとめきれず、「目的はシステム構築」に近いことをやってしまうケースです。これはどこに原因があるかというとPMが業務分析をしていないことにあります。
PMBOKはプロジェクト推進の方法は書いてありますが、プロジェクト準備の上流作業についてはほどんど何も語っていません。これは建築などではその部分は設計の領域なので当たり前の話です。しかし、ITの場合にはこの部分を行う必要があります。要求定義を行うためにはお客様の業務を理解することから始めなくてはなりません。ところが日本のＰＭはほとんどの方がこのトレーニングを受けていません。これは才能とかの問題ではなく、教育の問題です。かつて私のいた会社ではコンサル教育をトータル3週間以上受講することがほぼ義務付けられていました。ここでお客様の解決すべき課題を絞り込むためのノウハウ、チームとしてアウトプットなどの出し方を鍛えられるのですが、私は今でもその方法をアレンジして使っています。またPMは教育が義務化されていて、トラブルケースの対応などのついてのロールプレイ教育を受けました。ちなみにコンサルタントもこの教育は義務でした。
今のPMに聞くとそのような教育を受けないままフィールドの送り出されているケースが多く、多くのPMが自己流でやっているのが現状です。その方々が管理職になると「俺はできたのだからお前たちもやれ」と自分の部下に要求するようになります。結果メンタルになってつぶれるPMが増え、PMはブラックという評判がついてしまう。これはPMという職種の問題ではなく、ろくな教育もせずフィールドに送り出す企業の問題です
では教育や準備作業が出来ればそれでいいか、というは日本の場合はそこまで甘くはありません。一番の問題はPMが権限を持っていないことです。前述の通り、PMはプロジェクトの成功に全責任を負います。だからいろいろな権限を持つわけです。しかし、日本企業においてPMが部長というケースを何度も見ました。現場で指揮をとる代表者は権限がほとんどなく、滅多にこない管理職が権限を持っている状態です。何を決めるにも承認が必要になるためPMは事情をほとんどわかっていない上司に対して計画の説明、状況報告、承認依頼準備、場合によっては技術的説明資料の準備まで必要になります。
これはPM（役を権限なしでやっている人）にとっては過重負担になる場合が多くありますがなぜこんなことが起きるのか、この状況はITに関して言えばUSではあまり起きません。それはProject managerというものが専門職として認知されており、責任も権限も持たされているからです。では部長は何をしているのかというと部のメンバーが過重負担にならずに効率よく働ける環境を作ることをメインの仕事にすることになります。
老舗の日本企業は実質単線人事の会社が多く管理職になって一人前という常識が根強くあります。そのため専門職が育ちにくく、社員にその会社特有の仕組みに適応したジェネラリストを求める傾向にあります。スペシャリストは管理職にはなりにくい。
ここであれ？と思われ方、あなたはするどい。若者がなぜ管理職になりたがらないのか、もこのあたりの事情が影響しているケースがあります。スペシャリストは特に外資系には転職しやすいのです。その話は論点がずれるので、話を戻すと、企業がPMとしてのスペシャリストを育てる気が無いということが一番大きな問題になります。
今までの議論の裏返しがそのまま対策になります。「企業として」ちゃんと教育してスペシャリストとして評価し、権限を与える。問題は老舗ほど管理職至上主義の文化が強いこと。このあたりの状況を提案時にチェックすることも重要になります。
2024年09月20日
＜システム開発方法論の課題-２＞
＊本論は一昨年某社でお話ししたことをまとめたものです。この2年の変化を織り込み再掲することにしました
「導入される側の体制の問題点」
システム導入は面倒くさい仕事です。ChatGPTに要件定義をさせたらどうか、という提案に対してLinkedInにこんなコメントが
GPTにやらせるためには何がしたいかを正確に「顧客が」伝えなくてはならない。だから我々は失業することはない
これで笑える人は現場がよくわかっている人です。要件をまとめるのは大変難しい。断片的かつ時間が経つにつれ変わっている話をするお客様の意図を汲み取って「要はこういうことですかね」という確認を繰り返すのが要件定義。10年くらい前にＩＴメディアのHPでラピュタ祭りがあり、こんなパロディセリフが大受けしたこともあります。
シータ「実はまだ私、言っていない要件定義があるの」
「な、なんだと」
冗談はさておき、要件定義の後だしなんて話は日常茶飯事なのですが、実は日本企業がこれが多い。大きく言うと2つ理由があります。
一つは部門の代表が要件定義をしていないこと。
もう一つは今のままでいいと考えている人が入ってくること。
１つめの問題から話しましょう。要件定義は全員相手に行うことは無理です。関連する社員が1000人いたら全員の話を聞くなど無理ですし、違うことを言う人がバラバラいます。我々構築側はお客様に、要件定義に来る人はその部門の代表として権限を移譲してくださいとお願いするのです。その人が決めたことは部門の全員がOKを出したことになります。
しかしここから場合が二つに分かれます。単線人事において権限を持つのは上位管理職です。ですから上位管理職直々に来るケースがありますが、この場合、ほとんど要件定義に時間が取れないこと、そしてもっと重要なことは上位管理職は「現在の」業務に精通していないということです。管理職になると現場を離れるため、技術や、方法論の進歩についていけないケースが大半です。だから下から反発をうけて部長自ら修正を後で行う。
もう一つのケースは忙しいからと、あまり重要な業務についていない人、特に若手がアサインされるケースですが、なかなか決めることが出来ないし、決めてくれてもこれが簡単に覆る。業務の現在に精通し、将来を見通す専門家がいないことと、システムは業務と関係ないと考えている管理職が多いことが原因です。
2つ目のパターンはこれはこれで厄介ですが、ちゃんとしたPMはこの危険性をよく知っています。これをやらかすのは十中八九、営業でしょう。現状の業務は保証してくれるんだよね、というお客様の言葉に「もちろんです、だから契約ください」と。
この場合もデータを縦に並べるか横に並べるかとか、この要件は違う列にするとか、そういう無駄にお金がかかるものもあれば、今は支給品を有償で出しているのをこのEXCELに記載しているからシステムでEXCELに記載してくれ、とかいうとんでもないものもあります。ただこれはまだましなほうでしょう。
私も経験がありますが、一番厄介なのは、今のままの業務を守るため、最初からプロジェクトを妨害するつもりで難癖付ける人がいることです。最悪なのはその人がお客様側のリーダになっているときです。ガバナンスが効いている会社ではまずありえないのですが、日本企業では往々にしてあります。
通常、お客様側のPMは構築側のPM同様プロジェクトの成功に責任と権限を持つはずです。それを上位者、特に10億を超えるようなプロジェクトでは社長からの任命が形式的にはされるはずです。ではなぜ失敗させるような行動に走るのか、それは社長からアサインされていても、アサインした社長、役員は結果に興味がないと状況でプロジェクトを行うことが多いからです。そんなプロジェクトにアサインされて、もし成功しても評価、昇進できると思いますか？その間本業では成果ゼロとしてカウントされることも多いのです。
そのようなアンチの責任者には退場いただかなくてはならないのですが、役員自身がプロジェクトの成功はどうでもいいと思っているため、うるさい部下を厄介払いがてらプロジェクトにアサインするケースまであります。もしPMのあなた、そういうプロジェクトにアサインされたら、理由をでっちあげてでも一刻も早く抜け出すことをお勧めします。
この問題はさらに根深い問題をかかえていて、それはシステム化、ITというものに役員級が価値を認めていないということです。「わしの若いころはシステムなんか無くても仕事は出来たんだ」なんて話の好きな役員さんを説得するのは骨が折れます。あるお客様で現場から収益性が悪化しているが、原価分析を行う仕組みが無くて困っている、という話があり、原価分析の仕組みを提案した時に「みんなが努力すれば利益がついてくるのだから原価を見るシステムなど必要ない」と言われたこともあります。昭和じゃないですよ。平成の話です。
ここでも顔を出すのは単線人事、管理職至上主義です。お客様もその会社に特化したプロセスを粛々とこなすジェネラリストにならないと昇進できない。IT導入は経営目線で業務がどうあるべきかを考える良い機会なのですが、そんなことをしていたら昇進機会を逃してしまう。
現在タイミング悪く解雇規制緩和を叫ぶ政治家が多くいます。管理職やある企業に特化した業務しか知らない人は転職しにくいのは常識です。学生が、もしクビになるかもしれないと思ったらまず管理職は敬遠しますし、そもそも自社に特化したプロセスのジェネラリストを要求する会社、業界を避けるでしょう。この問題は将来の人材確保にも影響する、大半の日本企業が抱える問題です。
2024年09月20日
＜システム開発方法論の課題-3＞
＊本論は一昨年某社でお話ししたことをまとめたものです。この2年の変化を織り込み再掲することにしました
「日本ではなぜパッケージが合わないか？」
とあるパッケージソフトメーカがよくこんなことを言ってました。
「我々のパッケージを入れることがグローバル化です。」
この業界の方ならこんなこと言うのはあの会社しかないとすぐにわかる話です。これは営業がこのパッケージソフトを全く理解していない証拠とも言えます。そもそもパッケージソフトは多数売らないと開発費用が回収できません。このプロセスしかダメ、とかこの帳票じゃないとダメ、とか言い出したらお客様は減ります。つまり、パッケージソフトは柔軟性を持って作られている、すなわち、パッケージソフトは標準プロセスなどというものは何も語ってくれないということです。だからパッケージが要求する業務をそのまま適用しても、運用が決まらないし、相互矛盾を起こすこともある。
実例を一つ。購買システム上の購買記録と生産システム上のBOMで原価を自動計算する機能があるのですが、これがうまくいかなかった例です。購買システムでの単価は購買するための単価を設定しがちです。だからプリント基板を1000枚単位、受動素子も100個単位、チップコンデンサは1万個のリール単位で単価を設定します。ところが生産管理上は部品の所要量を計算するので、基板は1枚、受動素子は1個、チップコンデンサは50個しかつかないというようなケースを想定します。購買システムの要件定義時は例えばリール1本1万円としましょう。ところが単価という言葉を定義しないまま生産管理側で単価×所用数で計算すると１つの製品で使われるチップコンデンサの原価が50万円になったりします。
実はこれはあまり深刻な問題ではなく、前章、前々章で示した要件定義時の不備が原因です。我々は辞書という言葉を使いますが使う言葉を辞書形式にしてそろえるのは基本中の基本です。
では深刻なことは何か、というと２つあります。一つは業務が日本独自のものがあること、もう一つは組織単位でしか動かないため、スピードが出ない＝改善できないということです
日本独特のオペレーションにも２つあり、一つは手形、有償支給等に代表される商慣行です。前者は特に中小企業関連では普通にありますが、これは欧米製のパッケージソフトには存在しない。アホなコンサルタントは「手形を止めましょう」とか言って出入り禁止になったりしますが、これは外部処理するということを前提に考えないといけません。決算時にどのように整合性を取るかという運用を決めておかないと適当にアドオンとかでやるとかなりの確率で失敗します。
もう一つは前章、前々章にも関連しますが、業務が企業特有のやり方で固定化している場合です。例えば原価計算の方法が特殊であるとか、設計変更の出し方が特殊であるとか、詳細に記述すると「それ、うちのことか？」と言われるのでこれ以上は記述しませんが、この場合には標準的なやり方に変更する以外、解決方法はありません。
ここで前章にある「現状保証」という悪性の癌が出てきます。
「システム化したら業務を変えなくてはならないというのは聞いていない、今の便利なやり方を変えろというのはおかしい」
これで押し切られて莫大なお金をかけてパッケージSWを改造するという事例が山ほどあります。これは事前に準備作業としてプロセス設計を行っていないことが原因です。さらに言えばPMがプロセス設計能力を有していないこと、もしくは営業がオーバコミットして丸投げしていることが原因です。
パッケージソフトウエアはプロセスを何も語りません。しかし、教科書に書いてあることは要求します。例えば購入単価は決まっている、売上は商品を引き渡し時に決まっている、設計変更は書面で出す、製造実績は少なくとも日の終わりには確定している、購入品は発注した後に受領するなどなど。大学生だと、当たり前じゃないか、と言いそうですが、これが当たり前じゃないのが現実。しかし「システム（教科書的な一般常識）に業務を合わせる」と言う某システムベンダーの言い分がいかに不可能か、製造に関係した仕事をしたことがある人ならわかるでしょう。
システム導入の構想フェーズでこれらのGAPを先手を打って対策を考えておくことが重要です。しかし、売上優先で導入を急ぎ、導入が始まってからのFit/Gapでそれをやるベンダーが多いため、妥協の産物のアドオンだとか、手作業が増えたりとかでお客様側から「何のためにこのシステムを入れるんだ」という不満がどんどん出てくることが多いのが現実。
ある炎上プロジェクトで、その時にシステムを導入するコンサルタントが言い放った言葉は今でも覚えています。
「プロジェクト始まる前にシステムに合わせるということで合意しましたよね。この作業はシステムではできないので手作業でやってください。」
当時、EXCELで半自動化されている作業が手作業になって工数が増え、「何のためにこんなソフト入れるんだ」となり、「手間が増えるような話にはもう協力しない、自分の作業はEXCELでやる、あとはそっち（推進したIT部門）で入力しろ」。
2024年09月20日
＜システム開発方法論の課題-4＞
＊本論は一昨年某社でお話ししたことをまとめたものです。この2年の変化を織り込み再掲することにしました
「日本ではなぜスクラッチ開発がうまくいかないか？」
かつてのはシステムというとスクラッチ開発が普通でした。それが2000年くらいからスクラッチはもう時代遅れ、これからはパッケージソフトの時代、などと言う話が出ましたが結局フロントエンドの仕組みはスクラッチで残っています。かつてのソフトウエアの規模は今と比較すると桁違いに単純で小規模です。1990年代の汎用大型機のメインストレージは一つ500MB。現在は私のノートPCでも500GB。この容量を見るだけでもこの30年でいかに環境が変化したかがわかります。ちなみに組み込みソフトウエアも同じで90年当時はまだ8ビットが残っていてZ80という名作CPUで製品を作っていました。動作スピードも数MHz、メモリは16KBとか、今の若手にしてみれば、それで何ができるの？というレベルの話です。
ここからもわかるようにかつてはスクラッチ開発と言っても機能もコード量も比較にならないくらい小さい。この時の標準がウォーターフォールです。余談ですがウォーターフォールというのは、当時から「そんなうまくいくわけないだろ」と言われていた自虐的な言葉です。なぜかそれが規模が数百倍になった現在で、金科玉条のような話になっているのは皮肉以外の何モノでもありません。
そこで登場したのが細かく機能を独立に分けるという考え方で、オブジェクト指向とか、Iterationと呼ばれた方法論ですが、これは今一つ受けがよくなかった。この時に日本の老舗企業がちゃんと中味を理解せずに、使い物にならない、と捨ててしまったことがその後、ボディブローのように効いてくるのですが、この時は保守的な声のほうが勝っていました。スクラッチなど古い、パッケージで稼げばよいという安直な考え方でほとんどの大手ベンダが設計手法とか学ぶのをやめてしまったわけです。
2000年前後からドメイン駆動設計という考え方が出され、その後マイクロサービスという考え方が流行し、これがAgileの手法として定着するようになってきました。USの大手ではこの考え方で新しい技術を盛り込んだシステムをどんどん開発していったのですが、パッケージ景気にわく日本の老舗ベンダーは完全において行かれました。
特にプロトタイピングとアジャイルを混同する人が多くなり、作っては捨て作っては捨てを繰り返していつまでたってもまともなプログラムができず、適当なところでやめると保守性が恐ろしく悪いコードが出来上がってしまいます。これはスクラッチに限らず、パッケージのアドオンでも同じことが発生し、結局ちょっとした変更で動かなくなり、パッケージ全体が使われなくなっていくという結果になることもあります。
話を戻すと、このドメイン駆動設計、マイクロサービスのアーキテクチャを理解している人が大手に少ないというのが問題です。若手が起業した新しいIT企業ではこれを使いこなす会社も多くありますが、問題は作ったものをメンテナンスしていってくれるのか（そこまで会社が存続できるのか）という不安がお客様側にあることです。だから自分でメンテできる会社からしか発注してもらえません。
大手企業、特に製造業の情報システム部門、は自分で新技術、方法論でスクラッチ開発されたものをメンテする力のあるところが少ないのが現状です。よってパッケージ＋保守的な作り方をしたアドオン、という形でシステムを作ることになりますが、製品同様システムもすぐに陳腐化していきます。マイクロサービス等の考え方は時代の変化に合わせて部分改修が出来るように、と設計されていますが、残念ながらパッケージ＋アドオンでは時代の波についていけない。
何が問題なのか結論に行きましょう。一つ目、ベンダー側の問題。パッケージに頼りすぎて柔軟なシステムを提供できるベンダが少ないこと。二つ目、柔軟なシステムを入れも柔軟に運用するだけの知識がお客様側に不足していること。私は企業の情報システムの位置づけが経営層から見て低すぎるのではないかと常々思います。だから十分な予算、人員がもらえず、人材育成もままならない。
情報システムはビジネスの必要要件になっています。それを経営層がもう少し理解してくれるといいのですが。