サーバーサイドから考える、理想の開発スタイル

ぼくのかんがえたさいきょうの…という記事。 特に目新しい話はなく、よく聞く考え方の整理となる。

なお、特に前半はエンジニアに限らない話も混じっている。

考える目的

エンジニアとして、楽しく充実した開発と運用をする為である。 イケていてシンプルで効率的な体制を目指す。 これにより、エンジニアの幸せのみならず、使ってくれる方へ届くものの価値向上や、プロジェクト的な成功へも貢献できるはずだ。

前提

  • 「Web (API) + クライアント」の構成での話
  • ここでは、サーバー側のコードを書く人数は 2, 3 〜 7, 8 人程度で考えている
  • 様々な背景を考慮しない状況での話であり、状況に応じてここから変化させる
    • チームメンバーの好みにも寄り添う
  • 現時点版
    • 技術や制約、ニーズの変化により、長くないスパンで変遷すると予想させる
  • ツッコミ歓迎
    • 異論は認める、製錬させたい

全体方針

長々と書いていくが、全てこの原則に則る。

  • シンプルで自然を重視
  • 共通化
  • 楽をする為の努力を惜しまない
    • 下地に時間をかけて良い
  • 設計や、運用イメージを大切に

メンバーの姿

  • 求められる2つの力の軸
    • 技術力
      • 実現力
      • 後の運用まで見越した設計
    • サービスへの理解力
  • 挑戦する
    • もはや福利厚生
  • 常に改善を行う
    • 時間を割ける体制を用意しておく

情報共有

  • 隠さなければいけないもの以外は基本オープンにする
  • 情報への入り口を、分かりやすくする
  • チャットルームは増やし過ぎない
    • できるだけ統一したものをつかって、不便であれば慎重に分割する
  • 会議を不要に行わない、テキストで十分なものはテキストで
  • 会議や口頭での会話は、できるだけテキストに落として共有する
  • この辺りの細かいことは、以前ブログに書いているので参照されたい

別職種との連携

  • コミュニケーションしていく
  • 特に自動化はエンジニアの得意領域のため、こちらから改善の提案する
    • 企画者さん、デザイナーさんが、無駄に消耗しているかも

ツール

  • 外部に有用なツールが存在する場合は、積極的に利用する
  • 料金が発生しても、独自につくってメンテナンスコストが発生するよりお得

チャット

  • サービス連携がしやすいチャットツールを使う
    • やりにくいチャットツールをメインで使わなければならない状況下では、開発用として別途 slack を立てるのは許容したい
    • 乱立は避けたいのだが…
  • 連携ツール
    • デプロイ
    • エラーやアラート、パフォーマンス監視
    • その他ツールのアクティビティ(GitHub, wikiツールなど)
  • メールで通知するものは、チャットでも同時に通知したい
    • その場で会話が開始できる

資料

  • 属人化を避ける

ツールの使い分け

  • GitHub Issues
    • 手軽なエンジニアレベルの一時的な問題や作業上げ用として使いやすい
  • README.md, doc/*.md (git repository 内)
    • PR 運用でき、コードと合わせてコミットできる為、複数人での作業に向いている(比較的、コードに追従しやすい)
    • 使い捨てでない手順、エンジニア用のドキュメントに
  • wikiツール
    • 高機能で、非エンジニアも使いやすい
    • 他職種との共有が必要な、仕様書などに
  • Office, Google Docs
    • 一時的な共有に使うのには便利だが、後からは見にくい為、wiki に寄せられるものは寄せるとやりやすい

技術(手順系)

  • そもそも「手順」というものが、できるだけ存在しなくていいように、またはシンプルになるように
    • 例えば、1コマンド打つだけで終わったり、自動化されていたり
  • 初期構築は、README を見て、必要環境の確認をして1コマンドで完了、くらいに
  • コピペする手順書を避ける
    • イレギュラーな作業の為の手順書を作るのは問題ないが、日常的に同じものをコピペするような運用の手順書は不要
    • 共通で使えるようにする

技術(設計・仕様書

  • できるだけ自動生成させる

手で書く部分

  • リポジトリにマークダウンとして配置
  • コードを触ると同時に直すようにする

API

  • どういう資料が必要か

    クライアント側: サーバーの API 一覧と仕様

    サーバー側: クライアントのどのアクションでどの API が呼ばれるか

  • 前者は一般的であり、確実に欲しい

  • 後者は、複雑なシーケンスを踏む API がある場合に、あると便利
    • クライアントのどのアクションで、どんなリクエストがサーバーに送られてくるか分かるように

API

  • RESTful をできるだけ崩さない
  • JSONYAML で仕様を書く
    • いくつかのツールがあるので、良さそうなものを
      • JSON Hyper-Schema
      • RAML
      • Swagger (OpenAPI)
      • など…
    • 個人的には、Swagger を使いたい
  • API 仕様からつくるか、実装(コード)からつくるか、という選択肢がある
    • 後者のイメージとしては、テストやモデルの実装から仕様を吐く、など
    • API はコードとは分離して考えたい為、ここでは前者で
    • コード自体を知らない人も、仕様が書ける
  • これによりできること
    • ドキュメント生成
    • モックサーバー立て
    • サーバー連携
      • リクエストやレスポンスのパラメーターの検証
      • テスト
      • モデルに紐付けて連携
    • API クライアントや、テスト用の REPL の生成

図で表した。

f:id:misoobu:20160228213837p:plain:w400

  • レスポンスの形式
    • 一貫性のあるものにする
      • 全体の構造や、時間の表記はどうするか?エラーは?など
    • JSON API などの規格を採用したり(名前が分かりにくい)、ガイドラインを定めたり

コード設計、コード

  • 綺麗でシンプルを目指す
  • API は REST から崩さず、DB もシンプル(非正規化などを行わない)な所から考え始める
    • 後から必要に応じて、まとめたり崩したりする
    • 例えば API において、開発初期段階では1機能で複数API を叩く形を許容する
  • 運用まで想定してつくる
    • 運用のために内部設計を崩すことはしない(両立させる)
  • コード規約を導入する
    • メンテナンス性を考え、アプリ固有の設定はしすぎない
    • 規約違反は自動で通知、修正する
  • 頻繁に更新される(運用で追加される)とデータと、ソースコードは、リポジトリを分けるなどして分離する
    • 役割の明確化、コミットログの追いやすさ、コードデプロイとデータ適用の切り分けの為

コードのテスト

  • 適切な粒度を決めて書く
  • 前述の API spec は、ごく簡単なテストにも利用できる
  • 自動でテストを回し、通知する

ブランチ運用

  • 基本的に、master からブランチを切って、master へ PR する
  • master は常にデプロイ可能な状態を保つ
  • 本番環境は、常に最新の master ブランチでデプロイされた状態を保つ
    • master へマージしたらすぐデプロイ。後述のように自動化
  • ブランチ名は分かりやすく適当なものを付ける
    • feature などの prefix は必要にならないので付けない
  • ただ develop ブランチを追加したからといって、確認が厚くなるわけではない
    • フローを増やしたくない
    • 適切に(無駄なく)確認できているか

Pull Request

  • 最新の master で rebase した状態で作成し、マージ前も最新に追従させる
  • タイトルや説明文、コミットメッセージは、分かりやすくつける
  • レビューと修正を行う(当然)
  • CI が実行され、ステータスを表示する
  • 自動的に確認用環境へデプロイされる
  • できるだけ出しっぱなしにしない
    • つくったら時間を空けずに本番まで持っていく
    • 管理しない為
    • この為に、機能の開放時期を制御可能にしたり、API のバージョニング(後述)を行う

デプロイ

  • 本番環境は、master を更新すると、自動でデプロイされる
    • 別作業が必要な場合は手動で行えるように
  • デプロイ中は、随時チャットへアクテビティが投稿される
  • マージとデプロイはセットの為、デプロイ時のタグ打ちや開発者用リリースノートは不要
  • デプロイ自体に時間がかからないようにする

自動化、CI

  • 人間がやる必要のない定常的な作業は、自動化する
  • 自動実行するものの例
    • テスト
    • コード規約
    • デプロイ
    • ライブラリアップデート(PR 作成まで)
  • 便利なサービスがあれば活用したい

クライアントとサーバーのバージョニング

ここでは、クライアントのアップデートタイミングを細かく制御出来ない、モバイルアプリの場合について。

  • 破壊的な API 変更がある場合、サーバーは API バージョンを進め、新クライアントもそちらへ向き先を変える
    • API の変更の為にメンテナンスに入れる必要がない
  • サーバーは、直前のバージョンの動作を一定期間保証する
    • バージョン更新後、一定期間待った後にバージョンアップ必須とする
    • 利用者は、クライアントアプリのバージョンアップタイミングを多少コントロールできる

メンテナンス

  • 基本的にやらない
    • コストをかけてでもやらない(メンテナンスに実は大きなコストが掛かっていることも)
    • 無停止で DB を migrate する手法はいろいろある
  • 利用者にとっても、ないほうが良い
  • メンテナンスがあると作業やアップデートを集中させてしまいがち
  • 非常時には発動できるように準備はしておく
  • 関連して、DB の不要な履歴データは自動で少しずつ消えるようにしておく

国際化、他プラットフォーム対応

  • 予定がない時点で対応する必要はないが、対応イメージはできるようにしておくべき
    • 複雑化させない
  • コードベースは1つに保ち、開発コストを抑える
  • 前述の、コードとデータの分離とも相性が良い

管理画面、動作確認用機能

  • なにをしたいのか
    • データの確認
    • 簡単なデータ操作
      • マスターデータ作成や更新(seed 運用しないもの、許可するものとしないものは明確に分ける)
      • 動作確認の為の、ユーザーデータ操作
    • エンジニア以外による、利用者のサポート
  • 要素
    • データビューアーとその簡単な操作
    • アカウントや権限の管理
    • 動作確認用の機能
    • 操作履歴
  • やること
    • API と管理画面は分離する
      • 明確に住み分けることで分かりやすく
      • rails なら同プロジェクト内でエンジン化など
    • 手作りの管理画面 + 管理画面ライブラリによる簡易ビューアー、という構成
      • 徐々に手作りの方へ寄っていくと思われるが、シンプルなデータはライブラリによるもので十分
    • 手作りの管理画面は、使い勝手やデザインを揃えるため、スタイルガイドなどで縛る
    • 管理画面ライブラリは、カスタマイズを行わず、またそこからデータの編集もさせない
      • 要望に合わせて次々にカスタマイズをしていくと、手をつけにくい状態になることも
  • エンジニアによる調査対応が必要になった時、管理画面からも実行可能なようにして、誰でも出来るように

その他

  • 属人化を避ける為、特定の人物に特定の作業を集中させない
  • 名前空間をしっかり切る
    • 運用が進むと、把握の容易さが変わり、効いてくる

これらをやると、メンバーはどうなるか

  • 繰り返しの作業がない
  • 常に新しい、モダンで精錬された環境で仕事が出来る
    • モチベアップ(と表現すると、モチベに左右されるなと偉い人から怒られる?)
    • 環境の更新を切り口に、そのものへの理解を深められる
  • 知らないことが少なく、知らないことを知る方法を知っている
  • => 楽しい!(多分)

どうするとこれらが実現できるのか

理想を心に描いた上で…

  • 既存プロジェクト: できるところから、効果が高いものを少しずつ
  • 新規プロジェクト: 開発が活発で変化が多い時期だが、先を考えて基盤を思考する

常に改善する。コストを払う価値はある。

後書き

全体的に「なぜ?」が足りないように見えるが、よく聞く話の集合体であるので、省略した。

前提の通り、あくまで理想なので、現実でこの通りにやれることはないだろう。 プロジェクト成功の確度が低く、基盤構築に時間を割けないということもあるかもしれない。

しかし、理想を思考することは大切だ。これにより、実際の制約下でも、軸がブレない設計が出来る。 また、これらは、メンバーと話し合って磨き上げ、浸透させることが大切である。

より楽しい開発を目指していきたい。

組織における、エンジニアの情報共有について。あるいは、レビューや設計について。

これは、「ドリコム Advent Calendar 2015 その2」の、8日目の記事になる。

7日目は、middlemanとGitHub Pagesでブログを5分で開設!ほか盛りだくさん! | いくら寝ても眠たい だった。


私は、ドリコムでエンジニアをしている matsusaki (@misoobu) という者だ。 ここでは、最近考えることの多い、組織におけるエンジニアの情報共有と、そのあるべき姿について書く。 また、それに関連して、コードレビューや設計についても触れる。 内容は、エンジニア視点のものになる。

情報共有は、組織にとって極めて重要だが、簡単なことではない。 本記事が、再考するきっかけとなれば、幸いである。

情報共有とは

情報共有とは、「他人と、必要となる情報を伝え合い、活用する」という行為である。 これは、大小至る所で行われている事だろう。 この出来により、行動時の円滑さや効率は大きく変わってくる。 その為、大切なのだ。

ここでは、「チームでサービス開発をするエンジニア」に焦点を絞って、話を進める。

情報共有を失敗するとどうなるのか

情報共有が上手くいかなかった時に、どのようなことが起こり得るのか。

  • 認識齟齬による、作業効率の悪化やクオリティの低下
  • 誰が何をしているのか分からない
  • 高コストな、コードや設計のレビューとその成果物の保守作業
  • 充実しない会議による、時間浪費
  • 有用な情報があっても、知らない
  • 意図しない車輪の再発明
  • 実装と乖離したドキュメント
  • 遅い障害対応

目を覆いたくなるような、悲惨な光景である。 これらを防ぐために、情報共有を見直していく。

様々な情報共有

例えば、以下の様な内容の情報共有が行われる。

  • プロジェクトの状況や方針
  • 作業内容とその状況
  • プログラムの設計やコード
  • ドキュメント
  • 障害情報
  • 日報

それぞれについて、確認していく。

プロジェクトの状況や方針

プロジェクトの、状態や目指す方向を確認し、メンバーの目線を揃える為に行われる。 この共有が、優先事項の適切な判断、目的の理解、メンバーの意思統一に繋がる。

作業内容とその状況

メンバーが、何をしていて、どれだけ進んでいるかを把握する為に行われる。 また、プロジェクトの見通しを良くし、課題の発見にも役立つ。 前項のプロジェクト現状と合わせて、いわゆる朝会にまとめて行われることが多いようだ。 エンジニアとしては、他職種にもある程度分かりやすく、簡潔に現状を伝えることを心がけたい。

プログラムの設計やコード

日々行われるレビューも、情報共有と言っていいだろう。 双方に時間が掛かりがちな行為なので、よく考えておきたい。 ここでは、私の経験から得た、効率的なレビューの知見を紹介する。

なお、社内では、コードの管理に GitLab と GitHub を使っている。

レビューの目的

第三者が確認する事で、クオリティを高めたり、その対象についての把握者を増やすことが目的である。 これにより、バグを減らし、メンテナンスコストを下げ、総合的・長期的に効率を上げる。 また、メンバーのスキル向上も望めるだろう。

レビューをするときに心がけていること

これは、チームの規模によって変わってくるだろうから、ここでは10人以下のエンジニアチームメンバーがいることを想定する。 また、きっちりやりきると時間が掛かり過ぎることもあるので、適度な範囲で形式を崩すこともある。

早めにレビューをする

レビューをする時は、出来るだけ後回しにせず、見かけたその場でレビューをするようにしている。 こうすると、その対象物の展開は早くなり、レビューをされる側は効率よく対応がしやすい。 物は早く出来上がるだろう。 レビューをする側は、自身の作業の一時中断により、少し手が止まるかも知れないが、前述の利点は大きい。

コードレビューの流れ

pull request のタイトル、説明を読み、内容を理解する

この時点から、違和感がないか確認する。

メモを取りながら、コードを確認する

全体的な作りを先に見て、次に細かい所を見る。 これは、全体的な作りに問題があり修正を行う場合、それにより細かい指摘箇所はなくなる可能性がある為だ。 確認した結果、指摘事項がない事も多い。

作業を讃えるコメントする

指摘により、ネガティブな印象を与えない為である。 レビューは攻撃ではない。

メモを見ながら、指摘点をコメントする

全体的な作りの問題から先に、指摘のコメントを付ける。 これは、修正作業のしやすさを考慮してのものである。 コメントは、出来るだけ柔らかく、分かり易くを心がける。

モチベーション

お互いのスキルを高める行為でもあるので、積極的にやっていきたい。 折角やるのだから、自身の糧となるようにする。 また、簡単なミスや、頻繁に指摘する事項は、毎回指摘するのは厳しいので、後述の自動化を検討する。

レビューに反応や対応をして貰えたら感謝する

議論になる場合もあるが、円滑にコミュニケーションをする。

レビューをされるときに心がけていること

レビューをしやすい状態にする

コード、コミットの粒度とメッセージ、pull request の粒度とタイトルと説明、それぞれを分かりやすく整える。

お互いに少しの時間を使ってレビューをしやすくすることで、全体としての効率は上がる。 そして勿論、コードはより良くなる。

レビューを貰ったら、早めに対応する

これも、スピード感を持って対応を進める為である。 対応に取り掛かれるまでに時間が掛る場合や、少し考えたり調べてから答えたい場合には、一旦その由を伝えるコメントをするようにする。 無反応な時間が長いと、対応が進んでいるのか分からない。

レビューされることを感謝する

同じく。

「大人の事情」で、悪い事を認識しながらも行う場合は、その事を示す

例えば、時間が取れなかったり、緊急性が高く急ぎの対応となり、ベストでない選択をする時は、その事を示す。 いわゆる技術的負債を選択する場面もあるはずだ。 しかし、レビューをする側がその状況を分かっていない場合は、指摘せざるを得なく、効率的でないので、その無駄はなくすべきだ。

「周りに合わせる」は、良くない場合がある

周辺の似た実装をただ真似て作るのではなく、それがベストかを確認する。 結果として、周りに合わせた実装がベストな場面も多い。 合わせる方針を続けた場合、もしその元の実装に良くない所があると、コードは悪化の一途を辿ることになる。

自動化で人間による作業を減らす

コーディング規約の違反や、テストが落ちるようになったなどの、定型化した指摘は面倒である。 人間がやるべきではない。 自動化が出来るものは、積極的に自動化する。

ドリコムには、共通の rubocop の設定がある。

rubocop のしつけ方 - onk.ninja

多くのプロジェクトでこの規約を導入しており、自動で違反がコメントされる体制のプロジェクトもある。

同じように、自動テストも行われている。

余談になるが、コーディング規約は、どうしても個人の好みが出てしまう所である。 設定に迷った時は、近くの強い人に決めて貰うか、なるべくデフォルト推しが良いと考えている。

通知方法

コミットを push した時、pull request を作った時などのアクションを通知する方法は、いくつかある。 最近は、普段から使っているテキストチャットに、bot がそれらのアクションを投稿していく方法が、やりやすいと感じている。 集中力は切られにくく、流れも見やすい。 自然とメンバーが見に行ける状況を作りたい。

良い設計とは

良い設計により、後々の情報共有の形も変わってくると言えるだろう。 なぜ良い設計をしたいのか。 それは、後に掛かるコストが大きく変わってくるからである。

様々な設計

設計にも種類があるので、いくつか見ていく。

データ運用設計

コードには手を入れず、運用作業で投入するデータによってアプリケーションが変化していく作りは、一般的だろう。 その場合は、どうやって、どんなデータを入れるのかについて、慎重な設計が必要だ。 何を使って、どのような形式でデータを作るのか。

例えば、ゲームのパラメーター設定など、頻繁にデータ投入と確認を繰り返す作業を考える。 データ作成がやりにくかったり、そこから確認できる状態にする作業が複雑だったりすると、時間が掛かってしまう。 データ作成者がエンジニアでない場合に、毎回エンジニアに何か作業を依頼する必要があるなどのパターンは、その最たる例だろう。 これを繰り返していくのだから、コストが大きく増えてしまう。

長期的なプロジェクトほど、このコストは効いてくるので、できるだけ簡潔・簡単にすむような、データ運用の設計をすべきだ。 使うツールも、いろいろと考えられるだろう。

この為に、しっかりとした運用基盤の構築や、自動化をしていきたい。 なお、この作業は、なるべく初期の段階で行えるのが理想的である。

ここで注意しておきたいのは、データ運用の為に、データのテーブル設計等を歪にするのは、極力避けるべきであるということだ。 データベースサイドとしてのデータ設計についての記述はしないが、アプリケーションの保守性に関わるので、これは蔑ろにしてはならない。

また、例えば、モバイルネイティブアプリの場合、データ種別の使い分けも必要だ。 主に、以下のようにデータが分かれる。

  • サーバーでの処理に使われたり、 サーバーから web API として返すデータ
  • クライアントが組み込んでいるデータ
  • クライアントがダウンロードして、ローカルに保持するデータ

それぞれの特徴に応じて、適切に使い分ける。

リポジトリ設計

管理するソースは、サーバーコード、クライアントコード、データ、グラフィックなど、多岐にわたる。 これを、作業がしやすく、役割が分かりやすい形を目指して、分けて管理する。

大きなソースを扱う場合は、リポジトリが肥大化し重くなり過ぎないように気をつけたい。 コードの管理には Git が使われることが多いが、そのような場合では、SVN や Git LFS も検討する。

設定設計

コードと設定は、上手くファイル等で切り分ける。 これにより、分かりやすくなるのは勿論のこと、例えばソースを外部に公開する場合に、秘密としたい key 情報等がまとまっていると、作業が楽になる。 また、多言語のサポートを行うのなら、整理された文言設定は大切だ。

ブランチ設計

同一のアプリケーションを、プラットフォーム展開したり、海外向けの対応を行うなどで、ブランチを分けることもあるだろう。 ここでも、楽なブランチ運用を探すことになるのだが、その前にまず、ブランチを分けずに済む方法を検討してみたい。 ブランチを切るとマージや追従のコストが掛かるので、先に前項のようなデータや設定分けを使って、なんとかならないかを考えるべきである。 ブランチ分けが良い場合は、運用しやすいブランチ戦略を立てることになる。

設計の基本方針

私は、「理想を考えてから、現実に落としこむ」という流れを心がけている。

例えば、データベースにおいては、負荷を考慮し、非正規化等を行う事が多々あるだろう。

しかし、最初から現実問題を考慮し過ぎると、必要以上に形を崩してしまう事になりがちである。 その為、設計時には、基本の綺麗でシンプルな形を考えてから、現実の条件に照らし合わせて、手を入れていく方法を取っている。

また、「なくせるはずの単純作業を繰り返す状況(人)を生み出したら負け」とも心に置き、設計を考えている。

設計によっても、情報共有は変わるのだ。

ドキュメント

何かについて調べる時、人に聴いたりコードを読んだりしなくても、概要が分かると効率的なので作られる。 何から何までに対応するのは難しいので、需要と効果が大きい箇所を狙って作成する。 時間が経つにつれて、実装とドキュメントが乖離をしてしまう事は良くあるので、メンテナンスされやすい状態や環境を整えたい。

障害

運用しているアプリケーションに問題が発生した時は、速やかに検知、共有し、対応に入る。 検知とその通知のフローや仕組みは、事前に十分確認しておく。 運用を続けるに連れて、通知される物の種類や数は増えがちだが、緊急の物と緊急でない物はしっかり分けて、緊急時の対応をスムーズにしたい。

また、障害対応後は、また同じことが起きないように、対策を講じる。

日報

日単位で、行動を記録し、振り返りを行う。 これにより、作業改善のサイクルを回したり、自身の成長に繋げることも出来る。 頭の中を文章として整理することで、その場では解決できなかったことへの糸口が見えてきたり、モヤモヤしたものがハッキリしたりもする。 時間が立ってから見返しても、なかなか興味深く、この記事を書くのにも役立ってる。

日報の為の方法はいろいろあるようだが、ゆるくやれるのがいいと思っている。

情報共有の範囲

組織における情報共有と言っても、スコープは様々だ。 個人間、プロジェクト内、社内、社外…。

情報が必要になる範囲を考え、適切な範囲へ向けた共有を心がけたい。 プロジェクトを越えて有用な情報が、小さな範囲のみに共有されていては、勿体ない。

ドリコムの社内 gem も、そういった取り組みの一環である。

RubyKaigi2014で発表した - mitaku.log

また、このドリコム Advent Calendar 内でも、社内にあった sharedoc が、社外へ公開されている。

スライド共有サービス sharedoc を作りました - onk.ninja

私としても、gem を作ったり、登壇の機会を頂いたりもした。

また、情報を得たい人が、どんな情報があるか、どうやったら知れるのかが分かる環境を整える。

情報共有の手段

情報共有の際には、様々な手段が使われる。

大まかに、テキストと口頭に分けられる。 それぞれに良さはあるが、口頭でのやり取りも、概要をテキストでも共有できると良いだろう。 テキストだと、非同期なので邪魔になりにくく、また透過性や検索性を上げることが出来る。

また、前述の通り、適切なスコープを意識する。 例えば、問題ないチャットルームについては、基本的に公開しておき、アクセスしやすくしておきたい。

状況や条件を考慮し、適切に共有手段を使い分けていきたい。

情報の取捨選択

情報が多いのは基本的に喜ぶべき状況だが、それを単に追いかけ続けるだけだと、時間を大きく消費しかねない。 情報にアクセス可能なのを前提に、必要な部分を上手くフィルタリングする。 ツールを使いこなそう。

情報共有の自動化

本記事でも数回出てきた「自動化」は、エンジニアが得意とすることであるので、他職種の作業にも注目して、導入を検討したい。 人間は、人間にしか出来ないことをやるべきだ。

情報共有環境の継続的な改善

組織の規模など、状況は刻々と変化する。 慣れて思考停止せずに、環境の継続的な改善を心がける。

まとめ

組織における、エンジニアの情報共有について書いた。 レビューや設計についての深掘りは、別記事としたほうが見やすかったのかもしれないが、関連して書きたかった事柄であったので盛り込んだ。

私自身も、まだまだ情報共有力が弱いので、高めて行きたいと思う。

情報共有は、誰しもが行い、そして苦労をしやすいことだろう。 様々な考え方や取り組みがあるだろうから、その知見の情報を収集し、改善に活かしたいものである。

「情報は発信するところに集まる」という言葉もあるので、積極的に、良い情報共有を行おう。


ドリコム Advent Calendar 2015 その2」、明日9日目は、massy22 さんによる dotfilesを管理しよう - Qiita だ。

論理削除 Casual Talks #1 で、論理削除とElasticsearch活用の話をしてきた

onkさんの方面からお誘いを頂いて、発表してきた。定員が40人のところに140人ほどの参加希望の方がいて期待を感じたのと、周りの発表者の方々がそうそうたる顔ぶれだったので、緊張した。

論理削除周りで経験したことと、Elasticsearchを導入してみたことを話した。

喋り慣れている人が多い中、思い通りに喋れなかったのが反省点。

イベント全体の話は、ここに分かりやすくまとまっていた。ありがとうございます。

テーマを絞ったイベントだった為、話す内容の重複も多かったのだが、それぞれの微妙な違いも楽しめた。

とても為になるイベントで、いい経験になった。これからに活かしていく。

20歳になった

2015/2/23 に20歳になった

ついに20まできた。「もう若くない」というと年上に睨まれるのかもしれないが、実際に周りを見渡してみると、やはり若いとは言いにくい。もともと、若いからという理由での評価は微妙だなーと思ってはいたものの、若さバリューに甘えていたところはあった。

これからは、より自身の向上に励んで、しっかり力をつけていきたい。

(といいいつつ、若さはアピールできる場面では有効に活用していく)

10年間振り返り

せっかくキリの良い年なので、10代の10年間をざっくり振り返ってみる。

所属と所属年数はこんな感じ。

小学校 2年間
中学校 3年間
高専  3年間
会社  2年間

小中学はみんな似たような環境なので置いとくが、高専はなかなか特殊だった。高校と比べて、自由な雰囲気で、早い時期から専門技術を学べる学校。おそらく、高校と大学の間を取ったような雰囲気。(大学に通ったことがないので想像)

在籍中は、個人で簡単なゲームやWebサービスをつくったりした。Webサービスでは、経済産業省から賞も貰った。

本来は5年間で卒業のところを、いろいろあって3年生が終わったところで辞めたのだが(理由の一つは、いわゆる"一発当てたかった")、自分にとって高専を選択したことはよかったと思う。普通の高校に通っていたら、おそらくこっち方面の人間になるのは大学に入ってからになっていた。(中学の頃からC言語に挫折したりしていたり、半田ごてで遊んだりしてはいたのだが…。)何より、この後にショートカットして会社に入ることもなかった。

高専を辞めたあとは、自分でなにかつくって、それで生きていこうと思っていたのだが、会社に入ってみることにした。これは結果的に良かった。すすめてくださった先生、ありがとうございます。

東京に出てきて、会社に入ってからは、多くのことを学んでいる。まず、しょぼかった技術力がかなり上げられた。実際の現場で仕事をすると、実践的な技術を効率よく学べる。個人で勉強をするにしても、この現場のイメージを持ってると持ってないのでは、かなり違うのではないだろうか。他にも、すごい人から刺激を受けられたり、会社と会社で働く人というものがどんなものか分かったり。

もうすぐ丸2年在籍していることになるのには驚きだが、有益だったと思う。いい会社に入れた。会社の方々、いつもお世話になっています、これからもよろしくお願いします。 m _ _ m

おそらく多くの人がそうであるように「すごい人になりたい」と昔から思っている。依然この思いは強いので、諦めず寄り道しながらでも進んでいきたい。

私はいわゆる意識高い系の人々のキラキラさが苦手だ。憧れはあったが、自分はああはなれないなーと。その流れで、私は夢を「ニート」としている。働くっていうより、好きなことして遊んでる、みたいなイメージ。

20歳の抱負

頑張りますっ、よろしくお願いします。

具体的な今年の目標はいろいろあるのだが、とりあえずこのブログは定期的になにか書きたい。

余談だが、会社のチャットなどで、意欲アピールのために語尾に「!」をつけるのはよくやるのだが、ワンパターン過ぎるとアレなので「っ」と跳ねるのを混ぜたり、工夫をしている。

最後に

誕生日をお祝いしてくださった方、ありがとうございます!飲み会をやってもらったり、プレゼントを頂いたり…。

頂いたものをリストにしておく。漏れてないか心配。

  • アヒル隊長 × 3
  • Raspberry Pi 2 Model B
  • レタスみたいな折り畳み傘 Vegetabrella
  • ブラックサンダー × 20
  • SQLアンチパターン
  • レーザーキーボード
  • 缶ビール × 3
  • プリチケ × 2
  • プリチケファイル
  • 大音量目覚まし時計

wishlistも置いておく。気が向いたらなんか下さい。 http://www.amazon.co.jp/gp/registry/wishlist/3986QBTM1YLYW

エンジニアの心構え的な内容のLTをした

誘ってくださってありがとうございました。

今回のスライドは、黒背景に頼らないで、キレイ目なデザインを目指した。 内容は置いておいて、そこそこ満足のいく見た目になった。

内容を少し補足する。発表時は言葉で補った分。

まず、「辛い」という言葉を多く使ったので勘違いされるかもしれないが、仕事は好きである。 でも辛いのは減らしていきたい。

あと、前工程が明らかに遅れているということはあまりない。 たいていは、「さり気なく」遅れる。 スライド中の「仕様変更」のように、例えばデザインなら、仮の状態で期限通りに出してその後に余裕ができたら差し替え用のものをつくる、などだ。 (もちろん、最初から仮前提の期限なら問題ない)

エンジニアも自身の作業が遅れることはよくあるだろうから、誰かが悪いとか言う訳では決してない。 ただ、最終工程である意識は持とうという話。


特定の強い技術分野があるわけではないので、運用系の話に逃げた形。 技術系の面白い話は、聴く人がマッチすると、とても有益なものになる。

経験からの話はどうしても勝てないから、何かあたらしことをやりたい。