新卒１年目のwebエンジニアが入社から今日までを振り返ってみた
Gaiax Advent Calendar18日目です！
今日はわたくし、新卒1年目のエンジニアが入社から今日までの9ヶ月間を振り返ってみたいと思います！
入社〜研修
4月はシェア研修、5月はエンジニア研修という構成で、2ヶ月間の研修を受けていました。
シェア研修とは、合計10社ほど集まって合同で行う研修のことです。
- ビジネスマナーなどを学ぶセッション
- 自分の人生のミッションステートメントを考えるセッション
- 2週間ほどで0からサービスを立ち上げるセッション
などがありました。
サービス立ち上げの研修は本当にハードで、何度も徹夜しながら会社で議論していたのを鮮明に覚えています。それでも社内のたくさんの人の協力のおかげで「この課題設定力はすごい。新卒とは思えない！」などのフィードバックを得て終えることができました。
Gaiaxの2016年度の新卒は私を含めて6人なのですが、シェア研をうけた人たちを含めると80人ほどになります。同期がたくさんいるのはホンマええことですよね。マナー研修やミッションステートメント研修でも学びや気づきはたくさん得られましたが、同期がたくさんできたことも収穫の一つです。
5月からのエンジニア研修は2社合同で実施されました。
それぞれ研修の目標を設定し、それを達成すべく研修を受けていました。内容としてはwebに関係する技術全般を広く、おいしいところをつまんでいく感じでした。web初心者な自分にとって、ついていくのが大変なことも多々ありましたが、非常に濃い内容で充実した研修でした。
またメンターの方とはほぼ毎日レビューを行っていました。このレビューも非常に濃いもので、自分の今後のキャリアなども含めて様々な気づきを得られた機会でした。ちなみに今でもよく一緒に飲みに行ったりしていて、その度にいつもハッとさせられます。本当に、感謝です。
配属〜今日まで
6月から配属。
私は、内定者フォローや女性の活躍促進などのための社内SNS「AIRY」というプロダクトを作っている、エアリー事業部に配属されました。開発は私を含め5人で、開発からサービスの運用まで行う、いわゆるDevOpsの体制をとっています。今日まで様々な機能開発、問い合わせ対応、障害対応、改善活動、他にも展示会などのイベントにも携わってきました。
個人的には、このAIRYというプロダクトを通して、世の中のすべての人が毎日楽しく仕事ができる、そんな世の中を作っていきたいと思っています。そして、それが個々のパフォーマンスの向上につながり、仕事に還元され、結果、企業の競争力の向上につながっていく。そんなサイクルを作りたいです。
この9ヶ月で学んだこと、身についたこと
レガシーコード改善のテクニック
今日までやってきて、一番大変だったのは、やはりレガシーコード改善です。
これまで人のコードをほぼ読んだことがなく、プログラミングも苦手だという自分のスキルのなさ、そもそもプロダクトにユニットテストが少なかったり、複雑度が恐ろしいことになっていたりというコードの状況など、なかなかに大変な状況でした。
このレガシーコード改善では、配属後に社内で実施してくださっていた研修の内容が本当に活きました。
OOPやTDD、レガシーコードへのテスト挿入方法やリファクタ手法、デザインパターン、言語のバージョンアップ対応など様々な研修をしてくださったおかげで、現場でも存分にレガシーコード改善を行うことができました。
これからもどんどん練習して血肉化させていきたいと思います！
チームについて
今、うちのチームではスクラムを採用しています。実際にスクラムを利用して開発を進めることで、スクラムというフレームワークに対する理解が深まったこと、また、チームとはなんなのか、なんのためにチームを組んでいるのか、というチームの本質を改めて知れたのも大きな収穫です。
チームは現在5人で、POが1人、開発チームが４人（QAと開発者が２人ずつ）という構成で開発しています（この前のレトロスペクティブで私が開発チームを兼任でスクラムマスターをやることになりました）。そしてQAとDevがペアで作業を進めるペア作業（ペアプロ）という形を採用して開発を進めています。もともとペア作業はQAとDevの知見の偏りをなくし、開発作業における属人性を排除するためにやっており、最終的にはバスファクターが４本になっている状態（4人全員がどのタスクでもとっていける状態）がゴールだと感じていました。
しかし、チームの本質を考えた時に、この理想形はすこし違うな、と感じるようになりました。バスファクターが４本になれば単純にこなせるタスクの量は増えるかもしれません。しかしそれは1人の持つ100%の力が単純に４倍にしかならないのでは、と感じます。イメージとしてはフリーランスを４人雇った状態とさほど変わりません。これではチームを組んでいる意味がありません。
1人では何もできない。そのことをどれだけ理解しているか。そしてチーム内で、自分が持っていない要素を他の人が持っており、逆に他の人が持っていない要素を自分が持っている。それを補完し合うことで1人では達成しえなかったことをこなしていく。これがチームの本質だと気づきました。ペア作業を通して、200%以上の成果を出していく。そんなチームを目指していきたいと思うようになりました。
これからについて
今後どういうキャリアを歩んでいきたいか、どういうところを尖らせていきたいかなど、入社した時よりは明確になってきたとはいえ、まだまだぼんやりした部分が大きいのが現状です。この辺りの芯をはっきりさせていくと同時に、今以上にステップアップしていきたいと思います！
合同勉強会でinnoDBのインデックスとアルゴリズムについて発表してきた
最近はもっぱらQiitaに記事投稿してばかりです。
今日は久しぶりにこちらで更新。
背景
先日３社合同で勉強会を開催しました。
最近はあまり勉強会には登壇していなかったのですが、久しぶりに発表してきました。
今回のテーマは「innoDBのインデックスとアルゴリズム」について。
最近アプリのチューニングを行うことがあり、それがきっかけで調べてみました。
質疑応答
Q. こういった勉強の時間はどうやって確保しているのか？会社としてそういう制度があるのか？
A. 完全に業務外で、個人の時間を使って調べています。ストレングスファインダーの強みとして「学習欲」を持っているのもあり、学ぶことが好きなので休みの日は一日中こういうこと調べたりとかしています。
懇親会
今回は合同勉強会ということで、いつもより出てくる食べ物も豪華でした。
いくらとしゃけの親子丼やローストビーフ丼など超いい感じでした。
所感
久々の登壇かついつもより人数も多いので若干緊張しましたが、やっぱりプレゼンは楽しいですね。
あとは発表すると「innoDBの人ですよね！」みたいな感じで覚えてもらいやすくなるのがいいところ。
同年代のエンジニアも結構多く、いろんな人と交流できたので非常に楽しかったです。
プロのソフトウェア開発者に必要な考えとは！？Clean Coderを読んだ
ソフトウェア開発を生業とする者として、開発時に意識するべきことや行動を
身につけるべく、本書を購入しました。
- 作者: Robert C. Martin,角征典
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/01/27
- メディア: 大型本
- 購入: 12人 クリック: 645回
- この商品を含むブログ (36件) を見る
本書の内容を一言でまとめると
【プロとして、自分の作るプロダクトや行動に責任を持て】
となります。
責任を持つとは？
まずは、自分が作るプロダクトに対して出来るだけバグを作らないようにすることが求められます。
何回も手術を失敗する医者にかかりたいでしょうか？
何回やっても負ける弁護士に弁護を依頼したいでしょうか？
答えはノーでしょう。
同様に、プロの開発者はできるだけバグを作らないように意識し
実装しなければならない、と本書では述べられています。
とはいえバグがないことを証明するのは非常に難しい。
バグがないことを証明することは難しいが、
すべてのコードが正常に動いていることは把握しなければならない。
そのためにはTDDを用いて実装を行うべきだと、述べられています。
（このあたり、なぜTDDなのか、という話も本書の中で説明がされています）
また、ソフトウェア開発は非常に高度な作業であり、莫大な集中力を必要とします。
そんな作業において、いかに単位時間あたりの生産性を高めることができるか。
ここにプロとしての自己管理力が求められる、と述べられています。
その他にもチームとしてどう行動すべきか、何を意識すべきかという話など
様々な観点から、プロとしての意識や行動について記述されています。
その数、１４章にまでのぼります。
最後に
私自身、ソフトウェア開発を生業とする者としての意識はまだまだ足りなかったと、
痛感しました。
おそらく一度読んだだけでは身につかないものだと思うので、
繰り返し読み、自分の意識に刷り込んでいきたいと思います。
fuelphpのORMモデルによるDBアクセス時のデータキャッシュには要注意
最近がっつりハマってしまったfuelphpのORMモデルメソッド利用時の仕様について。
ORMのCRUDメソッドを利用してDBアクセスした場合、fuelのフレームワークがよかれと思ってアクセス時のデータをキャッシュしてくれます。
そして同じレコードに対するデータアクセスがあった場合には、そのキャッシュデータを返すという仕様になっているようです。
この仕様のせいでどえらいハマってしまったので、記録として残しておきます。
ORMのCRUDメソッド実行時の詳細なSQLクエリ実行の様子や、キャッシュを避けるための方法についてはQiitaにまとめて投稿しておりますので、そちらをご覧ください。
qiita.com
今回得た教訓としては、
・データの設定や実装が正しいのに、想定する結果とならない時はデータキャッシュを疑え
・フレームワークを信用しすぎない
ということ。
この二つは連動しており、フレームワークの挙動を一切疑うことなく、「想定通りにいかないのは自分の実装が悪いからだ！」と信じきっていたため、原因追求に時間がかかってしまったと思います。
想定しない挙動によるエラーが起こった時には、多角的な視点を持って解決に臨むべきだと学びました。
あなたのプレゼンをワンランクレベルアップさせるスライドデザイン
はじめに
先日行われました勉強会にてスライドデザインに関する発表を行いました。
勉強会での質疑応答時や発表後、スライドデザインに関する質問をいくつか受けましたので、その内容について記載しておきます。
質疑応答
Q：１行のみのスライドで、文章を中央寄せにしているのはなぜか？
A：こっち方が見栄えとしてシュッとしているからです。（逃
Q：前の人にしか見えないという点から言うと、スライドの下の部分も後ろからは見えないと思うのですが
A：その通りです。特に大会場だと前の人の頭でスライドの下が見えなくなるのは
よくあります。なのでそういう場合は
主張したいことを一番最初に述べ（スライドの上に書く）、
その主張を補足する内容をその下に書く
という構成もよく使います。発表の環境によっては、できるだけスライドの下、
３分の１は使わない方が無難かもしれません。この構成のメリットとしては
「後ろの人でもスライドが見える」こと、
「言いたいことを最初に言い切るため、スライド中の主張が明確になる」こと
などが挙げられます。
Q：アジェンダを出すのと出さないの、どっちがいいの？
A：アジェンダを出すメリットとしては、話の大枠をあらかじめ提示することで、
プレゼン全体を通して何を喋ろうとしているのか、
そして今は何について喋っているのかが掴みやすくなること
が挙げられます。特にそこそこ長いプレゼンだと、話題の切れ目がはっきりしないとグダりがちです（経験談）。聴衆に「あれっ、今何の話してんの？」と思われたが
最後、最終的に「よくわからんかった」という感想が返ってきてしまいます。
なので私はアジェンダを出し、その大テーマをスライド上部、青色の所に記載し、
常にこのスライドは何についての話なのかがわかるように作っています。
Q：ご清聴ありがとうございましたスライドについて
A：これは賛否両論あると思いますが、私は
「ご清聴ありがとうございましたスライド」は絶対に入れません。
理由は「そのスライドに情報量が全くない」から。聴衆としては別に、
そのスライドを見せられても何も嬉しくないですよね。それだったら、
「まとめ」スライドを一番最後にしておいた方が良いでしょう。
自分が伝えたかったポイントを少しでも長く聴衆に見せることができますし、
聴衆もプレゼンの主張点を振り返りやすくなります。
最後に
もし他にも「これってどうなん？」という疑問がございましたら
お気軽にコメントしていただければ幸いです。
（自分の知識的に）答えられる範囲で回答させていただきます。
仕事・勉強・研究、何にでも使える「nu board」のオリジナル活用法
nu boardとは？
一言で言うと「ノート型の持ち運べるホワイトボード」です。
モノによるかもしれませんが、ページ数は８ページ。
見開きで使うとおよそ２倍のサイズになるため、メモやMTG、打ち合わせなど
様々な用途で使える非常に便利な一品となっております。
ちなみに様々なサイズがあるようですが、今回はA4を購入しました。
つまり見開きだと最大A3で使用することができます。
CANSAY nu board (ヌーボード) A4判 NGA403FN08
- 出版社/メーカー: 欧文印刷
- 発売日: 2015/04/01
- メディア: オフィス用品
- この商品を含むブログを見る
仕事でも勉強でも研究でも、何にでも使えるこのnu board。
今回は自分なりの活用法についてご紹介したいと思います。
nu boardの活用方法
その１：To Do管理
仕事において、やらなければならないことがたくさん溜まっていきます。
その溜まりに溜まる(?)タスクを、私はnu boardを使って管理しています。
【管理方法】
自分が今抱えている全てのタスクを付箋に書き出し、見開き１ページを使って
nu boardに貼っていきます。
なおタスクを書く時は、付箋１枚につき１つのタスクを書くようにします。
※詳細なタスクはモザイクかけさせてもらってます。
「activity backlog」とはポモドーロテクニックに登場するキーワードで、
”タスク管理倉庫”みたいな意味で使われています。
スクラム等でもbacklogというフレーズはよく見かけますね。
そして次の見開きのページを
「Today」「Doing」「Done」
の３つのエリアに分割します。
ー今日やるタスクはTodayにー
「Today」の領域には、今日１日で自分がこなすべきタスクを貼ります。
毎朝「activity backlog」の中から今日やるタスクを選定し、「Today」の領域に
貼り替ていきます。
そしてその日1日は「Today」の領域に貼ったタスクを全て終わらせるべく
仕事をこなしていきます。
ーいま取り掛かっているタスクはDoingにー
Todayの領域のタスクの中から、とりかかるタスクを決め、実行していきます。
その際、選んだそのタスクを「Today」から「Doing」に移します。
ー完了したタスクはDoneにー
そのタスクが完了した時には「Doing」から「Done」に移します。
そして新たに取り組むタスクを「Today」から「Doing」に移していきます。
このようにタスク管理を行っています。
このタスク管理方法では、ポモドーロテクニックも合わせて実施しています。
ポモドーロテクニックを導入することで自身のタスクに関するメトリクスを
集めることができ、業務プロセス改善につなげていくことができます。
なおポモドーロテクニックについては過去のエントリーをご覧ください。
takaaki-z.hatenablog.com
その２：個人KPTボード
私は現在、KPTを用いて個人的な業務プロセス等の改善を行っています。
KPTの具体的な方法についてはググればすぐに出てくるので、
細かい説明は割愛しますが、ざっくりまとめると、
・Keep：今後も続けていきたいこと
・Problem：改善すべきこと
・Try：改善すべきことに対するアクションプラン
を一定期間ごとに振り返っていく方法です。
これをnu boardの見開き１ページを利用して管理しています。
私は１週間という期間でKPTによるふりかえりを行い、
その結果をnu boardに貼り付け管理しています。
そして、これ、Keepを続けていると、
今後も続けていきたい！と思っていたことが自分のアタリマエになってきます。
つまり意識しなくてもそれができるようになってくるわけですね。
そうなった時に、この項目はもはやKeepではなく自分の中でのRuleだ！
ということでRuleの領域を作成し、
アタリマエとなったKeepをRuleの領域に移動させていきます。
※ちなみにホワイトボードのページ以外にも
透明なクリアシートや黒い普通の紙のシートが挟んであり、
それらを活用して見開きのページ数を確保しています。
その３：ホワイトボード
ToDo管理、個人KPTに利用してもまだ見開き２ページ分のスペースが残っています。
ここはそのままホワイトボードとして利用しています。
書いた内容をそのまま残したい、というシーンが少ないので、
個人的には見開き２ページもあればホワイトボードとしては十分です。
どうしても残しておきたい場合には写メを撮って保存しておくようにしています。
全ての項目に当てはまるnu board最大のメリット
上記で紹介した活用法、全てに当てはまるメリットが
持ち運びができる
ということ。
以前は会社でスチレンボードを使ってそれぞれ管理していたのですが、
やはり
・複数の役割を担うことができ
・それらに関する全ての情報を一元化できる
・しかもそれを持ち運びできる
というのがnu boardの最も素晴らしい点かと思います。
最後に
今回はnu boardの個人的な活用方法についてご紹介しましたが、
いかがでしたでしょうか？
他にも「こんな活用法がある！」などなどございましたら
教えていただけると幸いです。
vim上でphp-cs-fixerを実行するときにdry−runでdiffを確認してからfixを実施するための設定方法
はじめに
php−cs−fixerを実行する際、どこがどう変更されるのかを確認してからfixをかけたいですよね。
ターミナルから実行するときはオプションに--diffをつけてやれば問題ありませんが、vim上で実行するときはどうやったら確認できるのでしょうか。
php-cs-fixerのインストール
インストールはこちらを参考にして行いました。
・php-cs-fixerのインストール
https://github.com/FriendsOfPHP/PHP-CS-Fixer
・php-cs-fixerをvim上で実行させるプラグインのインストール
https://github.com/stephpy/vim-php-cs-fixer
vim上でのphp−cs−fixerの動作
実際にvim上でfixerを動かすとこんな感じになります。どこをどう変更してくれるのかがわからないため、若干不安になります。
では、ひとつずつ見ていきましょう。
デフォルトのOption Available
まず、stephpy/vim-php-cs-fixerで指定できるオプションを確認してみると、diffの項目がありません。
" If php-cs-fixer is in $PATH, you don't need to define line below " let g:php_cs_fixer_path = "~/php-cs-fixer.phar" " define the path to the php-cs-fixer.phar let g:php_cs_fixer_level = "symfony" " which level ? let g:php_cs_fixer_config = "default" " configuration "let g:php_cs_fixer_config_file = '.php_cs' " configuration file let g:php_cs_fixer_php_path = "php" " Path to PHP " If you want to define specific fixers: "let g:php_cs_fixer_fixers_list = "linefeed,short_tag,indentation" let g:php_cs_fixer_enable_default_mapping = 1 " Enable the mapping by default (<leader>pcd) let g:php_cs_fixer_dry_run = 0 " Call command with dry-run option let g:php_cs_fixer_verbose = 0 " Return the output of command if 1, else an inline information.
どうやらデフォルトではdiffを有効化して変更箇所の確認を行うことは難しいようです。
なので今回はプラグイン本体に修正を加え、diffの結果を表示できるようにします。
プラグインの変更
プラグイン本体のファイルを確認してみます。
ファイルは~/.vim/bundle/vim-php-cs-fixer/plugin/php-cs-fixer.vimです。
デフォルトでは次のようになっています。
44 if a:dry_run == 1 45 echohl Title | echo "[DRY RUN MODE]" | echohl None 46 let command = command.' --dry-run' 47 endif
今回は一度dry−runを実行し、変更箇所を確認してから、実際にfixをかけるようにしたかったので、dry−run実行時にdiffを一緒に指定しました。実際には以下のように修正を加えます。
44 if a:dry_run == 1 45 echohl Title | echo "[DRY RUN MODE]" | echohl None 46 let command = command.' --dry-run --diff' 47 endif
このように変更を加えた後、オプションのdry_runとverboseの項目を１にしてやればOK。これでvim上からphp−cs−fixerを実行した時に、一度dry−runを走らせ変更箇所を確認したのちに、実際にfixをかけられるようになります。
" If php-cs-fixer is in $PATH, you don't need to define line below " let g:php_cs_fixer_path = "~/php-cs-fixer.phar" " define the path to the php-cs-fixer.phar let g:php_cs_fixer_level = "symfony" " which level ? let g:php_cs_fixer_config = "default" " configuration "let g:php_cs_fixer_config_file = '.php_cs' " configuration file let g:php_cs_fixer_php_path = "php" " Path to PHP " If you want to define specific fixers: "let g:php_cs_fixer_fixers_list = "linefeed,short_tag,indentation" let g:php_cs_fixer_enable_default_mapping = 1 " Enable the mapping by default (<leader>pcd) let g:php_cs_fixer_dry_run = 1 " Call command with dry-run option let g:php_cs_fixer_verbose = 1 " Return the output of command if 1, else an inline information.
修正後のfixerの動作
このようにdry-runを実行したときに具体的な変更箇所（どこをどう変更するのか）を表示してくれるようになります。そしてこの変更でOKであればそのままコードをfixさせます。
注意点
なおこの方法では、diffの結果の表示色は全てオレンジとなってしまいます。ターミナル上でdiffの結果を表示させた時は変更前が赤、変更後は緑、みたいな感じで表示されているので、それに合わせに行きたいところですが、目的は達成されたので一旦ここまでとします。
