【サポーターズ勉強会】イベント・勉強会主催をはじめよう にいってきた

【サポーターズ勉強会】イベント・勉強会主催をはじめようにいってきたので、その時のメモです。資料は公開されているので、興味のある方はリンクからご参照ください。

自分用メモ

ぶっちゃけほとんど資料に書いてあるので、それ以外で載っていない、自分がした質問とその答えを書いておきます。

Q「勉強会を最初にやるうえで、(心理的、物理的に)一番壁だと感じたものは?」
A「心理的には数が集まるかどうかがかなり不安だった。なので最初は5人だけに絞り、とりあえず埋まるようにした。物理的には場所、会場探しが難しかった。知り合いの企業にお願いするのが一番強いが、まあ難しいのでSNSで聞いてみる、勉強会に行って会場のスタッフさんに聞いてみる、あるいは(今回の会場の)サポーターズなどにお願いするなどがいいかも」

Q「実際やってみて、(壁は)どうだったか」
A「意外に需要あるなーという感じ。そこから徐々に人数を増やしたりしていった」

ちなみに、慣れてきても会場探しは結構大変らしいです。同じ場所で開催できるのは結構奇跡に近いとかなんとか。ちなみにサポーターズは勉強会を開く側にも積極的なようなので、初めてやるときはサポーターズさんに相談するのも良いかもですね。ていうか、恐らく自分はそうします。

ストレングスファインダーとか、ABD(アクティブブックダイアローグ)とか、やりたい勉強会はいっぱいあるんですよね。場所もいくつか提供頂ける当てはできたので、3月か4月ごろ開催に向けて準備するかなーという感じです。

転職ドラフトの良い点、悪い点

転職ドラフトで紹介が成立したというメールが来たので、改めて転職ドラフト使ってみて感じた良い点、悪い点をまとめてみました。

ちなみに、自分の紹介コードは「KKOZ」です。紹介した側もされた側もオライリー本が貰えるので、ぜひ!

良い点

年収が分かる

年収が前職(現職)の年収に引きずられない。普通の転職だと現在の年収をベースにして交渉するのが普通だが、ドラフトの場合は能力に対して年収が決まる。

振り返りの機会になる

普通の履歴書、職務経歴書よりも書くことが多く、深いので、書く中で色々発見があったりする。自分の場合、自分がやりたいことは言語化するとプロダクトマネージャだということに書いていて気づいた。

フィードバックが貰える

指名の際にフィードバックを貰えるので、自分のどこに価値があるのかが分かる。現職では評価されなくても、外部では重宝されるスキルを発掘することができる。

知らない世界を知ることができる

自分で探す場合は自分の視野の中でしか見れないが、指名の場合は意外な業界から指名が来たりして、それにより視野を広げることができる。今のところドラフトを使ってる企業は感度の高い企業が多いので、外れな企業は少ない気がする。

他にも応用が効く

ドラフトで書いた内容をビズリーチの履歴書、職務経歴書作成にコピペすると普通に使えるものになる。

 

悪い点

指名されないこともある

指名が来ないと凹む。まあ、1件も来ない場合は実力云々以前に書き方の問題な気がする。気になる方は添削とかするので、連絡頂ければ。

面接自体は普通のもの

ある程度以上大きい企業だと、面接者と指名者が違う、かつドラフトで書いた内容を読んでないので再度説明しないといけないことが多い。ぶっちゃけ普通の面接と同じ。

倍率は意外と高い

募集枠1名に対して指名を50とか60とか出すので、別に指名されたからって内定が貰えるとは限らない。っていうか、普通の面接と(ry

調整がしんどい

エージェントが間に入らないので、日程の調整などを全て自分でやらないといけない。自分の場合、6社から指名を貰って全部に話を聞きに行ったので、日程調整で死んだ。

事前情報が入らない

エージェントがいると事前に面接や技術試験の内容を教えてくれて準備できるが、ドラフトだと事前情報がないので結構きつい。なんだかんだ、エージェントが間に居た方が他の情報(残業とか、雰囲気とか、色々)も入ってくるので良いかも。

技術試験が受けられない

ドラフトのルールで、指名後にテストとかができないので、HackersRankを使ったプログラミングのテストなどができず、技術力の有無を証明しにくい。技術力不足で落とされたりしたが、そもそも技術的な話やテストがなかったりとか。尚のことポートフォリオが重要になる(特にSIer→Webの場合)。

今後人数が増えた時にどうなるか

人数が増えてきたので、機械的にふるい分けされる傾向が出てきつつある、という話を指名貰った企業から聞いた。実際、200人、1000人と参加者が増えてきたときに上手く機能するのかなーという話。

 

感想

運営が結構頑張ってるなーという印象です。色々書きすぎて文字数溢れてエラーになったりしたけど、すぐに対応してくれましたし。今のところはお薦めのサービスなのかなという感じです。実際に転職を考えている人にはちょいちょいお薦めしたりしています。ただ、これから人数が増えてくると色々課題も出てくると思うので、今後はそれ次第かなーという気もしますが。

現行の給与が低すぎる人って結構多いと思うんですが、その給与をベースに次の給与が決まるから中々上がりづらいんですよね。その問題を解消するという意味で、転職ドラフトには期待していますし、今後も頑張って欲しいと思っています。

システム開発:見積り工程についてまとめてみた

設計工程について、自分なりにまとめてみました。

オフショアでベトナムに設計書を出したりしていたので、日本人相手だけでなくベトナム人相手も想定した内容になっています。

言葉の定義

基本設計、外部設計、機能仕様

ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める(joel on software)。

要は画面なり機能なりの振る舞いを定めている。ユーザ視点。どう作るか、ではなくてどう動くか。

詳細設計、内部設計、技術仕様

プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている(joel on software)。

要は、データ構造なり処理の流れなり、プログラムの構造について定めている。
プログラマ視点。どう動くか、ではなくてどう作るか。

具体的に何を記載するか

joel on softwareをベースに、自分とメンバがやりやすいように手を入れた。

機能仕様

A. Background(背景)
何が問題なのか
何でこの修正が必要なのか

B. Purpose(目的)
この修正の目的は何か
この修正によって解決される問題は何か
どういう状態になれば完了なのか

C. Scope(範囲)
今回、何をやるのか

D. Out of scope(範囲外)
今回、何をやらないのか
(次フェーズでやる可能性があるのであれば書く
設計や実装に影響するので)

E. AsIs(現状)
現状の説明(画面のキャプチャー付きで問題を説明する)

F. ToBe(ゴール)
どういう状態になれば完了なのかを絵付きで説明する
期待される振る舞いについて説明する
(バリデーション、ダイアログ、メッセージ、エラーなどもここに記載)

技術仕様

A. Process flow(処理フロー)
処理の流れを図で説明する
入力、処理、出力をきちんと書く

B. Data definition, relate DB(DB周り)
テーブル定義に変更が入るのであれば、その説明
後は新機能であれば、DFDを書いて説明
挿入、更新、削除の処理があるのであれば、その条件や項目など
参照の場合も複雑になる場合は書く
(IDから1項目引っ張ってくるだけーとかであれば不要)

C. Validation(バリデーション)
必要なバリデーションについて説明

D. Error case(エラー)
エラーは二種類ある
システムエラーとプロセスエラー(ビジネスロジック起因)
主に、プロセスエラーについて書く
機能仕様のエラーと対応

E. 他に何か必要があれば、適宜

実際のところ

意外かもしれないが、ベトナムから一番要望が強くて、追加したときに効果も大きかったのが目的と背景。なぜこの機能が必要なのか、この機能がどう使われるのか。ここら辺をしっかりと書いておくと、逆に他が多少甘くても向こうから色々提案してくれる(こういう目的ならこういう実装の方がいいんじゃないかーとか)。

ちなみに、簡単な機能追加であれば機能仕様だけ投げればいける。複雑な機能の場合は技術仕様が必要(ベトナムの特徴として、全体を見るのが苦手というのがある。複雑な機能の場合、技術仕様がないと動くには動くが保守性が最悪なものが出来てきたりする。もちろん、別途コードレビューなどはおこなった方がいい)。

新規開発の場合、平行して運用設計が必要になる(ログどうするか、障害が起きたときどうするかなど)。別途書く、結構これを忘れる人が多い気がする(特に開発オンリーで保守運用の経験がない人)。

今後試してみたいこと、気になっていること

ペルソナをつくり、目的の部分などでその人が実際にどういう問題に直面し、どう困るかを設計書に盛り込みたい。わかりやすさの向上&ユーモア。ユーモア重要。

海外では実際どのくらいの粒度の設計書が普通なのか、気になる。国や業種などにも寄るだろうけど、例えばある程度大手がインドに出す場合とか。ちなみに、joel on software でサンプルとして挙げられている仕様書はこれ

 

 

 

システム開発:見積り工程についてまとめてみた

見積もりについて、自分なりにまとめてみました。

TL;DR

1.特に初期の見積もりは誤差が大きいので、各フェーズで見積もりなおす必要がある(不確実性コーン)
2.見積もり時にリスクを洗い出し、見積もりに組み込む必要がある
3.誰が見積もるかも重要で、実際の作業者に見積もらせるのがいい
4.どうやってもブレるものはブレるので、MosCow分析などを使って優先度をつけることが重要

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~という本が良いらしい(まだ読んでないので、後で読む)


自分の場合の話

自分は概算を出すときは「感覚的にこれくらいだろう×2+α」で出していて、大体ちょうどいいか収まる感じ。ざっくり要件聞いて、10日で終わりそうだと思ったら23日とかで出す(あるいは何もなければ最短で10日、現実的には20日程度~とか)。

多分、感覚的=楽観的で、Nな地点で、そこにリスクを乗せてちょうどいい感じになっている。

※人によって違うので、あくまで一例
※N、この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ

見積りの誤差

概算見積もりだと400%程度の誤差がありうる。基本設計まで落とし込んで、25%程度(1人月の見積もりであれば、0.75~1.25人月くらいまでは普通にブレる)。なので、概算見積もりのまま突き進むと、1人月の見積もりでも0.25~4人月までぶれるので、普通に死ぬ。

大体の案件は、これが原因で死んでいる気がする。最初の提案=400%の誤差がありうる状態で予算と日程を決めてしまい、それが確定なものとして扱われてしまう。……まあ、死ぬよね、っていう話。

見積りの誤差については、不確実性コーンの話が面白い。
プロジェクトの本質とは何か? プロジェクトマネジメントの基本1

後工程に行くにつれて誤差が減っていくのは、情報が増えるから?
⇒リスクが見えてきて、ある程度潰せるようになっているから。

リスクとバッファ

・熊とワルツを
見積もりを出す前に、リスクの洗い出しが必要。リスクの軽減策などを考えておく、必要であれば見積もりに入れる。納期は後ろに倒れるが、その分リスクが実現した際のダメージが小さくてすむ。

リスク図といって、プロジェクトの成功確率がどう推移するかをあらわした図がある。誰のための見積もり・何のための見積もり part2の15pを参照。

N:成功率がほぼ0の地点を見積もりとして出しがちだが、実際は顧客にはもっと後ろの方を提示して、内側にはもう少し前を出すべき。
「顧客への見積もり>スケジュール>N」

誰が見積もるか

・ピープルウェア
見積りの精度は、誰が見積もるかにもよる。一番生産性が高いのは、見積もらない(納期を決めない)。

目標設定者 生産性
プログラマー 8.0
マネージャー 6.6
プログラマーとマネージャー 7.8
システムアナリスト 9.5
目標なし 12

誤った目標の設定、すなわち絶望的に厳しい目標はプログラマーのやる気を吸い取ってしまう。実際に作業する人に見積もらせることが大事。

実際に作業を振るときに、敢えて納期を伝えずにやってみたことがあったが、確かに期待していたよりも早く終わり、暇だから次の作業くれーという催促まで来たことがあった。目標なしが一番いいのだろうが、上に説明しづらいのが難点……。

実際にやるときに心がけていること

大抵の案件は納期が決まっているので、MosCoW分析で「Must、Should、Could、Won’t」を洗い出してスコープを決める。当たり前だけど、顧客と一緒に決める必要がある(一見大事そうに見えても、顧客から見たらCouldだったりということが往々にしてある)。

んで、詳細が終わったくらいで改めて見積もりなおしてMust全ていけそうか、ShouldやCouldはどこまでやるか、を決める。Mustだけは死んでも収めるくらいの心意気で、その代わりMustは本当に必要最低限にする。

まあ、この辺は受諾だと調整が難しい気もする。自社サービスであれば調整しやすいけども。受諾でアジャイルが適用しづらいのも結局は契約の問題だし。

ともあれ、最初に一回見積もって終わりではなく、各工程で見積りを更新するーというのが大事。

疑問

QCDはトレードオフといわれているが、本当にそうなのか(品質を犠牲にすることで、納期は本当に早くなるのか?)。ピープルウェアによると、品質を下げると士気が下がるので効率が落ちる。つまり、品質と納期はトレードオフの関係にない?実際に試してみたい……。

オフショア開発:ベトナムとのコミュニケーションで気を付けたこと

オフショアを3年ちょいやってきて、自分なりにベトナムとのコミュニケーション方法というものが見えてきたので、共有します。

東京、沖縄、ベトナムの3拠点で一つのチーム。東京1人、沖縄1人、ベトナム8人程度。やり取りは全て英語で、基本はLyncを使ってのチャット、通話、画面共有となります。

大前提

同じ人間はこの世に存在しない
人が二人以上いれば、そこには必ず「差」がある。その「差」を埋めていくことが重要(基本的に日本とベトナムだから、とかではなく、日本人同士でも同じだと考えている)。

ベトナムと日本の差

ベトナム 日本
雇用形態 ジョブ型 メンバーシップ型
仕事の意識 仕事優先 家族、プライベート優先
品質の意識 低い 高い
言語 ベトナム語 日本語
経験値 低い 高い
お客様との距離 遠い 近い

※あくまで自分の印象、かつ全体的な印象。例えば若手と家庭持ちで残業に対する態度が変わったり、経験値の高いベトナムメンバーが居たりと、個別の事情に合わせてコミュニケーションは変える必要があるとは思っている。

どうやって差を埋めるか

雇用形態

ジョブ型なので、開発者とテスターはもちろん、開発者もフロントエンドとバックエンドでもさらに分かれる(さらに言えば言語でも)。そもそもバックエンド開発者にフロントエンドをやらせるのも筋違いなので、できれば分けるようにする(強い部分に集中させる)。

自分の場合は状況的に日本側がパンクしそうだったので、状況をきちんと説明した上で、VN側と話し合ってテストも引き受けて貰うようにした。その場合は、どういう理由で、どこまでを期待しているか、を明確に伝えて、納得して貰う必要がある(責任の範囲を明確にする)。

仕事の意識

基本はVN側の意識を尊重した(家族の用事やプライベートを優先してOK)。その上で、極力仕事の優先度を上げて貰う工夫をした。そもそも仕事が楽しい、あるいはやりがいを感じれば勝手に優先度上げてやってくれる。

・仕様説明の際に、目的や背景を明確に伝える(なぜ作るのか、どう使われるのか、それを作ることでお客様はどう嬉しいのか、など)

・(サービスだったので)KPIの達成度やユーザーからの声を定期的に共有する

・お客様の喜びの声を聞かせる(隣にいたので、VNとカメラで繋いだ状態でデモをおこない、歓声を届けた)

・細かくフィードバックする(良かった点、改善した方が良い点)
逆に、マイクロマネジメントは絶対に避けるように意識していた

品質の意識

そもそもの生まれ育った環境の差によるものが大きいので、一朝一夕で埋めるのは無理。VN側に90%までやって貰って、最後の仕上げは日本側でおこなう、など(あるいは許されるのであれば多少のバグには目をつぶるとか・・・ここは必要とされる品質による)。

出来ることがあるとすれば、コードレビュー。最低限、不経済なコード(n+1問題、再発明など)を弾くだけでも結構違う。後、コードレビューをおこなうことで日本側でも中身を把握できるので、休日等にトラブルが起きても最悪対応できる。

言語

日本語、ベトナム語、共にハイコンテキストな言語。ならば言わなくても通じるか、というとそれはない。

省略を実現するためには共通の背景知識が必要となるが、そこがお互いに異なるのでハイコンテキストなやり取りは不可能。ローコンテキストなコミュニケーションが必須となる(全て細かく書き出す、省略せずに明文化する。幸い、英語はローコンテキストな言語)。

英語力はそこそこあればいい(無論、高いに越したことはない)。最低限文法は正しくすることを意識する(単数、複数、過去、未来、主語を省略しないなど)。

後は言い方がダイレクトすぎないように気をつける(you made a bug, ではなく、we have a problem…など)。ざっくり言うと、「てめーのせいでバグってんだよ、ふざけんな、さっさと直せ」と「私たちはこういう問題を抱えているので、解決に力を貸してくれませんか」くらいの印象の差がある。

そもそもバグだと開発者を責めている感じになるが、実際は仕様の伝達ミスかも知れないので、バグという言葉を安易に使うこと自体が危険。特に開発初期はお互いのことを知らないので、そこでミスると最悪の印象を最後まで引きずることになる(まあ、普通にお互いを尊重しあって開発しましょう、という話)。

経験値

VNは全体的に若いので、経験の浅い人が多い。視野が狭くなりがちなので、日本側が広い視野でチェックする必要がある(コードレビュー、設計のレビューなど)。

VN側にリーダーを立てるときも、メンバーとリーダーでは求められる役割が異なるのでサポートが必要。ちなみに、VN側にリーダーを立てるのは主義に反するという意見もあるが、個人的には立てた方がいいと感じている。現地にいないと見えないことが多い(日本側のリーダーがVNに行って指揮を取るのであれば別。詰まってる、悩んでる、タスクがその人に合っていないなど)。

お客様との距離

これは東京と沖縄も同じかもしれないが、距離が遠いので温度感などが伝わりにくい。既に上で書いたが、ビデオチャットで共有する、各種KPIなどを共有するなどして、他人事から自分事に意識を変えていく必要がある。何のためにこの作業をやっているのかがわからないと、どうしても他人事になりがち(言われたとおりにやっただけ、みたいな)。自主的に動いて欲しいのであれば、当たり前だが目的や背景などを説明する必要がある。

最後に

当たり前ですが、開発者も人であり、感情があるということを忘れずに、という話。後は根本的にマネジメントスタイルが適切じゃない場合があると思うので、そもそも日本人に対しても不適切なマネジメントをしていないか、を考えた方が良い。

マネジメントというと指揮統制法を思い浮かべる人が多いが、曰く「言い換えると、軍隊が指揮統制を使うのは、それが18歳の若者に地雷原の中を突撃させるための唯一の方法だからであって、あらゆる状況で最善のマネジメント法だからではない。」。エンジニアに対して指揮統制法を適用しても、エンジニアが外へ流出するだけの結果になる

じゃあどうしたらいいか、は以下のリンクを参照(あるいはTeemGeek、ピープルウェア、デッドラインなどを読んで貰えれば)。

マネジメント法3種(イントロダクション)