プログラミング素人がLINE Developer Meetupに参加した話

暇つぶしと、自分を慣れない環境に身を置いて、新鮮な感覚を得るために、
参加をしてきました。学んだことは3つ。

一番最後にまとめてますので、
そこだけ読みたい方は2つ段落を飛ばしてください!

~会場のLINE Fukuoka カフェスペース~

綺麗でお洒落なデザインで、落ち着ける空間がとてもうらやましい。
それと比べてうちの会社は古びてて、使い勝手が悪く空気が重たい…
照明一つでも暖色にしてくれればいいのに。

<経緯>

最近プログラミングに対して、
スキル習得の一つとしてとても興味を持ち始めています。

思えば、レゴを小さいときから説明書の通りに作らずに、
勝手に違うのを作ったりしていたので、
自分のアタマで考えて何かを生み出していくことに
適性がありそうな気がしています。

さて、そんな中、言語何を勉強しようかなー、
プログラマーってどんな仕事だー?などいろいろと調べている中、
「connpass」というエンジニアをつなぐIT勉強会の
開催支援プラットフォームを見つけました。
リンク:https://connpass.com/

何か面白そーなのないかな、と調べていると
LINE Fukuokaのイベントを発見。

自分の会社以外のオフィスって、
就活のときぐらいにしか入れないじゃないですか!
なので、IT企業のオフィス見たさ半分、セミナー聞くこと半分で、
参加をしてきました。

~ゲスト用入館証~
首からぶらーんと
ぶら下げてました。

ちなみにですが、飲み物(ビール)
とちょっとしたお菓子もありタダの
セミナーなのにすげー!ってなりました。
(お酒好きならタダでビールが飲める
一つの手段になりうる。笑)

<セミナーの内容>

テーマは、「モバイルアプリ」。
ご存知の通り、LINEは、メッセージを送ることができるサービスだけでなく、LINEバイトやLINE payなど様々なサービスを提供するための
プラットフォームとしても機能してますね。

そのアプリの開発がどう進められているかを、
開発チームの人目線で話を聞くことができるものでした。

どうやって新機能を追加していくのか?
スマホがどんどん進化するにつれて、
アプリケーションも常に進化を続けていかなければいかない苦労などなど。

~入り口においてあったやつ~
とにかく色があるものがあって、遊ぶ心がある
明るく余裕があるイメージのオフィスでした。

真っ白な机と鈍い色の壁で囲まれてると
鬱になりやすいので、
視覚情報として職場環境を明るくすることは
大切だと本気で思う。

<プログラミング素人が話を聞いて得たこと>

そもそもエンジニアであったり、エンジニアを目指している学生向けなので、
場違い感はあったが、新鮮に感じたことが3つあります。

1.チーム体制ができたり消えたりフレキシブルであること。

あるアプリケーションを作るにあたり、プランニング、デザイン、開発、QA
など各役割ごとに分けて仕事をするまでは普通のことです。
が、
例えば、A・B・Cの物を作るってなった時に、
それぞれの物ごとにチームを作ったあと、
Aが要らないってなったらB・Cに人を増やしたり、
Bのチームに入れてたけど、Cのほうに向いている人だからこっち移すわ!
みたいに、

横の移動がとてもスムーズにできて、
スライムみたいに分裂したりくっついたりとフレキシブルに組織が組まれて、
物事を作り上げていくチーム制というのは面白いと感じました。

うちの会社も同じ顧客ばっかりとやっていたら段々飽きてきますし、
まったく違う業種を担当してみたりしたら新しい発見があったりすると思う。

加えて、同じことばかりしているとやり方が固定概念化されてきて、
他の人から見た時にとてもいびつで頑固な仕事になってそやし。
たまにはぐるぐると回してもらいたいものです。

2.「Release train」という考え方。

簡単に言うと、一つのプロジェクトに複数存在するチームを運営するときに、
だらだらプロジェクトの納期を延ばさないための仕組みです。

電車が時刻になったらホームにきて、定時になれば出発するように、
2週間(1週間でも1か月でもなんでもいい、とにかく一定時間)ごとに
成果を回収するタイミングがあって、
それに間に合わなければ次の2週間後までに遅れた分も含めて
進めておくように決めておく。

そうすれば、誰かのチームだけが、
「あと1日あればできます!だから少し全体でまとめるタイミングをずらしてください!」といって、とりまとめの期日をずらすようなことも生じず、
きちんと全体の期日を守って物事を進めることができる。

期日が後ろにずれずれになることを防ぐことができる点で、
様々なチームが個々に動いて物事を進める際に役に立つ仕組みやと思いました。

3. 「技術的負債 」

技術的負債Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。

https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5

エンジニアの人はよく聞く言葉のようですが、私は初耳でした。
具体的には以下のようなものがあります。

低いカバレッジもしくは全く書かれないテストコード

開発者・関係者の間でスムーズな共有が行われていない知見

無視されたコンパイラ警告・コード解析結果

不必要に複雑すぎる設計・コード

コーディング規約に従わないコード

放置された嫌な臭い (リファクタリング対象にはよくこの比喩が使われる)

古すぎるバージョンの言語やフレームワーク

開発環境と本番環境の差異

https://qiita.com/erukiti/items/9cc7850250268582dde7より

要は、普段の仕事でいえば、
過去に誰かがやった社内規定を守っていない仕事とか、
雑な仕事、引継ぎ不足、作った本人しか分からないエクセルや、
説明書きが説明になってないマニュアル。

あー、なんだか今自分が抱えている仕事ですんごい思い当たる節が…。

LINEでは、こういった過去のエラーや、修正されずに放置されがちなものを
直したときに、報酬がでるような仕組みになっているようです。

インセンティブ(誘因)が働かないと、
人間はちゃんと機能しないと思っているので、
仕組みとして過去のポンコツを直す仕事をしたくなるようにすることは、
とても大切だなーと感じました。

以上「プログラミング素人がLINE Developer Meetupに参加した話」でした。
ほなまた!!

シェアする

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

コメントする