ITストラテジストを受けてみた
前回投稿した「応用情報技術者を受けてみた」に引き続き、ITストラテジストを受けてみた所感をまとめてみました。
まず間違いなく落ちているので、次回自分が受けるとした際の参考になるように、めちゃくちゃ雑ですが、興味ある方の参考になれば。
試験当日
過去問の解き直しなどは一切せず、頭を休めることに専念した。
試験直前にはやっぱり頭痛が起きたので薬を飲んだ。
あと、直前に食べたねぎとろの手巻き寿司が駄目だったのか、試験中腹痛になった。
午前2
結果はおそらく17/25で合格ライン。
体感では10問くらいは過去問で見たことのある問題。もっとあるかも?
選択肢「エ」が25問中12問で、解いている最中かなり不安になった。
午前2の対策は過去問5年分くらいを数回解いた程度だったが、それ以上の対策は必要無さそう。
午後1
こっちは自己採点が出来ないが、おそらく合格ライン。
設問から問題文を読むのではなく、問題文の中のポイントになりそうな部分に印を付けつつ解く方法で割りとスムーズに解けて、20分余った。
最後の設問で問題文の序盤に書かれていることを答えるパターンがあったので、やっぱり午後1については設問からではなく問題文から一通り目を通すのが良いと思った。
午後1については2年分くらい過去問を解いただけなのと、時間も特に測らずにのんびり解いただけだったが、それ以上は特に必要無さそう。ネットでは時間が足りないという意見もあるが、個人的には気にしなくて良い。
午後2
間違いなく不合格ライン。
原因は以下
1.経営者目線で判断出来るような数値を文章内に盛り込み忘れた
2.設問アで書くべき、その事業の弱点や課題などが書ききれなかった
3.設計書を書くのに手間取り、しかも中途半端な状態だったので、書き直しが頻発し、時間がなくなった
4.握力がもたなかった
特に1について、コストに対してどのようなメリットがあり、どのくらいの期間で回収出来るのかという一文を入れるべきだった。
あと、最初書こうと思ってたのにOCRとか、そういう「IT使ってる感の出るワード」を書くのも忘れてた。
午後2に関して、設計書は何となく書く練習をしていたものの、最初から最後まで論文を書き切る練習をしていなかったので、次受けるとすれば2、3回は論文を時間を測りつつ手書きする練習をしておくべき。
思っていた以上に、頭で考えていることを順番に文章化していく難しさを感じた。普段PCで順番を気にせず加筆修正をしているせいで、書き直しにここまで手間取ることになるとは思わなかった。
応用情報技術者を受けてみた
久しぶりのブログ投稿になりました。
応用情報技術者を初めて受けてみて、何とか合格出来たので、その時の勉強法なんかをまとめてみました。
試験を受けるまでの流れ
プログラマーに転職する直前にITパスポートは取っていたものの、その後基本情報技術者を受けようと思ったらコロナでごたごたして結局受けず。
「なんかコロナも落ち着いてきたし、そろそろ何か試験受けてみようかな」
ということで、10/10の応用情報技術者を受験すると決めたのが8/6でした。
スタート地点の確認
午前の過去問を初めて解いた時の結果がこちら。
こんな綺麗に正解率分かれることある？笑 pic.twitter.com/tu8AHDIISk
— くぼ@Excelマクロ開発受付中 (@kubo_vbapg) 2021年8月9日
やっぱり1年前とは言え、基本情報の勉強をしていただけに、多少の知識や傾向は頭に入ってたみたいです。
あとは普段の業務で触れる知識もあったので、そのおかげですね。
この状態からのスタートだったので、最初の1ヶ月はテクノロジ系中心に午前の対策、その後は午前の復習をしつつ、午後をメインに対策していこう、という作戦でいきました。
試験対策に使ったサイト、書籍
応用情報技術者の勉強をする上で使ったのは以下のサイトです。
応用情報技術者試験 過去問道場🥋 ｜応用情報技術者試験.com
また、以下の書籍もKindle Unlimitedで読めたので、弱点であるネットワークやセキュリティについての部分のみ読みました。
書籍で勉強した時間は合計でも2時間程度で、あとは全て過去問道場を使った過去問演習に費やしました。
というのも1年分午前の問題を解いてみた感覚として、まぐれとは言えテクノロジ以外は合格ラインを越える正解率、テクノロジも手も足も出ない状況でも無かったため、過去問との類似問題を確実に正解出来るようにしておけば、合格ラインは越えるだろう、と思ったからです。
そう考え、平成28年分から過去問をひたすら解いて、約1ヶ月後。
テクノロジ系でこれだけ取れればまぁ他でカバー出来る…はず…
— くぼ@Excelマクロ開発受付中 (@kubo_vbapg) 2021年9月15日
応用情報技術者試験ドットコムでの学習記録📝
【分野指定】
50問中29問正解📈正解率58.0%#応用情報技術者試験#過去問道場 https://t.co/UX6VULLMgZ
まだ微妙ですが、初見の問題、苦手分野でほぼ合格ラインの正解率だったので、これで良しとして午後の対策に移りました。ちなみに勉強時間は基本的に毎日の通勤時間を使いました。
間違えた問題の解き直しは必ずしましたが、解説もちょっと目を通す程度で、さらに知らない事をググるようなことはしませんでした。
午前がひと段落したので、午後もまず1年分過去問を解いてみたところ、こんな感じ。
情報セキュリティが撃沈。
ただ、他は甘めの採点とは言え悪くはない。
(合計のパーセンテージはシンプルに平均を出してるだけなので実際の得点率はもう少し下がります)
情報セキュリティがネックなのは一目瞭然なものの、何をして良いかもよく分からないのでとりあえず土日の間に過去問をやる、平日は通勤時間で午前の過去問を解き直す、という感じでいきました。
解答時間は午前の方は全く意識する必要無いくらい余裕がありましたが、午後はちょっと気を付けないとまずいな、という感じでした。
ただ、めちゃくちゃ意識してやる必要も無いと判断し、特に時間を測って取り組むことはしませんでした。
そんな感じで試験直前まで続け、
こんな感じになりました。
古い方から順に手を付け、結局全部を解くことは出来ませんでしたが、正直午前よりはすんなりと合格ラインに乗りました。
「分かった！」という実感はそこまで無いものの、大きく正解から外れることは減った、という印象です。
出題形式に慣れて解答スピードは上がった気がしますが、午前のように過去問と同じような問題が出る、ということがないので、あくまで「どのような形式の問題が出るか」「どんなパターンの解答があり得るか」などのイメージを掴む程度でした。
試験当日
試験会場が大学で、自分の席がどこかを確認するのが一番大変でした。
午前、午後ともに解答時間のイメージは予想通りでした。
午前は早々に終わり、早めに退室して午後に備えました。(と言っても昼ごはん食べてのんびりしてただけ)
午後はとりあえず解けるところを埋めて、一通り終わった後で時間を掛ければ出来そうなところに戻って考え直し。
時間ギリギリまで解き続け、途中退室せずに終了の合図を受けて終了。
手応え的には良くもなく悪くも無く。
「時間あってもこれ以上の解答は自分には無理だな」
とは思いました。
結果
10/10に試験を受け、合格発表が12/17。
試験勉強よりもこの期間の方が苦痛でした。
前日からは特にそわそわし、発表当日の午前は何も頭に入りませんでした。
そしてネットで合格発表があり、以下の結果。
うあああああよっしゃああああ pic.twitter.com/dyaVeP5KRn
— くぼ@Excelマクロ開発受付中 (@kubo_vbapg) 2021年12月17日
第一印象
「合格か不合格か、もっとぱっと見で判るようにしてくれ！！」
蓋を開けてみると、やっぱり午前はテクノロジが低めなものの、68%と個人的には好成績。
もっと意外だったのが、午前よりも午後の得点率の方が高かったこと。
過去問演習では午後の方が何となく得点率高かったりしましたが、採点は相当甘くしていたので、もっと低くなることも十分あり得ると思っていました。
対策方法まとめ
- 過去問を1回分やる
- 苦手分野中心に過去問を繰り返す
- 苦手分野の基礎は必要に応じて書籍で情報収集
過去問が全て！！！(過去問道場様様)
テスターとして約1年間働いた結果
はじめに
久々の投稿です。
タイトルにある通り、約1年間はテスターとして働いていました。
ネットで
「SESはテスターなどのスキルが身につかない案件に入れられ続けて使い捨てられる」
みたいな話を目にしたことがあったので、
「テスターって実際どんな感じなんだろうな」
という怖いもの見たさみたいな興味はあったので、ある意味いい経験が出来たかなと今は思っています。
(という感情になったのも、次の参画先では開発の仕事もさせてもらえそうだからです。それが決まるまでは本当に地獄でした)
そんなわけで、この記事では
- テスターの仕事ってどんなもの?
- テスターは本当にスキルが身につかないの?
- 何が辛かった?
- テスターに配属された人へのアドバイス
などについて、実体験から書いていきたいと思います。
自己紹介
塾業界で働くことに疲れ、独学でプログラミングを半年間学び、プログラマーとしてSESの会社に転職しました。
最初の現場では開発の仕事を任され、業務のメインがプログラミングでしたが、そのプロジェクトが終了し、次に配属された現場がテスターの業務のみの現場でした。
1.テスターの仕事ってどんなもの?
テストの段階にもよりますが、例えば「単体テスト」と呼ばれるようなものは、おそらく開発の現場でもやったりします。(僕の経験上ですが)
ある関数を作成し、その関数に対してAという引数を渡したら、ちゃんとBになって返ってくるよね、というようなものが単体テストです。
今回僕が配属になったのは、結合テストや総合テストと呼ばれるものを行う現場でした。
単体テストの場合、実際にソースを見ることも出来たりするのですが、僕の現場では全くソースを目にすることなく、ただ画面を操作して、動きをスクリーンショットで撮っていく、というものでした。
おそらく大部分のテスターがこういう業務をやっているのだと思います。
テストを行う手順はテスト仕様書として準備されたものがあり、その通りに操作します。
その操作をしている過程と結果をすべてエビデンスとしてスクリーンショットを撮り、期待通りの結果になっているのかを確認していくのがメインになります。(仮に不具合が見つかっても、それを報告するだけです。自分でデバッグしたりは出来ません)
あとは同じ現場の他の人がテストした内容を他の人がチェックする、という業務もあります。
というか、これがすべてです。
2.テスターは本当にスキルが身につかないの?
業務内容だけをやっていると、本当に身につかないと思います。
ただ任されたタスクをこなすだけであれば、せいぜいExcelのショートカットに少し慣れるとか、その程度の成長しか無いと思います。
僕の場合、最初の現場が開発の案件で、短期間であまりにも色々なことが学べた経験があるだけに、
「この仕事をやるだけだと時間が無駄になる」
と思い、
・Excelマクロ作成
・PowerShellを用いたツール作成
・batファイル作成
・その他業務で使用するツールの使い方を改めてググって勉強
というようなことを自主的にやりました。
これをやっていなければ、逆に頭がおかしくなってたんじゃないかというくらい、良い息抜きになりました。
仕事量が少ないわけでは無かったのですが、Excelマクロを作るのは元々ある程度のスキルが身についていたのでそれを活用して業務効率化を行い、時間を作りました。
その空いた時間でまずは実務で使えるツールの作成に取り組み、「もう思いつかないな」と思ってからは基本自分のための勉強に充てていました。
その時間があったからこそ、テスターの現場でも出来ることを増やせましたが、正直開発の現場であれば1ヶ月で身につくくらいの内容を1年かけて身につけてしまった、くらいのスピード感です。
3.何が辛かった?
一番辛かったのは、「いつまで同じことをやり続けるのか」という考えが常に頭をめぐり続けることでした。
最初こそやるべき操作やルールを覚えながらだったので多少頭を使っていましたが、慣れてくると大して頭を使って考える必要も無くなります。
本当に「ただの作業員」として仕事をしている感がすごくて、「こんなこと誰でも出来るんじゃないか」「ずっと続くから達成感もなにもない」「頑張ったら後の仕事が楽になるとかそんなこともない」などなど、とことんやる気を維持するのが難しい仕事内容でした。
先述した通り、最初の現場では色々なことが学べました。ベテランのエンジニアさんから色々アドバイスをいただくことも出来ましたし、そのアドバイスを直にコードとしても見せてもらえたりして。
そういう状況からは一転し、プログラマーとして、エンジニアとして働いてきたらしい先輩と一緒に働いてはいるものの、Excelの関数の使い方は間違えるわ、仕事は遅いわ、コミュニケーションが苦手だわ、…
というような感じだったので、「何かを教わろう」という意欲も起こりませんでした。
そんな余裕のある人もいませんでしたし。
そういう意味で、「この人から色々学ばせてもらおう!」という人がいなかったのも辛かった点ですね。
4.テスターに配属された人へのアドバイス
かなりネガティブなことをたくさん書きましたが、仕事内容自体はあまり頭を使わずに済むので、考えるエネルギーは温存できると思います。
その温存したエネルギーと、仕事効率化の工夫で捻出した時間を使って、自己学習の時間を作り、腐らないように努めるのが一番だと思います。
今は多少落ち着いてきているようですが、やはりコロナの影響で実務未経験者や、経験の浅い人が入れる現場はまだ多くはないようです。(地域にもよると思いますが)
そういった状況があるので、特にSESで働く人は、案件が他に無さそうなのであれば、テスターの現場で出来る限りの自己学習をしつつ、開発の案件を探してもらうのが一番かなぁと思います。
一番良くないのは、「楽な仕事だからとりあえず任されたことだけやって楽して過ごそう」という考えだと思います。
少なくとも僕が入った現場は、業務をこなす上では何の成長もありませんでした。
ただ実務経験を1年間近く積んだというだけで「何も出来るようになってない」となれば、仮に開発の案件が見つかったとしても、「スキル不足」として落とされます。(自己学習でこういうことをやっていました、とアピールしても落とされる可能性は充分ありますし、実際落とされたところもあります)
最後に
テスターとして働いた期間、ずっと「プログラミングがしたい」と思い続けてきました。
だからこそ副業の依頼(Excelマクロ作成)がものすごく楽しかったですし、良い気分転換になりました。
プログラミングに対してのモチベーションは上がり、
「スキルを身に付けず、のうのうと過ごしていたらこういう現場にしか入れない」
ということを身をもって体感出来たので、悪いことばかりでは無かったなと思います。
まとまりがありませんが、少しでも誰かの参考になれば幸いです。
【副業1年目】2020年ココナラ収益公開【個人的には想定以上】
あけましておめでとうございます、くぼです。
前回の記事を投稿してからすぐにこの記事を書こうと思っていましたが、年末年始に想像以上にだらけてしまったので今日になりました。
僕は2020年の1月からココナラで副業としてお仕事を受けるようになったので、ちょうど1年間副業をしてきたことになります。
というわけで、早速実績公開します！
(金額は売上ではなく、ココナラの手数料を差し引いた実際の利益です)
利益合計:71776円
◯実績についての振り返り
正直、そもそも1月から開始して、1月中に仕事を受けられるとは思っていなかったので、そこから想定以上でした。
見ての通り1件あたりの平均利益は大したことありません。その上最初は出来ることがあまりに少なかったので、1件あたりに掛かった時間も今の比ではありません。
1月はとにかく実績作りのために出来る限りたくさん受けました。土日はもちろん、平日の勤務後も結構副業にあててましたね。
それ以降少しずつ案件を選び、少し難しくても単価がちょっと高く取れそうなものだったり、単価は低くてもすぐに終わりそうなものだったりを受けました。
12月の平均利益は他の月と比べてもかなり低くなっていますが、正直なところ、それまでに引き受けた仕事の内容を使い回すことが出来たので、時間に対しての利益で言うと、どの月よりも高いです。
Excel VBAを用いたマクロの作成を主に請け負っているため、同様の機能を求められると部分的に使い回すことが出来るんですよね。
本当は案件ごとにどの程度の時間が掛かったのかも記録したいのですが、僕の作業時間が子育ての合間だったり、妻が子供を寝かしつけている間だったりと細切れのため、なかなか記録しにくいんですよね。
あとは依頼主とやりとりをしている時間も少なくない上、これまた記録しにくいです。
ただ、ちょっと実績作りのためと、「どの程度お金を取っていいものか」の判断が難しいことから、少し安く引き受けすぎたなと反省しています。
スピーディに出来るようになったからと言ってあまり安く受けてしまうと、結局は自分の首を絞めてしまうので、2021年は適正価格を意識して、過剰な安売りにならないように気をつけたいです。
ちなみにココナラでの利益は上記の通りですが、Twitter等で直接お仕事をいただくことがあり、そちらも65000円ほどの利益があるので、合計すると2020年の利益は14万円弱ですね。
2021年は副業での収入を5倍くらいにはしたいなぁと漠然と考えています。
ふんわりとそのための作戦も考えているので、また実績を公開するタイミングが来た時に自慢出来る様に頑張ります。
最後まで読んでいただきありがとうございました。
副業を検討中の方の参考になれば幸いです。
Twitterもやっていますので、もし何か質問等ありましたらお気軽にリプライ等ください。
副業を始めて体感したメリット
2020年も終わろうかという時期になりましたので、今年の自分を振り返ったりするわけですが、そんな中で、「副業を始めてよかったな」と思うことがいくつかあるので紹介します。(本当にただ振り返りながら書いているだけなので、参考にはならないかもしれません)
僕は2020年の1月から副業を開始し、ココナラで依頼の受注を始めました。
最初は全く要領が分からず、実績も無かったため、自分に出来そうな内容であればとにかく提案しまくっていたのを覚えています。
(※ココナラでの2020年内の実績は次の記事ででも詳しくまとめます。)
副業の依頼を受けられるようになってまず良かったなと思うのは、「課題が得られること」でした。
僕の場合、副業ではEXCELの関数やマクロを使ったツールの作成を主に受注していますが、自分のこれまでの業務ではやったことがない処理を希望されることがよくあります。
VBA含めプログラミングを勉強していて困るのが、基礎となる教材を終えた後、何をすればいいかわからなくなることです。要するに、課題が無いんですね。
「プログラミングスキルを磨くなら、自分でアプリを作りましょう!」
みたいな文言をよく見ますが、それが出来る人間ばかりでは無いんですよ。
僕がアイデアマンなら、「こういうものを作ろう!」というものを考えて、それを作りながらさらに技術を磨けば良いのだと思いますが、残念なことに想像力があまりなく、自分で何か作ろうと思っても「勉強のために作るシンプルなもの」にしかならないんですよね。
それだと完全に勉強でしか無いんですが、依頼として受けた内容をこなすことで、
・自分では想像しなかったものを求められる
・人が求めているものを知ることが出来る
・相手に感謝してもらえる
・報酬ももらえる
という、ざっと考えても一石四鳥な利益が得られるんです。
学生に例えるなら、受験勉強してお金がもらえるような状況です。
プログラミング自体が好きな僕としては遊び感覚な部分もあります。(というと誤解を招きそうですが、集中して大真面目に取り組んでいます)
仕事で疲れて帰っても、依頼があると寝る前に30分でもやっておこうとして、気付いたら1時間経ってるみたいなことが本当によくありました。
嫌々やっているわけではなく、求められているものを作って喜んでもらえたり、自分がこれまでやったことがないことが出来るようになるのが本当に楽しいんですよね。
自分の中で「人生で嬉しいと思うこと」のトップ3のうち2位と3位が、この
「人に感謝されること」
「自分の成長を実感出来ること」
なので、本当に副業を始めてみてよかったなあと思っています。
(ちなみに一番うれしいのは娘の成長を実感することです)
まだまだ知らないことばかりですが、副業をやっていなければ得られなかった経験値は本当にたくさんあります。
VBAのレベルは相当上がりました。依頼を受け始めた時はマサラタウンでしたが、今は多分ハナダシティくらいだと思います。ヒトカゲを選んでカスミのスターミーにボコボコにされたのを思い出します。
また、人が伝えたいことを読み取る能力も上がった気がします。依頼を受けていると、やっぱりプログラミングを全く知らなかったり、そもそもEXCELの基本操作もあまりわかっていないような人も多いので、そういう人とやり取りしてその人の目線を知る事ができたのも収穫ですね。
本当はもっと得られたものがあるように思いますが、多分僕が頑張って説明するよりも、試しにやっていただく方が100倍言いたいことが分かると思いますので、もし副業に興味のある方は、2021年を期に始めてみても良いかもしれません。
僕自身も、2021年はさらにたくさん依頼をこなし、出来る幅を広げて、よりたくさんの人の手助けが出来ればと思っています。
なんか小学生が書いた作文みたいになりました笑
最後まで読んでいただきありがとうございました。
VBAコーディングの効率化～関数化と個人用マクロブック活用～
他の言語と比べてVBAが敬遠される理由の一つに、
「コードの使い回しにくさ」
があるんじゃないかなと思っています。
また、VBAを書きはじめてしばらくすると、
「なんか同じ処理を何度も書いててめんどくさいな」
と思うことも出てくると思います。
それを解消し、少しでもVBAのコーディングを楽にする方法を紹介したいと思います。
基本的には初心者向けの記事ですので、上級者の方の参考にはならないと思います。すみません。
※動画でも同じ内容を紹介していますので、文章だけよりも実際に映像で見たいという方はこちらへ↓
1.よく使用する処理の関数化
VBAを書く際、よく使う処理ってありますよね。
「この列の一番下の行を取得したい」とか、「この表の内容をCSVとして出力したい」とか。
最初の2、3回は、そういった処理をなんとか実装するのに調べながらコツコツ作るのも勉強になって良いと思いますが、それも5回、6回と繰り返すと
「理解しているのにいちいち書かなければいけないめんどくささ」が勝ってきます。
例えば「A列の一番下の行を取得する」は、
last_row = Cells(Rows.Count, 1).End(xlUp).Row
と書けば良いのですが、地味にめんどくさくないですか?
なので、この処理を
Function get_last_row(ByVal rng As Range) As Long
get_last_row = Cells(Rows.Count, rng.Column).End(xlUp).Row
End Function
として関数化しておくと、
last_row = get_last_row(Range("A1"))
と書くだけで、指定した最終行を取得することが出来ます。
この処理であれば引数で渡す情報も、「どの列か」がわかれば良いので、数値でも良いですね。(というかその方が楽です)
Function get_last_row(ByVal col As Long) As Long
get_last_row = Cells(Rows.Count, col).End(xlUp).Row
End Function
こう定義しておくと、
last_row = get_last_row(1)
と書くだけで、A列の最終行を取得することが出来ます。
頻繁にVBAを書けば書くほど、よく使う処理は0から書き始めるのではなく、関数化しておいたものを新しくマクロを作るブックにコピペして、その関数を使用するようにすると、コーディングは非常に早くなると思います。
2.個人用マクロブックの活用
ただ、関数をせっかく作っておいても、
「どのファイルに作った関数のコードが入っているか分からない」
「いちいちコードを保存しておくためのブックを作るのもめんどくさい」
「コードを保存してあるブックをいちいち開くのもめんどくさい」
という別の面でのめんどくささがあります。
その面倒を解消するために、「個人用マクロブック」の活用をオススメします。
・個人用マクロブックとは
一度個人用マクロブックを使用したことがあれば、その後どんなEXCELファイルを開いたとしても、VBE上に「PERSONAL.XLSB」というファイルが表示されるようになります。
このファイルにもVBAのコードを書くことが出来るので、
1.個人用マクロブックにVBAを記述する
2.完成したコードを本来マクロを必要としていたブックにコピペする
というふうにしておけば、自然と作った関数などもまとめて保存しておくことが出来、どのブックからでもそのコードをすぐコピペ出来るようになる、ということです。
・個人用マクロブックを使い始めるには
1.EXCELファイル上で「マクロの記録」を実行し、適当なセルを選択する
2.マクロの記録を終了し、マクロの保存先を「個人用マクロブック」にする
3.VBEを立ち上げ、ファイルに「PERSONAL.XLSB」が表示されていたらOK
・個人用マクロブックの本来の活用法
僕は最近個人用マクロブックを「使いまわしたいVBAの貯蔵庫」のようにも使っていますが、本来の使い方は別にあります。
それは、「色んなブックで使いたい処理を作っておくこと」です。
例えばVBAを書いている際、例えばM列1行目のセルを指定する場合、
Cells(13,1)
となりますが、Mって何番目だっけ?となり、コードを書きながら手を使ってアルファベットを数えるみたいな、すごく間抜けなことをしてしまったりします。(少なくとも僕はやらないとわかりません)
EXCELの列はもともとアルファベットで表示されていますが、EXCELの設定を変更すれば、数字に変えることも出来ます。
ただ、常に数字で表示されている方が良いかというとそういうわけではありませんので、「数字表記にしたり、もとに戻したりしたい」と考えますが、それを手作業でやるのはかなり面倒です。
その操作を一般的なEXCELファイルにマクロとして作っておいても、「そのファイルでしか」実行出来ないので、個人用マクロブックに作成しておき、ショートカットキーを登録しておくと、「どのファイルからでもショートカットキー一つで瞬時に実行出来る」ようになります。
他にも僕は
・今開いているブックをマクロ有効なブックにするマクロ
・今開いているブックのファイルパスとフォルダパスへのリンクを指定したファイルに作成するマクロ
なども作っています。この辺は次の記事にでもまとめようと思います。
まとめ
VBAのコーディングを少しでも効率化するために
1.頻繁に使う処理は自分の使いやすいように関数化しておく
2.関数化したものは個人用マクロブックに保存しておき、必要な時にそこからコピペし、自作関数を使い回す
この2つを意識的に実践することをオススメします。
ただ、自作の関数をあまり数多く使いすぎると可読性が下がるなどデメリットもあるので、関数を呼び出したところや関数を定義する部分に、コメントでどんな処理をしておくのか書いておくこともオススメします。
(自分だけが使うマクロなのであればそういう必要も無いかもしれませんが、他の人も使うようなツールになるのであれば、そういう配慮も大事です)
最後まで読んでいただきありがとうございました。
次の記事では具体的に、個人用マクロブックに作ってあるマクロをコードも含めて紹介したいと思います。
Twitterもやってます。良ければ気軽にリプライなどいただけると喜びます。
コミュニケーション能力が低い人と働くときに試してほしい工夫5つ
□はじめに
一昨日、僕はこんな記事を書きました。
内容としては、「コミュニケーション能力が無い人が具体的にどんな特徴を持っているのか」というものでしたが、予想以上にたくさんの方から共感の声をいただき、「あ、やっぱり他の現場でも似たようなものなんだな」と自分の考えがズレているわけじゃないことに安心しつつ、「これ、放っておくとまずいんじゃないか?」と不安にもなりました。
僕は学生から塾講師として働き、新卒からは塾のスタッフとして、うち3年間は教室責任者としても働いていました。そのため、人の教育にはすごく興味があります。
その延長として、塾で働いていたときには「うちの生徒たちは社会に出てからしっかり生きていけるだろうか」という心配も、大真面目にしていました。
僕は個別指導塾で働いていたんですが、個別指導塾の生徒って、前回の記事で挙げたような特徴を持ってる生徒がめちゃくちゃ多かったんですね。
だから個人的には、そういうタイプの人が排斥されるような流れは作りたくなくて、むしろそういう人たちが少しでも悪いところを自覚して、改善していってもらえればという気持ちで前回の記事を書きました。
前回の記事では「コミュニケーション能力の低い、切られる側の立場」の特徴を挙げましたが、今回は逆に、そういった特徴を持つ人たちと一緒に働く人がやった方が良いと思う工夫について、紹介していきたいと思います。
工夫1.Yes,Noで答えられる質問は「客観的事実を確認したい時」に限定する
例えば、「理解しているか」や「大丈夫か」は、そもそも抽象的かつ主観的で、客観的に100%理解している、100%大丈夫、という状態はありえないと言えます。なので、そういったことを確認したい場合は、Yes,Noで答えられる質問をしてはいけません。
もしYes,Noで答えられる質問をしても、相手は「楽な選択肢」しか選びません。
上司やリーダーから
「これ、わかる?」
と聞かれて、
「はい、分かります。大丈夫です」
という感じに。ここで「分かりません」と言える人はかなり少数派です。
これは何も嘘をつこうとしているわけではなく、
「ネガティブな意見を言うのは良くない」
「もう少し時間をかければ分かるはず」
「分からないと答えたら怒られるかも」
とか、色んなことをその人なりに考えている結果なんですよね。
結果、とりあえずその場は「Yes」と言っておく方が楽なので、「Yes」と答えてしまうんです。
そして、一度「分かる」「大丈夫」と言った人はその言葉を取り消すのが怖く、言い出しにくくなるというパターンに陥ります。そうした流れを回避するためにも、注意しましょう。
逆に、
「あのタスク、もう終わってる?」
という質問であれば、
「終わっているかどうか」
という単なる事実の確認なので、問題ありません。
工夫2.状況を把握したいときは説明させる
「Yes」か「No」で答えさせるのは「客観的事実」と書きました。
それ以外の内容を知りたい場合は、「説明させる」のが良いです。
例えば相手に、A～Gという一連の仕事内容を伝えたとします。
「Bの時に注意すべきこと、なんだっけ?」
「Cの次はどうしたら良い?」
「○○をするのはどの手順?」
というように、自分が説明した内容についての説明を相手に求めることで、相手がどの程度理解しているのかが分かります。
これを毎回やるのは面倒ですが、こうしたやり取りを何度かするうちに、
「この人は伝えれば理解出来るタイプだな」
「この人は少し不安だから注意しておかないとな」
というのが分かるようになります。
この工夫を実践する際に大事なのは、「相手の理解度をこちらが確認するための手段」であり、「相手の粗探しをして叱るためのものではない」ということです。
どうしても間違った回答をした相手には小言を言ってしまいそうになりますが、こちらの問いかけに対して答えた相手を叱れば、そのうち相手は「答えたらまた叱られる」と萎縮してしまいます。
コミュニケーションを取る上で「関係性」は非常に重要で、一度悪い関係になってしまうと修復はかなり難しいです。
コミュニケーション能力自体はお互いに高いのに、関係が悪いせいでスムーズに進まないことはよくあります。
コミュニケーションをうまく取るための工夫で関係性を悪化させてしまっては本末転倒なので、相手が答えたら合っていても間違っていてもOK。間違っていたら
「なるほど、ここがちゃんと伝えられていなかったか!教えてくれてありがとう!」
くらいのノリで、その後訂正しましょう。
工夫3.積極的に確認する・質問のハードルを下げる
よく「分からないことがあったらいつでも聞いてね」と言う人がいますが、コミュニケーションが苦手なタイプはこの発言でものすごく困ります。
そう言ってくれる上司やリーダーも自分の仕事で忙しそうにしているため、実際には「いつでも」というわけにはいかない。
また、自分が「分からないこと」が何なのかも分からない。何となく不安だし間違っている気がするけど、どこが間違っているのかが分からない。そんな状態で忙しそうな上司の時間を奪うのは…と思っているうちに、どんどん時間が過ぎてフォロー出来ない状態になってしまいます。
まず「いつでも聞いてね!」だけでなく、「いつでも聞いて良いよ!忙しい時はちゃんと断るから!」と一言付け加えるのが有効です。
当たり前のことではあるのですが、ちゃんと明言しておくことで、「忙しいかどうかは相手が判断してくれるからあまり気にしなくて良いんだ」と思わせることが出来、質問の心理的ハードルが下がります。
予め言っているので、断られたとしても「あ、今は忙しいんだな」で済みます。
また、自分から質問や相談をするのが苦手なタイプには、積極的にこちらから確認する時間を作っておくのが理想です。
事実確認なら「Yes,No」、それ以外なら「説明させる」方法で、こまめに確認しましょう。
もしそうした時間をこまめに作るのが難しいのであれば、時間を設定して、どのタスクがどの程度終わっているのか、簡単にチャット等で報告するような流れを作っても良いかもしれませんね。
確認の手順が増えすぎるとそれも負担に繋がるので、出来るだけシンプルな内容にしましょう。
工夫4.口頭での報告を極力減らす
コミュニケーションが苦手な人の中には、頭で考えた内容を口に出すのが苦手な人もかなり多いです。
突発的に口頭で質問されてすぐに返事が出来ず、正しくない回答をしてしまうことも多いので、チャットやメールなど、出来るだけ口頭でのコミュニケーションを避ける方がスムーズになる可能性は高いです。
口頭でのコミュニケーション能力を高めなければ根本的な解決にならないと思われるかもしれませんが、おそらくそんなことは本人が一番理解しているはずです。理解していながらもどうにもならないからこそ、苦しんでいる人も必ずいます。
あえてドライな言い方をすると、一緒に働く相手の能力が向上するかどうかなんてどうでも良いはずです。限られたメンバーでどれだけの成果を挙げられるかが大事なはずなので、特定の人物が苦手とすることが「業務で絶対に必要な能力」ではないなら、それが生産性に影響を出さないように工夫するのも、リーダーや上司に求められる能力だと思います。
苦手とすることを無理矢理やらせ続け、何か問題が起こるたびに叱責するような上司やリーダーは、仕事をしていないのと同じだと僕は思います。(怒るだけで解決策を考えないで良いなら誰でも出来ますからね)
工夫5.相手(が苦手とすること)に理解を示す
工夫2.で「コミュニケーションには関係性が重要」と書きました。
では、その良い関係を構築するために最も重要なことは何かと言うと、「理解」や「共感」だと思います。
コミュニケーション能力が低い人は、そのせいで人から理解されたり、共感されたりする機会が少なくなっていると思います。そもそも自分の考えを人にうまく伝えられないから当然ですね。
そういう相手に
「口頭でうまく話すのって緊張するよね。チャットなら大丈夫そう?」
「説明するのは少し時間掛かってるけど、ちゃんと理解はしてくれてるね」
というように、「理解してるよ」「共感してるよ」と伝えるようにすれば、いい関係を作っていくきっかけになるはずです。
僕が塾講師の頃、
「先生は2年生の時かけ算で0点取ったよ」
「逆上がりも出来なかったし泳げなかったし、出来ないことだらけだったよ」
「人と話すのも苦手だったよ」
というふうに、ひたすら自分が苦手だったことのエピソードを話していました。
僕の場合は本当にそうだったので具体的なエピソード込みで生徒と盛り上がれたのですが、実際に同じ特徴を持っていなかったとしても、理解を示すだけで反応は大きく変わります。
どうしても「先生」「先輩」「上司」「リーダー」という肩書を持つと、相手は萎縮してしまいますが、「あなたと同じように苦手なこともあるし、あなたを理解するつもりのある仲間だよ」ということをコミュニケーションを通じて伝えることで、コミュニケーションの土台となる関係が構築され、小手先の工夫をしなくてもスムーズにコミュニケーションが取れるようになっていきます。
□終わりに
前回の記事は「コミュニケーション能力が低い部下に対してのアドバイス」、今回の記事は「その部下と上手く働くための上司へのアドバイス」として書いてみました。
僕がこれまでに出会ってきたタイプの「コミュニケーションが苦手な人」に対しては有効だと思いますが、もちろん上記の工夫で上手くいかないパターンの人も多いと思います。
ただ、最後の工夫5.だけは、全ての人に対して大事なことだと思っています。
色んな人がいますが、せっかくチームとして働くなら、出来るだけ良い関係を作って、楽しく働きたいですよね。(真面目に働かない人は排除したくなりますが)
スムーズなコミュニケーションはお互いの努力が不可欠だと思います。「相手の伝える能力が低いのが悪い」と相手を一方的に悪いと決めつけず、その相手とどうすればうまくコミュニケーションが取れるか、自分自身でも工夫を考えてみましょう。
また偉そうに長々と書きましたが、最後まで読んでいただきありがとうございました。
プログラミング学習や転職活動、副業についての記事をメインに書いていますので、良ければ他の記事も読んでみてください。
Twitterもやっていますので、お気軽にフォロー、リプライしていただけると嬉しいです。
