途中からプロジェクトに参画した人へ最初に共有しておくと良さそうな3種類の情報
プロジェクトに参画するパターンとしては
1. プロジェクトの立ち上げ当初から参画する
2. 途中から参画する
の2つの場合がありますが、どちらのパターンで参画するかによって、プロジェクトに関する情報のキャッチアップのしやすさは異なるなぁと思います。
最初の1~2年は1のパターンで入る事が多かったのですが、最近は出向のような形で他のプロジェクトに入ることもあったり、別の会社で副業する機会があったりと2のパターンでプロジェクトに参画することが続いていて、立場が変わると
「こういう情報って最初に知っておけるととても楽なんだけどなぁ」
「こういう情報がまとまっているおかげでとても助かったなぁ」
と気づけたことがいくつかあったので、3種類に分けてまとめてみようと思います。
（1のパターンで気づいたことも書いています）
1. サービス自体に関すること
- サービスの概要・目的
- ユーザーロール
- リリーススケジュール
サービスの概要・目的
細かい仕様については追々共有してもらうとして、つくろうとしているサービスがどんなものなのか、そのサービスの解決したい目的は何なのかがわかると、とっかかりとしてとてもやりやすい様に思います。
背景やユーザー像が見えると開発をすすめるモチベーションにつながったりもしますし。
ユーザーロール
前提条件なのに自分にとっては当たり前になりすぎて説明することを忘れてしまい、話を進めていく中で「そんなユーザーがいるの？」と混乱を招いてしまった経験があります。
存在するユーザーロール、それぞれのユーザーの権限の範囲を先に説明しておくと、ソースコードだけでなく資料を探す作業が捗ったり、MTGで話がわからなくなったりすることもないのでとても大事だなぁと思います。
リリーススケジュール
これに関してはほぼ確実に共有される事が多いですが、個人的には「結局いつリリースするんだっけ？」と忘れてしまいそうになることがあるので、テキストや表でまとめておいてもらえると助かるなぁと思います。
2. 開発環境に関すること
言語・フレームワーク（バージョン含む）
自分が普段から開発しているものだとうっかり説明しそびれそうですが、忘れず軽く説明しておくと親切かなと思います。
設計の全体像
どこに何が書いてあるのかを調べる作業は結構たいへんだなぁ...と思うので、知っている人がざっくり説明してくれるととても助かります。（ディレクトリ構成だけでも）
なお、フレームワークもチームによってその利用方法はまちまち（一部しか使っていなかったり、それぞれの役割の使い分けが異なっていたり）だったり、馴染みがない人にはとっつきにくかったりもするので同様です。
とはいえ、説明する側も毎回話すのは結構たいへんなので、ドキュメント化したものを読んでもらって、わからないところとかを聞いてもらうのがいいかも。
ドキュメントやWikiのありか
上記のような情報は開発の助けになるので、一覧化されているページがあるととても見やすいです。
また、分類や階層に分けて管理されていると新参者にも情報が探しやすく、とても嬉しいです。
ツール
- タスク管理ツール
- 仕様書作成ツール
- デザイン確認ツール
などはプロジェクトやチームによって使っているものが異なっていることも多く、しかも似ているものがあったりしてややこしいので、それぞれの違いを教えてもらえると良かったりします。
仮想環境の有無
仮想環境があるのか、ある場合はどういうものが用意されているのか（Vagrant、Docker）など。
仮想環境のセットアップに四苦八苦してなかなかスムーズに進められない...ということもあるので、セットアップ方法や分かる範囲でのトラブルシューティングをまとめておいてもらえるととても助かります。
テスト環境/ビルドコマンド/デバッグ方法
これらも開発には必要な情報なので必ず。
こちらもドキュメントとしてまとめてもらえていると嬉しいです。
バージョン管理・運用ルール
- Gitのホスティングサービスは何をつかっているのか
- PRの運用ルールはあるのか
なども教えてもらえると嬉しいです。
gitコマンドが使えればだいたいどのホスティングサービスを使っていても問題ないようには思いますが、自分が使ったことのあるもの以外は名前すら知らなかったりするので。
また、PRのコメントの書き方やレビューの方針、マージャーなどについても教えてもらえると嬉しいです。
ちなみにPRの運用についてはルールがドキュメント化されていると出す側もわかりやすいし、マージャーになった際にもPRのフォーマットが定まっているとレビューしやすくていいなぁと個人的には思います。
3. 体制に関すること
- 連絡手段・稼働時間
- 開発手法・構成
連絡手段・稼働時間
チームによってSlackやchatworkなど使うツールもバラバラですが、使い方も微妙に違ったりします。なので、例えばSlackだとチャンネルごとの使い分けや、緊急時の連絡先については教えてもらいたいなぁと思います。
また、同じプロジェクトでもメンバーによっては違う時間に稼働していることもあるので、稼働時間も事前に把握できているとありがたいことが多いです。
（返信が来なくても「明日には返信してもらえるだろうな」といった予測を立てることができたりする）
開発手法・構成
ウォーターフォールとスクラムではメンバーの動き方も異なりますし、明確な開発手法をとっていなくても誰が何を握っているか、誰に何を聞けばいいのかといったことがわかるほうが圧倒的に仕事は進めやすいと思います。
入ってから感じ取っていく...という場合もありますが、可能であれば最初にどんなメンバーがいて、それぞれの役割でどんな体制かなどについて説明してもらえると嬉しいなと思います。
最後に
プロジェクトに途中から参画する経験を通して、今までは気づくことのできなかった「情報をちゃんと伝えてあげないと、途中から入ってきた人が苦労することもあるんだよ」ということに気づくことができたので、とても良い勉強になったなぁと思います。
今後はここにまとめた情報を伝え忘れないようにして、途中から入った人が早く開発作業に集中できるようにしていきたいと思います。
ウェブのギモンのワークショップ「Re:見積もりどうやってる？」に参加した話
もう一ヶ月も前になりますが、「見積もりをやってみる」という面白そうなワークショップが開催されたので参加してきました。
ワークショップを主催している「ウェブノギモン」では、 ウェブ制作で発生する「ギモン」を持ち寄り情報共有するワークショップ型の勉強会が多く、勉強になるし面白いのでたまに参加してます。
内容
街にある小さなパン屋さんからの「自分のお店のホームページがないので作って欲しい！」という依頼に対してチームごとに見積もりを行ってみよう、というもの。
最低限の前提条件のようなものは設定されているものの、それ以外については各々のチームで仮定条件を決めてもいいとのことでした。
所属したチームの構成メンバー
- 「普段から見積もりをやっている」方が 1名（ディレクター）
- 「やったことがない訳ではないけれど、あまり経験はない」方が 2名（エンジニア/デザイナー）
- 「ほぼやったことがない」（私）が 1名（エンジニア）
という構成でした。 職種も違うし、経験値も違うしで、見積もりだけでなく色んな話ができて楽しかったです。
見積もりの方法
チームによって見積もりの方法は異なるようでしたが、私のチームでは大きく分けて4段階に作業を分けて見積もりをやってみました。
1. 仮定条件を決める
4人で1つの見積もりを出す上で、仮定条件がバラバラだと話がまとまらないのでいくつかあげることにしました。
一ヶ月前なのでほとんど内容は忘れちゃったんですが、、、
「長期的な案件として扱う可能性はほぼない、一回作りきりという設定にしよう」
という条件なんかがあった気がする。
2. どんなものを作るのかを決める
仮定条件を決めたら技術選定とページ構成について検討しました。
とはいえ、今回は小さなお店のウェブサイトという題材だったので候補としては以下の2つのみ。
WordPress とは迷ったものの、想定したサイトに必要なページが
- トップページ
- 商品ページ
- お問い合わせページ
（他にもあったかもしれない）
と、少ないものだったこと、拡張性は必要としていないことから WordPress は使わずに一から作ることにしました。
また、この段階で手書きの WF のようなものを書いたりして、チーム内で作ろうとしているものの認識を合わせたりもしました。
「SNSを活用したいパン屋さん、ということだけど instagram をイチから使いこなすのはハードルが高そうだから、すでに使っている Facebook を埋め込む＆ Facebook で使える便利機能を教えることにしようか」とか。
3. 総額のことを考えず、各項目ごとで金額を見積もってみる
「どんなサイトを、どうやってつくるか」が固まったところで、ひとまずは感覚的に項目ごとの金額を算出してみることにしました。
覚えている項目としては以下のようなもの。
- デザイン費用
- コーディング費用
- 保守費用（レンタルサーバー代ぐらい）
- 進行・管理費
- レクチャー代
チーム内の各メンバーで「自分で実装するなら工数はどのぐらいかな〜」というのを出し合ってみたりしました。
4. 総額を考慮して微調整し、最終的な金額を決定する
3 の段階では割と自由に金額を出していったのですが、「なんとなく」で決めた金額だと説得力がないので、改めてクライアントのことを考えて見積書を仕上げることにしました。
このときに私のチームが考慮したポイントは以下のようなものでした。
2つめに関しては見積書の見映え上の問題もあるけど、あまり綿密に工数を記載してしまうと「実装工数にバッファーがなさすぎてしんどい...」みたいなことになりかねないのでは？という話から調整することにしました。
最終金額
見積もり明細書の写メを撮り忘れてしまったので細かい金額は覚えていませんが、合計ではだいたい50万円ぐらいになる結果となりました。
他のチームの見積もり方法
ページ単位で見積もっていたり、WordPress で作っていたり、見積もり項目自体もバラバラで全てのチームが異なる明細にはなっていたものの、
大体のチームが 50〜70万円 ぐらいの金額としていました。
（ちなみに、実際に見積もりを出すときには「松・竹・梅」を用意しておくのがよいらしい）
感想・まとめ
参加する前は「自分に見積もりなんかできるのだろうか...」と思っていたんですが、とっつきやすい題材で＆チームで考えたので楽しく、実践的に見積もりをしてみることができました。
実際の見積もり時にはもう少し色んな項目について検討したり、金額設定ももうすこし綿密に考えてみたりしないといけないとは思うけど、私のように経験値の低い人にとってはとても価値あるワークショップでした！
エンジニアとして働くことになったきっかけ
この仕事について3年目になりました。
最近行き詰まってる感じがあるので、ちょっとここらで「初心を思い出してみよう」的な感じに今までのことを振り返ってみようと思います。
「時代はプログラミング」「まじで？」
もともとは化学系の大学院生でした。
なんとなく「先生っていいよなぁ」と思ったのと、「一つのことを続けるのってかっこいいなぁ」という理由でそのまま研究を続けて大学の先生になりたいな〜とか思ってました。
だけど、大学の先生なんてそんな甘い考えの人がなれるはずもなく。
「自分はきっと向いている」「ほら、これだけ頑張っているじゃない（と思っていた）」と自分に言い聞かせつつ、ついに自分の研究への"純粋な熱意"の欠落に気づいてしまった私は卒業半年前に休学することにしました。
で、すぐに就活するのかと思いきや「なんか悩みすぎて頭おかしくなってる感じするな...」と思い、「ひとまずバイトで食い繋ぐか」とまさかのフリーター生活に。
当時働いていたイタリアンでのアルバイトだけでは生活できなかったので、とりあえず比較的高時給な日本酒を金閣寺で売るバイト（英語も使えるから楽しいかなと）を確保して、「なんかもう一つスキルが身につく系のことやりたいな〜」とネットで色々検索することに。
そしたら出てきた「時代はプログラミング」という言葉。
まぁもっと文章の前後関係はしっかりあったはずなんだけど、「まじか。プログラミングできへんぞ。じゃあ30年後とかこのままじゃ生き残られへんくなるん？」と焦りを感じて、たまたま見つけた Wantedly で縁あって今働いている会社にアルバイトとして行くことになりました。
半年ぐらい足を突っ込んでみて「楽しそうだなぁ」と思った
アルバイトとは言ってもプログラミングなんて趣味でもやったことはなく、本当に知識ゼロの状態から始まりました。
ネットの学習サイトでフロント周りの基本（HTML、CSS、JS）を勉強しつつ、社長にわからないところを聞くという感じを3~4ヶ月ぐらい。
その間に関西フロントエンドユーザーグループの年忘れLT大会に行って「みんな勉強熱心だし、楽しそうにやってるのがいいなぁ」と思ったり、フロントエンドカンファレンスをお手伝いしてみて「いっぱい人がきてて、ここでもみんな結構楽しそうやなぁ」と思ったり。
なんかよくわからないけど、ITコミュニティってのはみんな楽しそうかつ自主的に勉強しているんだなぁという印象がありました。
で、そろそろフリーター生活も疲れてきたし、「この世界でなら私も楽しくやっていけるかも」と思ったので就職させてもらうことに。大学院も辞めました。
次は実際に働きはじめてからのことについて書こうと思います。
自己紹介と今日のPHPカンファレンス関西2018で実行委員長をやった感想
はじめまして。
大阪のWeb制作会社で働いているショウノシオリといいます。
←このアイコンが目印
会社では Laravel とか Vue.js とかを使うことが多いです。
一応ブログ的なものとして Medium を何記事か書いていたんですが、どうしても Markdown じゃないと書く気になれないのではてなブログをはじめることにしました。
ついさっきまでPHPカンファレンス関西2018で実行委員長をやってました
4時間ほど前まで、PHPカンファレンス関西2018（以下、ぺちこん）の実行委員長（以下、委員長）として運営に携わっていました。
懇親会後も、みなさん二次会にいったりとかなり盛り上がったようで twitter から楽しげな様子が伝わってきました。
なんで今書くの
帰ってから速攻ブログを書いているんですけど、正直へろへろ。
だけど、委員長としてイベントに携わった直後の感想とかって絶対今じゃないと忘れてしまうし、「明日やろう」とかいっても絶対書かない。
しかも懇親会で「ブログ書いてね」ってみんなに言っちゃった。
という手前もあるので、このほやほやな思いを書き留める次第です。
実行委員長を2回やった感想
「いいんちょう！」ってめっちゃ呼ばれる
まぁ実行委員長なのであたりまえなんですけど（笑）
別に「わたしにはショウノシオリっていうちゃんとした名前があるの！ぷんっ」という訳ではなくて、どっちかっていうと「気軽に話しかけてもらえるのは嬉しいなぁ」という感じです。
運営スタッフとして参加するだけでも周りから話しかけてもらうことは増えるような気がしているんですが、委員長だとなお増える。
知らない人に話しかけるのって少し勇気のいることだと私は思っているので、わざわざそんなアクションをとってくれることが嬉しいです。
2回やると、1回目の反省を活かせる
去年はちょっといっぱいいっぱいなところがあって、あっというまにカンファレンスが終わってしまったことに後悔が残っていました。
なので、今年はできるだけ楽しむ＆記憶に残せるよう、当日までの事前準備に力を入れたつもり（まぁそれでも抜けはたくさんあったんですけど）。
そのおかげか、今回は「しんどい」というよりも「あー疲れた！！」というやりきった感で今は超爽快、超いい気分です。
楽しかったし面白かったしいい感じで疲れてよく眠れそうだし、ほんと最高。
twitter の使い方を知った
去年委員長をするまでは twitter の使い方も知らず、界隈で有名な人のアイコンも名前も全然知らなかった。
でも今はハッシュタグをつけて呟くことだってできます。未だに # の前のスペースを忘れてハッシュタグとしての認識がされてないときもあるけど。
まぁ相変わらずSNSは疎いし、これからも比較的この業界の人間にしては疎い人間であり続けるだろうとは思います。
でも、イベントの拡散手段や他のエンジニアの人との交流手段が増えたこと、またその交流手段が重要であることを実感できたのは確実にわたしにとってプラスとなりました。
（ちなみに Facebook は今もスマホにアプリはインストールせず、毎回ブラウザからログインスタイル）
ちゃんとしたメールが書けるようになった
「お世話になっております。」
「今後とも引き続きよろしくお願いいたします。」
「お忙しいところ恐れ入りますが、ご確認ご連絡のほどお願いいたします。」
何回書いたんだろうか、この言葉たち。
だけど、もう今はわりとスラスラッと書けちゃうし、なんならたまに書くぐらいならちょっと楽しいぐらい。
実行委員長としてスピーカー様・スポンサー様にたくさんのメールを送る機会を得たおかげで、だいぶビジネスメールについても学ぶことができました。
本当に去年なんかは全然慣れていなくて大変だったのだけど、2年目になると「この場合は...この締めだーーー！！」みたいに適切な言葉パターンもいくつか頭に入ってきたり、「こういう場合はどういうフレーズが適切なんだろう？」と自然と興味が湧いてきたり。
まぁ普段の連絡は基本 Slack なので、そこまで堅苦しい感じにする必要もないことが多いのだけど、いざという時にサクッと文面をつくれるようになったのは私的に大きなメリット。
とはいえまだまだ未熟なので、ヘンな文章を書いていたら遠慮なしに教えてもらえると喜びます。
大勢の前で話すのって実はたのしい
今年も大体300人超えぐらいの規模感だったんですけど、まぁそんな大勢の人の前で話すことってない。
去年は緊張するのといっぱいいっぱいになったのとであんまり覚えてないんですけど、今回は緊張しつつも話すの楽しかった。
ピアノの発表会に出るときの「緊張するし間違ったらどうしようと思いつつもそのドキドキがたまらん」みたいな感じに近かった。
準備さえ自分なりにできていたら緊張しても割と話すのはたのしいことがわかったので、やっぱり人前で話すときはそれなりにちゃんとやろうと思った。
自分たちで好きにつくれるってスバラシイ
今年はガラポン抽選会とかもやってみました。
ミーティングであるスタッフが出した「福引とかアナログな感じのことをやってみたいな」という案に「ガラガラ回したい！」とみんなが食いついた結果、実現されました。
しかもあのガラガラ、レンタルじゃなくて買ったんですよ。使う機会ってあるんだろうか...。
ガラポンを回すために集めるトランプカードの仕様が少しややこしかったり、nu-boardがダンボール20箱で届いたりとなかなか手間のかかる企画ではありましたが、かなり楽しんでもらえたようなのでみんなで頑張った甲斐がありました。
スタッフミーティングで挙がったアイデアがちゃんと形になり、しかも実際に参加者の人が楽しんでくれた。こんなに素敵なことってない。
KPTに向けて
わたし的にはいいカンファレンスだったなぁ〜と正直思ってはいますが、「やって終わり」ではなくふりかえりも重要です。
少し落ち着いたら今年度もカンファレンスについてのKPTを行うつもりでいますので、みなさんもぜひご意見・ご感想をブログや twitter にてお知らせいただけると嬉しいです。
ハッシュタグは #phpkansai で！
最後に今日の様子を
参加者の方には余韻を味わってもらうために。
来れなかった方、興味のある方には雰囲気を感じてもらうために。
では、寝ます。
