プロダクト開発の中になぜか置いてもらっている非技術職の小林（週末は主夫、たまに会社でプロダクトオーナー）です。 日々、エンジニア OR デザイナー OR コピーライター に囲まれながら、プロダクトの成長を見守ってまっす。
ところで、プロダクトが成長していく過程で、新サービス・新機能のリリースに伴い LPや各種画面のちょっとした修正が増えていったりしませんか？
事業戦略上で重要な機能・サービスを開発をしているチームに、飛び込みでキャンペーンLPのテキストの修正依頼が・・・。 仲間としては施策担当者がなんとかしたいと思う気持ちもわかる、でも、エンハンスに集中していて細かい修正をする時間が取りづらい。 そんな時に、同じチームメンバーとして非エンジニアでも手伝えることがあるかもしれません。
クラウドワークスでは、簡単な修正であれば施策担当者（非エンジニア）が行ってしまうこともあります。 我々と同様にGitHubを導入している開発現場なら実現可能だと思うので手順を書いてみようと思います。
やりたいこと
- エンジニアが、やろうと思っているタスクに集中できる環境を維持したい！
- 施策担当者（非エンジニア）の要望に、迅速に応えてあげたい！
持ち物
- インターネット・PC・ブラウザ
- GitHubアカウント
事前に調整しておくこと
- 施策担当者（非エンジニア）がGitHubにアクセスしてコード修正を行う承認と運用ルールの確認
私と同じような職制の施策担当者（非エンジニア）が実際に対応できるように、なるべく詳細に書くことを心がけます！
ブラウザから github.com を利用してコードを修正する手順
修正したい部分が書いてあるファイルを探す
実は・・・この段階から壁があるのです。 なので、ここからはじめます。
ファイルの場所を聞いちゃうのが早いんですが、いつもお願いしちゃっていることを理解するためにも探してみます。 同じ言葉が各所に分散しているケースの場合、依頼していることの影響範囲の大きさを再確認させられることもあります。
Githubにログインし、担当しているサービスのコードが管理されているリポジトリ名の部分をクリックします。
すると画面上部に「This repository」と記載されている検索窓が表示されます。
修正したいLPや各種画面の現在のテキストの一部などを入力して検索します。 それっぽいファイルを見つけたら、近くのエンジニアさんなどをつかまえて 「fugafugaのLPのファイルって、◯◯◯.html.erbであってる？」といった確認をしてみます。 あってましたか？あってましたよね。次いきます。
◯◯◯.html.erb のようなファイル名の部分をクリックします。
画面左上の「Tree」と表示されている部分から「masterブランチ」を選択します。 「masterブランチ」の名前は事前に確認しておきます。 今回は「Sample」と表示されているブランチが「masterブランチ」であるとします。
現在、Web上に公開されているであろうLPや各種画面のソースコードが表示されます。 修正したい箇所を確認してみます。 ありましたか？きっと、あったはず。 では、xxx lines や xxx KB と表示されている列の右側、「History」の隣の隣のペンのマークをクリックします。
なんと、ブラウザから修正できてしまうんです。 ということは・・・そうなんです。 関係ないところに余計なことを書くとヤバイんです。 ここからは特に慎重に作業します。何度かやっていても緊張感のある作業です。 変更したいテキスト等を修正します。
修正の入力が完了したら画面下部の「Commit changes」という部分に必要な情報を入力していきます。 日本語で誰が読んでも変更した内容がわかるように書くように心がけています。 書き終えたら、入力欄の下の「Create a new branch for this commit and start a pull request.」の ラジオボタンをポチります。
そして変更した内容を「masterブランチ」から分岐させる新しいブランチの名前を入力します。 今回は「blog_sample_branch」というブランチを作成します。 この画面での作業を終えるために「Propose file change」をクリックします。
それぞれの現場で設定されている作法に則って、「Write」に変更内容をできるだけわかりやすく記載していきます。 「Label」「Assignees」なども選択します。 次に画面中断に表示されている変更前と変更後のコード（赤色と緑色の部分）に誤りがないか確認します。 問題なければ「Create pull request」をクリックします。これも何度やっていても緊張感が消えません。
作成した「Pull request」は勝手に「Merge」せずに必ずエンジニアにレビューしてもらいます。 レビューしてもらう際には「レビューオネシャス！」と元気よく声をかけましょうｗ 上手く修正できていれば http://lgtm.in/ などで見られるような画像が送られてくることが多いです。 「Merge」以降はエンジニアにお願いしています。
「この簡単な修正、誰かやっといてくんないかな。」といったシーンで、このエントリーをご活用いただければ幸いです。 チーム・組織全体で効率よく開発をしていくために、これからも上手にタスクを分担していきたいと思います。
We’re Hiring！
クラウドソーシングのクラウドワークスでは、Android・iPhone向けネイティブアプリ開発を共に推進していただけるエンジニアを大募集中です。いいチームをつくりましょう。
興味のある方はお寿司ランチを無料で食べながらお話してみませんか？
