プロダクトについて考える時間(関西プロダクト開発アドベントカレンダー 16日目)
自己紹介とコミュニティ紹介
つねまげと申します。
SESに始まり、ERP開発、社内SE、SRE等を経て、今のメイン業務はカスタマーサポートです(部署名はユーザーリレーションズという独自の名称で業務内容も若干異なりますが今回は端折ります)
本記事は関西プロダクト開発アドベントカレンダー 16日目です。
本アドベントカレンダーの運営元となっているプロダクト開発meetup関西(プロカン)は様々な職種・業界の方が集うのが特色のコミュニティです。
11/24に最初のイベントが開催されたばかりの新しいコミュニティで、今後の展開がとても楽しみです。
本記事では、プロダクトに関わる仕事について、以前から漠然と感じていた事を言語化したいと思います。
なお、予めことわっておくと、プロとしての組織への貢献の仕方は人それぞれだと思いますし、特定の職種や仕事へのスタンスに優劣をつける意図はありません。
プロダクトについて考える時間は案外少ない
我が身を振り返るとプロダクトに関わる仕事をしていながらプロダクトそのものについて考える時間が極端に少ないなと思います。
昔から日々頭を悩ましているのは、以下のような事です。
- 保守しやすいコードを保つ
- 内外のキーマンを説得する
- 組織やチームのメンバーをまとめる
- 業務が停滞しないように、タスク単位に切り出して他の人に割り振る
- スケジュールに間に合うようにタスクの優先度をつける
- 日常業務を効率化する
言うまでもなくこれらはどれも非常に重要な仕事です。
でも、プロダクトに関わる仕事をする以上、プロダクトの仕様やユースケースなど、プロダクトそのものについて深く考える事にも多くの時間を割きたいと思っています。
プロダクトについて考えた方が楽しい
これも感覚的な話ですが、ゲーム業界の方の中にはゲーム自体が好きだし、自分が開発しているゲームがどうすればもっと面白くなるかに心を砕いている方が、他の業界と比較して多い気がしています。
今読んでいる『インディーゲーム・サバイバルガイド』に登場する開発者の皆さんがそうですし、プロカンのミートアップでもゲーム開発者の方のお話させていただいて似た情熱を感じました。
また、私の現職の社長(創業前から数十年経営管理/管理会計に携わっている)、自社プロダクトの話をする時は本当にニコニコと楽しそうです。
やはり、長い時間仕事をする以上、自身が関わるプロダクトについて考え、語れるくらいになったら楽しいのだと思います。
プロダクトについて考えるのに職種は関係ない
プロダクトについては、経営者や設計者・プロダクトオーナーといった特定の職種だけで良いという見方も存在します。
でも私は、プロダクトについて考えたり語ったりするのに、職種は関係ないと思います。
例えば日本一のマーケターの呼び声高い森岡毅さんは、USJ勤務時代には暇を見つけてはパーク内を歩き回ってアイディアを練っていたそうです。
私が今携わっているユーザーサポート業務においてもお客様の困りごとを理解するためにプロダクトによるユースケースをよく知る必要がありますし、前職でバックオフィス業務をしていた頃も自社のプロダクトやサービスを知らないと現場部門に適切な支援はできませんでした。
(私ごときを森岡毅さんを並べて引き合いに出すのはおこがましいですが、、)
どのような職種であっても、プロダクトについて深く考える事で見える地平があるように感じます。
プロダクトについて考えるために今後取り組みたい事
さて、理想論を語るだけではつまらないので、来年の抱負として私が具体的に取り組みたい事を列挙します。
- ユーザーの業務をより理解するために、ユーザーヒアリングの同席回数を増やす(今年は2回でした)
- プロダクトのバックグラウンドを深く知るため、関連する業務ドメイン(予算管理・原価管理・経理実務etc)の専門書・実務書を最低10冊は読む
- 自社プロダクトがどのように拡張できるか考えるために、ソースコードに一通り目を通す
- ドッグフーディングのためプロダクトを日常業務でも使う
プロダクトについてより深く考え、語れるようになって、仕事をもっと楽しめるようになりたいと思います。
業務システムエンジニアがマーケティングの本を10冊読んでみた
はじめに
10~11月にかけてマーケティングについての本を10冊読みました。
マーケティングについては門外漢なので、直感で面白そうなものや評判の良いものなどをセレクトしました。
他にもお勧めの本があれば教えていただけると嬉しいです。
以下、それぞれの一言感想です。
①『入門SEOに効くWebライティング サイトの価値を高める正しいコンテンツの作り方』
現職の企業ブログで記事を書くことになったので、Webライティングの基本を抑えたいと考えて読みました。
この本きっかけで、もっと広くマーケティングについて学んでみたいと思い、短期間で10冊で読む事になりました。
本書を読んだ上での、SEOについての所感として、マトモな文章でマトモな記事を書く事が一番のSEO対策だなと感じました。
小手先のSEOハックを使う事に心を砕く必要性が下がって良い時代になったなと思います。
②『ニューノーマル時代に即使える販売戦略がゼロからわかる! コトラーのマーケティング 見るだけノート』
本書はマーケティング用語を俯瞰したいと考えて読みました。
ビジネス理論はこれまでも一応学んだ事はあったので(中小企業診断士の勉強の中など)、ここに書いてある基本的な用語は大体知ってそうだったので自信が持てました。
③『マーケティングを学んだけれど、どう使えばいいかわからない人へ』
タイトル通りの悩みを持って本書を読みました。
著者の西口氏の主張を自分なりにまとめると、HOW(マーケティングの樹海)に溺れるのではなくWHO(お客様)とWHAT(製品サービス)の組み合わせを考え、そのためのHOWを導出するというもの。
そのためには、いわゆるペルソナというのは無意味で、N1分析(特定の一人の顧客を分析するマーケティング手法)が重要だという主張でした。
マーケティング界隈の有名人にはP&G出身者が多いという事を初めて知りました。(多分常識なのだと思いますがその辺疎くて知らなかった)
④『CRM―顧客はそこにいる』
2001年(初版は1998年)の出版ですがあまり古さを感じませんでした。
個客マーケティングというものが繰り返し主張されており、西口氏のN1分析とも通じているように思えました。
⑤『デジタル時代の基礎知識『SNSマーケティング』 第3版 「つながり」と「共感」で利益を生み出す新しいルール』
個別のハウツーも学んでみたいと思い、この本を読みました。
類書は多数ありますが、以下の2点がこの本の優れたところかと思いました。
⑥『NPOのためのマーケティング講座』
マーケティング活動が必要なのは非営利団体でも同じであるという考えてみれば当たり前の事が書かれていました。
お金を払う人(寄附者)とサービスの受益者(支援の対象)が異なる場合が多い、という事が営利企業との一番異なる点で、それ以外はだいたい一緒だなと感じました。
⑦『Hacking Growth グロースハック完全読本』
グロースハックについても、抑えておきたくて読みました。
グロースハックはスクラムやリーンスタートアップの派生版なのだという印象を持ちました。
⑧『USJのジェットコースターはなぜ後ろ向きに走ったのか?』
日本一のマーケターと名高い森岡毅氏の最初の著作で、実体験が生々しく描かれています。
第一章の序盤まで読むと、森岡氏が果敢に困難に立ち向かうジャンプの主人公の様に見えてきて思わず応援したくなってしまう内容でした。
また、自分の仕事柄の興味として、USJのバックオフィスの方々がどんな風に管理会計やシミュレーションの業務をまわしてるのかが気になりました。
⑨『USJを劇的に変えたたった1つの考え方 成功を引き寄せるマーケティング入門』
なるべくマーケティングの幅広いテーマの本を読みたかったので、同じ著者の本は避けていたのですが、森岡毅氏の本はあまりに面白かったので2冊目も続けて読んでしまいました。
こちらはよりマーケティングにフォーカスした本です。
⑩『プロが教えるいちばん詳しいGoogle アナリティクス 4』
こちらも個別のノウハウを学びたいと思って読みました。
Googleアナリティクスの本は沢山あるので、正直どれが良いのか選ぶのが難しいですが本書は、以下の2点が優れていました。
- 出版年が2022年で情報が比較的新しい
- 手順が丁寧にまとめられている
知っている限りNRIネットコムの方が書く本はどれもまとめ方が丁寧で、AWS関連の本も良かったです。
今後読みたい本
ピックアップしたけれど未読で、そのうち読みたい本も沢山あります。
コトラー&ケラー&チェルネフ マーケティング・マネジメント 〔原書16版〕
ここにマーケティング全てが書かれてるらしいです。分厚いし高いですが、そのうち読みたい。
森岡毅氏の著作全て
森岡氏の著作は2冊とも非常に面白かったので、刊行されているあと4冊もそのうち読むつもりです。
特に『確率思考の戦略論』は、需要予測の分野とも深く関連するようで個人的に大変興味深いテーマなので、近いうちに読む予定です。
その他個別テーマの本
今回抑えられなかった各分野についても、一冊ずつくらい読んでいきたいと思っています。
- マーケティングリサーチ
- ブランディング戦略
- 価格戦略
- 需要予測
- マーケティング営業
- データドリブンマーケティング
僕がIPOプロジェクトにいた時に読んだ本
はじめに
私は以前、情報システム担当者としてIPOプロジェクト(株式の新規上場に向けた社内プロジェクト)に在籍していた事があります(現職ではないです)。
守秘義務があるので具体的な詳細については語れませんが、IPO一般の知見については、勉強や発信を続けたいと考えています。
今回はIPOプロジェクトに参加した頃に自分が読んだ本・Webサイトを記録します。
個人的に今後読んでいきたい本を記録します。
最も網羅性が高い2冊
まずはIPO実務についての網羅性が高い2冊です。
1冊目はIPO全般について書かれた書籍。
2冊目はIPOプロジェクトの中で高い比重を占める内部統制全般についての書籍。
個人で買うにはそこそこ良いお値段ですが、類書と比較して網羅性が高くコスパは良いと思います。
全て目を通さずに辞書的に随時参照するのでも良いですが、私はプロジェクトに参画前に二冊とも端から端まで目を通しました。
IPOの実務経験がない時点においては、少なくとも知識ベースは頭に入っているという事は自信になりました。
また、プロジェクト会議のときに、自分の管轄外の話題になっても眠くならずにすみますw
IPOの雰囲気をサクッと頭に入れる1冊
一般のビジネス書のようにさくさく読めて、IPOプロジェクトの目的や雰囲気をつかめる書籍です。
IPOに直接関わる予定がなくても、教養として読むのも良いかもしれません
情報システム担当者としてIT統制について学んだ2冊
IPOに必須のJ-SOX対応。その中でシステム担当者が大きく関係するのはIT統制の部分です。
私が参考にしたのはこの2冊です。
いずれも10年以上前の本ですが、見た限り極端に現状と乖離している部分は無さそうでした。
なお、IT統制と似て非なる概念にシステム監査がありますが、より必須なのはIT統制の知識です(システム監査の知識も無関係ではないので余裕があれば勉強して損はないと思います。)
財務・経理部門を支援するために読んだ2冊
情報システム担当者としての主な業務は先述したIT統制に関わる部分になると思いますが、IPOプロジェクトで最も大小の課題に追われているのは財務・経理部門の担当者です。
各種業務の効率化のために、ITの専門家としてシステムやツールについての助言を求められる事は多々あります。
どういった領域でどのようなツールを導入するのが適切かを考えるために、CFO向けのIT利活用の本を読みました。
また、IPOに向けて大きな課題となる月次決算の早期化についても学び、どのような支援ができるかを考えました。
なお、個人的には他の業務との兼ね合いで財務や経理部門の負担軽減には充分な成果が出せなかったというのが正直なところです。
私がIPOプロジェクトに今後また関わるかは分かりませんが、もし当時と同じような状況の方から助言を求められた場合に、より良い方法を提示できるように精進していきたいです。
ちょっと宣伝
唐突ですが少しだけ宣伝します。
私は現職で経営管理/管理会計のソフトウェアの開発やサポート業務に従事しています。本製品は、管理会計や予実管理や原価管理のシステム化において有力な選択肢となります。
これらの業務領域でお悩みの方は弊社の専門の担当者をご紹介できます。また、個人としてもご相談に乗れると思いますのでご興味ありましたらご連絡ください。
今後読みたい書籍
備忘のため、未読の関連書籍も列挙しておきます。
以下の二冊は、類書の中で評価が高いものなのでそのうち読みたいと思っています。
以下は、労務に特化した書籍です。
完全に専門外ですがそのうち読みたいと思っています。
他にも、IPOでは規程の整備も必須なので、社内規程の作り方についても基礎から学べると良い気がしています。
(社内規程作成についてオススメがありましたら教えてください)
Docker + Tomcat9 + Maven のローカル開発環境構築まで
概要
私は、Tomcat9 + Mavenを使った製品の開発をしています。
ソースコードがそこそこ大きいので、新しいライブラリを検証する時には最小構成の環境で試したい時があります。
そのため、Dockerでローカル開発環境を作りました。
環境作りの流れを作業ログとしてブログにまとめます。
また、テンプレートとして繰り返し使用する事を想定しているため、テンプレートリポジトリとしてGithubにあげています。
前提
- WSL2 上のUbuntuでDocker Desktopが使用できる
- Githubのアカウントがある
- Ubuntu : 20.04
- Docker-desktop Version : 4.13.1 (90346)
①Dockerコンテナ上でTomcatが起動するまで
1.ディレクトリの作成
mkdir docker-tomcat9-maven cd docker-tomcat9-maven
2.Dockerfileの作成
FROM tomcat:9-jdk11
Tomcat9系の検証をする必要があったため、Tomcat9を使用してます。
Tomcat10以降でServlet等のパッケージ名が変わるため、に移行するのは割と手間です。
何の制約もない場合はTomcat10以降を使用した方が無難です
3. docker-compose.ymlの作成
version: '3' services: app: build: context: . dockerfile: Dockerfile working_dir: /app ports: - "8081:8080" # Tomcatのポート。ホスト:コンテナ
4. Dockerイメージをビルドして起動する
docker-comose build docker-comose up -d # コンテナに入れるか確認 docker exec -it docker-tomcat9-maven-app-1 bash
5. Tomcatの起動確認
ブラウザでhttp://localhost:8081/ にアクセスするとTomcatの404画面を確認できます。
②Mavenの導入~アプリのデプロイまで
1. Mavenを導入する
docker-comose up -d docker exec -it docker-tomcat9-maven-app-1 bash apt-get -y update apt-get -y upgrade # mavenをインストール apt-get instanll -y maven # mvnのバージョンを確認する mvn -version #3.6.3
Maven – Maven Releases History
によると、3系の最新は3.8系。
ローカル環境なのでとりあえず3.6系でいい事にする。
apt-getを使わずに、curlでmavenの最新版を入手する事も考えたが、今回はやめておく
2. Mavenプロジェクトを作る
mvn archetype:generate -DgroupId=jp.gr.java_conf.tunemage -DartifactId=tomcat-sample -DarchetypeArtifactId=maven-archetype-webapp # less を導入する apt-get install -y less # pom.xmlが生成されている事を確認する less docker-tomcat9-maven/pom.xml
3. warファイルを生成する
cd docker-tomcat9-maven mvn package ls target
tomcat-sample.warが生成されている事を確認
4. デプロイする
cp target/tomcat-sample.war /usr/local/tomcat/webapps
ブラウザでhttp://localhost:8081/tomcat-sample/ に入るとJSPの画面が表示されます。
③生成したMavenプロジェクトを組み込む
1. dockerコンテナ内で生成した雛形をホストにコピーする
ホスト側で以下のコマンドを実行
# コンテナIDを調べる docker ps # コンテナからホストにファイルをコピーする docker cp [コンテナID]:/app/docker-tomcat9-maven/pom.xml . docker cp [コンテナID]:/app/docker-tomcat9-maven/src .
2. DockerfileにMaven導入の処理を追記する
FROM tomcat:9-jdk11 RUN apt-get -y update RUN apt-get -y upgrade RUN apt-get install -y less RUN apt-get install -y maven
DockerでRUNを多く記述するとレイヤが増えてパフォーマンスに影響するので、&&繋ぎにするなどの対応が必要となるが今回は端折る
3. docker-compose.ymlにホストとコンテナのボリューム共有を
version: '3' services: app: build: context: . dockerfile: Dockerfile working_dir: /app ports: - "8081:8080" # Tomcatのポート。ホスト:コンテナ volumes: - ".:/app" #ホスト:コンテナ
4. 再度イメージをビルドする
ホスト側で
docker-compose build
5. index.jspを修正する
<html> <body> <h2>Hello JSP</h2> </body> </html>
6.ビルド&デプロイする
docker-comose up -d docker exec -it docker-tomcat9-maven-app-1 bash mvn package cp target/tomcat-sample.war /usr/local/tomcat/webapps
7. 確認
ブラウザでhttp://localhost:8081/tomcat-sample/ に入るとJSPの画面が表示されます。
④テスト用サーブレットの追加
生成したプロジェクトには、src/main/javaディレクトリがない。
javaファイルが1つもないのはさすがに寂しいので、Srevletを追加しておく。
1. ディレクトリの作成
以下のディレクトリを作成する
2. pom.xmlにServlet APIを追加
https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api/4.0.1
からpom.xmlにコピペする
<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> </dependencies>
3. パッケージを作成
src/main/java下に、jp.gr.java_conf.tunemage.servletを追加する
4. Servletクラスを作成
シンプルなServletを作成する。
package jp.gr.java_conf.tunemage.servlet; import javax.servlet.http.HttpServlet; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.ServletException; import java.io.PrintWriter; import java.io.IOException; @WebServlet("/HelloServlet") public class HelloServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { PrintWriter out = response.getWriter(); out.println("Hello Servlet"); } }
Tomcat10以降は、servletのパッケージ名が、javax からjakaltaに変わります。
5. ビルド&デプロイする
mvn package cp target/tomcat-sample.war /usr/local/tomcat/webapps
6. 確認
ブラウザでhttp://localhost:8081/tomcat-sample/ に入るとJSPの画面が表示されます。
⑤Githubに追加
使い回せるように、Githubにテンプレートリポジトリとして公開します
1. GithubのトップページでNewボタンを押す
2. リポジトリ名を入力して「Create Repository」を押す
3. Setting を押す
4. 「Template Repository」をチェックする
5. git init
ホスト側のトップディレクトリでgit init
する
git init
5. .gitignore
ファイルを作成する
/target/ /.vscode/* /bin/
内容は随時追加する想定です。
6. Githubにpushする
git commit . git commit -m "first commit" git remote add origin https://github.com/tunemage/docker-tomcat9-maven.git git push origin master
7. Githubにpushされている事を確認
「Use This Template」ボタンを作成
以上です。
CloudFormationでカスタムルートテーブルをメインルートテーブルに設定する事はできない
はじめに
”できない”という事実をWeb上のドキュメントから見つけ出すのは、できる事を見つけ出すよりも苦労するのでブログに記録しておく。
結論
自分で作成したカスタムルートテーブルをメインルートテーブルにする事は、クラウドフォーメーションでは出来ない(2022年10月、AWSサポートに確認)
AWS CLIでメインルートテーブルに設定する場合
describe-route-tables — AWS CLI 1.26.0 Command Reference
でassociationを特定してから
replace-route-table-association — AWS CLI 1.26.0 Command Reference
でメインルートテーブルに設定する
AWS マネジメントコンソールでメインルートテーブルに設定する場合
当該のルートテーブルを選択して「アクション > メインルートテーブルを設定」を押す
↓
フィールドに「設定」と入力して「OK」ボタンを押す
自分の想像
そもそもメインルートテーブルは、ルートテーブルと明示的に関連づけられていないサブネットに対して関連付けられるルートテーブルになる。
なので、全てのサブネットを明示的にルートテーブルを関連付けておけば事足りる
「ここだけはCLIで」みたいな事はなるべくしたくないので、CloudFormationで環境構築する場合は明示的にルートテーブルとサブネットと関連づけるのが良い気がする。
今になって、CloudFormationに機能がないという事は、メインルートテーブルの設定はさほど重視されていないのだと思う(非推奨というわけではないらしいが)。
参考
Excel VBAのブラックボックス化を避ける設計の工夫
はじめに
現場のExcelVBAはEUCとか野良マクロとか呼ばれ、ブラックボックス化の温床のように言われる事があります。
この記事ではExcel VBAのブラックボックス化を避けるための設計・実装上の工夫について自分なりの見解をまとめます。
Excel VBAを業務で使う方にとって少しでも参考になると嬉しいです。
内容についてフィードバックをいただると更に嬉しいです。
私のVBA経験
自身の背景を書いた方が皆様の文脈に適用しやすいと思うので、私個人の経験を書きます(興味ない方は本節は読み飛ばしてください)。
私は前職で4年間、製造業の会社の社内SEとして仕事してきました。
人数の少ない部署だったので、自社システムの開発から社内のサーバー管理やアカウント管理など幅広く行ってきました。
社内ではたびたびExcel業務の改善の相談を受ける事があり、必要に応じてVBAの設計開発も行いました。
この期間に6つのVBAプログラムを開発し、そのうち3つは私の退職時にも現役で後任者に引き継ぎましつた(他は2つ基幹システム変更に伴い役割を全う。1つは残念ながらお蔵入り)。
それ以前にもVBAの経験がない訳では無いですが、社内SEとして直接ユーザーからフィードバックを受けた経験を経てExcel VBAを自信を持って使えるようになった気がしています。
Excelでゲームを作るとかWin32APIを呼び出すといった凝った事はできないので上級者とは言えませんが、一応数時間~数日で業務利用に耐える品質のアウトプットは出せるというレベル感です。
ブラックボックス化を避ける工夫①まずはVBA以外のExcelの機能で事足りないかと考える
「マクロを組んでほしい」と依頼されても「VBAで実装する」という先入観を持たずに、他の手段がないかを考えます。
マクロを書かずともvlookup関数、ピボットテーブル、条件付き書式などで事足りる事がよくあります。
例えば、元シートから列の配置を変更したシートを出力したいだけであれば、普通にセル参照するだけで実現できます。
特定の条件にあったセルに色をつけるのは条件付き書式で充分です。
集計をVBAで自動化する場合も、自力でループを書いて一時変数を使って集計するよりも、ピボットテーブルの機能をVBAから呼び出す方がシンプルかもしれません。
既に業務で使われてるマクロについても「これVBAでやる意味ないよね?」と思ったら、別の方法を案内して廃止を促す事も検討したいところです。
ブラックボックス化を避ける工夫②パラメータや変換表をシート上に記載する(コードに直書きしない)
パラメータや変換表といった変更の発生しやすい項目は、Excelシート上に記載してVBAから取得するようにするのが良いです。
例えば月次で変換処理を行うようなマクロは、以下の画像のようにユーザーがシート上でパラメータを変更できるできるようにしておけば、処理の都度プログラムを修正する必要がありません。
また「アウトプットのフォーマットには部署コードを出力したいが、インプットのフォーマットには部署名の項目しかない」というケースのいて、プログラム中の配列に対応表を書くのは悪手だと思います。
以下のようなシートを作成して参照するようにすれば、マスタの変更時に業務担当者がシートを直接修正できるので手離れの良いマクロになります。
↓私が影響を受けたと思われるツイート
VBAについては、以下の2点に気を遣うだけでも、メンテナンス性が相当改善されると思う:
— 杉本啓 (@sugimoto_kei) 2019年5月24日
①ビジネスロジックはVBAで書かない。ワークシートに記述する。VBAには、繰返処理、印刷など、ビジネスロジックに関係ない処理を担当させる。
②VBAからセル参照するとき、アドレスではなく名前を使う。 https://t.co/bEhC1ZTMNA
ブラックボックス化を避ける工夫③手動でも検算できるようにする
VBAのマクロを実行する担当者が、必ずしもVBAも知識があってデバッグできるとは限りません。
でも、少なくとも表面に出ているExcelシートの内容は理解できれば担当部署を調整すれば、仕様変更やバグ修正をVBAプログラマに依頼する時もスムーズです。
例えば
というように、各担当者が分かるシートになっているかを確認するのが良いです。
万が一エラーが出た時にVBAプログラマが不在だったとしても、業務を止めずにひとまずは手計算で乗り切れる体制にしておくのが理想です。
担当者が業務内容もよく分からず、機械的に毎月マクロを実行しているような状況だと、完全にブラックボックス化します。
ブラックボックス化を避ける工夫④計算の過程をシートに出力する(元データを直接変更しない)
元データのシートを直接変更するようなマクロを書くと、いざというときにデバッグできません。
手動でバックアップをとれば良いですが人間なので忘れる事もあります。
そうすると、保守担当者がバグを埋め込むのを怖がって変更を躊躇するようになります。
これに対し、元データの内容は変更せず、計算経過と最終計算結果は別シート(もしくは別ファイル)に出力するように設計すれば、処理が置いやすくなります。
格好良い言葉で言い換えると、べき等性のある設計が望ましいです。
最後に
当たり前ですがExcel VBAに限らず、体制や引き継ぎをミスればブラックボックス化します。
なのでブラックボックス化は主としてマネジメントの問題だと思います。
とはいえ上述してきたように、VBAの設計・実装担当者がブラックボックス化を防ぐために工夫をする事は可能です。
今後も一エンジニアとして、また一業務担当者としてExel VBAと上手く付き合っていきたいと思います。
VBAの機能がいろいろアレなのはあるにしても。
— はけた@できるExcel2021 4/1発売 (@excelspeedup) 2022年10月9日
根本的には、「担当者個人でプログラムを組もうとする人がVBAを使う率が高いから」VBAが属人化しやすく感じられるだけなんだろうとは思います。 https://t.co/S2YZlgzDq7
参考書籍
Excel VBAのオブジェクトや文法について体系的にを学ぶにはこの本が最高だと思います。
経理業務に適用するにあたってはこの本を参考にしました。
いちばんやさしいPowerPoint VBAの教本 人気講師が教える資料作りに役立つパワポマクロの基本 「いちばんやさしい教本」シリーズ
余談ですが、今入手可能な唯一のPower Point VBA本がこちらです。 Excel VBAの本は大型書店の棚が1つ埋まるほど無数にあるのに、Power PointのVBAの本は数少ないのですね。
一度だけPowerPointVBAを書いたのは貴重な経験でした。
【ポエム】メイン業務以外の業務について
メイン業務とは別の業務をやってきた理由
普段任されている業務とは別に、タスクフォースとか自社プロジェクトとか呼ばれているものがありますよね。
どういう風に呼ぶのが適切かは分かりませんが、自分が所属している部門の主な業務とは別に単発で依頼されたり、プロジェクトチームを組んで行われたりするあれです。
僕はこういったサブ的な業務には、できる限り手を上げるようにしていました。
理由は自分のスキルセットに幅を持たせたいからです。
悪く言えばどうせ同じ時間働くのなら色んな経験をした方が得した気分になるという貧乏性かもしれません。
今までにやってきたメイン以外の業務
僕が今までにやったメイン以外のお仕事で今思い出せるものは以下のようなものがあります
- 社会人向け講師業務
- 法務資料の作成
- 営業支援(展示会での自社プロダクトの説明)
- 確定申告(フリーランス時代)
- 自社ホームページリニューアルプロジェクト
- 社内勉強会の講師役
- スクラムマスター(1年半)
- QCサークルのリーダー(在庫管理)
- 購買管理業務の改善
曲がりなりにも意味のあるアウトプットが出たものに限定し、頓挫したものは省いています。
振り返って
基金訓練の講師として講義した経験は数年後に副業でプログラミングの講師をした時に役立ちました。
フリーランスで自身で確定申告を行った数年後に、会社の業務の要請から簿記3級を取得しました。
法務資料の作成業務はWordのレイアウトの仕組みを学ぶキッカケにもなり、社内SEとして情報システムの規程を整備する時に役立ちました。
社内勉強会で学んだアジャイルの知識を、転職後のチームの立ち上げ時期にスクラムチームを提案してスクラムマスターを担当しました。
好奇心の赴くままにやってきましたが、今ふりかえるとどの業務の経験も忘れた頃に役に立っているように思います。
計画的偶発性理論
個人のキャリアの8割は予想しない偶発的なことによって決定される。その偶然を計画的に設計し、自分のキャリアを良いものにしていこうという考え方。
(Wikipediaより)
上記の説明に集約されている通り、キャリアは偶然によって成り立っています。
転職が多い人は勿論ですが、同じ会社にずっといる場合でも、どのような仕事を任されるかはその時の状況次第で10年後を予測する事は困難だと思います。
サブで任された業務が、次のキャリアを考えるきっかけになったり、メインの業務になっている場合もあります。
僕も、前述の業務を断っていたら、今ほど仕事の広がりはなかったように思います。
勿論メインの業務を疎かにするのは論外ですが、はざまにある色んな仕事を「これは僕の仕事じゃない」と言って線を引くのは勿体ない気がしています