2020/1/29 
今回はこのブログを立ち上げた経緯編です。
先に弁解しておくと、今回はちょっと長いです。
それと前職のせいでカタカナ横文字に毒されていますが、ご了承ください。
目次
前職で感じた疑問
前職はITコンサルティングの会社でしたが、
ずっと自分の中でモヤモヤしている部分がありました。
それは、
「なんでITコンサルタントなのに、非効率な作業が多いの？」
ということです。
ITコンサルタントの矛盾
私の職場では、多くの社員が「コンサルタント」として、
「IT」の仕事をしていました。
その割に、自分の仕事をITでスマートにこなそうと努力している人を見かけることは少なく、
ましてやみんなの仕事をITで効率化しようとしている人は滅多にいない。
…一応擁護しておくと、前職はとてもいい会社でした。
オープンかつフラットな組織文化。
たくさんの人が仕事を楽しんでやっている。
待遇も大学の同級生よりずっといい。
特に私は運よく上司やプロジェクトに恵まれ、
評価してもらいながらも色んなことを勝手にやらせてもらえていました。
でも、仕事を楽しんでいる人は多くても、
仕事を楽しくしようとしている人はなかなかいないな、
というのが働きながら強く感じていたことです。
先輩からもらったメッセージ
一方で、職場の先輩からもらったこんなメッセージが心に残っています。
「世の中、自ら進んで勉強できる人だけではないですし、
また、勉強したくてもそのきっかけ（というか入り口）がわからない人もいます。」
これは私が会社を辞める時に、
とある先輩から送られてきたメッセージの一部です。
確かにその通りだと思いました。
事実、よく周りのメンバーから、
「どうやってこういうスキルを身につけてるの？」
という質問を受けましたが、いつも
「ググれば出てきますよ」
と答えていました。
何故なら、特定のページに答えが全て載っていたわけではないからです。
なぜ「自分でググって」と答えてしまうのか
アイデアの具体化から実装に至るまでには、
いくつかのキーワードで検索し、
いくつかのページを開いて理解し、
必要な情報だけをいくつか掻い摘む、
という作業の繰り返しがあります。
つまり一言で明確な回答ができないのです。
「今度一緒にやってみよう」
とか言って手取り足取り教えてあげられれば一番いいのですが、
1人1人の単価がプロジェクトの原価となるITの現場で、
同じタスクに2人もつけるような贅沢なことはできません。
そう言った実情から出てしまう言葉が、「ググって」だったりします。
でも実際のところ、複数人が同じ情報を持っているというのは、
チームプレイが大事なプロジェクトにおいて後々有益だったりもします。
知識をコンポーネント化して公開したい
そこで考えたのが、私が学んだ知識のコンポーネント化です。
自分がやったことのコア部分と応用例をため込んで、
いつでもどこでもだれでもアクセスできるようにし、
各コミュニティへの導入時には業務への実装部分だけ配布する。
私はよくプロジェクト管理ツールとAPIを使ってゴニョゴニョしているのですが、
例えば別の職場でも同じ工夫をしたいときには、
「○○を自動化しませんか？」
「お金はかかりません。詳しくはこれ読んでください。」
「実はすでにある程度作っています。こんな感じです。」
このコミュニケーションで済みます。
さらに周りの人々が興味を持ってくれれば、
「この前○○に使った仕組みを利用して、△△も改善できないかな」
と言った展開を期待できます。
実際、前の会社でも私の取り組みをリーダーにアピールし続けたことで、
顧客業務の一部にそれを利用できないかと相談してもらえ、
実現できたことが何度かありました。
同様に周りのメンバーにもアピールできていればもっと良かったのですが…。
閉じた情報はすぐに風化する
前の職場ではプロジェクトのwikiに勝手に色んなことを書いたり、
みんなにツールを送りつけたりしていました。
でもこういった活動は、
結局のところプロジェクトの中に留まり、
プロジェクトの終了と共に消失して、みんなの思い出話と化してしまいます。
私自身、一度しかやってないことは自分の手を離れると同時に忘れいき、
次同じことをやろうと思いついてもキャッチアップから始まることがほとんどです。
コア技術と実装は分離させるべき
ということで、改善に使うフレームワークやコア技術と実際の導入部分は、
分けて管理しておくのが理想だと思います。
エンジニアの方ならわかってもらえると思いますが、
MVVMでいうところのMがコア技術、
Vが現場の人々が触るもの（ツールやWEBアプリ）、
そしてVMが、実際の導入部分なイメージです。
記事を書くときにも、これを意識して書いていきたいと思っています。
こうすれば、
どの職場に行っても最小労力で仕事を効率化することができます。
また周りの人々にも仕組みを伝えることで、
私には見えいていなかったような非効率な作業に対して、
なんらかの改善案を思いついてもらえるかもしれません。
仕事だけに留まらないメリットがある
さらに昨今ではスマートホームやらライフハックやらと、
仕事だけでなく人生そのものを快適に、効率的にしようという流れが大きくなっています。
私自身、自宅のスマートスピーカーにアプリを実装・導入しているので、
時代の流れに乗ってこれらのナレッジも同様に発信すれば、
仕事に留まらず、人生そのものを快適にできると考えました。
ブログを仕事につなげたい
さて、ここまでで私が「ネットに記事を投稿しよう」と思った経緯について書きました。
これだけであれば、正直Qiitaとかに記事を投稿していれば達成できます。
ではなぜわざわざ「AutoHacks」というパッケージにしたのか。
正直に言えば、この発信を仕事に変えたいというのがその理由です。
自分で仕事を作れる人間になりたい
これまでの私の経歴は、
全て会社という大きなブランドに支えられて成立していました。
プログラミング未経験で入った私でも3桁の単価で仕事をもらえていたのは、
会社のブランドに対し顧客から絶大な信頼があったからに他なりません。
今後も私は会社の一部として仕事するわけですが、
一方で徐々に独り立ちしていきたいという思いもあります。
そこで、会社の名前以外に自分の名刺や経歴に刻めるものがないかと考え、
出てきたのがブログ運営でした。
業務で活かした技術は外から見えづらい
自分がどんな技術を持っているかというのは、
職務経歴書や面接ではどうしても伝え切ることができません。
これは転職活動だけでなく、
複数のプロジェクトを渡り歩きながら感じたことでもあります。
例え同じ会社であったとしてもプロジェクトが違えば、
自分の作ったものをフルオープンにすることはできません。
なぜなら、それは多くの場合顧客資産であり、
またそうでなくとも、顧客の機密情報を多分に含んでいるからです。
成果に定量評価を与えたい
「それなら何をやったかでなく、
どんな成果を出したかアピールすればいいじゃん！」
…と思ってしまいますが、これまた難しい問題です。
常にチームプレイであるために、
成果に対する自分の貢献の割合が算出できないのです。
自分の成果にフォーカスを当ててしまうと、
多くの場合それは極めて定性的であり、
相手に評価を委ねることになっていしまいます。
そんなとき、自分のやったことを記事にしてPVを得ていれば、
真水ではないものの、その価値を定量化することができます。
だからこそ自分でブログを立ち上げ、多くの人に読んでもらい、
私のそれぞれの経験に客観的な評価を与えたいのです。
仕事獲得の導線にしたい
いろいろと述べましたが、正直これが大きいです笑
独立に向けて継続的に実績を作っていくにあたって、
このブログを仕事受注の導線に組み込みます。
直近の投稿はツール紹介や小技など、
仕事につながらないようなものが並ぶと思いますが、
定期的に複数ページに渡る大作を投稿します。
そして業務効率化に悩んでいる企業様や、
とにかく手数が足りない！という方に届けたいと思います。
またWEBからの受注でなくとも、
ツテでいただくご相談に対する名刺の一つとして、
このブログが機能すればいいなと思っています。
ということで、AutoHacks始めます。
