エンジニアがエンジニアであるために

はじめに

久々に思い立ってブログを書くことにしました。
僕が思う「エンジニアがエンジニアであるために」について、まとめようと思ったからです。
ここで言うエンジニアは俗に言うWeb業界がメインです。(僕がそうなので)
本とかブログとかを交え紹介をしていこうと思います。
基本的に3つの軸で書いていきます

  • 考え方を身に付け
  • 良いとは何かを知る
  • 自分の知識を更新していくこと

この3つが必要だと、僕は思います。個人的見解なので、ほかにももっとこういう考え方あるよ、とかもあると思いますので、参考までに読んでいただけるとうれしいです。

考え方を身に付け

考え方を意識すること

まず、エンジニアであるということは、柔軟な思考と戦略的な思考が必要だと思います。そもそも今目の前にある課題をクリアするために、コードを書くだけが解決の方法ではありません。オープンソースを利用して対応する方法もあります。DBも多種多様です。柔軟に考えプロダクトを前進させていかなければいけません。

最初にお勧めしたいのが、このストラテジックマインドです。
企業経営のための本と書いてありますが、本質は戦略的な思考の本です。エンジニアは常に考えなければいけません、課題をどう解決するか、将来どのようにプロダクトを成長させるのか。その中で、いろいろな自分の固定概念やあるべき論に縛られることがあります。その時にどう考えればいいかを紐解く一冊になると思います。
books.rakuten.co.jp

次にお勧めしたいのがエッセンシャル思考です。
これは有名な本ですね。まず、エンジニアは時間がないことを知らなければいけないと思います。自分が勉強できる・成長できる時間。仕事中の時間をなにに使い、何に貢献するのか。なにも考えないとすぐに1年終わってしまいます。エンジニアには時間がないのです。そのため、「しないことはしない」、「やるべきこと」、「やりたいこと」をするためにどういう考えを持つ必要があるか。正直これができてないエンジニアは、成長が鈍化するだけでなく、ストレスをためてしまうかと思います。
簡単に読める割には、多くの発見がある本です。
books.rakuten.co.jp

エンジニアには文化があることを知ること

エンジニアリングをしていると、当然のように人とかかわることがあると思います。直接でなくてもコードの中やシステムを通して間接的にも多々かかわることもあると思います。開発をする、チームを作るということは、そのメンバーで文化を構築していくということを意識することが非常に重要だと思います。AgileやScrumなどもその文化の中のひとつだと思います。文化はリーダーだけでなく、そこにいるメンバー一人ひとりによって代わるものです。

文化については、ここら辺がお勧めです。どういう組織を作りたいかGeekな集団とは何か。
books.rakuten.co.jp
Spotifyの文化は、すごく参考になります。英語ですがスライドを見ればなんとなくわかるかと思います。
labs.spotify.com
labs.spotify.com

ちなみに、僕は文化として、重要だと思ってることは大きく3つ合ります。

  • 真剣に振り返るできること
  • 安心感があること・失敗を恐れないこと
    • Spotifyの文化だとFailure Celebration: 失敗をして新たな発見をできたことを祝う。
  • 先を見越し動くこと(プロアクティブ)
    • 言われて実装するのではなく、先見の目を持って技術投資を行い、プロダクトを改新していく感じ
    • フォードもこの文化を持ってる1社ではないかと思います。

「もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。」
by ヘンリー・フォード(アメリカの自動車会社「フォード」の創業者)
http://meigensyu.seesaa.net/article/205528783.html

良いとは何かを知る

良いコードを知ること・良いアーキテクトを知ること

コードを書くときに、動けばいいや?って書いてるとそれは大間違いです。コードを書いた瞬間からそのコードの運用が始まります。コードを運用するためにはコードを読まなければいけません。そのためには、どのようなコードが読みやすいのか知る必要があります。僕はこう考えています。「企業の成長速度は、コードの良し悪しで決まる」と。改修しやすい、変更しやすいコードは企業のビジネスの変更に強く、その仮説検証を促進してくれます。逆にテストがなかったり、汚いコードはすぐにリリースはできますが、変更に弱く、いざビジネスを進化させようとする際に足を引っ張ります。
ゆっくり読んでも1週間くらいで読める本だと思いますので、とりあえず読むといいと思います。
books.rakuten.co.jp


次にお勧めしたいのが、レガシーソフトウェア改善ガイド
これを読めば、そもそもどんなソフトウェアが危険なのかの勘所とそれに対してどうすればよいかがわかります。なので、自分がレガシーソフトウェアに携わってないと思っていても、1度読むことをお勧めします。そもそもソフトウェアの構造がここ数年でどのように変わってきたかもわかるので、ある意味歴史の教科書です。個人的に、心に残ってるフェーズは「チームが既存のコードを改修しなくなったらそれはレガシーの始まりである。」という、組織文化についても少し触れていた点です。
books.rakuten.co.jp


使っているモノをちゃんと知ること

自分の扱ってるプロダクトに合わせて言語習得をしたりすると思います。既存のコードや書きたいコードを検索して調べて、それで実装して、リリースしたりしてると思います。でも、本当にその言語の強み、フレームワークの利用方法を学習してますか?なんとなく使えるからと、怠らずちゃんとそれがなんなのか知りましょう。先人たちが知るべきことを示してくれてます。

ベストプラクティスを読む

あと、ツールやDBだとベストプラクティスは結構公式に乗ってます。きちんと理解しましょう。
Googleで「Ansible BestPractice」とか打つと大抵出てきます。独自の発想で使うのではなく、ベストプラクティスに合わせて使いましょう。
そもそも、ベストプラクティスはツールの意義に沿って案じてあります。それに沿わないと、ツールがバージョンアップするときに取り残されて将来古いバージョンを利用し続けなくならなければいけない危険性があります。そんな、運用したくないですよね。

自分の知識を更新していくこと

幅広くアンテナを持ち続ける。

ご存知のとおり、Web含めIT業界の技術というものは日進月歩です。
日々とまでは言いませんが、常に少しだけでも読むようにしておきましょう。課題を解決するときに新しいOSSのことを知っていたり、既存のOSSをバージョンアップすることでより、より便利にしたりと、プロダクトとあなたをアップデートしてくれます。
ここでは僕が日々キャッチアップしている軸とサイトを少しだけ紹介します。自分に合ったものをちゃんと見つけましょう。

幅広くキャッチアップする

いろいろなものはどこかでつながってるもので、浅くてもいいので幅広く知っておきたいものです。
hacker news
ここでは非常に幅広いジャンルの記事を読むことができます。
OSSだけでなく、世の中の情勢記事(技術によってる)などを読むことができます。TOP30くらいが常にトップページに出てるので、朝から面白そうな記事だけ2,3個だけピックアップして読みます。
使い方的には技術新聞をぺらぺら読んで、情勢を知ったり、キャッチアップのために使います。
Hacker News

技術方法論を日々更新する

自分が良いと思っているやり方だけにこだわらず、いろいろな手法を勉強し続けることが大事だと思います。
dev to
表示速度が異常に早いことで有名になったページです。基本的にはWeb技術や手法についての記事が多いです。
自分のプログラミングや技術手法を改善するために、暇なときに読みます。
The DEV Community

利用してるものの知識を更新する

自分が使う技術回りは常にアップデートしておきましょう。それがそのまま自分の更なる強みになります。
ScalaTimes
名前から予測できるとおり、Scala周りの技術周り、ブログ周りを集めてるサイトです。
http://scalatimes.com/

ほかの言語でもいろいろとあると思います。メールを購読するようなサービスも意外と便利です。

同ジャンルの競合を知る。

自分が利用している技術の同ジャンル等はできるだけキャッチアップできることが大事です。
DB-Engines
DBのランキング紹介サイト。各ジャンルごとにDBのRankingを紹介しています。
僕は、上位のものを使うというより、そのジャンルで今どういうDBが出てるのかを知るために利用しています。それで、自分の利用用途に一番合うのはどれかを考えます。やはり、何かを採用する際は、ちゃんと競合には何が存在するのかを知っておく必要があると思います。
DB-Engines Ranking - popularity ranking of database management systems

最後に

最近、どのようにすれば自分がエンジニアとして価値を出せるのかを考えることが良くあります。この記事は、それに紐付いて思ったことを書きました。こういった人材を育て、同じチームでプロダクトに向かっていけるといいなと思います。もちろん自分もこういったエンジニアで在り続けないといけないなと思います。

最近、リモートワークで使ってるツール紹介

リモートワークで利用しているオンラインツールを簡単に説明したいと思います。
個人的には必須のサービスになりつつあります。
ぜひぜひ、利用してみてください。

appear.in

appear.in – one click video conversations
f:id:daigorowhite:20151105182330p:plain
簡単にテレビ会議をするためのサービスです。真ん中のリンクに適当な文字列を入力すると、会議が始まります。そして、そのリンクを会議したい人に渡すだけで、テレビ会議が始まるというすぐれもの。必要な環境はブラウザだけなので、なにか特殊なアプリをインストール必要が無いのがすごい楽。
画面はこんな感じ。
f:id:daigorowhite:20151105184605p:plain

  • ウェブでテレビ会議出来る
  • 画面シェアが可能
  • ページのリンクをコピペでほかの人にテレビ会議のページを教えることが出来る
  • キック可能
  • ページのロック可能(新規ユーザを限る感じ?)
  • 超簡単

web white board

A web whiteboard
f:id:daigorowhite:20151105182509p:plain
これは、ウェブ上にみんなで落書き可能なホワイトボードを作成するサービスです。
リモートで説明するときに、落書きしながら話したいときに、効果を発揮します。でも、マウスでのお絵かきはやっぱり難しいです。
ちなみに、この左下の人を+するみたいなアイコンをクリックしたあと、"Invite to board"すると、シェア用のリンクが出てきます。
f:id:daigorowhite:20151105183133p:plain

  • オンラインで参加者全員でお絵かきするホワイトボード
  • 文字も打てる、ペンのサイズ、色も変更可能
  • 図も挿入できる
  • 何気にチャットも可能
  • 書いたホワイトボードを、imageにして保存可能
  • 有料会員になると、ボイスチャット、ボードの保存が可能
  • やっぱり、書きながら説明するのは良い。

idea board

www.ideaboardz.com
f:id:daigorowhite:20151105184100p:plain
オンラインで付箋を貼り付けるスペースを提供してくれるサービス。
ブレインストーミングや、レトロスペクティブに使える。
こんなかんじで、スペースが提供される
f:id:daigorowhite:20151105184114p:plain 
各チケットにイイねできる
f:id:daigorowhite:20151105184151p:plain

  • オンラインでチケットを貼り付けるスペースを作るサービス
  • 軸の数とその名前は自分で設定可能
  • イイねボタンを利用して投票することができる
  • 左上のボックスに文字を入れると、フィルタリングも可能
  • 右上のリストからソート順も変更できる(作成順、イイね順)
  • PDFやExcelとして出力可能
  • ios/androidアプリもあるみたい
  • リモートでも、レトロスペクティブしようぜ

まとめ

今感じで、最近リモートワークをしております。
今は、何かツールを探すときは、オンラインほげほげで検索するとたいてい出てくるので、それを吟味しながら使っている感じです。プランニングポーカーなどもあります。しかし、簡単に使えるものでないとすぐにめんどくさくなるので、そこらへんはツールを選ぶ上で注意が必要です。あと、いかに優れたツールがあれど必要なのは、リモート先の相手との信頼関係です。そこを築くことがリモートワークで一番重要な気がします。

パリで働いて感じたこと 第5話 レトロスペクティブ楽しい

どーも、だいごろうです。

今回、パリで感じたことというより、
会社でやってるスクラムのレトロスペクティブが面白いなと思ったので、
ブログに書いておきます。
スクラム?それってラグビーのことだろ??ってひとは、ごめんなさい。)
チームで振り返りをしてみたいって人にはおすすめ。ただし、コンテンツは英語。
日本語で雰囲気を知りたい人はご連絡下しあ。

さきに、このレトロスペクティブの流れのイメージを話すと

レトロスペクティブが始まると、
最初に、スプリントの全体を全員が1枚ずつ絵を書いて発表します。
次に、スプリントのイベントをTwitterのつぶやきの書き方で時系列に並べます。
それから、何をすれば次のスプリントが完璧になるかをボード上に貼っていきます。
そのボード上のモノを、実行しやすいかどうか、効果が高いかどうかの軸で並べ、
実行しやすく、効果が高いものを次のスプリントの目標に設定する!


という感じで、わいわい楽しみながら、みんなでスプリントを思い出し、
なにすれば良くなるかなーってのを話し合うイメージです。
しかも、毎回レトロスペクティブの中身が変わります!

じゃあ、具体的に説明していきます。

使ってるもの

Retromatというレトロスペクティブ用に作られたページ
Retromat - Inspiration & plans for (agile) retrospectives

このブログの著者が運営してるみたいです。
Finding-Marbles | Making sense of systems – Lean, Agile, Change & Communication

このページどうみるのか

このレトロスペクティブでは5つのステップに分かれています。

  1. SET THE STAGE ( 振り返る準備に入る
  2. GATHER DATA ( スプリントの出来事を集める
  3. GENERATE INSIGHTS ( 改善点、良かった点をあぶり出す
  4. DECIDE WHAT TO DO (何するか決める
  5. CLOSE THE RETROSPECTIVE ( 振り返りの締め

ページを見ていただくと、色によって、5ステップに分かれてるのがわかるかと思います。

そして、それぞれのステップに複数のコンテンツがあるので、
毎回それを変えながら、いつも違った形でレトロスペクティブを楽しむことができます。
しかも、それぞれのステップで10-20くらいのアクティビティがあり、
全部で105のアクティビティが有るみたいです (2015/07/24現在

3321204 combinations (20x23x19x19x20+4)って公式に書いてあるっすね。
最後の+4がよくわからんっすけどw

ちなみに、ページアクセスすると、自動でアクティビティを選んでくれます。
しかも、それぞれの組み合わせはURLとして、表現されているので、
URLのコピペでレトロスペクティブの項目を保存しておけます。(便利)

では、それぞれのステップがどんなことをするか例を上げて説明します

SET THE STAGE ( 振り返る準備に入る

Check In - Amazon Review (#18)

スプリントをアマゾンのレビューと同じように評価する

  • Title
  • Content
  • Star rating (5 stars is the best)

そして、前で発表する
http://plans-for-retrospectives.com/?id=18

GATHER DATA ( スプリントの出来事を集める

#tweetmysprint (#97)

ホワイトボードにスプリントの始まりから、終わりまで時間軸を書き、
その上に付箋で、twitterでつぶやくように出来事を書いていく。
もちろん、@や#タグなども使って良い。

@daigoro
ここでだいごろうのバグ発見があった。
おかげで、リリース前にフィックスできた。
#bugfix #goodjob

GENERATE INSIGHTS ( 改善点、良かった点をあぶり出す

Perfection Game (#20)

全員が2枚の付箋を持つ、
1枚には前回のスプリントを10点満点で評価する。
もう1枚には、どうすれば次のスプリントが10点満点になるか書く。
最後に、一人一人、前で発表しながらホワイトボードに貼る。
http://plans-for-retrospectives.com/?id=20

DECIDE WHAT TO DO (何するか決める

Divide the Dollar (#72)

前のステップで出た改善点をすべて、並べて
もし、自分が100ドル持ってたら、どれにどれだけ投資するかを書く。
全員が投資を書いた時点で、点数が高い順から次のアクションになる。
http://plans-for-retrospectives.com/?id=72

CLOSE THE RETROSPECTIVE ( 振り返りの締め

Motivational Poster (#92)

前のステップで決めたアクションをポスターにして自席の近くに貼っておく。
ポイントは、

  • イメージ画像が有ること、
  • チーム同意のアクションが書いてあること
  • 自分の行動イメージが書いてあること

http://plans-for-retrospectives.com/?id=92

ちなみに

僕らが会社でやってるのは、ここにあるアクティビティを噛み砕いて、やりやすいようにやってます。

どうでしょうイメージ湧きましたでしょうか?

複雑そうに見えますが、非常に簡単なので、
レトロスペクティブがマンネリ化してると思うならば、
一度やってみることをおすすめします。

ちなみに、こちら、プリントエディションもありますので、
もし、興味がある方がいらっしゃいましたら、購入してみるのもありです。
この地球上なら送料無料です。(僕も買って、日本に送ってもらってますw
ただ、今年の販売が7/26までなので、もし買いたい方がいたら、早めに。
Retromat - The Print Edition


本日は、いままでにないくらいちゃんとブログを書いた気がします。
フランスに来て、スクラムアジャイルを自由にやってる方々を見ると、
日本では形式から入る人が多いのでは?と感じます。
とりあえず、こういう面白そうなことだけから始めるのもいいかなーって感じました。

では!
f:id:daigorowhite:20150725065113j:plain

パリで働いて感じたこと 第4話 今しかできないというセリフを言うこと

パリでフランス人と話して考えたこと。
「なんでそんなに仕事してるの?」
「今、幸せなの?」
「なんで家族とか友達とかにもっと時間割かないの?」
っとか、けっこう聞かれます。
"once life. you should do you want to do" : 「人生一回だから、自分のやりたいことやれよ」
っとか、言われます。

それに対して、
「だって、プログラマとして頑張れるのは今しかできない。だから今、イロイロと挑戦してます」
って答えてたんだけど、なんかしっくりこない気がしたから、ちょっとだけ考えてみた。

なんで、今しかできないの??ってことを突き詰めて考えると

  • 体力がなくなる
  • 頭が回らなくなる
  • 技術を追いかけられなくなる
  • 他にエンジニアリング以外のことが見えてきて、そっちが楽しくなる。(かも)
  • 日本ではそういう働き方では稼げなくなる

っとかを、頭のなかにでてきて、
でも、結局はどれも本質ではないなと思った。
エンジニア35歳定年説とかも、ここらへんを見据えてのことじゃないかな。
まだ、35歳じゃないから、本当のことはわからないけど。

結局は自分が好きなうちはプログラマで楽しく出来るんじゃないかなって思った。
今も、好きだからこの仕事でプログラミングしてるんだろうな。
きっと、今しかできないってことはないんだと思う。


ただ、「今しかできない」って言う、緊迫感を持ってチャレンジしていったほうが、
自分のキャリアとか人生とか面白い方に転びそうだなって思ったから
これからも、俺は今しかできないってこれからも言い続けると思います。


今しかできない(気がする)からチャレンジしたいんです、もっと。

そんで、振り返った時に、けっこうむちゃしてきたなーw
って言いたい。

パリで働いて感じたこと 外伝第1話 Google IO と WWDCを見て思ったこと

こんばんわー!!(´・ω・`)
全然、パリ関係ないけどブログ更新します!書きなぐります。

本日は、2つのでかいイベントを見て感じたこと、思ったことを書いていきます。
みなさん知っての通り、今、スマートフォン/タブレットといえば、
- apple (wwdc)
- android (google io)
の2つが巨塔( ・∀・)ノ

その2つの企業の発表から何がどうなのかーってことを、ぼちぼち考えてみました。
聞いてる部分と、聞いてない部分があるし、いつもどおり、このブログは完全なる個人的見解。

逆に総まとめから、書きます。

まとめ

それぞれの企業

  • google
    • 今まで他になかった、新しいを生むことに尽力している。他企業の前を歩いてイノベーションしてる。
    • 重要視するのは、製品を生むことによるユーザエクスペリエンス。
    • 何のために、このプロダクトを作っているかをちゃんと持っている。目的がありそれを良くするためにイノベーションしている。例えば、ネット環境が疎い地域のために、オフライン検索やオフラインマップを整備して、ネット環境が不十分でも恩恵を受けれるようにする。など。
    • そのために、データをディープに機械学習して、データを使って、新しいプロダクトを作っている。
  • apple
    • 今回の発表はapple製品と他のソフトウェアとの差分を埋めること。
    • なにが○倍早くなります!新しいエンジン積みました!っていうのは、すごいことだが、なんだか、実感がわかない。
    • インパクトを持ってこようとしているのは、分かったが、近年、イノベーションに慣れたユーザには目新しい物は少なかった。
    • developerに視点をおいて、swiftとかappの新規APIの話などをしてる点は、良かったと思う。
    • でも、その点はもっと深堀りしてもよかったのでは?apple musicとかで、ムダな時間使わずに。
    • うーん。やっぱり、発表が開発した人とか思いがこもってる人ではなく、偉い人がやってるイメージしかなかった。いいもの作ってると思うのに、ほんとにもったいない。
    • ios上でのサーチにチカラを入れていることが非常に分かった。アプリにAPIを公開するなど。
    • iOSOSXも最新版を8割位のユーザが持ってることは、開発側にとってすごくいいなと思った。androidの最新版のユーザはかなり少ないし、ほとんどのユーザが最新版を持ってることは非常にアドバンテージだと思った。

総じて感じたことは

  • 今、両方で起きている2つの大きなテーマは、機械学習とユーザエクスペリエンス」だと思った。appleはユーザが聞いた音楽などの動向から、サジェストを作るという点にチカラを置いている。googleは、検索、メール、お気に入り、写真などのさまざまな情報から、ユーザに適切なコンテンツやサジェスト、執事機能を提供するという点にチカラを置いている。この点においては、どうしてもgoogleのほうが多くの情報量やサービスを持っていて、ほんとにユーザのエクスペリエンスにそってると思うので、今のところは軍配はgoogleにあがってる。機械学習した情報をユーザにフィードバックする仕組み自体が完成していってる気がする。google now, okay google, google photosなどはそのたぐいだと思う。
  • あと、ほそぼそと来てるのが、「スマート家電」かな。googleはbrilloとweaveを発表し、appleはhome kits を開発中。やっぱり、多くの家にスマートフォンがあるこの世の中では、家にある家電は、スマートフォンと連携することで進化を遂げるという見解は、両者おなじっぽい。ココについては、正直、おれ、すごく興味があるから、どっちもちゃんとこの分野を成長させていって、開発キットをOSSで出して欲しい。スマート家電開発したい。
  • 全体的に、この記事がapple微妙って言ってる気がするが、絶対、発表者の問題。googleのほうが、ストーリ仕立てとか非常に上手くて、惹きこまれたのが事実。発表終わった時に、新しいスマホとスマートウォッチが欲しくなったのは、google I/Oやな。
  • googleは、どんどん新しいものを作って、まだ見ぬユーザエクスペリエンスを狙ってる感じ。
  • appleは順当進化と、ほかが持つ便利さを取り入れてる感じ。

あとは、いろいろな視点から、殴り書き。

発表されたものについて

  • google
    • とりあえず、一番嬉しいのは、brilloとweaveかな。実際に、自分でスマート家電を作れそうってイメージができたのが、エンジニアとして気合が入る。
    • google photosはユーザとして、嬉しい。機械学習を取り入れて、写真のシチュエーション分析して、カテゴリ分けしてくれるのは、面白い。動物園カテゴリに、男の先輩のセクシーポーズがあったのが非常に良かった。
    • offline something.. ネット環境が整備されていない国にもネットの恩恵を与えるための、オフラインマップや、オフライン検索。情報量を少なくして、データ転送量を下げるなど。
  • apple
    • siri/検索自体の言語解釈はかなり進んでいてい、自然言語でイロイロと検索したり、操作したりが可能になってきている。
    • 多くの既存プロダクトの更新があった。map/memo/music/....などなど。でもどれも他サービスをおってるだけのイメージしか感じない。
    • apple musicは名前のインパクトからすると、もっとインパクトの有ることがあっても良かったのではないか?youtubeとやってることは同じ感じ。他サービスを追っているイメージ。
    • なにげに、itunesandroidででるってことに驚いた。
    • apple watchでできること増えてる。別に、watchで写真を閲覧できなくてもよくね?
    • swiftOSSは本当に嬉しい。Linuxで触りたい。ムダになんか作りたい。

発表スタイルについて

  • google
    • エンジニアが前に出て、発表してるイメージ。
    • みんな、プロダクトに対する夢、思いを語っている。
    • どんなユーザにどういうエクスペリエンス(経験)をさせるために産んだプロダクトなのかをしっかり説明している感じ。
    • 発表の練習やスタイルを徹底している。英語もゆっくり、クリアに重要なことだけをしっかり伝えている。
  • apple
    • 最初に登壇された方はユーザエクスペリエンスからプロダクトを語っていて、すごく引き込まれた。使用するイメージを植え付ける上手なプレゼンだったと思う。
    • 途中のwatchの発表の人などは、機能をただ説明しているだけ。大学生でもできるやろうって思った。上の役員が、特に分かってないけど発表しているイメージを受けた。
    • apple music 発表のやり方自体、退屈そのものだった。youtubeでできることを、時間をかけて説明している。驚きでもなんでもない。一緒に見ていたフランス人も日本人も飽き飽きして聞いてた。


久々に、長々と書きましたが。今回もまた、殴り書きでした。情報をまとめるの下手くそなんですよね。じゃあ、最後に、この前見た、考える人の写真とその名言でさようなら。

I think ... therefor I am.
f:id:daigorowhite:20150609061840j:plain

パリで働いて感じたこと 第3話 コードの成長と成り立ちの巻

へろう( ・∀・)ノ

1ヶ月と半をブログの更新をしてなかった。
それは、毎日をエンジョイしすぎてたからである。
「ブログを更新するのめんどくせーな」ではなく、
ブログを持ってることを軽く忘れてた(オイw

っとまぁ、そんなこと、前置きは置いといて。

今日は、

コードの成長と成り立ち

について、感じたことを書きなぐる。

コードを読んだ感じ

今、見ているソースコードはかなりレガシーですw
そして、感じることはソースコード全体が、
ちょっとずれたパズルで構成されているようになっていて、
そのピース一つ一つから、各人の個性が伺えます。
同じ人が作ったピースはぴったり合うのだけれど、
他の人が作ったピースとは、(書いた人の技量次第だが)なんか、ズレがある感じ。
部分的には、かなりテクニカルだけど、部分的にはドン臭い感じ。

なぜ、そーなったかを考察してみた

簡単に、思ったことを箇条書すると

  • フランスの開発者は1-2年くらいで転職しちゃう。
    • だから、あまり、コードの運用のことを重視しない
    • もちろん、そうでもない人もいる。(超重要な人
    • なので、運用しやすいより、動くことだけを大事にする人が多い。
  • 開発に、新しいテクニカルなことを導入したがる人が多い。
    • 既存のコードとの組み合わせは無理やり。動けばOK
    • 1,2年ペースで新しいことがどんどんコードに足される
  • リーダーがやめたら、外から保管することが多い
    • 気のせいかもしれない。
    • でも、リーダーが変われば、方針が変わる。
    • 1,2年ペースで変われば、そりゃコードも荒れる。
    • ノウハウの衰退化。

ッて感じなのかなっと。

6ヶ月しかいない自分にできること

ってなんだろうな。
短期的な解決策としては

  • "今"のメンバーの意識を、ちょっとだけでも変える。
  • レビューを導入する。レビューでなにをするか伝える。
  • そのための時間を確保する。
  • 不要なコードを消す。

長期的だとこんなんかな。

  • もっとマクロサービス的に考えて、ちぐはぐなのを容認する(できる)システムを構築する。
  • ほげほげ

くらいかなー。
あー、なんか真面目だな。
もっと、不真面目で面白いことできないかな。

結局思うことは、意外とこれでもサービスは回ってるし、どうにかなってんだよね。
これはこれで、ひとつの開発のあり方なのか?
でも、こういうのって、確実にサービス成長を鈍足化させてるから、
やっぱり問題だな(´・ω・`)

結果、0から全部作り直したいになるんだよな(悪い癖(((((((((((っ・ω・)っ

まとめ

フランスで食べるパスタはそんなに美味しくない。
つまり、ソースコードはスパゲッティってことだ。

どうでもいい、後付

なので、最後に、先日作った
ポルチーニドライトマトの和風パスタの写真を置いておきます。
ポルチーニドライトマトが安すぎて、なけます。日本で作ったら、材料費だけで死ねます。
別に、料理を自慢したわけじゃないんだから!!(/ω・\)チラッ
f:id:daigorowhite:20150524194559j:plain

パリで働いて感じたこと 第2話 前進アルノミの巻

ぼんじゅーる!
全然フランス語が身につかない男で定評のあるだいごろうです。
もはや、発音が違いすぎて土地の名前すら分かってもらえません。

さて、1ヶ月目にして2話目です。
亀よりも遅いと自負しています。

今回は、わりとお仕事についてです。
さて今日は、こっちのコミット意識について、お話していきたいと思います。
(プログラムのバージョン管理系の話になるので、何だそれってなる人は、このページをそっとじしてね(((((((((((っ・ω・)っ )

ちなみに、今からするお話は、
僕の現場のお話なので、フランスの開発がこうだとは限りません。

日本にいた時は、

共通で開発しているブランチで作業をしているとします。
じゃあ、開発するかってなったら、

  • そこからブランチを切ったりして、ローカル環境を構築して
  • 自分の作業が完了して、テストが通るようになって、
  • ある程度動くことを確認してから、コミット、(レビューしたり)
  • みんなの作業ブランチにマージ

ッて感じで、

全員の共通のブランチは、基本安定させる
な感じで、開発進めていきますよね?

今の現場だと

じゃあ、開発するかってなったら、

  • そこからブランチをクローンして、ローカル環境を構築して
  • 自分の作業が完了して
  • とりあえずコミット、マージ、プッシュ
  • jenkins先生が怒る
  • 「だれのコミットだー」って感じで犯人探し、
  • 「おれだー、治すわー」
  • なんとなく修正したら、コミット
  • 上記を0回以上繰り返す。

って、感じで、
前進あるのみ、バグったら修正したらいいじゃんッ。
て感じ。

なんか、こういう文化は、けっこう個人主義があるからのような気がしています。
さくさくと自分のタスクを終わらせて、次々に進めていきたいという、ベンチャー基質な感じがあるのかもしれません。

なので、所感的には

最新版にして、実行しよう!ってすると、けっこう起動すらしないことが多い。
スピードは大事だけど、さすがに、一度くらいは実行してみてほしいと思うっす。
まぁ、全員でひとつのブランチでわっしゃーって開発するから、
協力プレイで強大なボス倒してるみたいで意外と面白いんですがw

では、最後に

モンマルトルの丘から見る、パリの町並みで今回のブログは締めたいと思います。
さよなら、さよなら、さよなら
f:id:daigorowhite:20150404073030j:plain