TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り

TechRacho:
技術情報発信から広げるエンジニア発
のコミュニケーション文化作り
BPS株式会社 Web開発部部長森雅智
Ruby Business Users Conference 2017
2017/02/231 Copyright © 2017 Beyond Perspective Solutions Co., Ltd. All rights reserved.

はじめに
本発表の資料は発表後公開しますので、気楽にお聞き下さい
※時間の関係でスキップするスライドもあると思います

自己紹介
• 森雅智
• Twitter/Github: @morimorihoge
• 学生時代からWebシステム開発アルバイト -> 少しだけフリー
ランスののちBPSに入社
• PHP 7年 -> Rails 6年なインフラ〜バックエンド寄りエンジニア
• 主な生業
• Webシステムの開発業務（インフラ〜アプリまで）
• Ruby, Rails, MySQL, PostgreSQL, AWS,
• 大学の非常勤講師としてWeb開発に関する講義
• Webサイト開発、RailsによるWebサービス開発など
• :beer: :onsen: :umaimono:

About BPS
• 2007年設立、今年で10年目
• 社員数40名前後、エンジニアが8割ほどの開発会社
• Web開発事業: Rails受託開発を中心とした開発部門
• 電子書籍関連事業: 電子書籍ビューア・アプリ・配信システムの
開発を中心とした開発部門
• 漫画翻訳事業: 日本語漫画の海外向け翻訳事業
• Web開発事業では6年ほど前からPHPからRubyon Railsに
メイン技術の方針転換を行った

Why Ruby/Rails?
• B2Bシステム・B2Cシステムを問わず開発してきたが、案件
の性質としては間を挟まない一次受け開発が多かった
• 物理的にコードを書く分量が少なく、仕様変更に柔軟に対応しや
すいRailsは魅力的だった
• 当時PHPフレームワークがまだ出ては消えを繰り返してお
り、追いかけるのが大変だった
• 受託だとフレームワークを選べないことも多いが、Rubyならほぼ
Railsしか選択肢がないのでわかりやすかった
• クックパッドの様な大規模な実績もあり、勢いのあるコミュニティと
活発なOSSプロダクトが背景にあったため、移行について特に不
安な点もなかった
• 実際に自社案件をRuby/Railsで開発してみたら楽しかった
弊社自社サービスのMANGA REBORN
当時Rails 3.0のRCが出た頃に試しにRailsで
開発してみたことがRails移行のきっかけ
http://mangareborn.jp/

エンジニア教育・評価への取り組み
• 自主学習のためのリソース支援
• 技術書購入他勉強に必要なものについて、会社での購入サポート
• 資格取得に対するインセンティブ
• IPA高度情報処理技術者試験に対する一時金（最大合計100万円）
• その他上長が認める資格について助成（Ruby技術者認定、AWS認定な
ど）
• 会社の求めるスキルセット一覧の明示化（スキル表の作成）
• 採用やエンジニア評価での活用
• 定期的な社内発表・勉強会の開催
• 技術ブログ執筆・レビューによるアウトプット・エンジニア間のコミュニ
ケーション機会の増加
この辺りの葛藤やトライ＆エラーについてはTechRacho記事
「開発会社におけるエンジニアスキル向上施策の過去と今」にて公開しています
https://techracho.bpsinc.jp/morimorihoge/2016_07_25/24383
本発表のメインテーマ

技術ブログ TechRacho: techracho.bpsinc.jp
• 2006年頃から運用を開始
• 当時開発会社の技術ブログが流行っていた時期
• 主なテーマ
• 初期は社員で自由に書いていた。気持ち技術情報が多めくらい
• 2016年8月より本格的に事業化を行い、平日毎日更新中！
• 社員による技術情報を中心とした構成で運用中

なぜ技術ブログを自社事業化したのか？

解決しようとしたもの
• 会社規模拡大に伴うコミュニケーション・ブレークイン問題
• 上級者から先への学習の場の提供
• 熟練者以上のさらなる成長

課題（1）会社の規模拡大と採用
• 継続的に事業が好調となり、案件のお誘いを頂いても手
が足りず断るか長期間お待ち頂く状況が続いていた
• 2016年より採用拡大を行い、現在アルバイトも入れると50
名弱の所帯に増加
約二倍！

課題（1）人数の急激な増加に伴って起こる問題
• 社内の雰囲気・文化継承（コミュニケーション）
• 社内のルールとして記述しきれない暗黙の価値観の継承がうまく
行いづらくなる
• => 社内のコミュニケーションが円滑に行えなくなっていく
• 開発における一時的な出力低下（ブレークイン）
• 中途採用のメンバーでも、その会社ごとのやり方や仕事の進め
方に適応するには数週間〜数ヶ月かかる
• 新規入社メンバーを受け入れたチームでは新メンバーへの情報
共有コストがかかる
• => 採用直後はむしろ一時的に出力が低下する
いかに早く自社の風土を知って慣れてもらうかが大きな問題

課題（2）上級者以上のエンジニアを増やしたい
• 初心者
• 状況に左右されないレシピ・ルールがあれば仕事を遂行できるが、想定
外のことには対応できない
• 中級者
• 少しだけルールから離れることができる。やりたいことがはっきりしている
場合に検索して解決することはできるが、物事の全体像は見えていない
• 上級者
• どこに問題があるのかを探し出し解決することができるが、問題解決の
際にどの部分に焦点を合わせるかの決定にはまだ経験が不足している
• 熟練者
• 物事の全体像や概念を理解しようとする。自分の行動を振り返り改善す
ることができる。他人の経験から学ぶことができる。経験から判断するこ
とができる。
• 達人
• 「よりよい方法」を常に模索しており、自分の持つ膨大な経験と引き出し
から直感で裁量の答えを導き出す
ドレイファスモデルによる技能の段階
リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法, Andy Hunt(オライリージャパン)より要約
仕事をある程度大きな粒度で任せられる
手順まで指示が必要
タスク分割までサポートが必要
プロジェクトの開発リーダーを任せられる
困難な問題の重要な点を探し当て解決できる
職業エンジニアに求める熟練度

課題（2） Ruby/Rails開発教育に関して思う現状
• 初心者向けのチュートリアルや勉強の資料
• Rails Tutorialをはじめ、多くのチュートリアル資料や勉強会・講座
が多数あり、質も高い（他の言語と比較してもすごい）
• 中級者向けの情報・学習
• 上級者以上のサポートがあれば「何を調べれば良いか」はタスク
として指示してもらうことができる
• 問題がはっきりしていれば検索から見つかるQiita/StackOverFlow
等による「XXでYYする方法」といった記事等で調べられる
• 上級者以上になるための学習方法
• 実際に問題解決を行っていく中で習得するしかない？
中級者 -> 上級者になるための学習教材は多くない
※熟練者以上は書籍や技術カンファレンス等で学習できる

課題（2）どうやって上級者になるのか？
• 上級者の仕事を見て・質問して現場で学習
• 同じチームの上級者はプロジェクトに忙しくて質問しづらい
• やり方を説明するのがうまい上級者ばかりではない
• 適切な粒度の仕事を任せてみて練習
• そう都合良く練習できるような案件は多くない（難易度＆納期）
• 勉強会に参加する
• 勉強会のレベルはまちまちで、自分の熟練度に応じた勉強会を
見つけられるか問題
• 発表する側に回るのであればレベルアップもできるが、ROM化し
てしまうと「参加して自己満足する」ことが目的になるケースも
上級者になるための学習チャンスをもっと増やしていきたい

課題（3）熟練者以上のさらなる成長
• 人数の少なかった頃はほぼフラットな構造だったのが、組
織として拡大する中でチームとして動くようになった
• チームリーダーとなる熟練者以上のメンバ同士が業務の
中で技術的に交流する機会が減少
• このメンバーが成長を続けることで将来会社を引っ張っていくの
に、互いの情報交流が疎遠になってしまう
チーム化したことでプロジェクトの並列実行度は上がったが、
熟練者以上が同じプロジェクトに取り組める機会が減る
熟練者以上が質の高い議論をできる場も大事

解決に向けて考えられた方法
• コミュニケーションのための飲み会を増やす？
• 強制参加の飲み会は弊社の文化と真っ向から相対するので没
• 開発における手順を文書化して共通フロー化？
• 多様な顧客を一様に扱えるフローの定義はそもそも難しく、チー
ム・現場への裁量が失われる点も×
• 外部の研修による上級者教育の外注？
• 開発力を競争力とする会社が開発教育を外部に丸投げするのに
は強い抵抗感がある
• もっとすごいエンジニアを連れてくる？
• 数多ある無名な開発会社の一つである弊社にあえて来てくれる
スーパーエンジニアはいない

弊社の取ったアプローチ
• 一つだけではなく、複合的な施策を行った
• 組織の仕組み自体へのテコ入れ
• 業務時間内に週一勉強会の実施
• プロジェクト・チーム横断の情報交換ができるSlack Channelの設置
• 既にあった自社技術ブログTechRachoを使ったコミュニケーションの
活発化

TechRachoの運営とポイント

About TechRacho
• WordPress＋カスタムテーマ
• 専任担当者は1名
• Rails Tutorial/Rails Guides日本語訳
の協力者でもある @hachi8833
• 運用サポート
• 一部開発メンバの稼働をもらいつ
つ対応
• 執筆者
• 社員とアルバイトを中心に運営中
• ※外部の執筆者募集も検討中
• 運営状態
• 社内事業化以後、毎日更新中

TechRacho過去の人気記事 – はてなブックマークより -
参考: http://b.hatena.ne.jp/entrylist?sort=count&url=techracho.bpsinc.jp
※大きくヒットする記事は1〜2ヶ月に一度程度

技術ブログ運営のポイント
• 取りくんで良かった点
• 記事を書きやすくするための環境作り
• 記事の社内レビュー
• 社内技術チャットの活用
• 注意すべき点
• 上級者以上のモヒカン化
• 機密保持契約
• 良いエコシステムが回り出すのには時間がかかる
• 技術ブログが全てを解決するわけではない
• 課題

ポイント（1）: 記事を書きやすくするための環境作り
• 正式に社内事業化し、社内に呼びかけた
• 上長の許可があれば業務時間を使って記事執筆しても良い環境
• それまでは月に1〜2回程度の更新だった
• マニフェストや執筆ガイドラインの提示
• 求める価値観を明文化することで記事に求める最低限のハード
ルや方向性を共有
• プラグイン導入と調整による執筆・レビュー負荷低減
• MarkDownでの執筆対応（効果大）
• 未ログインでも閲覧できるプレビューURL生成プラグインにより、よ
り広いメンバにレビューしてもらいやすい環境作り
• 共著プラグインにより元ネタのやりとりに参加したメンバを公開
少し時間ができたので書いてみようかな？と思ったときにぶつかる障壁を
なるべく排除していくことが大事（モチベーションのあるうちに書いてもらう）

初期マニフェスト

初期リーンキャンバス

ポイント（2）: 記事の社内レビュー
• 上級者以上のエンジニアによる記事内容のレビュー
• 技術的に正しい内容なのか？誤解したまま記事を書いていない
か？
• もっと伝わりやすい言い回しや例を出せないか？
• ここにこういう内容を追加するともっと良い記事になるよ
• 熟練者同士であーでもないこーでもないの議論に派生することも
• 編集部によるフォーマットレビュー
記事公開の流れ
1. 記事を執筆し、プレビューURLをSlackのpublic channelに投稿
2. その時レビューできる人が誰でもチェックできるので参加できる人が議論
3. 議論の収束を待って公開（レビュー内容を反映するかどうかは著者に委ねる）
• 初級・中級者でも高いクオリティの記事を執筆することができる
• レビューを通すことで会社として問題のある記事を公開前にチェックできる
• もし仮に記事が炎上して叩かれても編集部がケアする責任分離
• レビュー過程を見える所で行うことで、執筆者以外も見て学習できる

日々のレビューから
その1
条件式での比較演算子
の話からRubyの比較系
メソッドの話へ・・・
対応記事: https://techracho.bpsinc.jp/hachi8833/2017_01_23/32848

日々のレビューから
その2
ActiveSupportの
core_ext/regexp内のコードは
どうなのよ？的な話から派生
※#match?メソッドのRubyバー
ジョン互換対応コードに
//.respond_to?(:match?)
というものがあり話題に
対応記事: https://techracho.bpsinc.jp/hachi8833/2016_11_16/28801

ポイント（3）: 社内技術チャットの活用
• 社内技術チャットはネタの宝庫
• 現役エンジニアが質問して解決した実例：価値が高い
• 参考情報として流れてきた技術記事について熟練者や達人がコ
メントしたツッコミ
• 記事にすることで「前も話したけど」の頻度を減らせる
• 上級者も同じ質問に何度も答えるのは苦痛。後述するモヒカン化
の原因になることも
• 「あたりまえ」と思っていることも記事にする価値がある
チャットはオンラインのコミュニケーションには向いているが、
情報の蓄積には不向き
記事にすることで保存・検索しやすいまとまった内容として蓄積できる

注意（1）: 上級者以上の過度なモヒカン化に注意する
• 上級者以上のエンジニアが必ずしも良い先生であるとは
限らない
• 「こんなこともわからないのか？」「これはない」などの周りを萎縮
させてしまうような言い回し・マウンティング
• 質問者に答えに繋がるヒントをくれないなど（状況にもよる）
• しかし「間違ったことを間違っていると言ってくれる熟練者」
の存在は大事
• 馴れ合い重視で議論の質が下がるのは嬉しくない
• ほどよいマサカリの飛び交い度合いを保ち、議論の質を維持する
ことが大事
• マサカリを投げられることを恐れない・議論と人格を切り離せる風
土を作る

注意（2）: 機密保持契約に関する注意
• 受託開発の場合、納品物であるソースコードの著作権は
発注元に帰属するケースが大半のため、ソースコードをそ
のまま記事に載せることは避ける
• 多少面倒でもダミーサンプルのソースコードで説明する
• 既存の開発チームに準委任契約で参加する場合、他社
のノウハウを勝手に記事化しないように注意
• SES等で客先常駐がある会社の場合、特に注意すべき
• ※弊社は自社エンジニアの客先常駐は原則お断りしています
• 記事の書き方として、顧客を特定される様な書き方・不快
に感じさせてしまうような書き方は避ける
• 顧客も読む可能性のあるものなので、会社としての信頼を失わな
いように注意する
多くの場合は「広く公表された事実やノウハウ」を整理して記事にするケースが多いため、
書き方に気をつければ書けない記事というのはそれほどない

注意（3）: 良いエコシステムが回り出すのには時間がかかる
• ちゃんと続けるのは難しいし、大変
• 一時期流行った技術ブログの中で今でも更新されているブログ
の少なさを見れば難しいことは明らか
• スタートダッシュしすぎると続かなくなるので、継続可能なプランを
• 経営層の理解と推進担当の心の強さが大事
• 最初は思っていたより協力してもらえなくてもめげない心
• 地道に続けていく姿を見せていくことで参加してくれる人ができる
• うまくいかないことに対して社内に恨みを持たない。前向きに！
• 最初はこまめに様子を見ながら軌道修正を
• 社内の空気を読むべきところと空気を読まなくて良いところを見て
いく

注意（4）: 技術ブログが全てを解決するわけではない
• 技術ブログはあくまでアウトプットの一形態
• 勉強会発表やプロジェクト内での問題解決など、アウトプットの形
態は人によって得意不得意がある
• 技術に対する興味やアウトプットを大事にする社風・価値
観が前提
• 記事を書かない役員がエイヤッとやっても多分うまくいかない
• 参加しやすい空気作りや意見を言っても良い雰囲気を作っていく
• まとめて議論したいときには集まって話すのも大事
• チャットだけに囚われずスロットの勉強会を開くなど

TechRacho発の勉強会
週刊Railsウォッチつつき会
Ruby/Rails界隈の主に海外情報をま
とめてきた内容をみんなでつつきな
がら理解する勉強会
英語記事やRailsのPRなど、一人だと
追いかけるのが大変な内容をみん
なで追いかける
「希望者参加」「業務時間外開催」で
も毎回5〜6名ほどが参加

目下の課題
• 社内の流れが良くなってきた実感はあるが、計測可能な
指標として優位な良い結果が現れていない
• PV数はそれほど爆増したわけではない
• 滞在時間や直帰率は下がっているが、読者が満足しているかど
うかは不明
• 問い合わせ数や採用の手応えは良くなった感触はあるが、
before-afterが正確に取れるわけではない
• 社内向けの取り組みとしては概ね軌道に乗せられたが、
事業としての今後をどうするかが課題
• 会社の予算を使って運営しているので常に次の展開を考え続け
ていく必要がある
• エンジニアの稼働を使って記事を書いてもらうのもコストなので、
成果を計測してどこまで投資していくかの舵取りをしていく必要が
ある
• 外部のRuby/Railsエンジニア/コミュニティとの交流・展開
• まずは社内からと言って内部を固めてきたが、定着してきたので
社外にも出ていきたい

まとめ
• 時間の都合で話し切れないことも多々ありましたが事業
化から半年続けてきての思惑や取り組みを紹介しました
• TechRachoは皆さまのフィードバックをお待ちしています
• Twitter: @techrachoや記事をTweetして頂ければ見ています
• 弊社お問い合わせフォーム: https://www.bpsinc.jp/contact.html
• 合同勉強会のお誘いや情報交換などお気軽にお声かけ下さい
• エンジニア中途採用も随時募集しています ☺

TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り

Recommandé

Contenu connexe

Tendances

Tendances (12)

En vedette

En vedette (20)

Similaire à TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り

Similaire à TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り (20)

TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り