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対応

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

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

はじめに

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

上流工程の作業内容

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

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

qiita.com

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

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

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

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

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

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

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

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

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

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

議事録の書き方を教える……

書きかけてやめたシリーズ。

新人に議事録の取り方をどう教えるかという話。社内の議論が「書式どうする」みたいな話に終始してきているのを見て一言言い添えようかと思ったのですが、やめておきました。無益なので。以下、例によって書きかけてやめた文章。

議事録に関する教育について

私見かつあまり賛同を受けないので推すつもりはないのですが、テンプレート、書式は「中身がある状態で、それをどう見せるか」というものであり、中身が無い状態で議論してもたいてい無益な議論で終わります。
私が過去に受けた教育や業務では議事録を書けるようにするまで下記のようなステップを踏んでいました。

1. 話の論点を掴み、適切に追跡する（話の筋を追う。対象の話題に関するある程度の知識が必要。この経験を積むためなんどか打ち合わせに同席させてもらう。議事録ではなく議論に集中する）
2. 要点を抜き出して簡潔に記録する（何度かの打ち合わせ体験から、次は議事を取ってみようか、となる。ここでは打ち合わせや状況に応じた記録の手段と、記録した文章の無駄をそぎ落とし、原意を保って変形する能力が必要。キモは先輩の適切かつ正しい指摘と訂正。推敲のポイントもこの過程で学ぶ）
3. 読み手を想定した体裁、記法にアレンジ、レイアウトする（ここではじめて書式登場）

議事録に記載すべき内容は、議事を進めるなかで議長がきちんと命題として出せば記録に残るはずなので、特に「議事録に書くべきこと……」といった指導は無くともできるようになると思います。ちゃんと進行すれば、です。もしぐちゃぐちゃな打ち合わせであればそれは新人を投入するべき打ち合わせではありません。そういう場合は「議事録の最低記述事項」について書記が脱線を正しつつ進行を補助する必要があるかとおもいますが。それは新人書記の仕事ではないですね。ベテランの書記がやるべきことです。

3番目の書式云々は顧客や仕事場、チームによってまちまちなので、正直「なんだっていい」が私の個人的な見解です（不要とか適当で良いという意味ではなく、何であっても上記の1、2が出来ていれば対応可能、という意味です）。ぶっちゃけ「シャープペンで書くかボールペンで書くか」くらいの違いしかないと思います。ExcelだろうがWordだろうがMarkdownだろうが関係無いと思います。もちろん「書きやすい書式」というのは存在しますが、それは議事録の書き方の話ではなく、「文書フォーマットの作り方」「文書作成ソフトの使い方」の話です。

というわけで、書式は「標準化、会議関連業務の効率化」のためのもの。議事録の主体は書式ではないというのが私のスタンスです。

社内の議論ではえてして3番目の書式の些末な内容に終始し、肝心の内容や文章、日本語の表現手法に関しての議論や考えが丸々抜け落ちることがあるので、もし脱線等することがあるようなら上記の意見も参考にしてください。

「うまく」「はやく」書ける文章術

学びを結果に変えるアウトプット大全 (Sanctuary books)

類似エントリー

3月にも昨年の新人に向けた議事録研修どうするかの議論が馬鹿らしすぎて「書きかけてやめた」をやってます……。
www.backyrd.net