トップ > misc

アリエル・ネットワークを退職しました

misc

今月末をもって2年4ヶ月働いたアリエル・ネットワークを退職することにしました。

あるとき同僚とお昼ご飯を食べていて、私より後に入社した2人の同僚が私のブログを読んで入社を決意したという話を聞きました。

なんか書いた責任みたいなのも感じたため、辞めましたというのを書いておこうと思った次第です。

アリエルは良い会社だと思います。社員数が100人に満たない会社なので個人の裁量は大きいですし、周りの人や身近な部署が何をやっているのかが見通せて、組織間の横串も通しやすいです。開発者の視点からみたとき、一緒に働いている同僚に嫌な人がいなくて、同僚の技術スキルが高いというのが魅力的です。

Be the Worst

cLabs

という言葉があります。私にとってのアリエルの開発部はそんな場所でした。

いずれマネージャーをやってほしいという展望で採用されていましたが、結局は開発ばかりやっていました。お仕事なので良いことも悪いこともありますが、ある種の閉塞感があって、モチベーションの低い状態で働くよりは潔く辞めることにしました。

なんとなくいま思うのは、良いマネジメントというのはその世界を広げることなんじゃないかという気がします。

やったこと

開発したもの

プロダクトのコンポーネントのうち、5つほどコンポーネントオーナーとして開発に携わりました。

以下の3つのコンポーネントは、私がプロダクトである開発プラットフォーム上にスクラッチから開発したコンポーネントです (外部からみえるもののみ紹介) 。ようやくお客さんに使われ始めてこれからユーザーフィードバックがくるのにとか、あの機能も作りたかったなと心残りはあってすごく残念な思いがあります。またそれを引き継ぐ同僚へは迷惑をかけることになるので申し訳ない限りです。

1. 動画ストリーミング機能

Red5 のリポジトリが google code から github へ移行された後、Windows インストーラーの生成スクリプトと RPM パッケージの生成スクリプトを コントリビュートしていました 。それが認められて、数日前に Red5-Installer リポジトリへのコミット権が付与されました。

せっかくの申し出なので快諾しました。今後もできる範囲で何かしら貢献していこうと思います。

2. 外部システムとのデータレプリケーション機能

  • アプリレベルの、完全内製で作ったもののため、外部に出せるものがなかった ... (/ _ ; )

3. システム監視ツール

インターンシップ生のメンター

毎年1ヶ月半ほど、wikipedia:インド工科大学 という大学から3回生のインターンシップ生がやってくるのでその面倒をみました。親会社が面接やらライブコーディングやらで選抜した学生のみを招待しているのもあり、とても優秀な学生たちでした。もっとうまく指導してあげられたら、という反省が多い経験でした。

私はほとんど英語を話せませんが、1年目のときは自分の英語力が低いからうまくいかないと自己嫌悪になりつつ考え込んでしまっていました。2年目はその失敗を反省して、周りにも協力を仰いだり、日々彼らの進捗にあわせてカリキュラムを作ったりしていました。そのうちに英語とか関係なく、そもそも就業経験のない21歳の学生に対して、会社での業務開発にいきなり入っていくという高いハードルをいかに手引きするかということの方がずっと大事だと気付きました。

英語力が低いことでより高次の会話ができないのは事実だけれど、だからと言ってコミュニケーションが取れないというのはちょっと違うんじゃないか。日本語でやり取りしていても、開発プロジェクトで認識違いが普通にあります。インターンシップ生とやり取りも本質的にはそれと同じだと気付いて、それからはずいぶん自分の心持ちが楽になったことがありました。

Trac のインフラ管理

もともとは社内に Pythonista が少ないというのもあり、私が管理した方が良いだろうと自主的に始めました。普段の業務での開発は Java と JavaScript がほとんどで、たまに Python や Ruby といったスクリプト言語でツールを作るといった感じでした。業務でそこそこの規模のサーバーサイド開発をしていると、たまに息抜きしたくなるんです。

そこで Python ですよ！

Trac という、Python が書ける対象があったのでストレス解消的な位置付けでプラグインを作ったりしていました。Trac の良さの1つにプラグラインが簡単に開発できるという利点があります。気分転換にちょっと作って、社内で運用しているからユーザーフィードバックもすぐに来て、自分も便利になって、なんかすごい楽しい！みたいなっ ... 業務のイテレーション開発の隙間に気分転換でやっていたのがうまくまわっていたように思います。

良かったこと

働いていて一番何をしたかと思い返すと、とにかくソースコードを読んだことだろうと思います。

コードを読んで読んでも分からないことがあったり、見当違いのところを無駄にデバッグして遠回りしたり、すごい人たちはどうやってソース読むんだろうと先輩の背中から見てたり、とにかくコードを読むという体験が私にとって一番良かったなぁと振り返って思うことです。

忘れる体験

どこかの雑誌の記事で"米国の平均的なプログラマーが把握できるソースコードの量は1万行だ"というのを読んだことがあります。

ひらメソッド - LinuxKernelHackJapan

プロダクトのコードベースの規模が大きくなると本当に忘れるんです。ひどい場合は、例えば1年前に自分が修正していたという事実すら忘れていることもありました。そうすると、当たり前の話ですが、忘れていてもコードを読み直してその意図を理解できるかという可読性の重要さに気付けたわけです。

頭で理解しているのと実際の体験から得られるものの差異みたいなのがちょっと分かって良い経験でした。

直せない体験

他の人の書いたコードを自分のコードと同じくらいよく理解することはできない。どんなに熱心に読んだとしても、それは単に読んだというに過ぎず、書いたわけではないのだ。だからコードのある部分が複数の人によって書かれていたとすると、それは誰によっても一人の人に書かれたコードほど深く理解されることはない。


そして他の人もいじっているコードは、安全に再デザインすることができない。

頭の中にプログラムを入れる

他人が開発したコンポーネントを引き継いで1年半ぐらい保守開発やサポートもしました。

そうしていると、そのコンポーネントの全体像や振る舞いは把握できるようになって、この仕組みは潜在的に不具合になりやすいとか、ここは汎用的な仕組みに置き換えるべきとか、いくつか抜本的にリファクタリングした方が良いというところは分かってきます。

けれど、これがまた再デザインというレベルでは結局手をつけられませんでした。

自分が作ったものでないと、(前任者がいない状態で) コードからいまに至る変遷 (歴史的経緯) とその意図を完全に把握するのは困難です。チケットやコミットログをちゃんと書いてないのも論外です。

いわゆる「動いているコードは触るな」ですね。

具体的には以下のようなものを初期実装者がやっておかないと、他人が正しく再デザインしようというモチベーションになりにくいと実感できました。

  • テストを書く
  • 仕様を書く (ドキュメント)
  • 依存関係を小さくする
  • 意図を明確にする (可読性)
  • がんばって作り込み過ぎない

読めない体験

code is read much more often than it is written.

PEP 8 - Style Guide for Python Code | Python.org

Python 2 では文字列を str と unicode という2つのデータ型で扱いますが、文字コードを扱う処理のベストプラクティスとして、外部との境界で文字コードのエンコード／デコードを行うというものがあります。コード内では全て unicode 文字列を扱い、(ファイルやネットワークなど) 入出力のときに適切な文字コードに変換します。このプラクティスを無視して、コード内のあちこちで文字コードのエンコード／デコードをやっているツールがありました。

そういうツールで文字コード周りの問い合わせがくると、コード上のある時点で str と unicode のどちらのデータ型なのかの判別が難しく、あちこちに型チェックのコードが散らばり、結果的にデータ型や文字コードに依存した処理も所々に実装され、上述したベストプラクティスに従うにはツール全体をリファクタリングしないといけないという、どうしてこうなった状態が出来上がってしまっていたわけです。

Python みたいな言語だと、そんなコードを読むより実行してデバッグした方が確実だと読まなくなりました。毎回コードを読み始める度に「またこれか、、、」みたいな気持ちになって辛いわけですね。

これは顕著な例ですが、たぶん可読性の悪さと設計の良し悪しはそれなりに因果関係があるのでしょう (そういう理論があれば教えてください) 。もちろん最初から良いものを作れというわけではなく、可読性が悪かったらなにかが間違っているんだと直感的に信じて、どんどん直していく姿勢をもつ方が結果的に良いものができるような、何となくそう思うようになりました。

まとめ

そんな感じでお仕事ばっかりやってたのでしばらくは息抜きしようと思います。

アリエル・ネットワークに入社しました

misc

9月からアリエル・ネットワーク (以下アリエル) に入社しました。

以前、アルバイトで3ヶ月半ほどお仕事していました。以下はそのときの手記です。

さて、最近こんなツイートを見ました。


どうやら私がアルバイトをしていた頃から少し経って、最近たるんでいるようです。

これはまた締め直さなければ、、、

と思っていたら入社の初日から先制攻撃を受けてしまいました。ほんとに怖い会社です、、、

寝坊したんじゃないです！初日に入館できる手続きをするから9時に来てと言われてたんです (> <)、朝組イメージを払拭するために、朝何時に来ようが本当はどうでも良いです。生産性を上げるには、人によっては (私もそうですが) 朝型で取り組む方が効率的だったりもしますが、それよりも (自分にあった) 規則正しい生活を続ける方が安定したパフォーマンスを発揮できて、結果的に生産性が上がります。

閑話休題。私はこれまでフリーランスの経験もあわせると7社で働いてみました。それぞれの会社の特徴や文化の一長一短があり、どの会社が優れているとは一概に言えませんが、どの会社が自分の考え方やキャリアの方向性と最も一致しているかということは言えます。私はやはりプログラマーとしてのキャリアをもっと突き詰めたいし、チームメンバーよりもコードを書いて、チケットをクローズしまくるマネージャーが普通にいるアリエルのような職場が魅力的でした。

エンタープライズ分野のパッケージ販売という、ソフトウェア開発の王道とも言える業務に対して、これまでの経験を活かして何ができるか。結果的に過去のキャリアでは、最長3年と、中長期的な展望をもって開発に取り組むことができなかったことが私の中での課題であり、未知の領域でした。それは結果論であって本意ではなかったのですが、次に働くところは中長期的な展望をもって開発に取り組める企業にしようと決めていました。

ひとつ自己努力だけで容易に学べないものがあると思っています。良い開発プロセスを経験できるかどうかです。良い開発プロセスとはウォーターフォールできっちりやるという意味ではありません。社内の開発者がどれだけ合理的にプロセスを改善しようとしているかが重要です。会社にそういう文化があるかどうかです。開発プロセスは日々の行動の積み重ねなので、勉強会で話を聞いたり本を読むだけでは限界があります(わかった気にはなれますが)。

2013年度、アリエル新卒募集が始まりました | ありえるえりあ

実際、私が働いた7社の中で最も優れた開発プロセスをもっていたのもアリエルでした。開発プロセスの改善というのは、技術力やその知識以上に、会社の財務基盤や業務としての開発文化、そして上司の理解が必要になります。いわゆる wikipedia:技術的負債 を抱え込まないために必要なことは誰もが分かってますが、中長期的な開発計画がないと、そもそもそんな投資はできません。また、短期的な利益とのトレードオフになるため、そのバランスを取ることが難しいです。

これまで、私は独りで開発してきたことが多かったので、チームでの開発プロセス改善やその在り方を模索していけることも今後の楽しみです。

最後に1つ。

エキスパート職に関する仙石さんの見解は単純かつ明解でした。エキスパート職の職能は、まわりに良い影響を与えられるか、だと言いきりました。

マネージャになりたくないプログラマのキャリアパス | ありえるえりあ

これは私の中の「すごい人」理論にも通じます。

どこの会社にも優秀な方はたくさんいますが、本当にすごい人はあまりいません。職場にすごい人なんか滅多にいません。私が思うすごい人は、会社の枠や多少の損得なんかの概念を超えて、さらなる高みへ行ってしまうような人たちです。別の言い方をすると、自分でリスクを取って行動し、結果を出しても、さらに先を目指すような人たちです。

アリエルにはそういった人たちが何人もいますし、私もそんな人たちを目標に切磋琢磨していきたいと考えています。

結局のところ、何かおもしろそうだ、という直感は生きていく上で大事なものなんだと思います。

アリエル・ネットワークでアルバイトをしてきました

misc

3ヶ月半という短い期間でしたが、アリエル・ネットワーク (以下アリエル) でプログラマーとしてアルバイトしてきました。

よく見かける、どこそこでインターンシップをしてきました風な記事を書いてみます。普通はそういった記事を学生さんが書いているものですが、この記事は普通の無職の人が書いています。

最終日に「開発方法論提案 改めアリエル開発の所感」というタイトルで発表しました。

私が過去にいくつかの会社で働いてきた中で、アリエル開発で改善したら良いと思うことがあったら提案してほしいと言われていました。とはいえ、私の経験よりもアリエル開発の方がずっとレベルが高かったため、釈迦に説法な気がして、そんなタイトルに落ち着きました。この記事では、その内容からいくつか抜き出して紹介します。

私がやったこと

アリエル・エンタープライズ という Web アプリなグループウェアの開発に携わりました。

Trac でアサインされたチケット (バグや機能拡張) に対して修正するといった感じです。4-5年ぐらい開発を継続しているらしく、製品としての中核や部品、UI はかなり作り込まれていました。そのため、自分でコードをガリガリ書くというよりは、製品の動作や仕組みを理解するためにコードを読んで原因を特定したり、既存のコードを再利用して機能拡張するといった開発作業がほとんどでした。

製品の規模もコード量が数十万行というオーダーの、私にとってはこれまでで最も大規模なアプリケーションでした。開発を通して、大規模アプリの設計、ソースコードの読み方、Java のイディオムも少しずつ分かってきておもしろかったです。

アリエルの開発は、プロダクト系の開発だと Java、UI 系の開発だと Javascript がメインのようです。ただプロダクトと連携するツール類は Ruby や Python で書かれたものもいくつかありました。なので、業務で Java か Javascript しか書けないというわけでもありません。試験的な取り組み、プロトタイプ的なツールなどは、開発者の好みの言語で実装できそうに思えました。実際、私自身も Python でプロダクトと連携するツールを実装しました。

アリエル開発の良かったこと


開発体制／インフラ

雑誌や書籍で見かける類いの開発手法を当たり前のように業務の中に取り入れてました。開発インフラが整っていると、開発者はこんなに楽なんだということを実感しました。

また、開発者にとっての業務の中心は Trac です。チケット管理、wiki、ドキュメント、レポーティング (グラフ)、技術メモなど、かなり活用されてました。会社として開発情報を統合的に一元管理しようという意図をもって Trac に集約していて良い考えだなと思いました。

そんな中、チケットが分裂・派生していき、手動で関連チケットのリンクを張るのが煩わしくなって TracTicketReferencePlugin も作ってみました。これはアリエルの 10% ルールという枠組みの中で開発したものです。アリエルの Trac で耐えたら、世の中では大丈夫だろうと個人的に思っています。

仕様の決め方


アリエルの開発における仕様の決め方に、最初は戸惑ったのですが、これはこれで良いこともありそうだと後になって考え直した次第です。緩い感じに仕様を策定していきます。

バグ修正的なチケットは、バグを直せばいいだけです。大きな機能追加は全く違った開発プロセスを歩むので、ここでは書きません。適切な粒度の機能追加的なチケットは、大まかな方向性は決まっていますが、詳細は決まっていません。基本は担当開発者がまず、外部仕様策定から始めます。仕様は、チケットをあげたヒトやプロジェクトマネージャ、プロダクトマネージャと相談しながら決まっていきます。プロダクトマネージャがこうしたいと思っても、表向きは担当開発者が決める形になっています。ただ、あまりにも紛糾していて物事が進まないときは、偉いヒトの強権が発動されます。

http://blog.pasonatech.co.jp/ootani/105/17869.html

然るべき人が、ちゃんとした仕様を決めて、一方的に押し付けるというよりは、そのチケットの関係者が議論しながらより良い仕様に作り上げていくといった感じです。この過程を厳密にシステム化、もしくはプロセス化しないことで関係者間のコミュニケーションを促進している面もあると私は思いました。困ったら関係者のところへ行って「これってどういうことですか？」と聞くしかありません。そこで要件の齟齬や考え方の違いを認識して、やり取りから開発者も学ぶ、視野が広がるといったことに繋がるように思いました。

組織的な牽制機構

その緩い仕様の決め方にはもう1つのメリットもあります。



組織的な牽制機構が働かないと、ほとんどの組織は堕落します。

組織が1つだけだと、なぁなぁになってしまいます。組織が2つだと、けんかして対立関係になりがちです。組織が3つで、相互に牽制する関係が私の開発経験の中では、結果的にうまくいっていたように思います。アリエルもそういった3つ巴的な体制になっていて良さそうに私は思いました。但し、組織が分かれると、情報共有されなかったり、生産性が落ちたりするので、横の連携の工夫が必要になります。

会議がなかった

私がアルバイトだったこともあるかもしれませんが、会議がほとんどありません。こんなに会議がない会社も初めてでした。週報も書かないので、週例ミーティングがなく、グループミーティングのようなものもありませんでした。意図的に会議を減らしているように思いますが、開発に集中してたら1日中全く話さなくて終わるような日もあったかもしれません。

しかし、月に1回の開発部の全体会議がいまいちでした。私からの唯一の提案は、どうせやるならちゃんと全体会議をやった方が良いですという当たり前の意見を述べてみました。

また、Trac の活用度が高いため、開発の進捗状況やいろんな数字が出せるので、そういった数字からビジョンを語ると良いのではないかと偉そうなことを言ってみました。実際に Trac 上ではロードマップを管理して、バーンダウン・チャートも出力されていました。

パッケージ開発は長期的な展望をもって開発するので、普通の開発者は何を目指して開発しているのか、いまどういう状況なのかがよく分からなくなることがあります。何かしら開発者の意思統一を図るというか、共有するためにビジョンが必要です。ビジョンを語るのはとても難しいことですが、かっこいいビジョンばかり語っても本当の意味ではよく分からないので、実際の数字から現状分析や今後の方向性を語ると分かりやすくて良いのではないかと私は思います。


まとめ

・・・

この記事そのものは特に何かを伝えたいわけでもないのですが、アリエル開発の雰囲気が少しでも伝われば良い、、、のかな。

発表後に CTO がやってきて「その資料、公開しても良いです。公開するしないの判断は任せます」という謎なコメントを残して去っていきました *1 。そのまま公開しても中の人でないと、半分ぐらいは意味が分からないので補足を加えながら、自分の考えも整理してみました。

アリエルの文化はアドベントカレンダーを辿ってみると、おもしろいと思います。

開発者も募集してるようです

私から見ると、開発者にとっては居心地の良い開発環境、職場だと思います。いやな人がいない。

まずはアルバイトからも受け入れているようです。興味のある方は応募してみると良いと思います *2 。

*1:勝手にクックパッド vs. アリエル | ありえるえりあ

*2:アリエル・ネットワーク社の選考や採用に私は全く関係ありません

本当の本当は誰が怖い！？

misc

好評につき続編です。はい、嘘です。

先日、 本家Ariel Advent Calendar 2011 *1 の記事を書きましたが、今回は 元祖Ariel Advent Calendar 2011 *2 を書きます。このブログに読者という方々がいるならば、一体何をやってるんだろうか？と首を傾げたくなるでしょうが、大丈夫です。私自身、その意味も意図も、理由すら分からずに書いています。

今北産業

なぜか CTO が本家からあぶれてしまい、元祖を立ち上げて所謂、骨肉の争いに突入しました。
そして、ダークサイドに落ちたありえるたんの *3 、闇えるたん (@) も現れ、三竦みの陣容を取っています。
私は日々、3強の影に怯えながら、ひっそり開発を継続しています。

番長の暗躍

なるべく私は目立たないように開発していますが、たまに番長に見つかってしまうときがあります。

これは Trac のチケット管理のやり取りです。

とめさんをいじめて退職させる

とめさんは要領は良くないものの、がんばってテストをしていました。何とも残念なお話です。

リグレッションを起こした開発者への指導

私がある機能拡張を行った際に、そのスキーマ定義が完全ではなくて、別の箇所でリグレッションを起こしてしまいました。一旦は、私宛に担当を割り振ったものの、私が直す前に番長に修正されてしまいました。

つまらんミスをしやがって。もうお前にコードは触らせない。

と、言われているようなものです。

闇えるたんの胎動

行動がまったく読めません。

インドへ旅立った CTO を追いかけて行って闘いを繰り広げているようです。

闇えるたんよ。覚悟なさい | ありえるえりあ によると、会社ブログもクラックされたようです。

CTO との軋轢

もちろん CTO と社員との諍いも絶えません。

悪のりするときは、とことん悪のりしたら良い。

という総帥の教えに従います。

もともとアドベントカレンダーのイメージはこうでした *4 。

CTO がインドへ行った間隙を突いてコラージュされました。

もうやりたい放題です。

CTO は、きっと反攻の策を練っていることだと思います。

組長の真実

どうやら組長と呼ばれる人もいるそうです、まぁ、私なんですが。

一説には組長も怖いという風評があるようですが、それは明らかな間違いです。

組長は、ただ朝早いだけで人畜無害です。朝早くきて、ひっそりと開発に明け暮れてるだけのようです。

まとめ

かなり内輪感の強い内容を紹介しました。

開発というお仕事は、時にどうして良いか分からなくて不安に陥ったりします。世の中、本当に怖いことはたくさんあります。どんな状況であっても、心にゆとりをもつこと、ユーモアを受け入れること、おもしろいと思えることが大事です。

アリエルという会社の、そんな雰囲気が伝われば良いなと思います。

*1:本当はどっちが怖い！？ 番長 vs CTO - forest book

*2:元祖Ariel Advent Calendar 2011 | ありえるえりあ

*3:http://blog.repl.info/2011/12/22/ariel-tan/

*4:GIMPであそぼ〜なりゆきと結果編〜 - は な う た でオリジナル画像の作成について紹介されています

本当はどっちが怖い！？ 番長 vs CTO

misc

アリエル・ネットワーク さんでアルバイトをしています。

以前、経営者が「エンジニアの楽園を目指す」と喧伝していた会社で働いたことがありますが、社内の、開発者の雰囲気はそれに近いものがあります。

会社として Ariel Advent Calendar 2011 : ATND を行っているので、私も社内の雰囲気が分かるエピソードを書いてみます。アリエルの開発者の記事は ありえるえりあ | 上から読んでも下から読んでも・・・ で読めます。

番長とは

アリエルの開発マネージャー (？) で、Python コミュニティでは 番長 と呼ばれている方がいます。

私が初めて出会ったのは、Python Code Reading 10 という勉強会で発表したときでした。その後、番長が発表された 第10回InfoTalk 「Python Twistedフレームワークで始める非同期ネットワークプログラミング」 に参加したり、勉強会やイベントで会ったりしたのが縁でアルバイトさせてもらっています。

社内ではラスボスと 呼ばれている ようです。いいえ、実際には呼ばれていません。みんな 怖くて そう呼べないので、文章中でのみ登場する想像上のあだ名です。ラスボスを倒さないとエンディングに辿り着けません。アリエルの開発者たちは、そのために技術力を磨き、仲間を集い、日々がんばっています。

CTO とは

そんな番長にも怖い存在がいるようです。それは CTO です。

私は以前から番長のブログを読んでいたのですが、ことあるごとに CTO は 怖い と書かれています。いくつか紹介します。

僕は昔から優しいんですがね。アリエルではCTOが一番怖いですよ。

http://blog.pasonatech.co.jp/ootani/17831.html

CTOは歴代のプロジェクトマネージャの中でも異色のマネージメントで現場に混乱と狂気をもたらしたのです

http://blog.pasonatech.co.jp/ootani/199/14879.html

先日、私も CTO の怖さを発見しました。

アリエルのスタート地点は、Javaと聞いて、ふっと鼻で笑える地点です。

新卒向けカリキュラムで出す課題 | ありえるえりあ

ちなみに新卒の最初の課題は wikipedia:エイト・クイーン だそうです。

実は仲良し？疑惑

番長と CTO は、よく一緒にお昼ご飯を食べに行っています。

私もちょくちょく同行していますが、ぱっと見た感じでは結構仲良しです。お二方の名誉のために断っておきますが、お昼ご飯を食べに行って、怖い思いをすることはありません。ご飯を食べているときにエイト・クイーンを実装しろとは言われないので、安心してください。

よく出る話題としては、

番長は怖い人だ。

と、

CTO が本当は怖い。

です。

私はどっちも怖いです。

アルバイトは見た！

先日、現場を見てしまいました。

社内でのメールのやり取りで CTO がこんなことを言いました。削除されないよう、証拠としてスクリーンキャプチャを取りました。

なんと！ CTO は自分が Devil *1 だと言い出しました。これが混乱と狂気の始まりか。もうエイト・クイーンを実装しても許してくれそうにありません。

Devil 宣言をして、開発者を蹂躙し始めた CTO に対して、番長の反撃はこうでした。

アリエルは 怖くて楽しい 会社です。

明日のアドベントカレンダーは @ です。

*1:Devil's advocate

退職

misc

君は気付いた。様々な言柄と事柄に導かれながら。だから。気付かなかった頃にはもう戻れない。後は、君が選ぶ事だ

xxxHOLiC 百目鬼 遙

3月末日をもって、いまの職場を退職することにしました。

シンプルにおもしろいことを見つけて、やれる環境があって、やれる自分がいるんだったら、やってみようというだけです。

とは言え、1社だけ思い入れのあった Web 系企業の中途採用に応募してみましたが、結果は不採用でした。いまの自分の技術力ではやっていけないという現実を知る機会にもなり、しばらくはお仕事せずに技術力を高めようという覚悟も決めました。

これまで働いてきた中で周りと比べると、自分はお仕事が好きな方のタイプなのかなと漠然と思っていました。けれど、ここ3年ぐらい、勉強会や OSS 開発やコミュニティ系の活動に関わってきて、ちょっと違うなということに気付きました。何か課題があって、それを解決するのが楽しくて私はお仕事をしてきた面が強かったように思います。いまはお仕事とは違う領域でもっとおもしろい課題をたくさん目の当たりにするようになってきました。

それと同時に自分に足りないものがたくさんあることも分かってきました。分からないことがたくさんあり、もう少し体系的に学習する必要性をずっと感じていました。私は怠けものなので日頃だらだらしてることも多いです。自分に言い訳できない環境の方が集中力をもって良い状態を維持できるだろうと考えました。

すぐに何かを始めるわけではないですが、いまの活動の延長上でその枠を広げたり狭めたりしながら、自分はどうやって生きていくかをもう少し切実に考えてみようと思います。

というわけで、しばらくは修行期間に入ります。