2016.11.01 2022.10.29

MMMで働くエンジニア・デザイナーの行動指針

kuni

今日から11月。2016年も残り2ヶ月なので、もうそろそろ忘年会のお店をおさえないと予約が取れなくなることを恐れながらも、お店がなかなか決めきれない...。MMM代表の国本です。

先月10月に、MMMのミッション、ビジョン、行動指針というエントリーで弊社が存在する意義である「ミッション」企業としてあるべき姿の「ビジョン」そして組織としての優先順位を決めるための根本規範や価値基準として「行動指針」をご紹介しました。

これらのミッション、ビジョン、そして行動指針をベースとしながらも、よりエンジニアやデザイナーの実業務に対して、具体的な行動指針を明文化することで、全社員が本質を理解し、同じ方向を向いて、業務を進めることができると考え、先日、全社員で「MMMで働くエンジニア・デザイナーの行動指針」を改めて定義しました。

弊社で働くスタッフとして、あるべき姿を意識し、それに準じて考え・具体的に行動できることを策定の目的としており、継続的に内容はブラッシュアップされますが、現時点で定義されている具体的な行動指針を今回はご紹介したいと思います。

Contents

行動指針
まとめ

行動指針

具体的な行動指針は下記3つのカテゴリーで定義されます。

1．顧客視点

プロダクト開発時に実利用者の目線を強く意識することで、単に伝えられた仕様通り作るだけに留まらず、より良い設計、機能開発の改善提案を常に行う
プロダクトが実現したいビジネスの背景と目的を十分に理解した上で、機能設計や開発を進める
情報技術に関するリテラシーが低いお客様に対しても、お客様が理解できるようにビジネス的なメリットも付加してわかりやすく説明する

2．品質管理

機能要件をチケット(Issue)化する際、ビジネス的な背景と目的も含めて、お客様が何を求めているのか？実現したいのか？をきちんと把握できるように記載する
開発進捗を可視化する為に、最低限1日に1度は開発リポジトリにコードをPushする
社内で制定されているコーディング規約に必ず準拠したプロダクト開発を行う
コード内のコメントは「How」ではなく「Why」を記述する
既存コードに手をいれる際は、必ずコードを開いたタイミングで、手がつけられる小さな範囲で良いので、日々継続的なリファクタリングを行うことで、改善に繋げる
商用プロダクトにおいては、例外発生時のエラー内容を後から解析・検知できる仕組みを必ず導入する
コード実装時の命名は第三者が閲覧しても、意味や意図が推測・把握できるような命名を行う(リーダブルなコードを強く意識する)
社内で定義されているテストコード指針に必ず準拠したテストコードを実装する
コードレビュー時は、レビュー関係者のスキルと、実装背景・文脈を考慮して、相手が理解しやすいコメントを行う(必要であれば躊躇せず会話も併用する)
コードレビュー時のコメント投稿時に必ず絵文字をセットし、遊び心を忘れないようにして場を和ませる
コードレビュー時のチェックコメントは、コードレビューチェックコメント規約に必ず準拠して、コメントを行う
Pull Request時のファイルチェンジ数は、最大でも30までとする
レビュー者として指定されたエンジニア・デザイナーはコードレビュー遅延Botに怒られないよう、迅速にレビューを実施する
コードレビュー時に修正や改善提案がある場合は、可能な限り、コードや参考URLなどを含めて、具体例を提示する
コードレビュー時の指摘は、相手が気分を害するような発言は絶対に控える(相手の立場に立って考える)
知見がない新規技術やソフトウェア、設計方針を採用する場合は、事前に必ず検証フェーズを設けて検証を実施し、仮にスケジュールや人的要因で検証が行えない場合は導入を見送る
プロダクト開発時のスケジュールは可能な限り具体的に見える化(WBSなどに)する
プロダクト開発時にお客様が何を重要視しているのかを深く理解し、用いる設計方式、ミドルウェアやアーキテクチャはプロジェクト関係者全員で必ずレビューする
DRY(Don't Repeat Your Self：繰り返しを避けること) / YAGNI(You ain't gonna need it：機能は実際に必要となるまでは追加しない) / SOLID(オブジェクト指向設計原則の頭文字)に準拠する
OS、採用ライブラリ、利用フレームワークやミドルウェア、開発言語のアップデート方針は、それぞれ社内の規則に必ず準拠する
社内の設計・Tips、共有ドキュメントについては定期的に全社員当番制で棚卸しを実施し、使えるドキュメント基盤として常に最適化を図る

3．深いコミュニケーション

書籍『Team Geek』で定義されている謙虚(Humility)、尊敬(Respect)、信頼(Trust)を常に意識し、実践する
直接プロジェクトや業務と関係外の事でも、コミュニケーションの量を重視し、積極的にお客様やメンバー間でコミュニケーションを図る
懸念事柄を率直に報告できる時間を定期的に設けることで、ミスを責めるのではなく、チーム力でどうカバーするかを常に考えて、悪いことこそ、常にオープンにできる風土を作り上げる
結論を先に伝え、簡潔、かつわかりやすいコミュニケーションを心がけ、実践する(接続詞をあまり多用しない)
お互いを理解し合うために必要な『健全な衝突』を避けず、深いレベルでのコミュニケーションを図る
スキルセットや経験値が低いメンバー向けに、ドキュメント整備、参考書籍の共有や社内勉強会を開催することで、チームメンバーの成長にどんどん貢献する
エンジニア・デザイナーとしての必須となる基礎スキルをマップ化することで、常にチームのスキルを可視化し、不足しているスキルを積極的に補強していく
定期的にチームメンバー個々人にフォーカスする機会を設け、共に働くメンバーに興味を持って接する
会議を開催する人は参加者全員の意見を引き出せるようなファシリテーションを行う
常に共に働くメンバーを意識し、困っているメンバーに対して主体的に声掛けしプロジェクトを成功に導く(ONE FOR ALL，ALL FOR ONE)
直接担当業務ではない分野でも積極的に学習に取り組むことで、エンジニア・デザイナーとしてのスキルに『幅』を持たせる
新技術やトレンドに高い感度を持ち、積極的に検証・レポーティングすることで、チームに貢献する
Googleの検索言語はデフォルトを英語に設定する(情報量が桁違い)
大小にかかわらず、失敗談を『しくじり話』として積極的にレポートすることで、経験値に変えていく
プロジェクト規模を問わず、3回以上同じタスクを行う場合は、必ず自動化を試みる
開発効率向上に向け、開発環境を改善するタスクをIssue化し、プロジェクト関係者全員で対応する