こんにちは。CTOの馬場です。

ハートビーツで社内ドキュメントとして策定した「ハートビーツのエンジニアの倫理規定」を公開します。

技術とは・技術者とは・成長とは・倫理とは・結果を出すために重要な考え方といった内容を含んだ、 CTOとしてのわたしからの・わたしたち中堅/ベテランエンジニアから新規参画者へのメッセージでもあります。ものごとの考え方やとるべき態度など、属人的な事柄を伝達するための取り組みです。

エンジニアや学生のみなさんには、ハートビーツとハートビーツのエンジニアの雰囲気を知っていただくきっかけとなれば幸いです。

また各社のCTOやVPoEのみなさんとは、お互いに知見を持ち寄り情報交換・議論したいです。おそらく似たような悩みを抱え様々な取り組みを実施されているかと思いますので、情報公開や情報交換、議論などを通じてよりよい業界にしていければと思っています。

ダウンロード: [PDF]ハートビーツのエンジニアの倫理規定

ハートビーツではこのドキュメントをオンボーディングや新人研修の中で都度参照しています。なお、これを人事評価にそのまま利用してどうなるかわかりません。 (嫌な予感がビシビシするので、ハートビーツでは直接の評価ポイントにはしていません。おおいに参考にはしています)

詳細はPDFを読んでいただくとして、社内で特に話題になる点をピックアップして紹介します。

なお July Tech Festa 2019 ( #JTF2019 )ではこのドキュメントに関連して講演します。ご都合がつくかたはぜひいらしてください。

⇒[D30] 「エンジニア像」を言語化し文化の礎を築く - July Tech Festa 2019

ピックアップ：技術とは

「技術力が欲しい」と思う気持ちはわかりますが、目標を具体化しないことにはアプローチのしようがありません。

技術者各位がその技術を向上させるにあたり、技術者や技術を構成する要素を分解し図示しました。

構造を知ることは全体を知ることであり、要素のバランスを把握したりボトルネックを特定することが容易になります。

そして目標との差を把握することができるようになります。

構造を知ることだけで目標との距離が縮まることはありませんが、効果的な努力の支えになります。

図はPDF内の「技術とは・技術者とは」をご参照ください。

ピックアップ：成長とは

「成長したい」と思う気持ちはわかりますが、目標を具体化しないことにはアプローチのしようがありません。

社会人の成長、を以下のとおり定義しました。

端的に以下の3要素で説明できると考えます。

結果を実現すること

結果の期待値を維持すること

結果の期待値を高めること

社会人の成長は相手からの信頼で構成されていると言ってもよいです。

また、社会人が成長するためには着実な積み重ねと行動変容が必要不可欠であること、あるべき姿と現在の自分のギャップを見つめ、あるべき姿と現在の自分の非連続を認め、「あるべき姿との連続性を持つ自分の姿」に変化する自己変革が必要だということを明言しています。

これは少し難し目の言い回しをしていますが、

「このままの自分の延長線上に自分のなりたい姿がない」ということを自覚する
「自分がなりたい姿」に繋がる世界線に自分で自分を移動させる

ということです。

このドキュメントの成り立ち

わたしがハートビーツにjoinしてもうすぐ12年が経ちます。 CTO歴も11年を越え、ハートビーツは人数規模で3倍に大きくなりましたが、依然として全体の7割以上がエンジニアというエンジニア比率の高い組織です。 (常勤取締役5人のうち3人がエンジニア経験者)

ハートビーツはCTOの他にVPoEもいて、エンジニアがその能力を発揮しやすい環境・組織・制度づくりに取り組んでいます。 CTOのVPoEも在職中にそれぞれIT/経営(MBA)の修士号を取得するような、真面目な会社でもあります。

ハートビーツは小さな会社でありながら、もう10年以上に渡り本当にイチからトレーニングを行い、未経験がエンジニアとして活躍できるよう支援してきました。

そんな真面目でコツコツ型の会社ですから、テクノロジーについては教育課程が整っているものの、ハートビーツのエンジニアとしての現場判断・物事の優先順位・Noという境界線などは明確に伝えることが難しく、背中を見て学んでもらうことがほとんどでした。わたしも最近まで現場で案件を抱えていましたが、 VPoE高村の就任などもありここ2年ほどは案件から離れ自由な立場で活動しています。規模の拡大やロールの変化により、背中を見せる機会が格段に減ったことで起きそうな諸問題に先回りしたいという動機がありました。

わたし個人としては自分の思考やノウハウをとりまとめて文章にすることに多く取り組んできました。例えばわたしの単著 Webエンジニアが知っておきたいインフラの基本は、わたしが業務で培ったノウハウ、ISUCONで @fujiwara さんを見て、彼に追いつくために思考をトレースする試みを重ねた結果を書き下ろしたものです。その他に、今までも社内では業務虎の巻、技術選定指針、半年ごとの技術戦略共有(市況や業界動向の認識共有)など、業務上の迷いを減らして自由度を増やす試みは続けてきました。このドキュメントは今までのどのアウトプットよりも内面的なところに踏み込んだ力作です。随時更新し、より現実に馴染ませる努力を継続していきます。

このドキュメントのビルド環境

このドキュメントはMarkdown形式のテキストファイルで構成されていて、コードは社内のGitLabで管理されています。 mkdocs, mkdocs-materialでMarkdownをHTMLに変換し、 wkhtmltopdfでPDFに出力しています。 PDF出力の際に表紙やページ番号の付与、もくじ(TOC)の生成も行います。

一連の変換作業はGitLab CIを利用した自動ビルドにより実行され、生成されたPDFはbuild artifactとして社内に公開されます。

ゆくゆくはGitHubを利用して元テキストをそのまま公開できるといいなと思っています。