ziguzagu.org

ブログを自分も開発にメインで関わっていたMovableType.netから、Emacs org-mode + ox-hugo + Hugo + Netlify という形に移行した。

古いブログの記事も全部MT形式で書き出して、スクリプト書いてorg-modeフォーマットに変換したのだけど、text_hatena形式で書いていた記事とかなんかいろいろあって、スクリプトが想定より壮大になってしまった。Markdownで書かれた記事も書き方いろいろでやたらHTML混ざってるものとかあったりで、まぁいろいろ一苦労だった。

とはいえ移行してみると最高。

  • すべての記事が手元にプレーンテキストとして存在している
  • org-captureですぐに下書き始めれる
    • ウェブの管理画面にいって書き始める最初の「どっこらしょ」がない

この2点による体験が素晴らしい。

これでもう少しカジュアルにブログ書いていけるかな?

昨日職場でちらっと話していた、個人的に気をつけているというか回避しようとしてることに、SQLアンチパターンにのってそうな名前をつけてみた(文体もそれっぽくかいてみる)。

SQLに限った話でもなく純粋にクラス設計のアンチパターンともいえると思う。

目的:デフォルトで否定したい

デフォルトの挙動が否定側のような意味や、否定となるレコード数が支配的になることがわかっている場合そのままの意図をテーブル名やカラム名に持ち込みたくなる気持ちも理解できます。

アンチパターン:否定的な単語をつけtrueをデフォルト値としてしまう

create table awesome_functions (
  disabled bool not null default true
);

スキーマだけ見ると「ふむ」と一瞬納得しかけるが、コード上では結構えぐいことになっている or なっていくはず。

if !awesome_function.disabled?
  # 一部の人はイケてる機能を実行
end

あるいは以下。

unless awesome_function.disabled?
  # 一部の人はイケてる機能を実行
end

否定の否定は、何をしたいのかそれはどのような条件なのか書いた本人がその瞬間しかわかりません。もしくは本人もよくわかっていない可能性が高く、自分で嘘をついたのかどうかすら判別不能のはずです。

アンチパターンの見つけ方

否定形の接頭詞(dis-、non-、not-、un-、im- など)が現れた場合はすでに危険が及んでいます。 否定的な単語(failed、negative など)が現れた場合、ひょっとしたら何かを間違っている可能性があります

アンチパターンを用いても良い場合

それがユビキタス言語でありドメインを理解している関係者にとって自然な場合には用いても良いかもしれません。 (が、自分の経験上は思いつきませんでした…)

解決策:ポジティブに

カラム名の場合

ほとんどの場合ポジティブな単語に入れ替え値を反転させるだけで意図や条件はより伝わりやすくなります。

if awesome_function.enabled?
  # 一部の人はイケてる機能を実行
end

すでに存在してしまっているものについては反転した値を返す肯定形で別メソッドを使いそちらを標準的に使うことでコード上での問題はある程度回避できます。

def enabled=(val)
  disabled = !val
end

def enabled?
  !disabled?
end

テーブル名の場合

ORM の機能をつかってテーブル名に否定形単語がはいったまま肯定形単語のクラスとすることもできるかもしれませんし、チャンスがあればテーブル名を変えることも検討できるとよいですが、おそらくはそのタイミングでクラス名や場合によってはそのオブジェクトを保持している変数名まで変更せねばならず、影響範囲がかなり大きなリファクタリングを行うことになってしまいます。しかもロールバックがしんどい。

この場合は、過渡期を経て新しい肯定形の名を関したテーブルに移行する計画を立てましょう。それに価値が見合うのであれば…。

まとめ

うそ発見器にかけられたときのようにすべてを「No」で答える必要はありませんし、「No」が正解となる答える前提で質問を考える必要はありません。

前向きに人生をおくりましょう。

トレタ Advent Calendar 2018 の1日目(初日から遅れ書いてる…)の記事として、コードの品質ということについての短文ポエムをだらだら書いてみる。

『Code Complete』、『リファクタリング』、『リーダブルコード』などなどコードの品質的なものを対象として書かれた書籍は結構あって、ほぼ同じようなことかいてあったりもするのだけど定期的に出版されて、自分もついつい買ってしまうたぐいの書籍の一つ。

これらの書籍でよくある分類はこういうやつ。

  • 読みやすさ
  • 理解しやすさ
  • 美しさ
  • テストのしやすさ
  • メンテナンス性
  • 堅牢性
  • 拡張性

整理する、知るという観点ではこの分類大変よい。

ただ、結局このたぐいの内容は日常で実践する自分のスキルとしたいわけで「習慣化できるかどうか」にかかってる。習慣化するというのは、

  • 一回やれば覚えれるような小さなこと
  • 何度もその場面に出くわすこと

というのが結局ある。で、重要なのは後者で、最初に実践する際の少しのコストを惜しまずに出さないと一生コードの品質はあがらない。例になるコードが結構近くにあってそれを参考にコード書いてしまうこともままあるけど、その際に、もう少し良くならないか?を考えることがなければ、スキルは伸びないし品質も上がらない。

コードの品質については上に書いたように「習慣」でできることが多く、習慣化されてるとほぼコストがゼロなものも多い。となると、そこには品質とスピードのトレードオフ、といったものはない。できる人はコストかけなくてもできる、できない人は時間かけてもできないし、品質の意図的な上げ下げは上げたことがある人しかできない。

コードに限らず「品質」というのはなにかひとつで大きなものを生み出すことはなく、小さなことの積み重ね。当たり前のようにやってる毎日のことに疑問感じて、課題を探しに行って、改善に取り組むことでしか差はつけられないので、結局その瞬間瞬間で何考えながら生きていくかってことになる(極端)。


疲れも溜まってるし眠いしで深夜に書き始めたらまったくとりとめない文章になったけど、書いてなんぼのアドベントカレンダーなのでこれでよし。

今年は公私共に人生最大級で忙しく、またブログを書くのが年1になってしまっており由々しき事態だけど、来年はいくつかの状況を打破して自分の時間を少しでも多く技術に投資できるように画策して、ブログも書いていきたい。

この記事はトレタ Advent Calendar 2017の25日目の記事です(2日遅れ…)。

これはなに?

トレタで約半年間 VP of Engineering という肩書(実質的な活動はそれより前からやってたので約1年くらい)で活動した結果、選択ミスだったかな?というのをまとめてみる試み。

前置き

トレタ入社以後、自分が今の役割である VP of Engineering をやるまでに以下のような役割、役職の変化があった。

  • 2016年4月: サーバーサイドエンジニアとして入社
  • 2016年7月: 他部署や他社からの技術に関する問い合わせ窓口担当、採用担当
  • 2017年5月: エンジニアリングマネージャー
  • 2017年7月: VP of Engineering

そして VP of Engineering という職位は 「人・組織のアウトプットを最大化する」 という役割を担うために作られたもので、そのときに役職名と Job Description をセットで提案したものだった。

VP of Engineering という職位が違う役割をもっている場合には当てはまらない。かもしれない。

アンチパターン 1: Playing VP of Engineering

ここで言う Playing は「業務として特定のプロダクトのコードを書く」の意。

人事を中心にみるといえど、VP of Engineering になる多くの人は現エンジニア、または過去にエンジニアだったという経験を持つはず。個人的にはそうでない人がエンジニアの上長として信頼を得るというのは、よほどの魅力があり、対話力があり、人望がある、いわゆる人間力の塊のような人ではないかと思う。それくらい、エンジニアとの上下関係における信頼構築の基礎となるのは技術理解だと思う。

そのひとが業務として特定のプロダクトに開発メンバーとして参加、コードを書き続けようとするとどうなるか?

答えは、簡単といえば簡単。どちらも中途半端になる。

プロダクトのコードを書くという点については、エンジニアの頭数に(うっかり)カウントしてしまうことでプロジェクトの進捗を滞らせる、という事態に陥る。

加えて本業であるべきはずのピープルマネジメントの部分については、プロダクト開発ほど明確・定量的なゴールが設計しづらいため結果として時間的優先度が下がってしまい、ケアがおろそかになることで問題発見がおくれたり、対応が後手になったりする。

さらに、この役職には部署長としての総務業務(勤怠管理や各種申請の承認)や採用関連の業務なんかも一緒にくっついてくるはずで、思っている以上に業務範囲が広い。ますますコード書いてる時間はない。

こういったことを繰り返せば、メンバーからの信頼はおろか、経営層からの信頼もなくなり、あげくプロジェクトの遅延、予算計画未達みたいな自体にまで発展しかねない。そうなると自身の精神的なダメージはもう取り返しの使いないところまで行くと思われる。

おそらくこれが最悪のパターンのはず。

VP of Engineering になったら業務としてコード書くのは(ひとまず)やめておこう。

アンチパターンを用いてもよい場合

基本的に期限のないものや、いつかやりたいリファクタリング、あったらいいよねというテスト、みたいなところのコーディングについては、ありかもしれない。

が、それも本番にデプロイして問題おきたり CI をとめたりする事態に陥ると即対応が必要なので、やはりできれば避けたい。

アンチパターン 2: Technical Management -> People Management

「テクニカルマネジメント」という用語が適切かどうか、というのはおいておく。役割としてはサービスや開発部に関する新規案件や、技術に関することでだれに聞いたらよいかわからない、そもそもその技術が何なのかよくわからない相談などの担当窓口、みたいな感じ。

この役割の人に寄せられる相談、業務とかは以下のようなものがある(あった)。

  • 他部署から
    • 連携して行う業務についてのメンバー、手法、進め方についての相談
  • 顧客から
    • セキュリティチェックシート記載依頼
    • 利用規約、プライバシーポリシーに関しての技術的・データ的な観点の問い合わせ、確認、説明依頼
  • 他社から
    • セキュリティ監査
    • サービス連携に向けての技術的なやりとり、打ち合わせ参加
      • そのままプロジェクトとして取り組むことになればプロジェクトの立ち上げ
  • 開発部として
    • サービスの障害、セキュリティインシデントに関する取りまとめ
    • 社内の一部署としての振る舞いや意志決定
    • 業務委託契約に関する手続きや管理

そもそも上下関係がほぼない小さなフラットな開発組織から一人選抜してこういう業務に取り組むと、他部署との関係からその人がその部を代表する人のようにどうしてもなっていく。結果、最後にあげたような開発部としての対応や開発総務的な業務も結構くっついてくる(きた)。

こういう業務が中心となり社内に既成事実として確立、運用が回り始めたぞ、ってなってからピープルマネジメントにシフトするというのは、しっかり役割を分解・移譲しないと、単に業務が増えるだけになってしまい、パターン1と同じくとにかく業務範囲が拡大して時間に追われるということになる。その結果どうなるか?というのはパターン1と同じ、全部中途半端になってしまう。

可能であればこのパスは避けたほうが良い。

そもそも技術マネジメントとピープルマネジメント、求められるスキルは結構違うはず。マネジメントというところだけでひとくくりにせず、それぞれ別の人を当てれないか考えよう。

アンチパターンを用いてもよい場合

それでももしこのパスを通るなら、緩やかに移行せず、短めの期間(1ヶ月くらい?)でエイヤッと移行すべきである。既存の技術マネジメント業務に関しては、それぞれの担当をエンジニアに移行・移譲しその業務に関してはサポートに周る。そして VPoE はさっさとピープルマネジメントに集中すべきである。

まとめ

まだありそうだが、長くなったのこのあたりでひとまず。

基本的に 「兼務はダメ、絶対」 ということである。マネジメント業はとにかく範囲が曖昧で広くなりがちなので、時間的なバッファはかなり持っておかないと対応しきれない。そして、人・組織のマネジメントについては失敗の影響はとかく大きいし、失敗・成功という結果が見えづらい、見えるのにもエンジニアリングと違って時間がかかる。

ただ、成功すると持続性が高く、1つの成功からの相乗効果みたいなものも結構あると思う。

それが感じれたときの喜びは大きいし、一人のエンジニアとしての技術・行動で解決できる範囲を遥かに超えたものとなるので、人・組織をマネジメントするというのもまた面白いキャリアパスかも知れない。

VP of Engineering という役割、まぁ結構しんどいのだけど、万人がなれるポジションではなく、全く違う視点から物事を見る・捉えるということができるようになるので、機会が訪れたら一度チャレンジしてみると良いと思う。

2016 年いろいろあったのでふりかえる。

仕事

4月にシックス・アパートからトレタへと転職した。約10年ぶりの転職でもあり、とにかく今年はこれによる変化がすべてだった。

業務的にはフルスタックでなんでも兼務状態の前職から、サーバーサイドに集中して Ruby / Rails ゴリゴリ書いていくぞ、と思っていたが、7月からエンジニアリングマネージャー業をやることになって状況が変わった(役職はついてなくて職務としてだけではあるのだけど)。

どれくらいその業務があるかわからんので一旦来るもの拒まず全部やってみよう、と思ってスタートきったとたん一気に押し寄せてきて、ちょうどやってた開発も結構面倒な案件だったこともあり、キャパを超えて体力的にも精神的にも辛くなってしまった。それもあったので開発タスクを自分から取りに行くのちょと控えた結果、スムーズに行くようになってきたが代わりにコード書く機会が随分減ってしまった。

キャパ超えたのもコード書く機会減ってしまったのも、基本的にはタスク管理全然できていないというところが大きくて、そのあたりの改善のために精神的なところやツール的なところ改善する取り組み始めたけど、いまだに習慣化できてるとは言い難い。

エンジニアリングマネージャー業で一番大きなウェイトを占めているのは組織、特に新規採用周りのところだけど、そもそも別に採用担当経験あるわけでもなく何かにつけて時間がかかってしまった。少しづつ改善されてはいるものの、その中で気づいたことベースに新しい取り組み始めたりしてまたスローダウンさせたりしてるので際限がないといえばない。

一方でエンジニアリングマネージャー業は結構楽しい部分もある。組織について、よいところ・足りないところを探す、未来を考える、最適化するための方法を探るといったあたり、コード書いてても全体最適化を考えるのが好きな自分の性分にあってるのか、結構楽しい。製品開発においてもそれは同じ。コードは書けてないけど。

技術

仕事上メインで使い始めた Ruby / Rails はまだどうにもなれない部分がある。Rails のマジックにまだ全然ついていけてないという感じ。社内輪読会で『プログラミング Elixir』を読み始めて Elixir も少し触ってるのだけど、Ruby がまだ初学者段階にある段階で Ruby の文法とよく似た別の言語を同時に学ぶのは結構混乱してよくないかも。ただ、関数型言語は全く異なる考え方や、アプローチなどたくさんあって頭の体操には大変良かった。

Ruby / Rails に関してアウトプットはないのだけど、こうなったらいいのになぁというところはポロポロあった。にもかかわらずアウトプットは無かった。

ブログも年間で7エントリ。アウトプットする数も少なく、またアウトプットすること自体にも時間がかかるという悪循環に入ってて良くない感じ。

毎年読み始めて途中分断することが多かった『エリック・エヴァンスのドメイン駆動設計』本、3週目にしてついに短期集中読破した。いままでの経験もあってか3週目にしてようやく DDD の基礎固めできた感。

個人

4月の有給消化期間で行ったシドニーは本当に楽しかった。歴史もありきれいな街だし食べ物も結構美味しいし散歩好きにはとてもいい街だった。2時間電車のって徹底的に散歩したブルーマウンテンズは最高だった。また行きたい。

7月末、左足親指骨折した。仕事でいっぱいいっぱいになってる状況をさらに悪化させてタイミング的にも最悪だった。そして骨折のきっかけ自体も最悪だった。もう二度とやりたくない。

家庭

娘5歳。日々成長を感じる。アルファベットもかけるようになったし、サンタさんからもらった(補助輪なし)自転車も2時間足らずで乗れるようになった。すごい。

転職して通勤時間が伸びたことで平日家にいる時間が短くなって家族に迷惑かかってる感は否めないし、さらに仕事が変わってやることも変わった結果ストレスためて不機嫌にしてしまうこともまぁまぁあってだいぶ迷惑であっただろう。それでもなんとか平和な正月すごしてるのはひとえに奥さんの忍耐力に尽きると思うので感謝したい。

毎年夏休み旅行として行ってる久米島は相変わらず最高によくて家族全員の楽しみ。次は別のどこかに、とおもいながらもまた行きそう。

まとめ

仕事も個人も家庭もイベント盛りだくさんの年で人生振り返っても忘れがたい1年だった。思考も生活も仕事にベースにあって、それがうまくいかないと何もかもうまくいかないのは改めてわかった。2017年、トレタは成長期でまだまだ変化が多く、また成長痛みたいなのもちらほらあるのでそれらうまく乗り越えつつ、今年達成できなかった個人的な技術力向上やアウトプットは、エンジニアリングマネージャー業続けるのでことさら増やしたい。

2017年はついに40歳となる節目の年。踏ん張りどころであるが何もかも楽しくありたい。