misc.log

日常茶飯事とお仕事と

仮想マシンが「すべてのパイプ インスタンスがビジーです」で起動しない

前の日、職場での帰宅前にVMware Playerが完全に落ちる前にPCをシャットダウンしてしまったらしく、今朝PCを起動したら真っ黒な画面のVMware Playerが最初から起動していました。なんだこりゃ?と思っていろいろ触って見るも、どうやらゲストOS(仮想PC)のシャットダウンに失敗した状態になっている様子。こういう場合は仮想PCのフォルダにロックファイル(名称の末尾がlckのフォルダ)ができているので、それを消せば大丈夫……と思ったのですが、VMware Playerを強制終了してからそれをやっても、下記のようなエラーが出て仮想PCが起動しなくなってしまいました。

f:id:frontline:20200124092846p:plain
「すべてのパイプ インスタンスがビジーです」エラー

エラーメッセージは

パワーオン中にエラーが発生しました: VMware Playerは仮想マシンに接続できません。プログラムが起動でき、使用しているまたは一時的に使用されるファイルがある全てのディレクトリにアクセス権利ががるかどうか確認してください。
パイプを仮想マシンに接続できませんでした: すべてのパイプ インスタンスがビジーです。

結論からいうと、lckフォルダを削除したのち、ホストPCを再起動して改めてVMware Playerから起動し直すと治りました。参考まで。

AccessのクエリとVBAにおけるADODBで用いるクエリーではLike文記述が違う!

これに気づかず午後をひたすら原因探ししてしまった……

Accessを使ったデータ引っ越し作業(この是非については別の問題とします。客先の指定なので仕方ない)において、以前は手作業でクエリとして組んだSQLを実行していたのですが、VBAで自動化することになりそのままSQLを文字列としてVBAの処理に組込みました。VBAではADODOのRecordsetを使ってSQLを実行していたのですが……上手く動かない。というかエラーは起きていないのに処理結果が想定と違う。しばらく考えてふと「あれ?LIKE文のワイルドカードアスタリスク(*)になってる!」。

そう、Accessの機能として作るクエリではワイルドカードアスタリスクなのですが、ADODBで使うワイルドカードはいわゆる一般的なSQLと同じ「%(パーセント)」なんですね。やられました。

たとえばこのように「abcを含む列は全部固定文字ABCに置換する」のようなSQLの場合

UPDATE テーブル名
    SET テーブル名.列名 = 'ABC'
    WHERE テーブル名.列名 LIKE '*abc*'

こうなります。

UPDATE テーブル名
    SET テーブル名.列名 = 'ABC'
    WHERE テーブル名.列名 LIKE '%abc%'

あーもう!!!

Accessマクロ&VBA 開発工房 Office365/2019/2016/2013対応

Accessマクロ&VBA 開発工房 Office365/2019/2016/2013対応

  • 作者:緒方 典子
  • 出版社/メーカー: ソシム
  • 発売日: 2019/07/19
  • メディア: 単行本

上流工程を担当できる人材をほしがる管理層に知って欲しいこと

人事/教育担当者と経営層との打ち合わせ結果の話に対して書きかけて止めた内容です。なんか……これくらいはご自分達で学べばいいかとおもって(却って説明することで気分を害される可能性が高いと思ったので)。

はじめに

念のため長いですが書いておきます。既にご存じのこともあるかと思いますが、私が考えていることをお伝えして置かないと全体方針と違うことを研修で伝えてしまう可能性があるので。それは違うよ、という点があればお知らせください。合わせます。

上流工程の作業内容

話題に出ていた上流工程ですが、顧客を相手にした対人/業務用語を使った対話、聴き取りのスキルの他にも、一般的にはシステム設計までの工程が含まれます。当然のことですが、次に来る工程でどんな資料や成果物を作るか、下流の工程に何が控えているかを知らずに顧客の話を聞いてもまずいことになるだけです。

ちょうどよいまとめが注目されていたので掲示します。

qiita.com

よく言われるような業務知識などに加えて、上記リンク先にあるような作業も行えることが最低条件として求められるということはおさえておいてもらえるとよいかと。このあたりまでは部門問わず把握しておいて損はありません(営業や企画の仕事でも、作業規模やボリューム、受託可否の判断などを行うにはこの程度のイメージは持っておかないと顧客側や社内エンジニアとの会話も難しくなると思います)。

見てもらうとイメージ付くかと思いますが、「どうやって作るか」「どういう材料でどういう風にやるのか」までの知識は上流工程でも必須です。これが無いと、お客さんと一緒に机上の空論を組み立てて、要求された期間と費用では実現できないものを設計してしまう可能性があります。

このあたりの上流工程や下流工程で行う作業と意義の知識をすっ飛ばして「業務知識」や「上流、顧客窓口となる人員」という言葉だけを先行させると、土台となる下流工程の知識やノウハウを軽視してしまう可能性があるのではないかと恐れています。あくまで「一般的な開発が出来る」という最低条件に加えて、「上位人材のオプションスキル」として顧客業務知識や対人交渉能力がある、というのが現状の人員構成だと妥当で安全、確実なステップアップの筋道だと思います。

いきなり上流工程をやりたい人

なんでこんなことを書いたかというと、先日の社内の研修会まとめで少し気になった感想が挙がっていたためです。下流工程の経験なしで上流工程をできるようにならないかというものです。結論から言うと、出来る人もいます。ただ、誰でも無条件になれるわけではないと私は思います。

たとえば以下のような人は未経験でも上手くやることがありますが、下段の方にいくほど人材としてはレアだと思います。

  • コンピューターサイエンスを大学や専門学校で有る程度学んで、下流工程でやるべき事の想像が付く(もちろん大学出たて程度で完璧なんて無理ですが、ゼロよりまし)。
  • そのほか何かを作ったり組み立てる仕事を経験したことがあり、物作りの段取りについてジャンル違いでもある程度の知見がある(学生時代のバイト経験でも役に立つことがあります)
  • 数学や論理学などを学んだことがあり、目的に至るまでの道筋を考えることが好き。
  • 想像力や応用力が非常に豊かで、未知の作業に対してもおおよその筋道が想像できる(たいてい何かしらの製造経験やチームでの作業体験がある人です)。
  • 好奇心や行動力が非常に旺盛で、短期間での学習や習得に関する要領が非常によい。
  • 良い意味で口が上手く他人を動かすことが上手で、自分に出来ないことを上手く人に伝えてチームとして行動できる。

上流工程はハイレベルな工程ではない

そもそも、上流工程のことを「ハイレベルな作業」、下流のことを「レベルの低い作業」と捉えているのではないかという疑念もあります。このあたりは一般的なITシステム開発の勘違いとして巷でもよく言われている話です。こうした話も全社的に浸透させた上で新人に教えていかないと、先輩達との会話でお互いを否定しあって、結局新人が混乱するという結果になりかねません(例: **さんはああ言ってるけど、下流工程なんて誰でもできるんだよ……)。

プロフェッショナル要件定義の教科書

プロフェッショナル要件定義の教科書