新卒へのアドバイス

桐野 俊輔 (skirino) @ ACCESS

2018/04/13, 2019/04/12

前置き

  • 社内で新人向けに話す機会をもらった
    • どんな心づもりで仕事をして欲しいか
    • 自分が1年目に聞きたかったこと
  • ここでは当たり前のことしか言わない
    • が、当たり前のことができている人は少ない(自戒も含む)

前置き: この話の前提

  • ACCESSはソフトウェアで利益をあげる会社
  • audienceはACCESSのソフトウェアエンジニア
  • project単位の日々の作業について主に議論する。”そもそもこのprojectやるべき?”といったレイヤーの話はしない
  • プログラミング言語非依存

前置き: 自己紹介

  • 2011年入社
  • 学生時代は物理やってた
  • サーバサイドの人
    • Rails => Scala => Elixir

ソフトウェアのmaintainability

ソフトウェアで儲ける

  • プロダクトの価値を高める
    • 外部品質。いろいろあるがこちらはスキップ
  • プロダクトの開発・運用コストを下げる
    • 内部品質。今回の主題はこちら

「変更」について

  • 対象ユーザ、ユーザのニーズ、動作環境、言語バージョン、ライブラリ、…
    すべて変わっていく
  • ソフトウェアを変更しないことには食べていけない

Maintainability

  • 変更しやすい
    • 修正箇所が明確で局所的
    • 修正の影響が予測しやすい
  • 変更しにくい
    • 修正箇所が把握できない・あちこちに散らばっている
    • 修正によって何が起きるかわからない

Maintainability

  • どちらが望ましい?
    • 変更しにくいがバグがないソフトウェア
    • 変更しやすいがバグがあるソフトウェア
  • (バグの深刻さにも依るが)たいてい後者のほうが望ましい
    • バグを修正するのも簡単なはず

良いコードのために

良いコードのために

  • ここはもっと良くなるはず(code smell)、を認識できるようになろう
  • コードについての話をしよう
    • こういうコードはここが良い/ここが悪い、こんな書き方がある、等々
    • 特にレビューの場を活用しよう

良いコードのために

  • maintainabilityの敵は
    • 重複
    • 分岐
    • 悪い命名
  • (マルチスレッド時は話がもっともっとややこしいが、いったん置いておく)

重複

  • “uncontrolled duplication of information is evil”
    • (義務教育で教えるべき!)
  • “information”にはコードのみならずデータもあてはまる
    • DB正規化とか

重複

  • 重複をなくすべく死力を尽くそう
  • 各プログラミング言語・ライブラリはそのための方策を用意している

分岐をどう扱うか

  • if文などで分岐を書くのは簡単だが、多重になると把握しきれなくなる
    • 大事でない分岐を別の関数などに追いやってレイヤーを分けよう

分岐をどう扱うか

  • 分岐するコードと逐次実行するコードをなるべく住み分けしよう
    • 逐次コードによって大事な分岐を埋もれさせないように

分岐をどう扱うか

  • 分岐をエレガントに扱うための言語・ライブラリの機能を活用しよう
    • パターンマッチ、仮想関数、型クラス、等々

命名(識別子など)について

  • 悪い名前は事実と異なる認識をもたせてヒドいことになる元凶

  • 良い名前は概念を端的に言い表すことで脳の負担を減らす

  • 雲泥の差が生じうる。難しいが時間をかける価値がある
    • 類語辞典などを活用しつつ、複数の案を出して検討しよう

良いコードのために

エンジニア個人レベルの話

個々のエンジニアの生産性

  • 技術力(すぐには変化しない)
    • 状況に応じた”正しい”解決策を採れるかどうか
  • モチベーション(コロコロ変わる)
    • 単位時間あたりにactionを起こす数
    • 技術力の上昇度合い

プログラマー風林火山

  • 「風」: 迅速な設計/実装によってチームを加速させる風のエンジニア。
    風のエンジニアがいない開発チームでは、他に先駆けて新製品やサービスをリリースすることが困難になる。
  • 「林」: 突発的なトラブルが発生しても冷静に対処し、チームに乱れぬペースを提供する林のエンジニア。林のエンジニアがいない開発チームはトラブル発生時に何をすべきかの正確な判断を行えず、混乱に陥りやすい。

プログラマー風林火山

  • 「火」: 新しい技術/方法/ツールの積極的な導入によってチームやその成果物の競争力を高める火のエンジニア。火のエンジニアがいない開発チームは同じやり方を繰り返すことはできるが、進歩する機会が少ない。
  • 「山」: 厳密なエラーチェックと堅牢なプログラミングによって成果物の安定性を高める山のエンジニア。山のエンジニアがいない開発チームは常に品質の低さからくる不安にさいなまれる。

プログラマー風林火山

  • いろいろな貢献のしかたがある
  • 言語・ライブラリなどに依らない”能力”
  • 各エンジニアがすべての要素をある程度備えている必要がある
  • その上でチームに何か1つの要素をプラスすることを目指すべし

プログラマー風林火山

  • 「風」と「火」タイプは目立ちやすい
    • が、手戻りなども多くなりがち
      • 「火」がいっぱいいても仕方なかったり
  • 「林」と「山」タイプは目立ちにくい
    • 一方で確実な戦力になる場合が多い
    • 新人エンジニアに意識してほしいのはむしろこちら

チームでの開発について

ソフトウェア開発はチームスポーツである

  • Team Geekより
  • いいメタファーだと思うので紹介
  • (陸上のリレーとかではなく、球技(サッカー、野球、etc.)を思い浮かべよう。Team Geekのイラストはアメフト)

チームスポーツとの共通点

  • メンバーの長所を活かし合ってチームとして機能
  • スーパースターがいるチームが勝つとは限らない
  • 勝つための戦略は単純にはわからない
    • 常にうまくいく戦略は(おそらく)ない
  • => チームを機能させることに注力しよう

参考: チームスポーツとの相違点

  • 1チームのメンバー数に上限はない
    • “無闇な増員”という間違いが多発しがち
      • 実際には、長期的視点に基づかない増員はたいてい悪手
  • 対等な相手との争いではない(ことが多い)。明示的な”敵”はいない

HRT(再度Team Geekより)

  • 「あらゆる人間関係の衝突はHRTの欠如によるもの」
    • Humility(謙虚)
    • Respect(尊敬)
    • Trust(信頼)
  • Team Geek読もう

新人へのメッセージ

自分の成長に責任を持つ

  • 会社から与えられた「状況」で何を学ぶか
  • 会社の外で自分用のカリキュラムを作って進めていけるか
  • また、なるべく”廃れないこと”を選んで学ぼう
  • 3年くらい経つとすごい差に

こだわりを持つ

  • 自分の携わるプロダクトに誇りを持とう
    • 持てないようなら、誇りを持てるようにするには何を変えればいいか考えよう
  • 「ここはこうあるべき」を常に考えよう
    • 現状ベースではなく理想像を考えよう

自発的に動く

  • 状況把握を欠かさず、自分からアクションを起こそう
    • 他メンバー・他チームの作業に目を光らせよう(GitHub通知など)
    • できそうなタスクを積極的にこなしていこう
  • 逆に、周りに自発的に動いてもらうため情報を発信しよう
  • (他人のアクション依存の人は、社内トータルの仕事量を増やしている)

メタ認知

  • 人は「自分」を特別扱いしがちであることを認識しておこう
    • たとえば「自分が書いたコードは良く/悪く見える」とか
  • ニュートラルな判断を下せるようになろう

思考停止しない

  • 思考停止していいのは「思考停止は悪」という公理を受け入れるときだけ
  • 常に頭を使おう
    • 何が”正しい”かを状況に応じて批判的にチェックしよう
    • 代替案をメリット・デメリットと合わせて列挙しよう

思考停止しない