ぷろぐらまん@ご隠居プログラマ

芸歴40年を超えた、ご隠居プログラマ。最近、ちょっとやる気を出して転職。仕事は楽しいけ…

ぷろぐらまん@ご隠居プログラマ

芸歴40年を超えた、ご隠居プログラマ。最近、ちょっとやる気を出して転職。仕事は楽しいけれど、長時間通勤が辛い。さて、どうしようかと思案中。

最近の記事

システムは、作って、使って、始末して

金融機関に限らず、コンピュータシステムは、作って、使って、始末しての3段階のライフサイクルを経て行きます まずは、「作って」 システムを新規に開発する、またはパッケージプログラムを導入するフェーズになります ある意味、プログラマにとって一番楽しいフェーズです ユーザ(お客さま)から業務要件の聞き取りを行なって要件定義書にまとめ 要件定義書に基づく設計を行なってプログラムを実装する 勿論、予算、納期の制約はありますし、ユーザが必ずしも協力的でない時も少なくありませんし 会社

    • プログラムの生命は永遠ですか?

      システム開発を行なっている中で、ユーザの方となかなか分かり合えない事項にシステム寿命の話があります ユーザ気持ちも分からないでもないのですが、ここはシステムにも寿命があるんですよと声を大きくして言いたい 私は、金融機関のシステム子会社で働いているのですが銀行のようなところでも30年以上使い続けているようなシステムが残っています それこそ「昭和」の時代から動いているシステムが冗談のようですが、あったりするのです 今の若い人なんて「昭和」なんて元号は歴史の教科書の話になりかね

      • 遅延対策は、進捗報告と分離すること

        上司であったり、プロジェクトのチームリーダーである時に聞きたくないのは、部下からの遅延報告 正直なところ、プロジェクトの遅延なんて日々、プロジェクトメンバの顔を見ていれば、いちいち報告を聞かなくでもわかるもの とは言っても、プロジェクトは組織で行なっているものですし、マネジメント(経営層)への報告も必要なので進捗会議を行なって、議事録を回付するといった約束事を省く訳にもいきません 自分がチームリーダーでプロジェクトを回していた時には、遅延対策もなく、ただ遅延が発生しました

        • プロジェクト崩壊の予兆 有識者の不足

          システム開発プロジェクトを進めていると様々な事が起きるのですが、その中でプロジェクト崩壊の予兆と思われるものについて書いてみます 開発プロジェクトをシステム監査の立場で見ていると、このプロジェクトの先行きは暗いなと思える事象に「有識者の不足」があります プロジェクトを進めるための要件として ・必要なスキルを持った要員の確保 ・必要な予算の確保 ・システム開発において合理的と考えられる開発期間の確保 が必要なのですが、ここで話をするのは 必要なスキルを持った要員=「有識者」の

        システムは、作って、使って、始末して

          触っちゃいけないEUC

          システム部門にいると銀行の職員の方が作成されたEUCプログラムが持ち込まれることが少なくありません 要は、ちょっとプログラムを齧った(AccessやExcelのマクロがちょっと書けるようになった)銀行員の方が作成したプログラム 配置転換で作った人が居なくなった後もそのまま使っていたのだけれど、業務の見直しなどで改修が必要になり急遽持ち込まれるパターンです プログラムを見ると、作った本人はそこそこ分かって書いていたのだと思われますが、使うだけの人にとってはブラックボックス 使

          プロジェクトにおけるサンクコスト(埋没費用)

          炎上プロジェクトによくあるパターンのひとつにサンクコスト(埋没費用)の問題があります サンクコストは、「すでに支払ってしまい、取り返すことのできない金銭的・時間的・労力的なコスト」と定義されるものですね サンクコストがシステム開発プロジェクトにおいて問題となるのは、PM(プロジェクトマネージャ)の判断を誤らせる要因となることが少なくないためです プロジェクト運営において方向転換をした方が良いと思われる事象が発生した時 たとえば、テスト工程においてバグが多発して収束の目処が立

          プロジェクトにおけるサンクコスト(埋没費用)

          パッケージ導入案件でカスタマイズ悪人説があるけど、それ本当ですか?

          その昔、金融機関のシステム開発はインハウス(内製)開発が主流でした でも、最近はインハウスの開発をやめ、パッケージを導入することが増えてきました 内製開発は、自行の業務にフィットしている反面、開発コストを自行のみで負担するためどうしても高コストになる傾向があります また、業務、システムに精通した要員を確保、育成する必要があるため人的コストも多くなってしまいます そのため、最近は銀行業務の周辺だけでなく、コアな勘定系システムについてもパッケージを導入することが多く成りました

          パッケージ導入案件でカスタマイズ悪人説があるけど、それ本当ですか?

          見積もり125人月、終わってみたら250人月

          今だから笑ってできる話ですが、まだ私がペーペーのプログラマだった時の話です 当時の主査のひと、見積もりが甘く、やるプロジェクトどれも工数オーバーでデスマーチになることで有名 本人、銀行員なのですがプログラム大好きな人 某H社のパッケージ導入の案件だったのですがバッチシステムとして構築されたものにやっつけ仕事のオンラインインタフェースを付けてパッケージ化したという恐ろしい代物 なんて言っても、インタフェース動かないんだもの(笑) そんな案件に放り込まれた私は、入社2年半

          見積もり125人月、終わってみたら250人月

          大駒は高い、されど歩兵を何枚入れても代わりにならない

          プロジェクトにおける有識者問題 プロジェクトを始めたら有識者がおらず(不足していて)、遅延をはじめとする問題が多発する事案が少なくありません この問題が発生する要因のひとつが、見積もりにおける「人月」の問題 ありがちなのは、この案件(プロジェクト)は何人月でできますと言った見積もりを出してしまうこと プロジェクトは、要件定義、設計、製造(コーディング)、テストといったプロセスを経て完成しますが、各工程で必要となるスキルは一緒ではありません 要件定義では、企業における案件(

          大駒は高い、されど歩兵を何枚入れても代わりにならない

          有識者、育てる前に買ってくるのが正解

          いま、うちの会社は親会社のシステム更改案件の真っ最中 30数年ぶりのシステム更改なので、前回のシステム更改をやった人間はほとんど残っていません いたとしても役員、部長クラスなので現場作業をすることはありません そうなると問題になるのが有識者の不足 もちろん、いまの現役メンバもプログラマですからシステムがどのように動いているのかはプログラムを見ればわかります でも、 なぜその処理を行なっているのか? どんな理由で現在の処理方式が選択されているのか? といった業務要件を理解して

          有識者、育てる前に買ってくるのが正解

          見積もり一発!3億円

          ことの始まりは、ある日、当時の上司に呼ばれ 上司:要件はまったく分からないんだが、オープン系(PCやサーバを使うやつ)でシステムを一つ作ったらいくらで出来る? 私:何やるか分からないと見積もりなんて出来ませんよ 上司:先方から期限が切られているので、超概算で良いので明日までに出せるか? 私:3億円!(即答) 上司:3億円の根拠は? 私:えっ!これで文句があるなら自分でやって下さい これで一旦、話が終了 その後、1年ほど経過した頃に再度、その話が出てきました システム部の担当

          情報処理 高度試験の受かり方

          思い切りシンプルに書いてしまいます 受験対策は、翔泳社の三好康之さんが書かれた受験対策本を使う これ一択でお勧めします 私ごとですが、何年も試験に合格できす 会社の面接では、「勉強、嫌いなの?」と言われた 私が、プロマネ、アーキテクト他に合格できたのは三好さんの本のおかげ 勿論、一定量の勉強が必要な試験ですが、それまで通信教育や、セミナーを受けてもさっぱりだった私が合格できたのですから 繰り返しになりますが、最後に感謝を込めてもう一度書いておきます 「受験対策は、翔泳

          情報処理 高度試験の受かり方

          有識者は育てるもの、それとも見つけるもの?

          システム開発案件で問題となる事案の一つが有識者の不足 システムの更改案件では、システムの開発(導入)の経緯や、その後の改修プロセスが分からなくなっている そもそもシステムが行なっている業務に係る知識がある人が居ない システム動作の基盤となるインフラに係る知識のある人が居ない などなど、有識者と言われる人が居ないためにプロジェクトが破綻したり、システムの品質が向上しないといったことがありがちです 会社の中長期の計画、経営方針でも有識者の育成、後継者の育成があげられることが多い

          有識者は育てるもの、それとも見つけるもの?

          赤プリの桜🌸

          桜の季節です 今年は、殊更開花が早いようですね 桜の季節を迎えると思い出すのが、今はなき赤坂プリンスホテルの桜 毎年、深夜のタクシーから見ていたのを思い出します 東京の桜といえば、3月の下旬 企業でいえば、期末の決算の時期と重なります 私の勤めるシステム子会社でも、親会社の銀行の期末が3月末なので 夜間のバッチ処理は、トラブル発生に備え、システム要員が立ち会って処理を行うのです そのため、3月末の帰宅は深夜のタクシー帰りとなってしまいます 桜の時期の日中は、人出の多い皇居

          業務知識や経験値は、給与の多い人から少ない人に流れる

          システムは一度作ったら永遠に使えるモノではなくいつかは更改、再構築の時期を迎えます。そんな時にシステム開発のスキルや経験値の継承がされていないことが問題となることが少なくありません。 普通に使っている間は、大きな問題とはならないのですがシステムの更改プロジェクトを始めたら必要な知識を持った人が居ない、ユーザ部門との折衝経験がある人が居ないことが発覚してなかなか話がまとまらない。 これは決して珍しいことでは無く、良く聞く話です。 実際、私の勤める職場でも大規模システム更改が始

          業務知識や経験値は、給与の多い人から少ない人に流れる

          プログラマの習性→chatGPTに毎日同じことを聞く

          chatGPT、すごいですね。賢いですね。 うちの会社でも試してみて、すごい!を言っているメンバが何人もいます。 仕事を離れた知人達とのZOOMミーティングなどでもchatGPTが話題に上ることがあります。注目度がとても高いのを感じます。 ところで、みなさんはchatGPTにどんな質問をしていますか? プライベートや、仕事で出てきた疑問を問いかけていますか? それともレポートの代筆を期待していますか? 私の場合、プログラマの習性なんでしょうか、毎日同じことを聞いてみたく

          プログラマの習性→chatGPTに毎日同じことを聞く