puke and bounce

アプリを作るのが好き。アジャイル開発でみんな幸せになればいい。最近は複合現実による価値創造に興味

結局、お金がほしい?

何がしたいか?

仕事で人間関係でちょっとした悩みがあり
「相手はなんでこんな要求をするのだろうか?」
「なぜ私はこんなにつらいのだろうか?」
と思考してみました。
一通り整理がついたのでpukeします。

問答

ディレクターとのある会話。
私はあるプロジェクトのエンジニア代表的なポジションにいました。
最初のリリースで私はMVPでリリースする想定いましたが
ディレクターは最初の構想通りのリリース想定という思い違いがあったのです。
私はMVPでリリースしてユーザーの反応を見てから次の開発判断をしたからった。 MVPでリリースするという構想が全く伝わっていなかったのが最大の問題でした。
本当ごめんなさい。とだけ心の中で唱えておきます。
でも
「○○さんは、なんでそんな細かくリリースしたいんですか?」
と言われて若干ムッとしてしまった。
この機能をリリースして本当に効果があるのかわからない。
しかも多くの改修を加えたところで、それを直してテストをするのはエンジニアなのだ。
予定が遅れれば残業するリスクを抱えているのは我々なのだ。
余裕を持って工数を伝えることはできる。
でもそれで負い目を感じるのは我々なのだ。(見積もりは本当にきらいだ)

ともろもろ思ったところで何もおこならないので私は週末のスケジュールを確認して納期とスケジュールを飲み込んだ

結局、お金

私はサービスをより多くの人により便利に使ってもらうために
エンジニアをやっていると思っています。
一番うれしいのは初めて会った人が私の作ったサービスを使っていたとわかったときです、、、、、、、、、、

というのはきれいごとでした。 サービスを使ってもらって嬉しいのではなくて
サービスを作ってもらうことによって自分にお金が入るのが嬉しいのです。
社会的な評価があがる気がするのがうれしいのです。 社会的な評価があがることによって、次の転職先で給料があがることが嬉しいのです。
結局はすべて金儲けです。
ディレクターも自分が担当したプロジェクトがある程度の納期で
宣言したとおりの機能が作れていれば評価があがって給料が上がるから
先程の問答になったのでしょう。
結局、お金なのです。
結局、仕事はお金のためです。

それでも私は

より人々を幸せにしたいと思います。
私がお金を得てしたいことはまず家族を幸せにしたい。
更に余裕があれば友達を幸せにしたい。隣に住んでる人を幸せにしたい。
そして世界中の人を幸せにしたいと思います。
そのための手段はお金だけではもちろんなく 時間、すなわち命をかけて人を幸せにしたいです。

ソースコードレビューの際に気をつけること(備忘録)

コードレビューどうやるんだっけ?

プログラミングのレベルは大して上がっていないんですが
業務上ではプログラミングをするよりコードレビューをする場面が多くなってしまいました。
それにあたって、自分なりに判断基準をもってソースコードレビューを行うために本記事にまとめる。

ポイント

  • プロダクトのバグを減らすのと保守性向上のために行う
  • 開発者、レビュアーともにプロダクトの仕様理解につながる
  • チェックリストを用いて漏れなく迷いなくレビューを行う

ソースコードレビューはなぜやるか?

レビューに関わるのは開発者とレビュアーになります。
レビュー後にプロダクトはどうなるかと登場人物の行動を考えてみる。

開発者

  • レビュー指摘を持ってソースコードを修正する
  • 仕様の知識が増える
  • コードの知識が増える
  • 効率の良い処理の記述方法を知る

レビュアー

  • プロダクトの仕様がわかる

プロダクトはどうなる?

  • ロジックのミスが少なくなりバグが減る
  • ソースコードの可読性が高まり追加開発の際に効率がよくなる

レビューで辛いこと

現時点でレビューでの辛みを考えてみた。
今回の記事はレビュアーとして視点だけれども
両者からの観点でつらみを考えてみる。

開発者観点

  • PRの説明を書くのがめんどくさい
  • レビューをもらうのが怖い

レビュアー観点

  • 開発者の意図がわからない
  • そもそも仕様理解も必要
  • 辛いレビューをするのが大変
  • そもそも自分がそんなに知識がない → わたし

ソースコードレビューでのチェックリスト

これは開発者とレビュアーが両方使えるチェックリストになる。
PRとDIFF(ソースコードの差分)ごとに用意した。
これを漏れなくチェックすればソースコードレビュー漏れはないかもしれない。
少なくともレビュー時にチェックリストを思い出す脳内メモリが節約できる。
チェックリストが埋まらない部分があればすぐ聞くことである。

PR

  1. 説明文で仕様がわかるようになっている
  2. PRのタイトルと説明文が一致している
  3. UI変更がある場合にスクリーンショットもしくは動画が記されている
  4. 設計思想がわかるようになっている

DIFF

  1. 変数名に誤植がない(名詞、動詞のスペルミスはないか)
  2. コメントに誤植はない
  3. インデントに誤りがない
  4. プロダクト全体の設計パターンから大幅にずれていない
  5. 既存のライブラリの再開発を行っていない
  6. 冗長な処理を記述していない
  7. 共通のオブジェクトを用いている場合、オブジェクトの中身が保証されている
  8. 処理の順番が実現したいことに大して等しい

参考資料

コードレビューの際に気をつけること - Qiita

昔いた会社にスクラムの考え方を徐々に浸透させてみる

RGST2019のAdventCalender Day24!

adventar.org

昨日はtakakigさんでした!

日々アウトプットを意識していますがなぜって部分は深く考えたことがなかった。。
私もアウトプットの理由を自分自身に問いかけながら本投稿を進めていきます。

takaking22.com

昔いた会社にスクラムの考え方を徐々に浸透させてみる

伝えたいこと

  • あらゆる業態、業界であってもスクラムの知識は役に立つ
  • RGST2019ではたくさんの人と話したいよー

金融業界での失敗

個人的な体験談です。
今でこそ、ゆるふわなWeb企業でゆったりサービスを作っていました。
1個前は6ヶ月間ほど金融系企業のシステム部門にいました。

そこでは1人に1システムを担当し業務内容はプログラミングや設計書作成は一切なく
発注している会社にシステムの不具合や要望をエスカレーションするだけでした。

仮に障害が起こっても電話をすることしかできず何もできない。
同じ会社の人間も他人の担当のシステムは全く無関心。
当時は上司が部長でしたが、システムのことは知らない天下り部長でした。

結果として体調を崩して退職しますが、当時の自分はすべてを組織のせいにして何も改善をしようとしていませんでした。

問題点を振り返る

あまり思い出したくない過去ですが頑張って振り返って
当時の組織の問題を重要度順で2つ考えました。

  • サービス間で責任分離されており当事者意識がない
  • 組織改善のサイクルが回せていないため成長が遅い

スクラムでの解決策

最初からスクラムを導入というのは難しく、
なまらスクラムフレームワークに当てはめてもよくないことが多いので
スクラムの考え方を部分的に少しずつ浸透させていくとよいと思いました。

サービス間で責任分離されており当事者意識がない

スクラムの必須となる当事者意識の醸成が必要。
ビジョンの共有を行いましょう。
現状のサービスレベル、チームレベルでの問題点を洗い出し
ビジョンとの差異について目線合わせができればよかった。。。

 

www.lifehacker.jp

組織改善のサイクルが回せていないため成長が遅い

定期的なレトロスペクティブを行える状況を作る。  
業務の評価を週次で行い、障害は事前に防ぐ。
障害が起きるたびの振り返りであモチベーション的にも辛いし
実際に障害の対策の話しかできないので効果が少なそう。

振り返りについては様々なプラクティスがあるので
障害などが起こったタイミングで提起すれば良さそう。

個人的にはエモーショナルグラフがおすすめです。

nulab-inc.com

今後の活動

業務ではスクラムに拘らずにサービスとチームをよくするために動く。
社会的にはアジャイル開発の考え方を浸透させてより
楽しく仕事をするためのヒントを提供していきたい。  

[宣伝]LeSS Huge!

1日目に東名阪を跨いだLeSSのお話をさせていただきます。
LeSS Hugeはもちろんリモートワークでのチーム開発に興味のある方や
大人数チームでの開発事案としてレアな話ができると思いますので、ぜひ起こしください!
そして飲み会には進んで参加しますので、みなさま仲良くしてください!!!

confengine.com

 

Cycle inside TownMap; building could produce unreliable results....

経緯

本日のコンパイル事件簿。 carthageで使っていたSDKをpodに乗せ換えた。

error: Cycle inside TownMap; building could produce unreliable results. This usually can be resolved by moving the shell script phase 'h' so that it runs before the build phase that depends on its outputs

とりあえず注意も読まずにClean Build Folderしてpod updateして再実行。

...

したら通った。 意味はあとで調べるとしてよかった。

スクラムマスターになれたから今の自分がいる〜抜擢編

5分で読める投稿です。

ポイント

  • マネジメント経験を活かして入社3ヶ月目でスクラムマスターに抜擢
  • スクラムとはプロダクト開発を最高に楽しむ方法の一手段

経歴

私はスクラムマスターの経験から「結構人生楽しいんじゃないか?」と考えられるようになってきました。

下請けシステムインテグレーター 21歳
↓
金融の社内SE 25歳
↓
充電期間
↓
Web企業 27歳

私は大学を3年で中退しています。
単位は問題なく取っていましたが部活や遊びすぎでお金がなくなって就職という道を選びました。
就職のタイミングではプログラマーになろうとは考えていませんでした。
給料が大学卒並に貰えてホワイトカラーならどこでもいいと思っていたので 、出版社や家庭用品の営業なども受けていました。
その流れで最初に受かったのが下請けシステムインテグレーターでした。
当時は業界の情報も全く知らなかったので1回目の面接で内定がでたので 「この企業は私にこんな期待してくれてる」と本気で喜んでしまい入社を決意しました。
1社目の会社ではそこそこの成果を収めて3年目に周りが金融系企業のの社内SEに転職します。大学卒以上しか取らないような企業だったので私はこのとき「やっと周りに追いつけた。まともな会社に入れた」と思いました。 このときの仕事は1文字もプログラムを書くことはなく ひたすら営業や業務部門からの要望を下請けのシステム会社に引き継ぐというもので、いわゆる責任だけを取らされるポジションでした。その結果、激務と慣れない調整業務に全く慣れず6ヶ月後に体調を崩し突如退職します。
そこから3ヶ月ほどの休養期間を経て今の会社に転職しました。

スクラムマスターに抜擢された理由

今の企業は良い意味で風通しがよく社員個々のレベルがものすごく高いです。
ただBtoC企業で締切などに対する意識があまり高くなく、ゆるい組織でした。 入社当社は大きな衝撃を受けて、あらゆる人にそのゆるさを訴えてきました。 そして朝会などでのファシリテートも積極的に取りに行って組織のゆるさの改善に自らの力で取り組んでいきました。
年も若く、突出した技術力のない私がいくら行動しても影響力はないと思っていましたが、そういう背景もあってかLeSS-Hugeを導入するにあたってスクラムマスターに抜擢されました。
旧組織での経験を現職と融合させるのが中途入社者の強みです。私は喜んで前職で身につけた仕事に対する責任感を今の組織に活かしていく方法としてスクラムマスターの役職を受諾しました。

スクラムとはプロダクト開発を最高に楽しむ方法の一手段

スクラムマスターになるにしてもスクラムのことは初心者だったのでめっちゃ勉強しました。
Scrum Boot Camp に始まりファシリテート入門など必要そうな本は読み漁りました。
セレモニーなど形式的な部分は一通り覚えましたが
私はスクラムとはプロダクト開発を最高に楽しむ方法の一手段と考えました。
常に振り返りを行ってプロダクトとチームを成長させていこう
ROIを高めながらみんなで幸せになろう。
そのお手伝いを推進していくのがスクラムマスターの仕事と考えました。 例えば、リファインメントではストーリーに対する不安をチーム全員で吐き出して見積もりを進めます。
このリファインメントを行えば不明確な箇所がなくなり、みんなが腹落ちしている状態になります。
「わからないけど、どうせ自分は作らないからいいや」
という感じにはなりません。
レトロスペクティブではチームの全員がチーム運営の課題解決の答えを探します。
組織改善がリーダーに一任されることなくチーム全員の課題となります。
課題は解決させるよりも、自分で解決するほうが絶対効果的です。

私は楽しいチームを作りながら強いプロダクトを作りたいと思いました。
そこで意識したのは下記の2点

  • スキルマップの平準化し業務の属人化を減少させる
  • エリアの課題をチームに積極的に持ち出して全体の課題解決の意識の醸成

ただ志高く望んだものの最初の半年は正直失敗でした。 (次回につづく)

Advent Calendarに記事を掲載する前にブログを充実させおかなくては恥ずかしい。

登壇が決まりました!

Regional Scrum Gathering Tokyo 2019にてスクラムについてのお話をすることになりました。
(同僚の方々が申し込んでくれたおかげです)
実はLT以外で登壇するのは初めてで、、すでに緊張しています。

24日にAdvent Calendarに登録してしまった!

Regional Scrum Gathering Tokyo Advent Calendar 2018

軽いノリで12/24を選んでしまったんですが
(みんなクリスマスイブは忙しいし人気ないだろうなと思いました)
その時点で私はAdvent Calendarはカンファレンスの前日までやってるものだと思ったんです。
でも実際はクリスマスまでのカウントダウンの位置付けだったのですね、、、
イブはめっちゃ重要じゃん!!!と数日前に知りました。

でもブログの内容がうすい

正直、くだらない記事を載せすぎて公にするのが恥ずかしいくらいだから
Advent Calendar専用のブログでもつくるかーと思ったくらですが
これを良い機会だと思って1人Advent Calendarを開始しようと思います。
単純計算で自分の番が回ってくるまでには23記事かけているはず!

続けるためには

とりあえず知っていることをアウトプットして書くことなくなったらポエムでも加工。
毎日書くことに意味があるのさ!!

渋谷デザインスクランブル2018で交差してきました!!

渋谷デザインスクランブル2018とは??

渋谷デザインスクランブル2018
渋谷を会場としたデザイナー、クリエイターのイベントです。
さっき知ったんですあ今年初開催でした。

感想

渋谷のあちこちに会場があるのでフェス感があって面白かったです。
実際に街を歩いて移動するのが意外と新鮮だったりします。
また学生のデザイナーさんと話す機会は良い経験となりました。
来年もぜひ開催してもらってなんとか出展側で参加できればいいなと思いました。

自分の居場所は自分でつくる。これからの渋谷、場のデザイン

クリエイティブシーンの先端の方々のお話が聞きました。
せっかくだから一通りの場所には今週中に見に行ってみようと思います。
(コワーキングスペースは仕事として堂々と行けるからありがたいです。)

cohsa
代々木上原のBathhouseさん←12/2オープン!
伊勢丹さんのTOKYO解放区

paletteさん

似顔絵ありがとうございました!
本当に嬉しかったです。
palleteも定期的にチェックさせていただきます! f:id:takono0807:20181125120952p:plain

BCG Digital Venturesさん

コンサルティングファームのBCGDVさん。
企業も素敵ですがブースの展示がシンプルでかっこよくて参考になりました。 どんなテクノロジーも社会実装してくれそうな想像が掻き立てられました。
f:id:takono0807:20181125125145j:plain