@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

201802 振り返り

retrospect

デブサミでエンジニアとしての話を聞いてきたから自分のことを真剣に考えようと思った。
お金欲しいからどうにかお金が稼げるようにならなくては。英語やって給料上げるか技術力あげて転職して給料あげるか。
転職の話もやったことのある人からいろいろ聞いてみたいなと思った。

べんきょうかい

Developers Summit 2018とCookpad TechConf 2018に参加してきた。他社の話を聞けるのは面白い。
色々落ち着いてきたから３月はもう少し勉強会に参加していきたい。

ほん

珈琲を家で飲むようにと道具を買ったので簡単な入門書を何冊か読んでみた。
今は粉を買ってきていれてるけど豆買ってきて自分で粉をひく方がどうやら美味しいみたいだから徐々に買い揃えていこうと思う。

えいが

今月もほぼ週１で映画見れた。こんなに毎週毎週新しい映画が始まるなんて良いことだ。
今年は単館ものとか探して観に行ってみようと思っている。

ぶろぐ

デブサミに関する感想を２本書いてた。
技術的な話よりもエンジニアとしての矜持の話をたくさん聞いてきた。
デブサミはセッションを聞くのも楽しいけど個人スポンサー特権でスピーカー控室でスピーカーと話せるのがすごく楽しくてありがたいと思う。
カイゼンジャーニーはチームとしての活動を始めようとしている人や困っている人に勧めてみようと思う。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「カイゼン・ジャーニー」を読んだ

impression

勉強会でよく発表しているのをお見かけする２人が本を書いたと知ったので買ってみた。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで [ 市谷 聡啓 ]

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで [ 市谷 聡啓 ]

開発の現場をカイゼンしていくための手法、心構えが小説仕立ての３部構成で書いてある。

１部 : 一人から始める
２部 : チームで強くなる
３部 : みんなを巻き込む

本書の主人公は、社会人３年目でコードは書けるけどチーム開発はうまく出来たことがない転職を考えている若者。
この若者が１人での活動からチームでの開発へ越境し、会社内部のチームメンバーからプロダクトに関わる人達を巻き込んでの開発へと越境していく姿が書かれている。

自分の立場で考える

自分はもうすぐ８年目を終えそうな立場だが、この主人公みたいに１人でやらなければいけないタイミングは全くなかった。６人くらいまでのチームで開発をしてきただけ。ただし、同じ時期に１つのチームだけではなく複数のチームに所属していたことはあった。その時には１部にあるように１人でタスクを毎朝確認し、振り返りもしていた。 その後チーム開発を６年ほどやっているがチームメンバーとのやり取りで困った経験はないなと思う。

勉強会に行ってすごい人に会ってやる気が出るのはすごい共感した。勉強会に行って自分の知らない環境や知識を学ぶのはすごく大事なことだと思う。(僕は勉強会に行って著者のお二人の話を聞くたびに刺激を受けてます

チームでの開発

本書ではチームでの開発手法をリーダーがスクラムでやると決め、外部からスクラムマスターを雇いチーム開発をすすめていくことになっていた。

色々起きる問題をチームみんなで解決していくための手法や心構えを

実際に起きるであろう問題→解決へ向かうための方法→解決策の説明

の順番で書いてある。

自分が悩んだ時に見直せばそこに解決策が書いてあるはずだ。
自分はスクラムを学んだことがないのでやるべきことや困った時の解決手法が学べてとても役に立った。

読んでいて思ったのは、チームとして活動するなら開発を始める前にいろいろやっておく方が良いのではと思う。意思疎通がうまく取れない人とチームを組んでもなにもうまくできるとは思えない。逆に意思疎通ができるチームだったらどんな開発手法でもうまくいくのではないかと思う。

実際には、本書でチームが揉めた時に行っていることをチーム結成時に済ませ、チームとして活動できるようになってから全てを始めるのが良いのではと思う。
※自分は急に大半以上チームメンバーが変わる経験をしていないので勝手を言ってます。

チーム外も巻き込む

複数チームでの開発の仕方、スコープの決め方や変更の仕方が分かりやすく書かれていた。

  • 本当にこの変更は必要なのか？
  • なんでこの変更は必要なのか？
  • 視座を変えて問題を捉え直す

これらは、本書の中ではプロダクトの変更が外部から来た際に行っていたがチームメンバーで定期的に行うべきものだと思った。

今の自分は、チームで必要だと思ったのを作り続けているが、

本当に使われるものを作っているのか?
本当に使いたいと思われているものから作り始めているか?
今のプロダクトは動いているが変更をする必要がある箇所はないのか?

こういったことを今のメンバーと見直す会を頻繁に定期的に行っていこうと思った。

まとめ

本書ではスクラム開発を行うための手法、またスクラムでなくてもチーム開発をする時の心構えが小説仕立てで書いてあるので、技術書を読むのに疲れて読みきれない人でも読みやすいものだと思った。
チーム開発をやっている、これからやろうとして困っている人たちにオススメしていきたいと思った。

ただ、これから初めてみようという人に対しては書いてあるものが沢山あるので、必要になった際に必要となったものをやってみるのをオススメしてみたいなと思う。

追記

僕はこちらの資料を参考に新しいチームを作ろうと絶賛勉強中なので相談をさせてもらえる方や、僕と同じようにこれから始めようとしている人と話をしてみたい！

#devsumiに参加してきた

impression conference

目黒の雅叙園で１年に１回行われるDevelopers Summitに参加してきた。

毎年技術的なトピックを聞きに行っているが、今年はエンジニアとしての生き方について語っているセッションを中心に聞いてきた。 あと、初めて登壇者として(発表者として名前は出ていませんが...)参加してきました。

人生20年説・好きな事と得意な事を仕事にしていけるかも知れないエンジニア人生のヒント（中井 悦司 [Google Cloud Japan]）

Googleの中井さんの発表。
中井さんが大学院を卒業してから現在の職に就くまでの人生を教えてもらった。
予備校講師時代の練習でプレゼン技術を身に着け、その後アプリケーション開発、仮想化、クラウドなどと自分の興味 + 半歩先にはやりそうなものをやり続けていたよう。

その中で中井さんが大事にしていたのは以下のこと。

  • 複数の得意分野を持つ
  • 面白そうと思えるトピックを見つける
  • 原理原則を学ぶ

原理原則を学んでいるから次のものを学ぶ際にあまり苦労がなさそうだった。
まずは自分の強みを考えてそこを伸ばすことをしないとなと思った。

夢は正夢〜「野球エンジニア」になるまでの歩み（中川 伸一 [ネクストベース]）

今年夢を正夢にした中川さんの発表。
エンジニアとしてどうなるという強い意志を持って実際になるまでの道筋を聞いてきた。

自分の得意な分野を使って〇〇エンジニアとしていくために

  • エンジニア的圧倒的強みを持つ
  • 最低限のビジネス力(特にプレゼン)
  • 他人事より自分の事を大事に
  • 銭闘力を身につける

以上のことを忘れないようにする必要があるみたい。
今のところ3番目以外はできていないので少しづつ自分に自信を持ってできることを増やしていくしかないと思った。
お金に妥協しないってところがすごく胸に痛い...

一生、エンジニアで食っていこう（漆原 茂 [ウルシステムズ]）

ウルシステムズ代表取締役兼現役エンジニアの漆原さんの発表。
何歳になっても現役エンジニアとして生きていくための方法、心構えを熱く語っていたセッション。
自分ももうすぐ36歳になるのですでに世の中で言われるプログラマは35歳説の年を過ぎてしまった。
でも、今の仕事好きだしまだ続けていきたいしと思っているのでものすごく楽しく聞いてきた。

  • 楽しんで没頭する
  • インプットの幅を広げる
    • 世代
    • 国境
  • 【個】で仕事ができるように
    • 自分のことを知ってもらう

これらができるようにまとめとして「一生エンジニア」宣言（β）も用意されていた。

「一生エンジニア」宣言（β） 〜呪縛を解き放て！〜

プラスエネルギーを解放せよ！
繋がろう！国を超え世代を超えて
外に発信せよ！自分が誰か教えよう
依存症から脱却せよ！個を信じろ！

忘れないようにちょいちょい見直したいのと、エンジニアみんなでのメンテナンスができると面白そうだなと思ったので、どこかへアップされることを期待している。

実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 -（及部 敬雄 [楽天]/佐藤 竜也 [楽天]/宮﨑 剛太 [アイデンティティー]）

毎日会社で話をしているモブチームに参加させてもらった。
画面もソースもほぼ初見でやりたいことを30分で実現できるかというタイムアタックっぽい発表をさせてもらった。

普段自分で触っているプロダクトならばよく知っているので修正箇所も修正内容も分かっているので、なんとなく試してみてうまくいったら詳しく書くみたいなことをしているが今回は全くわからないのでこの手法が使えなかった。
その場合僕にできたのはプロダクトのことを知っている人に聞くということだけだった。それでも、見て頂いてた方にはわかると思うが当初の予定のものが出来上がっていたと思う。

最低限の技能があって、コミュニケーションさえとれればよくわからないものだろうとチームで取り組めば解決できるのだろうと思った。
自分でも体験できてみたから今後興味がある人がいたら是非教えてあげたいなと思った。

結局大事なのは一緒に働く人ってことなのかなと...

まとめ

自分から見ると天上人のような3人の話を聞いて共通していたなと思ったのは、

  • 自信の持てるワザを持つ
  • 楽しんで学ぶ

なのかなと思った。
自分に自信のあるものがあれば積極的に仕事も取りにいけるし、他の人からの信頼で仕事も回ってくる。
楽しんでないと継続できないし、やる気も身につく物も全然変わってしまうと思う。

ひとまず、自分の強みを探して深めながらそれと関連付けて幅を広げていきたいなと思った(体のことではない)。
あとは、お金は妥協しちゃいけないとのことなのでお金欲しいって言い続けてみよう。いいお誘いとかいただけるように頑張ろうと。

お金欲しい。

201801 振り返り

retrospect

本を読んでいて部屋をキレイにしていたらあっという間に一月終わってた。
あ、よくよく考えたらイベントのお手伝いしていたや。
あれくらいの規模のイベントに関われることは少なそうなのでとても良い経験をさせていただきました。
関係者の皆さまありがとうございました＆今後も宜しくお願い致します。

べんきょうかい

今月は1個も出なかった。

ほん

勉強会に行かなかった代わりと言っては何だけど本を今月は沢山読んだ。
まあ、半分以上マンガだけど。

えいが

キングスマン面白かったなー。
新参者の最後も良かった。

そのた

hihihiroro.hatenablog.com RSGT2018にスタッフとして参加してきた。 スタッフの人たちがうまく手を抜きながら上手に回していた気がする。良い経験をさせてもらった。 しかしみんな朝まで飲んでたのにあんなによく働けるもんだ。

ぶろぐ

今月は面白い本をたくさん読んだのだろう。感想をいっぱい書いてた。
感想を書いてて思うのは自分の文章力が低いなとおもう。言葉だったり表現だったりが全然でない。
ただの思いつきのメモだから良いのかもだけどと自分を納得させてる。
きれいな文章書けるように心がけていきたい。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

いまさらながら「ウェブオペレーション」を読んだ

impression

今年は色々勉強をしようと思って積読になっている本を消化している。 ウェブオペレーションはすでに１年位以上放置してしまっていた。

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

ウェブオペレーション サイト運用管理の実践テクニック （Theory　in　practice） [ ジョン・アレスポー ]

ウェブオペレーション サイト運用管理の実践テクニック （Theory　in　practice） [ ジョン・アレスポー ]

ウェブオペレーションという単語は株式会社はてなのエンジニアの名前ではよく聞いているけど具体的にどういう人なのかは分かってなかった。ざっくりオペレーション側のことなのかなと思っていたけど、役者まえがきによると「ITシステム管理の専門分野で、ウェブアプリケーションの開発・運営・保守・調整・修理を含む」らしい。開発も入るのか。

内容は複数の寄稿者によるウェブサイトの運用にまつわるトピックを扱ったエッセイ集になっている。目次を見てもらえれば分かるけれども内容は寄稿者によって違うので本当に幅広い。面白く読んだのは4、7、13、17章。

φ(..)メモ

継続的デプロイ

小さなサイズでの設計・実装・デプロイが大事だと書かれている。わかってはいるけど出来ていない。 少し他のエンジニアとも話をしてみたところ何回も同じバッチをリリースするのが面倒くさい、テストを回すのに時間がかかると嫌がっていた。どちらも自動化しておいて、ボタン１つ押せばテスト、リリース、切り戻しができるようにしておけば良いのだろう。まだまだやることは多いな。

いかにして複雑なシステムは失敗するか

リチャード・クック博士の論文について書いてある。失敗する理由がきれいにまとまっていると思った。短いので何回も読んで自分の中でまとめておきたい。

障害を活用する：ふりかえりの技芸と科学

部署の中でふりかえりをよくやっているのを見るが改善までうまくいってるのを見てない。全員参加していない、その場で振り返ったら終わっていることが多い気がした。以下のことをやってないからなんだろうなと思った。

改善は完了するまで追跡しなければならない。

ふりかえって終わってしまっているので定期的な観測をしていくようにする。

夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）

そうだよね。ちゃんと眠りたいよね。

誰も信じない

新卒で配属されて最初の１年間先輩にずっと言われていた。できる人だからってミスしないわけでもないし、なによりも自分が間違うはずがないと思って信じ切らないようにと言われた。今でもこれは守っている。

技術的にも面白い

6章の監視、12章のリレーショナルデータベース、14章のストレージ、15章のNoSQLについては運用者はもちろん開発者も知っておくべき知識であることは間違いない。

まとめ

ウェブサービスに関わっている人には読むのをオススメしていきたい本だった。2011年の本ではあるが今も必要な知識であることは問題ないと思う。DevOpsやSREに必要な考え方がまとまっていると思う。新卒が一歩すすむために読むのにもちょうど良さそうなのでチームの若い子に読ませてみようと。

今見るとAmazonでも楽天ブックスでも新刊が売ってない。もしや絶版...？

#RSGT2018 に参加してきた

impression conference scrum

01/11-13に大崎で行われたRegional Scrum Gathering Tokyo 2018にボランティアとして参加してきた。 ボランティアとして働いてみてここがすごかったなと思ったことを今後のイベントのためにもφ(..)メモメモ。

イベント規模

2セッション、約350名参加。
スタッフは20名。

ここがすごいよRSGTスタッフ

料理と飲物が豪華

ネットワーキングパーティ、お昼のお弁当、おやつ、珈琲屋さんが美味しいものが準備されていた。
僕はお弁当を毎日お昼の時間にTwitterとFacebookでシェアをする仕事を勝手にしていた。弁当を取る時に迷わないように前もって写真をシェアしたのは良かったのではと勝手に思っている。美味しいものを食べながらだと皆楽しく話ができてるように見えたので美味しいものは正義。

話しやすいスペース

机と椅子が所々にあったり、単焦点プロジェクタが用意されていたりと参加者の人達がいつでも好きなタイミングで話ができるように準備されているのが良いと思った。
誰かが話していると気になった人がさらに集まってきてどんどん参加者の輪が大きくなっていた。
好き勝手に話したい人と内容を喋れるスペースがあるため色々な意見交換ができていたら良いなと思う。

良いチームメンバ

実際にボランティアとして働いたのは前日から土曜日までの4日間だけ。なのに、皆とうまく話ができた気がするし、イベントもうまく回っていた気がする。これが、実際の現場だとしたらちゃんと機能できたチームとして褒めてもらえると思う。
イベントに責任をもっている人がいてチームをまとめる人がいて、チームのためにみんなが勝手に動いていた。自分の現場でも同じことをやればうまくチームが回るのかな。

臨機応変な対応

僕はイベントでやらなければいけないことを実はあまり知っていなかった。
さらにその場で急にできたものも多かったと思う。それもうまく機能していた。

  • １日目最後のセッションの時間延長
  • Job Board
  • ワークショップ申し込みボード
  • OSTの時間割の貼り出し

スタッフが必要と思ったことをその場で行っただけなのにうまく回っていてすごいと思った。

気の良い参加者

お手伝いをすすんでやってくれる方がいっぱいいた。
机や椅子を運んでくれたり、帰りのハイタッチに並んでくれたり、オープンスペースでみんなを巻き込んで話をしてくれてたり。 コーチクリニックの先生役を沢山の人がやってくれていたのを見た。参加者の人にたくさん助けてもらったなと勝手に思っています。

まとめ

内容や場所もそうだけど、スタッフと参加者が一体になって良いイベントにしようと思って参加しているのがイベントをうまく回すコツなのではないのかと思った。なによりもスタッフが一番楽しんでいたと思う。自分たちが楽しくないものは参加者も楽しくないだろうから自分たちが楽しめるようにするのは大事だなと思った。
お手伝いいただいた参加者の皆様、ボランティアとして参加して一緒に働いてくださったみなさま大変ありがとうございました。
とても良い経験をさせていただきました。

あー、たのしかった。

「エンジニアのためのデザイン思考入門」を読んだ

impression

デザイン思考という言葉を聞くけどなにかよく分からなかったので学んでみようと思ったけど、ただデザイン思考って言葉を勉強するだけだと読み終われなそうだったのでエンジニアのための本が出るとのことだったのでエンジニアのためのデザイン思考入門を読んでみた。

エンジニアのためのデザイン思考入門【電子書籍】[ 角征典 ]

エンジニアのためのデザイン思考入門【電子書籍】[ 角征典 ]

エンジニア思考とは、

ユーザへの「共感」から「問題定義」を行い、アイデアの「発想」「プロトタイプ」「テスト」といった５つのステップを繰り返すことで、問題の本質をインサイトとしてとらえ、そのインサイトにもとづいたソリューションをデザインすること、そのプロセス、その考え方。(P.14)

デザイン思考となにかということが細々と書いているわけではなく、東京工業大学のエンジニアリングデザインプロジェクト(EDP)という講義の説明がされていたり、実際に講義を受けた人たちのコラムとかが面白く読めた。講義は東京工業大学、東京藝術大学、武蔵野美術大学の学生さんと社会人の受講者やボランティアを交えて多様性のあるチームを作っているみたい。

読んでみて取り入れてみたいなと思ったのは、 * どんなに雑でも良いのでプロタイプを作ってみる。プロトタイプにも種類があるので必要なものをつくる。 * CEP : Critical Experience Prototype * CFP : Critical Function Prototype * DHP : Dark Horse Prototype * FKP : FunKtional Prototype * FCP : FunCtional Prototype * XFP : X-is-Finished Prototype * VFP : Validated Final Prototype * ユーザに対してインタビューを繰り返す

現状は自分たちで勝手に必要そうな機能やインターフェースを決めてしまっているので実際に使っているユーザともう少し話をしてから作っても良いのかなと思った。

まとめ

サービスをユーザに提供するものについては、インタビューをしてプロトタイプを作って試してみてもらうを繰り返すのは大事だと思う。この本では、課題の絞り込み方、多様性のあるチームを組無事の重要性、アイデアを形にするためのプロセスなどが学べた。「T型人材」になりたいな。今度はもう少し真面目にデザイン思考について勉強しようと思ったので次はデザイン思考が世界を変えるを読んでみようと思った。

さーて、あいまいさとダンスしようと。

デザイン思考が世界を変える イノベーションを導く新しい考え方 （ハヤカワ文庫NF　ハヤカワ・ノンフィクション文庫） [ ティム・ブラウン ]

デザイン思考が世界を変える イノベーションを導く新しい考え方 （ハヤカワ文庫NF　ハヤカワ・ノンフィクション文庫） [ ティム・ブラウン ]