開発リソース不足について思うこと

もしあなたがベンチャー企業に勤めているとしたら、まず間違いなく開発リソースが不足していると思います。多くのベンチャー企業において開発者は足りていないはずです。
 
おそらく多くのベンチャー企業というものは、売上が十分あるわけでもなく、資金が潤沢にあるわけでもなく、でも実現したい世界があり、そのために作りたいものがあり、作ったら今度は追加したい機能があり、追加したら今度は改善したい機能があり、また追加したい機能があり、改善したい機能があり、いつのまにか負の遺産があり、それを解決したい欲求があり、そんな中機能追加があり…という感じだと思います。
 
 
 
そんな中、経営陣や開発リーダーが口を揃えて言うのが、この有名なセリフ、
 
「開発リソースが不足しているから、採用を強化しよう!」
 
です。
 
 
 
このセリフ、一見何の問題も無いように聞こえるので異議を唱える人は少ないかもしれません。ですが、開発リソースが不足しているという問題を解決するための手段としては実は危険なのではないかと考えており、警鐘を鳴らす意味でこのポストを書いてみることにしました。
 
 
 
 
 
さて、人手が足りなくなりやすいというのは事実だと思いますが、ではどれくらい人手が足りなくなりやすいのかと言うとこれは自明ではないので、考えてみることにします。
 
 
まず、機能を追加開発することを考えます。機能は時間経過とともにどんどん増えていくもので、経過時間Tに比例して機能数が増えていくとすれば、機能数Nは
    N = aT (aは比例定数)
として表せます。つまり機能の実装にかかる総コストは、機能1つの実装に必要な平均的な開発リソースをFとすれば、
    NF
となります。これをTで微分すると、ある特定の瞬間において機能追加のために必要な開発リソースCが求まり、
    C = dNF/dT = aF
となります。
 
 
また、機能は作っておしまいということはほぼ無く、使われていく間に改善させていかなければなりません。ある特定の瞬間において機能を改善するために必要な開発リソースKはその時点で存在する機能数Nに比例するので、
    K = bN (bは比例定数)
と表せます。
 
 
つまり、ある特定の瞬間において新機能の開発と機能の改善に必要な開発リソースは
    C + K = aF + bN = aF + abT
となります。
 
 
言い換えると、開発開始(≒起業したタイミング)から時刻Tまでに必要な開発リソースは、上記を経過時間Tで積分して
    aFT + abT**2 (**2 は2乗の意)
となるわけです。
 
 
 
 
 
必要な開発リソースの総量の支配項が経過時間Tに比例するのではなく、Tの2乗に比例してしまうんですね。
 
 
 
これはどういうことかと言うと、「経過時間に比例した数の開発者を採用しなければ、開発リソース不足に陥る」ということです。
 
 
 
 
まぁとんでもなく回りくどい言い方をしましたが、簡単に言えば、
  • 機能数に比例した数の開発者が必要
  • 機能数は時間に比例して増える
  • つまり時間に比例した数の開発者が必要
ということです。
 
 
 
 
 
なので、2次関数を知っている人ならすぐに想像できるかと思いますが、あっという間に「やりたいことがたくさんあるのに全然追いつかない」という状況になります。負の遺産を解消する余力なんてあるはずもありません。機能を追加・改善しようと思ったら開発リソース不足になるのが当たり前なのです。
 
 
 
 
 
 
 
 
 
 
 
さて、ここでもう一度この発言を見てみます。
 
「開発リソースが不足しているから、採用を強化しよう!」
 
 
 
ちょっと見え方が変わっていませんか? まるでお風呂の栓を閉めずにお湯を入れている人が「お湯が足りないからバケツでもお湯を入れよう!」と言っているように聞こえませんか?
 
「忙しさの解決のためにはエンジニアを採用すべし」と盲目的に考えてしまうことが危険なことであるというのは経験的にもその通りだと思っていて、そういう状況下でエンジニアを増やして「あ~、忙しさが解消されたわ~。幸せだわ~。」って言ってる人を見たことが無いのですよね。
 
 
 
 
では採用強化じゃない方法で開発リソース不足を補うにはどうすれば良いのか?
 
 
これは上述の方程式の中での仮定のうち1つ以上を覆すしかありません。明示的にあるいは暗黙に何を仮定したかというと、
  • 機能数が時間経過に比例して増える
  • 全ての機能は改善する必要がある
  • 開発者がこなせる作業の量は一定である
  • 経過時間に比例した開発者数の確保は困難である
  • 比例定数aとbが小さくない値である
などです。
 
これらの仮定のいずれかが間違っていると断言することができれば開発リソース不足は解消できる可能性があります。
 
例えば2つ目の仮定が間違っていて、「実は改善する必要のない機能もある」とか。
 
例えば最後の仮定が間違っていて、「実はaとbは限りなく小さい値で、必要な開発者数は確かにTに比例するんだけど、その値が1を超えるのは10年後で、2を超えるのは14年後であるから、この先10年間は開発者は1人だけで十分」とか。
 
 
 
 
 
 
 
私見ではありますが、これらの仮定を覆すための方法が「リーンスタートアップ(機能数を時間経過に比例させず、改善に重きをおく)」だったり、「ピボット(機能を捨てることで、改善すべき機能の数を減らす)」だったり、「めっちゃ売り上げる(そして開発者数を時間に比例させて採用する)」だったりするのかな、と考えています。
 
 
 
 
 
 
僕個人としては、「機能数が時間経過に比例して増える」という仮定を覆すのが良いと考えています。「やるべきことを精査し、やらぬべきことをもっと精査する」というのが開発リソース不足解決のための第一歩で、極限までやるべきことを絞った上でその機能をリーンに改善していく、というのが最良なのではないかな、と。
 
 
もちろん、言うは易し行うは難しではありますが。
 


リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (94件) を見る

 

GitHub PagesとJekyllで静的サイトを構築する第一歩

備忘録として、GitHub PagesにJekyllでサイトを作成する初歩の手順を書いておきます。以下、環境はUbuntu 14.04です。

 

1. ruby2.0以上をインストールする

% sudo add-apt-repository -y ppa:brightbox/ruby-ng
% sudo apt-get update
% sudo apt-get -y install ruby2.1 ruby2.1-dev

 

2. Jekyllをインストールする

% sudo gem install jekyll

 

3. GitHubに組織とリポジトリを(もしまだ無ければ)作り、cloneする。

組織名を<organization>、リポジトリ名を<organization>.github.ioとします。

 

 

4. 以下のフォルダ構成を作る。

.
├── _config.yml
├── _layouts
│   └── base.html
└── index.md

=== _config.yml ===
auto: true
server: true
markdown: kramdown

=== _layouts/base.html ===
<!DOCTYPE html>
<meta charset="UTF-8">
<title>Test</title>
<p>Hello,</p>
{{ content }}
<p>World.</p>

=== index.md ===
---
layout: base
---
ほげほげ

 

5. ローカル環境で確認する

% jekyll serve

ブラウザで http://localhost:4000/ にアクセスして確認する。「Hello, ほげほげ World.」みたいな感じで表示されていればOKです。

 

 

6. コミットしてpush

% git add .
% git commit -m "Test commit"
% git push origin master

 

7. ブラウザで確認する

https://<organization>.github.io/

 

 

以上で、GitHubが勝手にJekyllを実行してくれて静的なHTMLを生成してくれます。あとは Jekyll • シンプルで、ブログのような、静的サイト などを参考にしながらカスタマイズしていけば良いと思います。

 

なお、Pythonが好きなので本当はPelicanに良かったのですが、GitHub本家がJekyll推しのように見えたのでひとまずJekyllを使ってみることにしました。

 

書き心地が最高のノート

6年程前にスマホを使うようになってから、同時に手帳を使わなくなりました。

 

スケジュール管理もタスク管理も簡単なメモも、まぁスマホで十分効率的に扱えます。

 

ただ、最近

「あれ? 実は手帳も持ち歩いた方が効率的なのでは?」

と考え始めました。

 

んで、あれこれ考えた結果、やっぱり手帳を持ち歩こうという結論になったわけです。主な理由は「紙の検索性能は実は高い」「閉じた図形を描きやすい」という2点なのですが、この2点について説明を書いてみたらそれだけで1,300字くらいになって自分でも読む気が失せたので詳細は割愛します。

 

 

手帳を持ち歩くことを決めたら、今度は良い手帳と良いペンを探すことになるわけですが、先日最高のものを見つけましたので、少しでも多くの人に少しでもより幸せな文具ライフを送っていただけるようこの記事を書こうと思ったのでした。

 

 

最高の手帳について

ずばりこれです。

アピカ プレミアムCDノート CDS90W 無地 A5

アピカ プレミアムCDノート CDS90W 無地 A5

 

有名な商品ですしPRにも力が入っているようですのでご存知の方も多いかと思いますが、このノートの紙質は他の製品と一線を画しています。


「良い手帳とか言っておきながら、手帳じゃなくてただのノートじゃないか!」とお思いの方もいらっしゃるでしょう。が、このノートのすごさを知ってしまえばもはや手帳かどうかということにこだわる意味すらおぼろげに霞んでしまうことでしょう。

 

このノート、本当にすごいんです。何がすごいかと言うと、紙を頬ずりした時の感覚が、最愛の息子を頬ずりした時の感触と似ているのです。

 

東急ハンズでこのノートを初めて手で触った瞬間から「もしや!」と思っていたのですが、買って自宅で夜な夜な頬ずりしてみたら案の定という感じでした。ノートに頬ずりだなんて気持ち悪いやつだなと思ったそこのあなた、是非騙されたと思って頬ずりしてみていただければと思います(真顔)。できれば、モレスキンのノートとかと比べてみるのがわかりやすいかもしれません。同じくらいの価格帯なのにここまで差があるのか!というのがわかりやすいかと思います。

 

ノートにしては少々高価なので買うのはちょっとなぁという方は、是非文具店・東急ハンズ・ビックカメラなど、今すぐお近くのお店に行って頬ずりしてみましょう。店員さんに怒られるかもしれませんが、もし怒られたら諦めて重々店員さんに謝り倒した上でお買い上げください。ノートを手に入れるだけでなく、


あなた「文房具屋でノートに頬ずりしてたら店員に怒られちゃってさ。」


会場「どっ」


という面白エピソードもゲットできるので、きっと後悔はしないと思います。(真顔)

 

この紙質に出会ってしまった以上、もう他の紙は使えません。なのでシステム手帳のようなものではなく、無地のこのアピカプレミアムCDノートを使うことにしました。サイズはもちろんみんな大好きA5です。


使ってみて、本当に快適です。ペンがスムーズに紙の上を走り回る感じで、ペンの違いがすごくわかるようになります。

 

 

最高のペンについて

さて、最高の紙を見つけたら最高のペンを探したくなるのが人間の性です。人間って本当に強欲ですね。最高の紙だけでなく最高のペンまで手に入れようとするなんて、「お前はまるでバベルの塔にでも登ってるんじゃないのか」というツッコミが聞こえてくるようです。ただ、最高のペンは実はまだ購入していないので、まだギリギリセーフです。年内には買うつもりですが、それはそれで置いといて、今回はお気に入りのインクについて紹介したいと思います。

 

自分はここ数年間、もっぱら高速に書いてもインクが絶対にかすれないペンを使ってA4のコピー用紙にメモや計算などを書いていました。インクがかすれないということをKPIに置くのであれば、おそらくこのインクに優るものは無いでしょう。


ただ、ノートに書くとなると話(KPI)が変わってきます。ノートに書く場合は裏写りとか速乾性が重要になってきますので、インクを垂れ流すような水性ペンではちょっと厳しいんですよね。

 

そこで油性ボールペンを検討しようということになるのですが、しばらく油性ボールペンから遠ざかっている間に、なんとまあ百花繚乱の様相を呈しているではありませんか。ジェットストリーム/アクロインキ/エマルジョンインク/ビクーニャインク…。なんか四天王みたいな感じで熱いことになっています。エナージェルも水性ながらなかなかやりますし、正直どのインクを選べば良いのか全くわかりません。

 

 

まぁわからないなら試すしか無いということで、試しまくりました。もしビックカメラや伊東屋の試し書き用の紙に「素数」と書いてあるのを見つけたら、おそらくそれは僕の仕業です。四つ葉のクローバーよりはレアなものを見つけたと思って喜んでください。

 

 

結果、ジェットストリーム(界隈では"ジェスト"と呼ぶので覚えておくと良いかもしれません)とアクロインキが甲乙付け難いくらいにとても良いです。が、ジェットストリームは以前から常に鞄の中に忍ばせていて、先日インク漏れのせいで鞄がちょっと汚れてしまったので、今後はアクロインキをメインで使ってみることに決めました。まぁインクで鞄が汚れたと言っても、文房具は子供みたいなものなので子供のおしっこが鞄に付いたくらいの感じで全然問題ないんですけどね。

 

 



というわけで、最高の紙とインクを持ち歩くようになって、毎日が充実しています。ノートはハードカバーのものもあるので、こちらはプレゼントとかにも良いかもしれません。是非お試しあれ。

アピカ プレミアムC.D.ノート ハードカバー CDS250W A5 無罫 ブラック

アピカ プレミアムC.D.ノート ハードカバー CDS250W A5 無罫 ブラック

転職のご報告

私事で恐縮ですが、とは言いながらもこのブログに私事以外のことを書いた記憶がほぼ無いので本当は全く恐縮していないのですが、この度転職いたしました。


2013年に株式会社アイリッジ(今年の7月に上場して感慨深いです)のCTO職を辞して株式会社リーディングマークのCTOを務め、リーディングマーク社においては『レクミー』という新卒学生向け動画サービスを作ったりして、世の中を変え得るチャレンジングなプロダクトに携わっていました。現在の就活のあり方はおかしなことだらけで、かつそれに気付く人が世の中に増えてきているので、構造を大きく変えるチャンスはまさに今あるものだと感じています。


にも関わらずわずか20ヶ月で退職するに至ったことについては、自身の力不足を痛感せざるを得ません。人生における最大の失敗と言えるかもしれません。本当に恥ずかしすぎます。どれくらい恥ずかしいかと言うと、土曜日の昼下がりに渋谷のスクランブル交差点のド真ん中で「1は素数だ!」と大声で叫ぶくらい恥ずかしいです。


辞めた理由を端的に記しておくと、社内の重要なポストに就いている人物が、社内はおろか社外の方々との約束まで平然と軽視(≒ブッチ)したり、あるいはそれに準ずる(それを超える?)ことを恒常的に行い、反省せず責任も取らず改善もせず筋の通らない言い訳しかしない、という状況が長らく続いており、氏の改善のために少なからず時間を費やしたものの一向に改善することができなかったので、またその改善されない状況を是とする経営判断が行われてしまったので、これは無理だなぁと判断し辞職するに至りました。


僕だけでなく、他では見たことないくらいに優秀な中途入社の方々も既に何名か辞めてしまいました。まだ残っている従業員の方々や前途洋々なインターンの方々を思うとかなり辛いものがありますが、皆さんのことは大好きなので草場の陰で応援しています。




前置きが長くなってしまいました。




どこからともなく、


「んで、結局どこの会社に転職したのよ!?」


という声が聞こえてきます。





「1が素数wwwww恥ずかしすぎるwwwグフフwwwwグフッwwwwブヒヒヒwwww」


という声も聞こえてきました。(幻聴)




さて、この夏より、株式会社マイクロベースという小さな小さなベンチャー企業でCTOを務めることとなりました。


従業員数こそまだまだ少ない(ジョインした時点では社長と僕とインターンの方々+αだけ)のですが、マイクロベースが持っているデータはとてもユニークで面白いものばかりです。地理情報に紐付いた高精度の人口統計や2040年の人口予測データを始めとして、あらゆるデータが既に作成されており、また今後増やしていく計画があります。社長が東大の博士号を持っている筋金入りのデータマニアで、参入障壁が極めて高いデータを高速に・省リソースで作ることができるのです。この能力と環境には目を見張るものがあります。


一方で僕の強みとしては、いくらかのWebサービスやアプリを創った知見/人並み程度の数理情報学の素養/チームビルディングの経験、などがあるので、組み合わせたら面白そうだなと思い人生を賭けてみた次第です。


社長が1人でやっている会社に2人目としてジョインするのは、アイリッジの時以来2度目の経験となります。前回は独身でしたし何とでもなりましたが今回はそうもいかないので、慎重かつスピーディに全力で頑張っていきたいと思います。興味のある方は是非お話しましょう。株式会社マイクロベースをよろしくお願いいたします。


なお、5月から7月までの間はフリーランスとして働きながら転職活動を細々と行っておりました。転職サイトに登録せずともいくつもの素晴らしい会社からお声がけをいただき、日頃お世話になっている皆様には文字通り本当にお世話になっていたのだなぁと感激することひとしおでした。皆様への感謝の気持ちを忘れず、いつか御恩をお返しするつもりで、気持ち新たに開発者人生を謳歌していきたいと思います。



長くなりましたが、今後共どうぞよろしくお願いいたします。

電子書籍の無料化について







「――――電子書籍、読んでますか?」





さて、ちょっとドラマチックな展開が期待できそうな書き出しにしてみましたが、ドラマチックな展開はありません。電子書籍について思うところがあったので書いてみようと思います。

数年前から、電車の中で電子書籍を読んでいる方をチラホラ目にするようになりました。最近は「自炊」という言葉もあまり耳にしなくなったように感じますが、ひょっとすると当時は腰が重かった大手出版社が現在は割りと電子書籍に前向きになり、自炊を必要とするユーザーが少なくなってきたのかもしれません。(憶測)

そんな電子書籍ですが、自分は「ひょっとしたら電子書籍(マンガ)って無料化できるのではないだろうか」と考えています。今の電子書籍は正直コンテンツ料金が高いと思っていて、紙を印刷せずに電子データを転送するだけで提供できるのにこんなに高額なのは、きっと誰かが何かをサボってるからなんだろうなと考えています。なので、もっと安くできるだろうなとは信じているのですが、無料にできるのではないだろうかとも感じるのです。

ではどうやって無料にするのかというと、「全ページの全コマを広告枠として販売する」という方法によって実現します。

例えば、ジョジョの奇妙な冒険の第5部でアバッキオがジョルノにお茶を飲ませるシーンがありますが、その通称アバ茶をクリックしたらリプトンのお茶の購入ページに飛ぶとか。あるいは第3部でテレンス・T・ダービーがやってたゲーム画面をクリックするとスマホアプリのダウンロードページに飛ぶとか。そんな具合です。

ワンピースで言えばゴムゴムの実をクリックすると千疋屋のメロンのページに飛ぶとか。

デスノートで言えばデスノートをクリックするとコクヨのページに飛ぶとか、夜神月の腕時計をクリックするとSEIKOのページに飛ぶとか、"計画通り"の文字をクリックするとアコムのページに飛ぶとか。

まぁ無数に「おっ、ちょっとクリックしたくなるかも!」とユーザーに感じてもらい得るものができると思うわけです。

第一段階

その仕組みをまずは「権利者(出版社とか漫画家とか)が1PV(=1人のユーザーが1ページを見ること)あたりの広告の単価を定め、どのページを誰に何PV分売るかを決める」というスタイルでスタートします。もちろん、広告の単価はページごとに異なります。

最初はどの権利者も疑心暗鬼なので、販売するPV数の最小単位はなるべく大きめにしておきます。(広告枠が売れなかった時のリスクをなるべく下げるため。)

人気の漫画は広告枠も売れやすいので、これにより人気作品を無料で提供できるようになります。このフェーズにおいては、広告無しで読みたい人は1冊500円くらい支払って今までどおり広告無しで読めます。また、残念ながら広告主が見つけられなかったマンガは今までどおり定価で売り続けるしかありません。(佐藤秀峰先生のように無料で作品を提供する方もいるかもしれませんが、ごくごく少数なはずです。)

第二弾階

上記の施策によりいくつかの人気マンガにおいて無料でも売上を上げることができる実績ができると、今度はいかにより多くのマンガを無料にできるかについて考えることになります。あまり販売数が見込めないマンガにおいて売上を上げるためには、より多くの広告主を集める必要があります。

また、この段階になると「このコマのリンクはリプトンじゃなくて午後の紅茶にした方が絶対面白いだろう」のような意見をもった読者が現れてくると予想されます。

そこで、「広告主がどのページを購入するかを決めるのではなく、一般ユーザーがどの広告をどのページ(のどのコマ)に載せるかを定めた、"広告パターン"というものを作成できる」という機能を実装します。広告主は今までどおり広告料を支払いますが、どのページにどの商品へのリンクを配置するかは広告主ではなく広告パターン作成者が決めるということです。広告パターン作成者は広告主が提供する商品の中から最適なものを選び、適切だと信じるコマに貼り付けます。読者はどのマンガをどの広告パターンで読むかを選択できます。「ジョジョを広告パターンAで読む」みたいな感じです。

この時、広告料は権利者の収入になるだけではなく、広告パターン作成者にも一部支払われるようにします。

ただこの広告パターンのCGMはうまく設計しないと「誰かが広告パターンXを作って、そのパターンではどのコマにも広告が存在しない」という状況ができてしまうなど、結局広告無しで無料でマンガを読めてしまうことになりかねないので慎重に設計する必要はあります。

無料化していないマンガの広告がクリックされた場合は、広告料が広告主と広告パターン作成者の2者によって分配されますので、広告主としては広告料の削減につながります。

第三段階(最終段階)

上記の施策により、以下のようなメリットが既にある状態になります。

  1. 本気でクリックさせたいという広告パターンが大量に作られるので、クリック率が上がる。
  2. 数ある広告パターンのうち最もクリック率が高いものがわかり、「どのコマにはどの広告を貼るのが最適か」がわかり広告の最適化が可能になる。
  3. それまで無料化せず定価で売っていた漫画にも広告パターンが作られるようになり、無料化を躊躇していた権利者がその広告パターンに後押しされることによって権利者が無料化に踏み切るケースが現れ始める。

そこで、「自動的に計算された各コマの最適な広告を組み合わせた最強の広告パターンZを用意する」という施策を打ちます。これにより権利者はより多くの利益を生み出せるようになります。

また、出版社を通さずに自由にマンガを提供できる環境を整えたり、マンガを海外に提供するために翻訳機能を付けたりするのもこのフェーズで行います。機械学習を用いて自動的に広告を配置してみるなどの実験もこの段階でやれるかと思います。

まとめ

現状で200ページのマンガが1冊500円で売られているとすると、1ページ分の広告枠を1PVあたり2.5円で買ってくれる広告主がいれば採算が取れる可能性が出てきます。1万部売れそうなマンガなら1ページ2.5万円の広告枠に相当することになります。全ページに広告主がつくことも無いと思うので、1ページあたり5〜30万円とかそんな感じでしょうか。

なんか、意外に現実的な気がしますので、是非興味を持った方はご連絡ください笑 進める上で最も厄介なのは権利者との交渉だと思うので、そういうコネというかスキルを持った方がチームにいないと失敗しますね。

Panasonic DMC-CM1

開発用にAndroid5の端末が必要になり、かつカメラの性能が良い端末だと嬉しいな思って色々と調べてみたら、逆転の発想で「デジカメにSIMを挿せるようにしてみた結果wwwwwwww」という紹介記事があってもおかしくないような面白い商品を見つけたので、買ってみました。

PanasonicのDMC-CM1という商品です。

「他のスマホより圧倒的に分厚い」という欠点があり、レンズケースを付けるともはやジーンズのポケットには入りません。なので、レンズケースを着けたい場合はポーチとか鞄に入れるとかしないと持ち歩くのはつらいかと思います。

また、レンズがスマホに比べてかなり大きく目立つので、「電車や公共の場で使う時は盗撮してるんじゃないかと疑われそうで若干ソワソワする」という欠点もあります。

それ以外は完全に満足で、本当に素晴らしい商品だと思います。

自分はカメラや写真には疎く「楽してそれなりに綺麗な写真が撮れれば良い」という感じなので上記の写真程度のクオリティで十分なのですが、CM1は基本的にはデジカメなので、シャッタースピードやら露出やらを調整したりしてもっと美しい写真を撮ったりはできそうです。これを機に写真の勉強でもしてみるか!…とはなりませんが、とりあえず日々持ち歩いて楽しんでみます。

ちなみにMVNOのIIJmioのmicroSIMをヨドバシカメラで1,800円で購入して挿していますが、かなり快適です。

スタートアップが初めてGitHubを使う際の手順

先日、スタートアップの方からGitHubの使い方について質問を受けたのでまとめてみます。この記事を読んで役に立つ可能性があるのは

  1. これからGitHubを使ってみようとしている
  2. ソースコードを管理したいが公開はしたくない
  3. エンジニア歴が短かったり非エンジニアだったりする

という方々に対してなので、これらに当てはまらない方はそっとブラウザを閉じていただければと思います。

まず最初に、「Organizationを作る or 作らない」によって手順が若干異なるので、決めてしまいましょう。Organizationというのはいわゆる「会社用のアカウント」みたいなもので、権限の管理(◯◯さんはソースコードを見るだけ、△△さんはソースコードを改変することもできる、等)が楽になるというメリットがあり、毎月の利用料金がかさむというデメリットがあるもの、と考えていただければ概ね間違っていないかと思います。

  1. リポジトリを新規に作る頻度が極めて少ない(≒ 頻度が上がるのはだいぶ先の予定)
  2. 携わるエンジニアの数が少ない(≒ エンジニアの数が増えるのはだいぶ先の予定)
  3. 支出をなるべく低価格に抑えたい(毎月7ドル or 25ドルの差が出ることがあります)

これら全てに当てはまる方はしばらくは「Organizationを作らない」という方針で大丈夫かなと思います。 いずれか当てはまらないものがあればOrganizationを作ってしまいましょう。あとで作ることもできますので、 何かしら不安があれば作らない方法で大丈夫だと思います。(個人的には最初から作っておいた方が気持ち良いのでオススメです。)

Organizationを作るにせよ作らないにせよ、事前準備としてGitHubアカウントを作っておいてください。アカウントの作成は https://github.com/ にアクセスして、usernameYour emailCreate a passwordを適宜入力するだけで簡単に作成できます。

Organizationを作る場合の方法

手順1. Organization(組織)を作る

GitHubにログインした状態でhttps://github.com/にアクセスし、画面左上の自分のアカウント名をクリックして +Create organization をクリックします。

f:id:phero:20150510134727p:plain:h180

あとは画面の指示に従ってカード情報等の必要な項目を入力したり選択したりするだけです。最初は最も安いBronzeプラン(月額25ドル)を選択しておけば大丈夫です。

手順2. Teamを作成する

Organizationを作る最大のメリットの1つがこの「Teamを作れるようになる」というものです。 ではTeamとは何かというと、以下の箇条書きをご覧いただければ存在意義がわかるかと思います。

  1. Teamは個人のGitHubアカウントの集合である
  2. TeamはOrganizationに属する
  3. Team単位で読み込み権限/書き込み権限/管理者権限を設定できる

つまり上述の「権限の管理が楽になる」というメリットを実現するための機能がTeamということですね。

Teamの作成は https://github.com/ の画面左上から自分のアカウント名をクリックし、Manage organizationsをクリックします。

f:id:phero:20150510151931p:plain:h240

(あるいは直接 https://github.com/<先ほど作成したOrganization名> にブラウザからアクセスしてもOKです。)

続けて画面右側の Create new team のボタンをクリックします。

f:id:phero:20150525104457p:plain:h240

続けて表示される画面でチーム名チームの説明(任意)アクセス権限を適宜入力し、Create team ボタンをクリックします。

手順3. Teamに関係者を追加する

今ブラウザでは https://github.com/orgs/<Organization名>/teams/<Team名> のページが表示されているかと思いますが、画面右上のAdd a personから「招待したい人のGitHubアカウント名」を入力(下図参照)すればその人がTeamに属するようになり、指定された権限でアクセスできるようになります。

f:id:phero:20150525104920p:plain:h240

ここで気を付けなければならないのは、「決して入力間違いを起こさないこと」です。もしタイプミスなどで他のアカウント名を入力してしまうと、どこぞの誰かもわからない謎の人がソースコードを読むことが出来てしまうという状態になりますので、極めて危険です。

手順4. リポジトリを作る

https://github.com/ にアクセスし、Organizationのページに進みます。

f:id:phero:20150527145000p:plain:h240

続けて画面右側のRepositoriesの項目から、+ New repository のボタンをクリックします。

f:id:phero:20150527145501p:plain:h120

手順5. リポジトリにTeamを加える

上記手順4で作成したリポジトリのページ( https://github.com/<Organization名>/<リポジトリ名> )にアクセスし、画面右側のSettingsをクリックします。

f:id:phero:20150527150320p:plain:h240

画面左側のメニューのCollaboratorsをクリックします。

f:id:phero:20150527150619p:plain:h240

Select teamから、先ほど作ったTeam名を選択します。

f:id:phero:20150527150729p:plain:h240

これで指定したTeamから指定したリポジトリにアクセスできるようになりました。

以上でOrganizationを作る場合の設定は完了となります。


Organizationを作らない場合の方法

もしOrganizationを作らない場合は、個人アカウントでプライベートリポジトリを作成し、そのリポジトリにおいて特定のGitHubユーザーに対して権限を付与するという形で複数名で開発できるようになります。

手順1. リポジトリを作る

https://github.com/ から、画面右側の+ New repository(緑色のボタン)をクリックし、新たなリポジトリを作成します。

手順2. リポジトリにアクセスできる人を増やす

画面右側のメニューからSettingsをクリックします。

f:id:phero:20150527151355p:plain:h240

画面左側のメニューからCollaboratorsをクリックします。

f:id:phero:20150527151511p:plain:h160

Search by username or full nameにGitHubアカウントを入力し、右側のAdd collaboratorボタンをクリックします。

これで指定されたアカウントからリポジトリに対して読み書きができるようになりました。


割りと長めになってしまいましたが、上記が「1人でGitHubを使わずにでもGitを利用して開発してたけど、開発者が自分だけではなくなったのでこれを機にGitHubを使ってみよう」という方の参考になれば幸いです。

GitHubに詳しくなりたい方は手始めに以下のような本をお読みになると良いかもしれません。(プルリクのことを"プルリ"と呼ぶのは初めて耳にしましたが)

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール