2019年7月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

最近のコメント

最近のトラックバック

無料ブログはココログ

システム開発

2019年6月19日 (水)

64bitのIIS(Internet Information Services)で32bitのアプリケーションを動かす方法

先日、古いASP.NETのWebアプリケーションの開発環境の構築を頼まれて、PCに構築していたら、Visual Studio上ではコンパイルが通るのに、ブラウザで動かそうとすると、エラーメッセージが出てきて悪戦苦闘しました。

エラーメッセージ「ファイルまたはアセンブリ’・・・’、またはその依存関係の 1 つが読み込めませんでした。間違ったフォーマットのプログラムを読み込もうとしました。」

何だろうか、見当がつかずあれこれやっていたら、そう言えば、サードパーティー製の古いdllを読み込んでいたなと思い出し、64bitのIISで32bitを動かすときは、IISの設定しないと思い出しました。

設定することは、下記の内容になります。
IISのアプリケーションプールの詳細設定で、「32bitアプリケーションの有効化」をTrueにする

設定したのはWindows8.1のIISです。多少他のバージョンでは、画面の構成が異なると思いますが、同じ設定で動くと思います。
IISのアプリケーションプールの詳細設定画面

2019年6月 7日 (金)

詳細設計書が役立たずになる理由や解決策について

※以下の内容は、中規模~小規模なシステムの開発で要件定義~テストまで同一グループで行う場合に当てはまるであろうことで、大規模システムの開発では、通用しないことは断っておきます。また、ユーザの頭の柔らかさや、開発手法の違い等も影響するので、ある一例と考えてもらいたいです。

詳細設計書は、だいたい役立たずになります。あんなに時間をかけて、コードと1対1になるようにExcel方眼紙に文章書いて、SQL文は印刷に収まるように加工したのに、役に立つのは最初だけ、その後は、不具合報告を潰しまくっているうちに、どんどん設計書と乖離していく始末。

教科書通りでは、「詳細設計書を直したうえで、プログラムを直すように」なんて言われますが、その時間は遅れているプロジェクトでどこから捻出できるのでしょうね?

教えて偉い人(プロジェクトマネージャー)
プロジェクトマネージャー「そんなの自己責任だ、どうにかしろ!」

出ました自己責任、新自由主義者かアンタは。

あんまり書くと、パワハラのフラッシュバックが来て「近所迷惑」をしでかすかもしれないので、これぐらいにしておきます、文章が進みませんし。

詳細設計書を書いてからプログラミングという流れって、開発環境がまだ十分でなかったころ(COBOL全盛の頃とか)の名残だと思うのですよ。昔は、端末でコーディングする前に、入念にコーディングシートに記載して、机上デバッグしてから、端末でコードを打ち込むのとよく似ているなと思いまして。

でも、当時と今では、開発する内容も高度化していますし、複雑さも増していて、更に低価格受注、短納期となっていますので、古き良き時代(?)のようには、行かなくなっているかなと思います。

それなのに、このコーディングシートの後継と思われる、詳細設計書は名前を変えながらに残っている。
しかも、JavaやC#を使っているプロジェクトなのに、使用関数と書いてあったりしている。

愚痴をだらだら書くだけでは、居酒屋のサラリーマンと変わらないので、解決策というか、この詳細設計書を誤魔化した実例を載せておきます。上には極秘でこっそりやった方法になります。(色々な要因があるので、「銀の弾丸」では無いと思っていますが、この時は比較的、上手く行きました)

今の時代だと、Excel方眼紙と睨めっこして、プログラムを脳内で作ろうとするよりも、テーブルの定義をとりあえず作ってみたり、考えるためにプログラミングをした方が、開発効率が良いと考えて、実際そうしました。脳内妄想よりは、実際動かして試行錯誤できる分だけ、信頼性は上がるのではと思います。

こんな方法で、プログラムを書くと、品質の悪いコードが出来上がりそうですので、その汚いコードをリファクタリングして綺麗にするか、もう一度、綺麗に清書する必要はあります。

そのときに、最終的にプログラムを完成させるために、上記の未修正のコードと直す指示を出すためのものとして、ドキュメントを作って、プログラム担当者に渡す必要がありました。
(自分で直すなら、大規模修正でない限り、要らないと思いますが)

それで、プログラムが完成した後に、プログラムの説明を記すものとして、プログラムの説明書は作っておいた方が、良いかと思いますが、コード1対1のようなものは、作りませんでした。例えば、画面だったら、ボタンを押すとこういうイベントが発生して、どのメソッドが呼ばれるかなどでいいかなと思います。それ以上細かいことは、コードを読みましょうでいいと思うのです。(実際そうなるのだし)

それ以上に、クラス図などプログラム間の繋がり等を俯瞰できる設計書は必要と思っています。

そもそもプログラムを書くという工程は、製造ではなく設計の最終工程と思っています。プログラムが製造されるのは、コンパイルで、実行可能ファイルが出来上がるところだと思います。(コンパイル不要な言語でしたら、適宜読み替えましょう)

でも、「プログラムは人件費の安い中国(この頃は東南アジア?)にオフショアだ」とお考えの方々には、プログラミングは、製造なんでしょうね。

2019年6月 3日 (月)

会社標準の開発プロセス(ウォーターフォールモデル)に関する、あるユーザー側の評価と私見

今、勤務している会社はウォーターフォールが大好きです。
ウォーターフォールを必要としないような、小規模開発などについても、ウォータフォールに沿った手順を踏まされます。
では、ウォーターフォールで上手くできているかというと、決してそういう訳ではないのですが...

先日、システムを導入した会社の担当者(システム担当でなく、業務担当)と話をする機会があり、そのとき、ウォーターフォールに関する進め方についての、ユーザー側の意見を訊きました。

前提

  1. 弊社開発のパッケージソフトの導入で、パッケージ部分の導入については、ほぼパッケージ通り(一部カスタマイズあり)
  2. 小規模なサブシステムを機能を新規で追加する(マスター・帳票含めて10画面程度)
  3. ユーザー側は、システム担当1名、業務担当1名という状態で、とてもドキュメントの確認に手が回らない状態
  4. 会社の方針で、標準に定められているウォーターフォールで勧めろとの指示(パッケージ導入とカスタマイズ部分を同時に導入しろとのこと)

これに対する意見

  1. 要件を出してくださいと言われても、いざ動かしてみないと分からない箇所や見落としがあるので、要件定義・基本設計で仕様凍結をしてしまうのは、問題がある
  2. バインダーに挟まれた大量の紙資料をもらっても、システムの動くイメージまではどうしてもできなかった。
  3. 動かせる部分は、早く操作して、業務との乖離を確認したかった。(多少の設定ミスのバグなどは気にしないとのこと)

開発担当者だった私の意見としては、さっさとパッケージのパラメータ設定してパッケージのままで動かしてしまい、パッケージのカスタマイズ部分と小規模なサブシステムを反復的に開発した方が良かったと思っていましたが、会社の方針でダメだったと伝えました。

そうしたら、担当者からは「そうして進めてもらえれば、良かったかもしれない」との意見でした。

開発プロセスの標準化も結構ですが、あくまでも「標準」であって、絶対では無いと思うのです。標準通りに進めることが「お客さんのため」ではなく、開発側の都合(ISO9000の審査のためなのか、いちいち考えるのが面倒と思っているかは分かりませんが)だと思っています。

プロジェクトでは開発側、ユーザ側、双方が使える資源(費用、人手、時間、技術レベル等)の中で、どのような手段をもって実現していくかを考えて行かないといけないかと考えています。標準の開発プロセスに無理に合わせるのではなく、プロジェクトによってカスタマイズないしは、従わないという選択肢もあっていいのではないかと思います。

それに、管理者は「会社の決まりだから従え」というのではなく、「自分の頭」で考えてもらいたいものだと思います。

2019年3月21日 (木)

2019年3月19日のココログのメンテナンスおける不具合についての私見(3月21日時点)

ココログで2019年3月19日に行ったメンテナンスで、大規模障害が生じています。
21日13時現在、公式な発表などは出ておりませんので推測で書きますが、システム関連の仕事をしているため、他山の石をすべく、まとめておこうかと思います。
現場の担当者の方々は不眠不休で頑張っているかとは思いますし、批判する気はありませんが、ニフティ株式会社に対しては、あまりにお粗末な不具合であり、その後の対応についても利用者は不信を募らせており、怒りを覚えます。

3月19日の作業遅延

切り替え作業は、3月19日の0:00-13:00の予定でしたが、17:00に延長しました。その後、トラブルが続発して、阿鼻叫喚の事態になりました。
予定通りに切り替え作業が進んでいなかったと思われます。
その遅延が、データ量等、本環境での特有の問題でしたら、終了時間の遅延も致し方ないかと思います。
その後のトラブルを見ると、データ以外の問題、例えば、システムに不具合が見つかって、修正していたのではと思いました、このようなことをしていたのなら、潔く延期した方が、良かったのではないかと思います。

切り替え後にシステムが不安定

切替後、ログインができない事象や、ログアウトしてしまうなどの事象が、多数報告されていました。
その後、20日の深夜にサーバを急遽増設をして、しのいでいましたが、新システムのサーバ負荷を過小評価していたのではと当初は思いました。
しかし、その後も不具合が報告されているところを見ると、プログラムのミスで、高負荷の状態が継続していた可能性もあるかと考えています。

移行ミスが見られる

私のブログでも、画像が無くなっていたり、URLが変わってしまっていたりして、ページがGoogleでの検索からページが表示できない事象が見られました。
これらは、移行時の処理に、何らか不具合があり、移行が出来なかった可能性が相当高いと思います。

管理画面の不安定さについて

管理画面の不具合については、いくつか「検証していれば気づくだろう」レベルの不具合が報告されています。
開発側、受け入れ側(ニフティ)の検証が不十分だったのでは、と思っています。

管理画面の操作面の不満

管理画面を一新したため、利用者から「使いづらい、元に戻してもらい」「あの機能が無くなった、代替機能はあるか」という
問い合わせが見受けられます。
慣れの問題もあるかと思いますが、事前に変更後の画面イメージの提示などがあっても良かったのではと思っています。
これは、難しいかもしれませんが、ココログ利用者から、新システムのモニターを募るなどして、利用者の意見を本稼働前に取り入れられるようにできれば、良かったかもしれません。

利用者に対する情報公開の遅れ

トラブル発生時に、どのようなトラブルが生じていて、現在解決したのか、修正見込などの、情報の掲載がされていないため、
利用者が余計に不安になってしまったのではと、考えています。
Excelの表をPDFにしたようなものでも構いませんので、niftyのトップ画面など分かりやすい所に載せてもらいたかったです。

切り替えは、稼働日ありきのスケジュールだったのでは?

ここまで、ひどいものだったら、ニフティで受け入れテストを行った段階で、気が付くと思いますが、それが見過ごされているのは、ニフティ及び協力会社で稼働日ありきのスケジュールでの切替だったのでは、という疑念を持っています。
3月というのも、決算期末の月になる可能性が高く、切替日の決定は会計上の理由もあったのではないかと思っています。

親会社のノジマに対して

ニフティの親会社にあたる、株式会社ノジマに、多少の私怨を交えてには、なりますが、一言苦言を載せておきます。
システム更に言えば、インターネット接続サービスを行う会社のサービスを、家電量販店のノリ(強引に顧客に物を買わせるような販売方法)で、運営してはダメでしょ。
御社の野島廣司社長は携帯電話販売子会社の店長に「使えない」と非難した内容を社内のイントラネットに見えるところに載せたと朝日新聞に報じられたと東洋経済の記事で見かけました。東洋経済の記事の中に『ノジマで採用して教育した社員を送り込んで、ノジマ流を移植する』(原文のまま)と書いてありましたが、ニフティにも同様に、『ノジマ流』を移植して今回の大トラブルを起こしたのでは、ないですか?

2019年1月17日 (木)

「ライト、ついてますか―問題発見の人間学」の感想・書評

「ライト、ついてますか―問題発見の人間学」ドナルド・C・ゴース (著)  G.M.ワインバーグ (著) 木村 泉 (翻訳) (共立出版 ISBN 978-4-320-02368-0)を久々に読んでみました。

問題の解が書いてあるのではなく、「問題の発見」について書いてある書籍になります。

コンサルタントやシステムエンジニア(SE)のような、「問題を発見」して「解決策」を探すような職種の人は、読む必要があると言われている本です。

(どのような職種の人も「問題を発見して、解決策を探す」ということはしますので、読む価値は十分にあるかと思います。)

問題の発見についても、たとえ話(高層ビルのエレベータが遅い問題やトンネルでのヘッドライト点灯の注意看板など)から教訓を結びつけるという書き方をしていて、分かりやすいです。やや、文章がまわりくどく、分かりづらい「問題」があり、何度か読むと良いのかと思います。

2019年1月12日 (土)

システム運用に関する、取引先との「おつきあい」で、個人商店を見習うべき3つのもの

先日、得意先の担当者から「御社の営業から年末の挨拶も、年賀状もないよ」と言われてしまい、平謝りしておきました。

私の家では、「個人商店」とのつきあいが多く、中には50年来というお店もあったりします。

上司は、「チームで動けるように標準化しないとダメだ!」と言っておりましたが、個人商店の方が、弊社よりもはるかに顧客満足度が高いのではないかと思うことを書いてみようと思います。

上司の「誰かが抜けてもチームで穴埋めできるように、標準化したい」という気持ちはわかります。
しかし、社内SEになった知り合いと話したとき、「ベンダーの評価も結局は、担当者の対応の良さだったりするんですよ、担当変わって対応悪くなったら、他社に切り替えましたし」という話も聞いています。

1.高いものを勧めない
よく上司から「少しでも高く、客から金をとれ」と怒られます。しかし、付き合いのある街の電気屋さん(パナソニックのお店)では、高いものを勧めてきません。

「あんまり高機能でも、高齢者(家族にいる)には使い勝手悪いし、そこそこの機能がついている安い方をすすめますよ」と表向き商売気がありません。

しかし、こういう対応をされると客としては「家の事情を考えてくれているんだ」と思い、また「10%ポイント還元」のどこぞの家電量販店でなく、このお店で買おうという気持ちになるものです。

2.常連になると覚えてもらえるのは気分がいいもの
近所のたこ焼き屋さんに月2回ぐらいの頻度で買いに行っていたら店の人に憶えてもらえたらしく「にーちゃん、マヨネーズはかけなくていいんだよね」と言われるようになりました。
やっぱり、店の人に憶えてもらえるとうれしいものです。

私も取引先の業務を記録しておいて担当者に「御社はこの時期、特別処理が入りますね、準備大丈夫ですか?」等とマネをしております。

3.特に仕事をお願いしていなくても定期的に来てくれる
家を建てて以来、付き合いのある大工さんは、工事をしていなくても、毎年最低1回は挨拶に来てくれます。こうしてもらうと、修理や家に関する相談の時に、この大工さんにお願いしたくなります。

昨年も、「雨どいが多少ずれた」のを直してもらうという、簡単な工事しかお願いしていないのに、タオルと写真付きの高そうなカレンダーをもってあいさつに来てもらいました。

それに比べて、毎月10万円ぐらいの保守費用をもらっているのに、定期的に電話もしないし、挨拶に行かない営業は何様だよと思います。(私は、遠方の取引先にも定期的に電話をして挨拶他をしています)

2018年12月 7日 (金)

「プロジェクト・マネージャーが知るべき97のこと」を読んでみて

システム開発のプロジェクトマネージャーは、こういう仕事なのでしょうか?
「無理なスケジュールを作らせて、遅れたら、後からメンバーを恫喝することなのでしょうか?」
「メンバーを毎日怒鳴りつけて、精神障害を発症させることなのでしょうか?」
「社内ではえらそうにしているのに、怖い客には何にも言わないものなのでしょうか?」
「無理なスケジュールを押し通して、開発終盤に連日徹夜させるものなのでしょうか?」

こういうプロジェクトマネージャーは少なからずいると思います。私自身こういうマネージャーの元で仕事して、精神的に参ってしまいました。

そうじゃないだろという思いで、下記の本を読みました。

「プロジェクト・マネージャーが知るべき97のこと」(発行:オライリージャパン 発売:オーム社 ISBN 978-4-87311-510-8)

世界各地の凄腕プロジェクトマネージャー達のエッセイをまとめた本ですが、様々な事例が2ページにまとめられて書かれており、「凄腕」と「上記のようなダメな」プロジェクトマネージャーの違いが良く分かりました。

内容も様々で、「人月の神話」から言われている通り、システム開発に「銀の弾丸」は無いのだなと改めて感じました。

その中で一部特に気になった内容を箇条書きで書きますと

・ユーザと開発者は早く話し合えるようにしないと、プロジェクト終盤に問題が露呈する。

・要件はシンプルにすること。シンプルなツリー構造をイメージして要件を書く。根にある要件がプロジェクト全体のシンプルな目的になる。

・要件の一部が特定できれば、プロとタイピングを開始して、ステークホルダーにテストしてもらい、顧客からフィードバックを得て、ギャップがあったら作り直す。

・優れた開発者と並の開発者では生産性が大きく異なる。並の開発者はプロジェクトの足を引っ張る。

・遅延プロジェクトへ人を投入するとコミュニケーション量が増えて、更に遅延する。

・作業中の割り込みは、仕事の効率を低下させる。思考の流れを取り戻すには、20分程度かかってしまう。

・顧客に計画させて、徐々に構築してテストを何度も繰り返す。

・シンプルなタスクを過度な自動化するようなアドバイスを顧客にしない。

・必要な労力、企業文化、プロジェクトのフォーカス、地理的に分散したチームなどの制約により、教科書通りの方法論に沿ったプロジェクトマネージメントはしない方が良い。

・プロジェクトスコープ記述書(目標と成果物、プロジェクト成否の評価が書かれたもの、会社によってはプロジェクト計画書とも言うものと思います)を絶えず確認すること。

・プロジェクトの方向性をある程度コントロールする。
・チームを官僚主義から守る。
・仕事環境を改善する方法を考える。
・チームがチームであることを意識させる。
・ワークライフバランスを尊重する。

・ミーティングでは、具体的なアジェンダの準備と本当に必要な出席者のみ出席させる。(開発者の時間をとらせない)

・参加者に事前に資料や文献などを準備させる。

・ミーティング中は、通信デバイスを使用しないようにポリシーを決める。(副業禁止)

・メンバーを尊重して、脇で個別に会話したり、割り込んださせない

・見積もりは一人でつくらず、チームメンバー全員で作る。こうすることで、チーム全体で見積もるため意見の共有ができる、コーディングを開始するときに思考プロセスを知っている、反発の機会を減らすなどの利点がある。

・プロジェクトは、チームメンバーの姿勢と適性にかかっている。メンバーをやる気にさせないといけない。

・定期的なミーティングは、コミュニケーションを減らしてしまう。プロジェクトマネージャー不在のときに開かれないミーティングは意味が無い。


書き綴ってみると、「ダメな」プロジェクトマネージャーは悉く、逆のことをやっていると気づきました。