リレーショナルデータベースと存在論

社内の Qiita::Team に投稿したポエムなんだけど、公開して欲しいという声もあったし、別に公開して問題のあるところはないので公開することにした。


長らくデータベースの主流として使われてきたリレーショナルデータベース(RDB)のスキーマ設計は、事象の存在と向き合うことである。そういう意味ではとても深遠で哲学的な営みだ。

f:id:a_suenami:20150131160443j:plain

いや、待って欲しい。僕の頭はおかしくない。ちょっと説明する。

データベースの用語と存在論の用語は近い

例えば RDB のテーブルのことを「エンティティ」と呼んだりする。存在論において「実体」を表す用語だ。

カラムのことを「アトリビュート」と呼んだりする。これは存在論においてエンティティの「属性」を表す用語である。

このように用語だけとってもみても RDB と存在論が近い関係にあることがわかる。

「人間」の主キーは一体何か

以前、おもしろい議論をしたことがある。

「人間の主キーは一体何か?」

住民台帳にユニークな番号があるでしょ?と思ったあなた。海外在住の人はどうなりますか?生まれたばかりでまだ出生届けを出していない赤ん坊はどうなりますか?

適当に連番振ればいいじゃんと思ったあなた。Rails に慣れすぎです。わからなくはないんですが今議論したいのはそういうことじゃないです。とりあえずSQLアンチパターン3章「IDリクワイアド(とりあえずID)」を読むことをオススメします。

DNAの情報を記号化できればユニークだと思ったあなた。惜しいですね。一卵性双生児はDNAが同じです。

指紋なら完全にユニークだろ!と思ったあなた。例えば事故にあって腕から先を失くしたした人や指先を酷使して指紋がすり減ってしまった人は人間と認められませんか?

ある事象の存在をどのように特定するのかというのはとても難しい問題で、僕らが普段身近に接している「人間」という存在だってこれだけいろいろ考えて、それでもこれだというユニークなキーは見つからない。だから普通は世界を絞り込むために制約を設ける(例えば日本人に限るとか、役所への届け出をもって存在してるものとするとか)し、もっと設計をシンプルにするためにサロゲートキー(代理キー)、つまり Rails で実装されているような連番の id を使ったりする。

リレーショナルデータモデル

RDB の背後にあるのはリレーショナルデータモデルというデータモデルで、数学的に言うと関係代数と一階述語論理をベースにしている。

リレーショナルデータモデルにおける「リレーション」をテーブルとテーブルの関係だと思っている人はよくいるがこれは誤りで、リレーションは属性(つまりカラム)の関係のことを指す言葉で、平たく言うとテーブルやビューのことである。それは数学的に言うと「ある時点においてある命題が真となる事実の集合」を表すのだけど、そのときに「存在が確実じゃないものは存在しないものとして扱う」という前提がある。これを閉世界仮説という。

要するに何が言いたいかというと RDB はその成り立ちというか背後にある数学的理論からして「ある事象の集合」を扱うものであって、それ以上でもそれ以下でもない。そしてそれらの事象をどのように表現するかとか、どのようにモデリングするかということを考察するうえで存在論の話が出てくるのもおかしな話ではないし、本質的に「存在」を扱うデータモデルなのである。

お詫び

なんかもうちょっと伝えたいことがあった気がするんだけど全然わけのわからない文章になった。今では反省している。

仕事を楽しむ

前職の会社が人事査定の季節ということなのでちょっと昔話を兼ねて思ったこと書いてみる。

僕の前職の会社は半年に一度人事査定面談があって、所属しているチームの事業責任者と所属している職種のリーダー(僕の場合はエンジニアリーダー)の面談を受けていた。

そのときに「今期、仕事をする上で心がけたことは何か?」という質問があり、僕はそれに対して「楽しく仕事をできるように意識してました。」と回答した。

その発言は今でも覚えてるし、今でも同じことを意識してるし、実際転職した今でも本当に楽しく仕事ができてるのでちょっとエントリ書いてみようかなと思った。

仕事を選ぶということ

そういう風に言った意図は、仕事は自由に選べないし、どうせ選べないんだったらそこにある仕事の中で自分が楽しめるように考え方を変えたほうが幸せだってことだった。

そのときの上司にその意図が伝わったのかどうかはわからないけど、でも「その考え方はおもしろいね。その考え方は大事にして欲しい。」と言われたのは覚えていて結構嬉しかったなというのを覚えている。

前職の会社、受託開発の会社としてはエンジニアにとって心地いい環境だった*1し、ある程度これやりたいあれやりたいという主張は通っていたけど、それでも自由に仕事を選べていたかというとそんなことはない。これは別に Dis ってるわけではなくて受託開発という構造において空いている開発リソースと人手不足のプロジェクトがあれば当然そこにアサインが発生するし、それを断ることは基本的にできないし、まあしょうがないよねとは思う。

もちろんもっと仕事を選ぶ選択肢はあったと思う。自ら営業活動をして自分が一緒にやりたいと思う顧客を開拓するとか、マネージャに立候補して社内の制度を変えていくとか、パッと思いつくだけでもいろいろな「仕事を選ぶ」方法はある。もっと極端に言えば起業して自分がやりたい事業をやるとか、転職してそもそも違う会社で違う業務をするというのも「仕事を選ぶ」方法のひとつだ。ただ当然だけど責任と裁量は同時に発生するわけで、その責任を自分が負ってまでそれをやりたいかというとそうではなかった*2し、そこまで大きな不満もなかったので僕はそれをしなかった。

ただ大きな不満はなくても目の前にある仕事に小さな不満はあった。というか、仕事をするということは小さな不満の連続なのではないかと思う。まったく不満がない仕事が本当にあればそれはすばらしいことだと思うけど、それは改善の余地がないつまらない仕事の可能性もある。改善は常に不満から生まれるわけで、不満がなければそれ以上の改善はない。

そんな小さな不満を改善につなげ、それ以上大きな不満になることを未然に防ぐ方法がその仕事を楽しむということだった。いつからかどんな仕事でも楽しんだ者勝ちだと思うようになっていた。

僕の今のお仕事

僕は今の会社で広告の仕事をすることになった。いわゆるアドテクというやつである。いつまでこの仕事をやるのかわからないけど、メディアを運営してる会社にとって広告って収益の柱だし、そこにアサインされたということはまあしばらくはここにいるだろうと思っている。

僕にとって完全に新しいフィールドで今猛烈に勉強をしているけどこれがなかなか楽しい。どういう風に楽しいかはまた別の機会にお伝えできればと思うが、とにかく楽しい。

もともと広告がやりたかったというわけでもないし、今の会社にジョインしてから決まったアサインではあるんだけど、それでもこれだけ興味が持てているというのは我ながらすごいことなのではないかと思っていて、丁寧に業界のことを教えてくれる仲間たちに感謝するとともに、前職で意識的に仕事を楽しもうとした結果でもあると思う。

スキルや経験は掛け合わせれる

今の僕みたいに畑違いの分野に来てよくわからない状態だったり、あるいは苦手意識を持ってる分野の仕事だったり、嫌いな仕事だったり、そういうときは自分の好きなもの・興味あるものと掛けあ合わせれば大抵の仕事は楽しむことができると思ってる。

例えば僕はソフトウェアテストとか好きだったりするし、モデリングとかも好きだったりする。そうすると広告配信の品質をどうやって担保するんだろうとかよく考えるし、アドテクノロジーというドメインの分析をやってみたくなったりする。

広告に関しては僕は(現時点では)ド素人だけどその分野に自分の興味領域を掛け合わせると見えてくるものがきっとあって、これからもそうやって楽しめる領域を広げていくんだろう。

*1:勝手なイメージかもしれないけど受託って営業が強いイメージがある。

*2:結果的には転職をするという道を選んだわけだが…

転職して2週間くらい経った #DevLOVE

このエントリは DevLOVE Advent Calendar 2014 「越境」 の 1/21 のエントリです。もう何日目かわかりませんw

僕は 11/12 にも書いたのですが、今月転職(=越境)したので 2 回目を書くことにします。

ちなみに 1 回目のエントリはこちら。

前日はきょんまるさんの「越境ノススメ のこと。」でした。

ちなみに

このエントリは転職エントリではありません。転職エントリはこちらです。

このエントリでは、それから2〜3週間経ちどんな変化があったのか書いてみたいと思います。

受託開発から自社サービス開発への越境

一番わかりやすい変化はそもそものビジネスモデルの違いでしょう。今まであまり意識しなかったですが実際受託開発からサービス開発へ変わるといろいろな違いがあります。

作った機能の多寡によって売上や利益が決定するビジネスモデルだと作るものの複雑さや作り方は非常に興味の対象になりますが、作るものの意図や作る目的については意識が向きづらいです。もちろんこれは個人の価値観にも依存するのでそれについて真摯に向き合ってる人もいるとは思いますし、前職の会社でも実際そういう人はいましたが、「会社として」「絶対に」向き合わなければいけない課題にはなり得ないのでどうしてもその意識にバラつきが出てしまうものです。

一方、今は目的が達成できさえすれば作り方は基本的に自由にできますし、複雑性のコントロールもわりと可能だったりします。逆に作る目的や事業意図がわかっていないとそれができないので、そういった意図や目的をより強く意識するようになりました。

その結果、この DevLOVE Advent Calendar 2014 「越境」の 1 回目のエントリで書いたようなことが実現しやすい環境になったと思います。

何が必要か/本当に必要かがわかるまでは開発しないか最低限の開発で検証を重ねるのがいいと思いますし、その結果コアドメインが姿を表したらユビキタス言語を構築してモデリングをするべきでしょう。逆にノンコアドメインについてはフレームワークや既存のパターンを使って低コストに済ませてしまうのがよいと思います。

このようなイテレーティブにサービスを開発していくというスタイルは納期と予算が明確に規定されている受託開発では難しかっただろうなと思います。

アジャイル

開発スタイルの組織のあり方も変化がありました。僕が理想としているアジャイルのあり方にひとつ近づいたかなと思っています。

前職でも、カンバンや朝会、TDD、CI などのいわゆるアジャイルプラクティスと呼ばれるものはいくつか取り入れていましたし、ある程度は柔軟で機動力のあるチーム作りやプロセス作りはできていたと思いますが、うまくプラクティスを使いこなせてないと思う点もありましたしまだまだ改善できるなと思っていた部分はありました。

転職してから今僕がいるチームでよかったと思う点はいくつかあるのですが

  • スプリントバックログにストーリーが入った時点でチームメンバー全員が実現するべき内容(Definition of Done)を理解している
  • 事業戦略や KPI の変化によって組織が柔軟に変わる
    • スキルや意識が固定化せず、常に全体観を把握していられる(気がする)
  • スキルの違い、役割の違い、得手不得手はありつつもそれを対話で解決できている
    • 堅苦しいルールや重たいドキュメントが無駄に増えたりしていない(気がする)

といったことを感じています。

これも事業意図や目的をちゃんと意識しているメンバーが揃っているからこそそうなってるのだと思いますし、サービス開発をしている人たちからすれば当たり前のことなのかもしれませんが、僕にとっては大きな越境でした。

ビジネスとの距離が近い

これも先に述べたことの延長というか結果的にそうであるということなのですが、開発とビジネスの距離が非常に近いと感じていて、僕にとって非常に居心地がよいです。

開発チームが開発で閉じることなくビジネスと近い距離にあればそれだけ設計空間が広がりよいシステムを作れると思いますし、それができる環境であるということを嬉しく思っています。

「ビジネス」というとすぐにマネジメントを想起する人がいますがそんなことは絶対になくてソフトウェアアーキテクトとしてドメインのあり方を理解することは大事ですし、そことの距離が近いことはすばらしいことなのだと考えています。

最後に

まだまだ時期が浅いのでチームのあり方についても事業のあり方についても僕の理解が間違っていることがあるかもしれません。それについてはあらかじめご了承ください。

今回の越境を通してさらなる成長を目指したい所存です。

次は kimKimmy さんです。よろしくお願いします。

スキルの境界線の話

先日、前職の先輩と一緒に飲んでたときにスキルの境界線の話したのでそれについて思ってること書いてみる。

以前にも似たようなこと書いた。

結局言いたいことはこのエントリと同じことなんだけど、転職して(まだ数日だけど)チームのあり方の違いとか考えるところとかあるのでもうちょっと詳しく書いてみる。

忙しい人のために先に結論

  • アーキテクチャは市場で何が求められているかによって最適な形が変わる。
  • アーキテクチャのあり方が変わるとそれを効率的に設計・構築するために最適なスキルのあり方も変わる。
  • Conway の法則によれ組織のあり方はアーキテクチャのあり方によって規定されるべきである。つまり市場のあり方が変われば理想の組織のあり方もスキルのあり方も変わる。
  • 似たようなスキルセットを持った人たちによってエコシステムが形成される。

要求の変化や技術の変化

アーキテクチャは基本的にその時代によって変わる。たかだが5〜6年程度しか業務としてソフトウェア開発をしていない若輩者なので説得力ないかもしれないけど、直接関わったことはなくても文献で各技術の栄枯盛衰について調べたり、年上の先輩エンジニアの方の話を聞いたりして僕なりに考えた結果としてこれだけは間違いないと思っている。

ユーザが求めるものが変われば当然それを満足するためのアーキテクチャは変わるし、要求そのものが変わらなくても技術の変化によってそれまで高い技術力が必要だったものがお金で解決可能になったりする。例えば PC 中心だった世の中からスマートフォンタブレットが中心的デバイスになったのは前者の好例だし、SaaS や IaaS によってサービスやインフラを安価に調達可能になったのは後者の好例だ。

スキルの境界の変化は随時起こる

理想のアーキテクチャが時代によって変わるんだから当然それを使うために必要なスキルも変わるし、その境界線も変わる。以前も書いた。

僕が最近感じてる「スキルの境界の変化」はこういうことだ! - assertInstanceOf('Engineer', $a_suenami)

あるスキルと別のスキルの間にはそれぞれ近さ/遠さがあって、その近いものをまとめた一連のグループが「職種」として定義されると思っているのですが、世の中の変化によってそのグループは変化すると思うのです。当然そのとき、自分のコアスキルの活かし方が変わるし、境界の向こう側にあったはずものを身につけないと自らの専門性が立ち行かなくなったりするのではないかと。

さらに最近思うのはこの境界線を超えるとそこにはきっと別の「チーム」があって、そこはある程度堅めのコミュニケーションが必要だと思う。スクラムのように対話を中心としたコミュニケーションでアジリティを保って問題を解決していければそれはすごくいいことだけど実際にそれが可能なのはそこにいるメンバーのスキルがある程度近い場合だけだと思っていて、境界線を超えた向こう側のスキルの持ち主との間のコミュニケーションはもう少し堅めのドキュメントが必要だったり、形式的な業務フローが必要なのではないかと思っている。

その流れを最もよく表しているのが microservices ではないかと思っていて、以前読んでおもしろいと思った記事を一部引用させてもらう。

microservicesに分割する際に注意するべき5つのこと - Qiita

最初に紹介したcookpadの記事では、導入に「conwayの法則」が紹介されているなど、十分に意識されていたと思いますが、microservicesへの分解は、実のところ組織パターンの問題です。

ある程度大きなサービスになり、多くのメンバーが関わるようになると、領域別にチームが編成されることが多くなります。チーム間の調整コストが増大すると開発は遅滞しやすくなり、大きな変更をすることや継続的な改善を行うことが難しくなります。

スキル境界線の内側でエコシステムができる

アーキテクチャが変わり、スキルの境界線が変わると、その境界線の内側、つまり似たようなスキルセットを持った人たち同士でコミュニティが構成され、エコシステムとして機能するようになる。そのアウトプットは OSS かも知れないし勉強会やカンファレンスの類かも知れないしいろいろあると思うんだけど、いずれの形にしてもこれはその業界やその技術領域の発展にとても寄与していると思っている。

逆に言えばある組織がこのエコシステムを構成してる範囲と違う境界線を独自に引くのはこのコミュニティの恩恵を受けられないという意味でかなり辛いことだと思っていて、スキルの境界線がどこにあるのか、その結果どういうエコシステムが構成されているのかを意識し続けるのはとても重要なことだと思う。

結論(再掲)

  • アーキテクチャは市場で何が求められているかによって最適な形が変わる。
  • アーキテクチャのあり方が変わるとそれを効率的に設計・構築するために最適なスキルのあり方も変わる。
  • Conway の法則によれ組織のあり方はアーキテクチャのあり方によって規定されるべきである。つまり市場のあり方が変われば理想の組織のあり方もスキルのあり方も変わる。
  • 似たようなスキルセットを持った人たちによってエコシステムが形成される。

アジャイルは青い鳥

結論

アジャイルは青い鳥だし、隣の芝は常に青い。

ランチのときにアジャイルについて話した

昨日、ランチのときにアジャイルで開発やった話とかそれぞれの経験談について話したけど、自社サービスやってた人たちから見るとあれは受託開発のほうがやりやすいんじゃないかとのこと。

僕が前職で受託開発やってた頃はみんな自社サービスじゃないと無理と言っていたし、やはり隣の芝は常に青いんだなと感じた。

それだけ。

でも僕らは隣の芝をチラ見しながら、きっとこれからも青い鳥を探し続けるんだ。

ファクトリアルを卒業して Peroli にジョインしました

タイトルの通り、株式会社ファクトリアルを卒業しました。2014/12/26 が最終出社日で、本日が Peroli 初出社日でした。

このエントリは僕の生まれて初めての転職エントリになります。

ファクトリアルという会社、Peroli という会社

ファクトリアルは Web 系の受託開発をやっている会社です。

株式会社ファクトリアル | fact-real, Inc.

社員数は 40 名程度でしょうか?うち 10 名程度がエンジニアという環境で、職種間の軋轢や政治的なしがらみもあまりなく、アットホームで働きやすいよい職場でした。

一方、新たにジョインする Peroli(ペロリ)は mery という女性向けのキュレーションサイトを運営する会社で、昨年 10 月に DeNA に買収され傘下に入った会社になります。

僕とファクトリアル

僕はこの会社で前職の頃から少しお手伝いをさせてもらっていて*1、その後フルタイムの正社員となりました。フルタイムになってから丸 4 年、その前も含めると延べ 5 年強いたことになります。

元々経営陣が学生時代にお世話になった先輩たちでありお互いによく見知っていたということもあったので、特に何の不安もなく入社しましたし、当時の僕の技術力を考えればもったいなさすぎるくらいの評価をいただけたと感じています。それから時が経ち、4〜5年の在籍期間の中で出来る仕事も増えてそれなりに当時の恩を返すことができたのではないかと思います。

僕は学生の頃からよりよいチームを作ること、そのメンバーとして自分が参画することに非常に興味がありました。それについては以前書いたエントリにいろいろ書いてるのでよかったら読んでください。

僕がファクトリアルで働き始めたとき、それは本当に理想的なチームに見えて憧れを抱いたと同時に、この会社でチーム作りのノウハウを学べば僕の人生にとって非常に大きな経験になると思いました。それは間違ってなかったと思っていて、4 年間いろいろなプロジェクトを経験していろいろな人と仕事する中で学べたことは大きかったと思いますし、チームとしてよい関係を築けた人も何人かいて本当によい出会いが数多くありました。

何故転職するのか

何故転職するのと言われると理由はいろいろあって、かなりの時間をかけて他の可能性(≒違う会社)と比較・検討し、それぞれの選択肢を吟味した上での決定なのでこのエントリだけですべてを語れないのですが、特に大きな点を 2 つ述べたいと思います。

これまでと違うチーム

ファクトリアルの組織体制はとてもおもしろかったし僕にとって刺激的だったんですが、昨年くらいから違うチームでもやってみたいと思うようになりました。

ファクトリアルは、受託開発である都合上、受注とともにプロジェクトチームができ納品したら解散するという感じだったので、社内のほとんどの人と一度くらいは一緒に仕事をしたことがあるという状態で、結果として部署間の変な軋轢やしがらみの生じにくいとてもよい環境だったと思います。小規模なプロジェクトであれば1ヶ月や2ヶ月という短期間でチームが構築・解散されることもあるのですがそのサイクルををうまくまわせる人たちが揃ってましたし、それはベースとなる価値観や意識がしっかり共有できていたということの結果であるとも思います。また、あるプロジェクトでの反省が別のプロジェクトで改善されたりして、会社全体として前進していこうという意識も見えて誇りに思っていました。

そんな恵まれたチームの中にありながら何故それを変えようと思ったかというと大きく

  • より長期的に「よいチームを作る」ということについて考えたい
  • アーキテクチャとチームの関係性について考えたい

という 2 つがあります。

短期間でチーム構築と解散を繰り返すという組織のあり方は先に述べた通りよい仕組みだったと思いますし、実際にそれがちゃんとまわっていたということ自体がすごいことだと思っていますが、長期的にチームの改善していくという経験はしづらく、アジャイルコミュニティなどで得た知見を活かす機会がなかったというのが 1 つ目の動機です。

またアーキテクチャの選定もチームが短期間で変わる前提に立つとある程度汎用的で世の中に情報が多く出回っているものにするバイアスが働きやすかったため、要求に対して最適な技術を選定できていたかというとあまり自信がないというのはありました。 Conwayの法則として知られる組織パターンがありますが、それによれば「組織がアーキテクチャに影響を与えるのではなく、アーキテクチャが組織に影響を与えるべき」であり、それを実際に実践したかったというのが 2 つ目の動機になります。

「成長」の経験

僕は前々職で一応起業を経験してるんですがその際はビジネスがスケールする前に抜けてしまいましたし、ファクトリアルは受託開発を主としているというビジネスモデルの都合上そもそも爆発的にビジネスが大きくなるということはありませんでした。そのため、僕はこれまでの人生においてビジネスが成長するということ・組織が拡大するということを経験しておらず、それに対するコンプレックスと強い憧れがありました。

そういう意味で今回新たにジョインする Peroli にはすごくよいタイミングで誘っていただいたと思っています。ビジネスは急成長していますが組織の人数はまだ極端に多くはなくこれからいろいろな人が入ったりいろいろな問題が顕在化したりして、成長することの酸いも甘いも経験できると思っています。

ファクトリアルの皆様へ

長い間本当にありがとうございました。お世話になりました。

最終出社日に同僚何人かと飲みに行きましたが、「22時までなら!」とか「終電まで!」とか「1〜2杯だけですけど…」とか言ってた人たちが結果的には余裕で終電を越えて、みんなで朝までカラオケしてました。わりとこういうノリ当たり前になってしまったのでありがたみがなくなってきてしまってたのですが、これって実はすごいことで本当にありがたいことだなぁと思ってます*2。みなさん、本当にありがとうございました。

Peroli の皆様へ

これからお世話になります。よろしくお願いします。 初出社日からみんなで初詣行ったりランチ行ったり楽しかったです。

個性的なメンバーの中に入り、それなりに期待されているようなので実はかなりプレッシャー感じてますが、自分らしさを出しつつサービスの向上に向けてがんばっていきたいと思います。

例のリスト

こちらになります。皆さま、どうぞよろしくお願いします!

http://www.amazon.co.jp/gp/registry/wishlist/1XWXWEARJ5I8P/

2015 年は「持たざる生活」をモットーにしようと考えており、こちらのリストも一新しました。基本的に消耗品を中心に、書籍は Kindle を中心としています。

2015/1/6 7:20 追記

Kindle 本はギフトにできないということでもうひとつのウィッシュリストを公開しました。ご指摘いただいた皆さま、ありがとうございます。

*1:出稼ぎみたいなもんです。

*2:まあ僕に対するアレコレじゃなくて自分たちが飲みたい&歌いたいだけだった可能性高いんですけどw

あけましておめでとうございますのポエム

新年あけましておめでとうございます。本年もよろしくお願いいたします。

いろいろな方々が Facebook やブロク等で 2014 年を振り返っているのを見ながら僕は沈黙を貫いていたわけですが、それは別にシカトしてたわけでも面倒くさかったわけでもなくて、一体どういう風に振り返ればいいかわからなかったからなのです。

ただせっかくだし何か書いて形に残しておきたいのでちょっと文章化するの難しいんですけどエントリに起こしてみることにしました。よくある今年の抱負エントリみたいに具体的な目標を掲げるつもりはない*1です。もう少し精神的なものです。

直近 3 年くらいの僕はがんばってなかった。

だいたいこの時期になると「昨年は○○でした。来年は…」とか「次は○○をがんばります!」とかという話になりがちなんですが、悲しいかな、今の僕はそれを主張できるほどがんばったことも達成したこともないのですね。

それも当たり前で昨年は大した目標設定もせず、元日には Facebook でこんなことを言っているのです。

f:id:a_suenami:20150101215324p:plain

これは思えば 2011 年か 2012 年あたりからそうで、わりと自分でも意識的に充電期間と位置づけていたような気がします。

まわりの人たちが出世したり、結婚して子どもができたり、起業してその会社が成長したり、いろいろ変化がある歳だからこそそういうのに焦ったりもしましたけど、まあ人は人だしと自分に言い聞かせていたりしてました。だからこそ、わりと面倒くさがりのキャラを作ったりもしたし、「充電を邪魔されないこと」だけは全力でがんばるという年だったと思っています。

特に目的意識がなかったので人と会うことにはたくさん時間を使った。

ゆるゆると過ごしていたここ数年は、何かのスキルを身につけるとか、何かの知識を増やすという方向性ではなく、とにかくいろいろな人に会うことに時間を使っていたと思います。特定の方向性がなかったからこそ専門性も背景も人となりも違う人と話をしたり飲んだり、場合によっては一緒に仕事をしたりできました。

その中でいろいろな価値観を知って考えの幅が広がったと思っていますし、自分と異なる考えの人や違う専門性を持つ人とどう付き合っていけばよいのかということを学べたと思っています。

よく何かを目指すことや何かに到達することを道を歩くことに例えますが、そのメタファーを使うならばここ数年の僕は歩く道を決めて前進することにではなくいろいろな曲がり角や分岐点を知って自分の持っている地図に描かれている範囲を広げることにがんばった時期だと言えます。

今年はがんばると思う。というか、がんばらざるを得ない環境になると思う。

さて、そして今年以降ですが、そろそろこの充電期間に終止符を打とうかと思っています。今年は大きく環境が変わる予定で、それによってがんばらざるを得ない状況にきっとなってしまうでしょう。

そろそろ地図だけ広げてもしょうがないかなと思うので自分の足で進んでいきたいと思いますし、まわりの友人たちの活躍に対する焦りも大きくなってきたのでそろそろアクセルを踏んでいってもいいかと。

しばらくゆるゆるとやってきたのでしばらくはいろいろ慣れないかもしれないですが、2〜3年くらいは修行期間と位置づけて改めて自分の足腰を鍛える機会にしたいと思っています。

皆様、本年もよろしくお願いたします。

*1:というか、今年は自分にとって大きく環境が変わる予定なので具体的な目標設定は現時点では難しいです。どういう風に環境が変わるかは追ってご報告します。