書評:精神科ナースになったわけ

いわゆるエッセイコミックです。会社の本棚にあったので軽く開いてみたら、思いのほか面白かったので借りて読んでみました。

周りから見ておかしい行動だったり理解できなかったりでも、本人にとっては意味のある行動なんだとか、そもそも正常と異常の境目ってどこだろうとか、軽く読めるわりに色々考えさせられる一冊です。

中でも印象的だったのが、
・基本は「生きたい」のほう
(生きたいから 生きづらいと 死にたく なるんだよ [幻聴妄想かるた」)
・だいたい血行
(今日の先生の診察を見てて、身体が具合悪くなると心も具合悪くなるんだと思いました。→だいたい血行。という会話)
の2つでした。

そう、基本はやっぱり生きたいんだよなーっていう。こち亀でも両さんが人生相談乗るときに、まずは生きる方の選択肢に絞る、という話をしてたのを思い出しました。

後は血行の話。最近肩こりから頭痛や吐き気がしており、血行を意識していたからというのもあるかもですが。ただまあ、やっぱり血行悪いと頭痛など身体の具合が悪くなりますし、そうすると精神的にもしんどくなってくるので合ってる気がしますね。なので自分は最近、ストレッチや生姜湯を飲むなどの対策を始めました。ちなみに血行良くなるとダイエットにも効果あるらしいです。

精神科というとなんとなく近寄りがたいイメージがあるかもしれませんが、最近は昔よりも身近になってきている気もします。理解を深めるきっかけとしても、この本を読んでみるといいかもしれません。

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

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

自分用メモ

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

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