2016年の振り返り
2016年の振り返りをします。
ちなみに去年はこんなこと書いていた。 suzan2go.hatenablog.com
2016年の振り返り
仕事で一からサービスを立ち上げた
仕事で1からサービスを立ち上げました。一昨年は既存のサービスを別WEBサイトとして立ち上げるということをしたんですが、本当に全く新しいWEBサービスを立ち上げるのは初めての経験でした。立ち上げまで殆どの期間でエンジニアが自分ひとりだったので、全体のモデル設計、決済関連の実装とか中々経験できないことを経験値として積むことができました。
プロダクト開発について色々考えた
仕様を考えるにあたって、それをやるべきかどうか判断するためのデータも少ない状態で作るのは本当にしんどかった。リーンスタートアップ的な考え方って正直あんまり好きじゃない部分もありました(いやいやちゃんと作れよ…的な)。が、正解が何か殆ど判断できない状態で作り込んでも無駄が多いっていうのは本当に実感したです。実際リリースしてから機能が全く使われない or KPIには寄与しないところを議論しまくって作ってたりとかしてました(たらればも少し入ってるかもしれないけど)。
- ただ、「小さくリリースしていく学習する」ことを掲げるだけではだめで、そうすると「これ大変だから仕様削ろう」みたいな話になりがち
- MVP(Minimum Viable Product)が考えられてないと、本当は優先度が高い機能が削られたり、サービスの立ち上げ時にはさして重要じゃないものに時間を掛けてしまったりする。
- そんで、MVPをチームで考えるときには「解決する課題の仮説」をもっていないといけない。これがないとMVPがふわっとして、結局「競合はやってるからやった方がいい」「過去サービスでこれをやって◯◯が向上した」「◯◯さんはこれやった方がいいと言ってる」みたいな、そりゃやったほうがいいとは思うけど…みたいなことでいっぱいになってしまう。
みたいなことを学んだのでした。
以下のスライドははてブかtwitterで見かけたのですが、何かもう心当たりのあることしかなくてｳｯってなりました。 speakerdeck.com
Reactを沢山つかった
なんかもうReactを使うこと自体は特に珍しいことでも何でもないですが、技術的にはReactをかなり積極的に採用しました。以下の記事にも書いたんだけどrailsとの組み合わせでReactを使うとき、かつwebpackなどを使用してSprocketsを使わない場合にはreact-railsじゃなくて、react_on_railsを使った方が色々捗ると思う。というわけでreact_on_railsを使ったです。
Reactを使ったこと自体には後悔していないんだけど、使い方には後悔があったり。react_on_rails (react-railsでもほぼおなじ)では、以下のようにReactのコンポーネントをERBやSlimに埋め込めるので、普通のrailsのテンプレートとReactを共存させることができますが、これをあんまりやらないほうがよかった。
.hoge
= react_component ‘HogeComponent’, props: { pico: ‘hello' }
.user
= @user.username
既存のサービスならともかく新規のプロダクトでReactを使うなら、全部SPAとまではいかないまでも(実際そこまでの工数は掛けられなかったが…)あるネームスペース配下のURLでは全てSPAにするとか、ヘッダー・フッター以外は全てReactでrenderするとかにするべきだったなと。ReactにしてもReduxにしてもやっぱりSPAを前提にして作られているものだと思うし、上記のような使い方はどうしてもエコシステムに乗り切れない感じがした。
設計について色々考えるようになった
サービス立ち上げとも絡む話ではありますが、設計について色々考えるようになりました。この冬色々話題になったサービスクラス、railsのconcernなど、プログラムのテクニック的な捉え方しかしてなくて設計観点でどうかということは正直意識が低かった。ビジネス要件が大きくなって実装が複雑になっていったときに、どうしてもアプリケーション側のテクニックで何とかしがちだったのですが、あるべきデータの形が何かとか、モデルの責務としてどうかとかそういうことを何となくではなく意識して考えるようになったのでした。その辺りの話は以下のアドベントカレンダーをどうぞ。
今年はDDDとかオブジェクト志向とか改めてちゃんと勉強していきたい。
キャリアについて考えるようになった
まだまだ若手枠のつもりでいたのですが来年30になるということで、気づいたら中堅になってた…そりゃ「どういう方向性に進んでいきます？」ということをよく聞かれるわけやｗ
良いプロダクトを生み出すには技術力だけでは駄目なんだということはよくわかったし、チームで良いパフォーマンスを出していくにはジャーマネ的な動きが大切なのだということがよくわかった一年ではあったものの、やっぱりまだ自分はエンジニアとしてコードを書くことを一番していきたいというのが正直なところ。
去年子供が生まれてライフスタイルが大きく変わった。自分に費やせる時間は圧倒的に減っているので今後の生存戦略を本気で考えないといけない。
2016年を振り返って
正直関わっていたプロジェクトは結構ハードで、良いことばかりではなくどちらかというと反省の方が多いのですが、それでもサービスの立ち上げというものを経験できてよかったと思います。 一昨年はSIerから転職してきて何とかWEBエンジニアとして頑張っていこうというところでしたが、去年はWEBエンジニアとして自分の価値をどう出していくか考えていた一年でした。自分の価値が出せたのかというと結構微妙なところな気はしているので、今年は明確に見える成果を出していきたい。
今年の抱負
雑ですがこんなことことを考えています。
社外の人に会う
去年は社外の勉強会にあまり参加できなかったので参加したいというのと、もっと社外のエンジニアの人と色々話してみたい。いろんな会社のRails Wayを知りたい。そして自分がどんな位置にいるのかを把握していきたい。
機械学習でなにか作る
アドベントカレンダーの以下の記事が割と衝撃的だった。WEBだけやっていても自分の市場価値はもう上がっていかない感が凄いので、色々手を出して行きたいと思います。 qiita.com
React + Redux + Railsのサンプルを色々アップデートした
アップデートしたのはこれ。 react-rails と redux を同時に使うためのサンプルです。
github.com
公開する時期が早かった(2015年の8月)せいか、謎にスターが100個以上ついてる。有難い。 (当時はReduxがまだ流行り始めたころで、Railsと組み合わせて使ってるようなサンプルが無かったから…と思う)
使っているgemは以下。
こんなサンプル作ったけど、仕事ではこの構成で運用してなくて、JS/CSSのビルドとして Sprockets は使わずに、 webpack を使う構成だったりします*1。
browserify 自体の開発がもうあまり活発には行われていないっぽい(さらにrails 5.1 では webpack のサポートが入る*2… )のと、 個人的には react-rails よりも react_on_rails *3 の方が色々都合が良い( HMRがやりやすいとか、コンポーネントをグローバルに置かなくてよいとか、AuthenticityTokenをポストする方法がサポートされているとか )と思っているので、このサンプルの構成自体ちょっと微妙ではあります。
が、react_on_rails の方にはかなりしっかりした Redux を使ったサンプルコードがあるので*4 、 react-rails でうまくやる方法はまだ一定需要があるかなと思い、色々アップデートしてみました。
Railsを4.2から5.0.0.1に上げた
ほぼ中身のアプリケーションがないということもあるけど、何も困らずに上げられました。特筆することも特に無いｗ
テストを追加した
こんなIssueを貰っていたので、テストを追加してみた。 github.com
E2Eのテスト
普通にcapybaraとseleniumで。仕事でもハマったのですが、 firefoxの47以下でないとselenium-webdriverが動きません。。以下、 capybara の公式より引用です(2016年12月18日現在)。
Note: Firefox 48+ If you're using Firefox with selenium-webdriver and want full functionality stay on either Firefox 45.0esr or 47.0.1. If using selenium-webdriver 3.0+ this will require configuring your driver with the marionette: false option as shown below
本当は Poltergeist のようなヘッドレスブラウザの方が良さげですが、それそれでハマりそうだったので一旦仕事でも実績のある構成にしました。
JS単体のテスト
正直、テストのライブラリだけでも色々あって何が良いとか全然わからないのですが、過去ちょっと触ったことがあって今も流行ってるっぽい enzyme で書きました。
github.com
JSDOMを使ったテストのセットアップはほぼ以下を参考にしています。
github.com
正直、ESEのテストがあればJS単体のテストってそこまでいらない気もするのですが、どうなんですかね。オートコンプリートとか割と複雑なコンポーネントを自分で書いた場合には確かに欲しい気もしますけど…フルSPAとか書いたりするとコンポーネント毎のテストが欲しくなったりするのだろうか。
サンプルとしてはかなりシンプルなので(Redux公式のカウンターアプリそのまま)、もうちょっと色々肉付けしたい感ある。 仕事で使った時便利だったRedux Formとかそういったライブラリも混ぜて、もうちょいリアルなアプリケーションにしていこうかな。
【その「エンジニア採用」が不幸を生む】を読んだ
その「エンジニア採用」が不幸を呼ぶ という本を読みました。
その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?
- 作者: 正道寺雅信
- 出版社/メーカー: 技術評論社
- 発売日: 2016/12/07
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
何故読んだのか
ブログやtwitterで見かけたので。 Rubyエンジニアの採用戦略について話した - pblog
自分は会社で採用に関わる立場ではないのですが、今後のキャリアとかちょっと考えるきっかけになったりするかなと思い、買ってみました。 (結論からいうと、そういう観点ではそこまで参考になる部分はなかった)
感想
いくつか印象に残った点をメモ。
経営課題をエンジニア採用で解決しようとする落とし穴/エンジニアの募集要項が書けない人事
えーこんなひどい経営者/人事いるのか・・・という感想です。目的はないけど100人エンジニア採用しようとする、「よくわからんけどクラウドサービス作りたい」でよく分からんままエンジニア雇っちゃう経営者とか、エンジニア募集要項のよくわからないところを勝手に削っちゃう人事…とか。自分のいる環境って結構恵まれてるんだなと思いましたw
現職エンジニア、転職時の希望職種は「特にこだわらない」が50%
えーこれは本当にそうなのかーって思いました。少なくとも自分の観測範囲にはいなかったなぁ。 自分がSEやってたとき「SEやめてー」はよく思ったけど、すくなくともエンジニアではいたかったので。
エンジニアを2つのタイプ、4つのグループで分類する
自由な開発環境(タイプA)と、ガバナンス優先の開発環境(タイプB)という2つのタイプ、技術×志向×経験でレベル分けした1〜４までのグループの組み合わせ8つのセグメントにエンジニアを分類して採用を考えましょう、というお話でした。これ、最近よく聞くようになった SoR/SoE とかも絡んでくる話な気がします。
20代の開発経験がタイプAとタイプBのどちらかになるかに大きく影響するとあって、自分はどっちなんだろうと思いました。 タイプBの開発環境にいた期間は長いですが、それにフラストレーションがたまって転職したところはあるので、現在でいうとかなりタイプAだと思われる。でもタイプB的なところを最近評価されることが多い気もするので、どっちとも言えない。
優秀なエンジニアはSNSつながりで転職する
何となくそうだろうなとは思ってましたがやっぱりそうなんだなという感じ。でも、人材サービス会社経由で見つけるのが難しくなっているレベルだとは思わなかったです。自分もSIerから転職するときにはリクナビやら◯◯ナビ系にはいくつか登録しましたが、いま転職するとしたらきっと登録しないだろうな(自分が優秀かどうかはさておきｗ)。
久しぶりにブログ書いた。本を読む熱が上がってきてるので、また読んで書こう。 次はじょーかーさんのqiitaで読めって言われてた以下の本を読もう。
オブジェクト指向設計実践ガイド ?Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
- 作者: Sandi Metz
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/02
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
2015年の振り返り
2015年を振り返ります。去年のはじめにブログを毎週更新するとか書いた気がするが忘れる。
今年の個人的に重大な出来事
転職した
某メーカーのSEから、5月にWeb系のベンチャーへ転職しました。2015年の2月に内定をもらったのですが、当時は趣味で作ったWebサイト/nodewebkitアプリと仕事で社内向けの管理アプリを作った程度(しかも自分一人で作った簡単な奴)で、今思えばエンジニアとしては結構ウンコな感じでしたｗ
実際、色々Web系の会社に応募しても書類は通れど…という感じだったし、ぶっちゃけ自分自身本当にWebエンジニアとしてやっていけるのかどうか不安もかなりありました。せっかく二次面接まで進んだのに「やっていけますかね…？」的な質問を沢山してたら、「モチベーションに不安がある」という理由で落とされたこともあります。今の会社に入れたのもやる気とかガッツを見せたからだと思うので、スキルがなくてもやる気を見せるのは結構大事だと思います(実際、落とされた会社では、その後元営業からエンジニアになった人もいたようだし)。拾ってくれてありがとう今の会社。
入社後の話。大規模なRailsのソースを見るのは初めてだったので、とにかく最初は色んなソースコードを読んだり、他の人のPRレビューを見て、こういう書き方は駄目/良いというのをとにかく盗んでました。今思えばもっと他の人に聞けばよかったんですけどね。「え…こいつこんなことも知らんのかよ…」みたいに思われたらどうしようという恐怖があったような気がします。ただそのおかげでコードを読む力は大分身についた気がする。年代の近いエンジニアが多かったのにも助けられました。あと某フリーランスでスーパーなエンジニアの仕事を間近で見られたのは本当に良かったです。
仕事で自分で1からWebアプリケーションを作った
3ヶ月くらいは既存サービスの機能改修や機能追加をやっていたんですが、8月に1からWEBサイトを構築するプロジェクトに参加しました。マネージャー的な人が一人、手を動かす人は自分含め2人で納期1ヶ月とかだったんでまじかよ…と最初は思ってましたが、今思うと本当に良い経験を積ませてもらったなと思います。認証回りとか1からやらないと触る機会ほとんどないですし。Javascript回りで会社の中でも新しい挑戦ができたのはよかった。
reduxはこれ書いた8月当時にまだ1.0rcとかだったんで全然日本語の情報が無かったんですが、そのおかげでGitHubのIssueあさったりソース読んで理解するしかなかったのでJS力が結構上がった気がする。(時間的な制約もありぶっちゃけ使う機会はあまりなかったのですが…)
あと裏側で他のクラウドサービスとAPI連携する部分を、仕様と実装含めて全部自分でやれたのがとても良かった。今思うともっといい実装に出来たのですが、そういう思考に辿り着いたのも一回自分でやったおかげです。
子供が生まれた
12月の終わりに子供が生まれました。マジかわいい。天使。 でも時間の使い方を今までよりもっと考えなければいけないなと感じます。お家に来て4日目、大分よく寝てくれるようになりましたが、オムツ替え・おっぱい・ぐずるので抱っこ、で一日終わることもありそう…
OSSに貢献した
これも12月の終わりの話ですが、初めてOSSに貢献しました。趣味開発中にたまたま見つけたバグで、原因をさぐり他のライブラリでどんな風に修正してるか探して、英語でビクビクしながらPR。Railsのデフォルトconfig変更により、落ちるようになってしまったテストもついでに直しました。
英語でやりとりしなくて済むようにさっとマージしてもらえることを期待してたのですが、色々とツッコミが入り(しかも相手のツッコミが微妙に間違ってる)ビビりました。が、意外と何とかなるもんで英語で色々と説明して、修正して無事マージしてもらうことが出来ました。
マージしてもらったことも嬉しかったですが、そのバグで結構困ってる人がいたようで「Awesome!」「Thank you.」「Thank you!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! So many hours searching for this.」などと言ってもらえたのが嬉しかった。
意外となんとかなることがわかったので今年はもっとOSSにPRを出そうと思います。あとエッジなものを使うと色んなバグを踏めてPRチャンスが生まれることがわかったので、今後は少なくとも趣味開発ではエッジなものをガリガリ使っていきたい(エッチなものではない)。
まとめ
去年は転職とか色々なことがあって、密度が異様に濃い1年でした。RubyやJS力はかなりあがったので、次はインフラにも強くなりたいところ。
あとはOSSとかQiitaとかアウトプットを増やしていきたい。他社のエンジニアにもほんの少しは認知されるような存在になれたらいいな。
SIerからWeb系に転職して半年。転職前にやっといてよかったなぁと思ったこと
SIerから自社Webサービスをやってる会社に転職して半年たったのでまとめる。本当は試用期間が終わったころに書こうと思っていたのに、すっかり忘れてました。。。
SIerでは仮想化のインフラエンジニアっぽいことしてました。いまはRubyの会社でRails触ったりReact触ったりしています。
以下は、これをやっておくと転職のときに有利…とかいうものではなく、転職後になってやっておいてよかったなと思ったことですので注意。
やっておいてよかったなと思ったこと
Gitの使い方を覚えておく
Gitは普通に使いますし、Gitが全く使えないと開発に参加するところから大変です。
当然、仮想化のインフラエンジニアなんてやってたのでGitなんて全然仕事では触ってませんでしたが、趣味の自分一人の開発でも更新はGitHubでプルリクエストを送りセルフマージする感じにして慣れるようにしてました。
以下の本では、なんと実際のレポジトリにプルリクエストを送ることができますし、GitHubだけではなくGitの基本的な使い方を教えてくれるのでお勧めです！
http://www.amazon.co.jp/GitHub実践入門-~Pull-Requestによる開発の変革-PRESS-plus/dp/477416366Xwww.amazon.co.jp
ちなみに会社でGitHubを使ってアプリ開発をする場合は、レポジトリをforkではなくブランチを分けて開発をしています。
以下の記事の様な感じです。blog.qnyp.com
リーダブルコードを読んでおく
「他の人にも読みやすいコード」とはどんなコードなのか、何となくでしか分かっていなかったことを順序立てて説明してくれます。特に自分のようにコードレビューをする・される経験が殆どなかった人にはオススメです。www.amazon.co.jp
自分でWebサービス・プロダクトを作って公開してみる
これが一番ためになってます。一からWebサービス(自分の場合はWebサービスではありませんでしたが…)を作ると、インフラからアプリまで一通りのことが経験出来ます。そして何かを作ろうとすると、チュートリアルや初心者向けの解説では書いてなかったようなことを自分で調べたり、考えたりする必要が出てくるので、只々勉強するよりも遥かに身につきます。
何も作りたいものが思いつかない…という人は、自分のためのブログやサイトを作ってみたり、友達から案をもらったりするのも良いかもしれません。自分の場合は、知人のイラストレーターさんのサイトリニューアルをやらせてもらいました。
このときに学んだHerokuやAWSの知識は結構今でも役に立っています。suzan2go.hatenablog.com
Webサービスではないのですが、こんなのも作ってました。今見ると割と糞コードなのですが、このブログ書いた時にはそこそこ色んな人が見てくれて、スタートアップのCEO?とかそんな感じの人から使ってます！とtwitterで言われたのは嬉しかった。趣味で開発してるとモチベーションが中々続かないものですが、公開して何かリアクションがあるとメチャメチャやる気がでますのでオススメ。suzan2go.hatenablog.com
React + Electronで書き直そそうとしてるのですがストップ中…
suzan2go/redelectron · GitHub
やっておいてよかったなと思ったこと(Rubyの会社に行く人向け)
以下からはRuby(というかRails)で開発をしている会社に転職する人向けです。
(しつこいですが、これをやっておくと転職のときに有利…とかいうものではなく、転職後になってやっておいてよかったなと思ったことです)
Rails チュートリアルをやっておく
このチュートリアルのいいところは、単純にRailsだけではなくてGitの使い方とか、どんなふうにテストコードを書けばいいかなど、実際の開発でやるようなことを一通り流れにそって経験できることです。特にテストコードをどんなふうにかけばいいかって、経験がないとあまりピンとこないところだと思います。自分はこのチュートリアルで初めてテストコード書いて、テストをどんなふうに書くのか理解することができました。railstutorial.jp
Rubyの資格に挑戦しておく
資格なんてとっても…と思うかもしれませんが、単に文法だけではなくRubyがどんな仕様の言語になっているかを体系的に学ぶ良い機会になりました！単に文法的なところは都度調べるでも良いかと思いますが、そもそも知らないと「こんな書き方できるの！！」となるようなものがRubyにはたくさんありますし、色んなものがオブジェクトだったり、既存のクラスが拡張できたりする言語仕様は学んでおいて本当に良かったなと思ってます。suzan2go.hatenablog.com
やっときゃよかったなと思ったこと
以下は、自分がやっときゃよかったなと思ったことです。
こちらもRubyやRailsを使う会社に行く人向けです。
Railsガイドを読んでおく
これをいきなり読んでも頭に入らないと思うので、Railsチュートリアルをやったあととか少し慣れてきた後がオススメです。railsguides.jp
Active Support コア拡張機能の章だけでも読んでおくと良いかも。tryとかpresent?とかよく使います。
Active Support コア拡張機能 | Rails ガイド
Style Guideを読んでおく
以下適当にググッて出てきたものを張りました。会社によってはスタイルガイドを公開してたりもするので、確認してみると良いと思います。github.com
github.com
特定のページを読み込んだときにアラートをだすchrome拡張を作った？
本番環境で間違えて開発環境でやるような操作をしてしまいそうになった／してしまったことはないでしょうか。ブラウザから何かの登録とか削除とか…
普段から注意することはもちろんですが、技術的に解決できるのではと思い特定のページにいったときにアラートを出すchrome拡張を作りました。と言えるのか分からんくらい簡単にできました。というかチュートリアルとかで全く同じことやってそうだ。。。github.com
対象のURLはmanifest.jsonで、対象のメッセージはscript.jsを変更すればOKです。
設定ができたら、chromeからmanifest.jsonを読み込みましょう。
デベロッパーモードにチェックをいれて・・・
パッケージ化されていない拡張機能を読み込む、を選択し、manifest.jsonが格納されたディレクトリを指定します。
するとmanifest.jsonで指定したページを読み込むと、アラートが表示されます。
manifest.jsonやscript.jsを更新した場合は、拡張機能のリロードが必要です。
気合いれて作ろうと思ったら、最初に調べたことで全部出来てしまった…
今回はmanifest.jsonやscript.jsを直接弄ってますが、chrome側でURLやアラートメッセージを設定できそうなので気が向いたら作ってみます。
chrome拡張何となく難しいイメージあったけど、結構お手軽に色々出来そうなので何か作ってみようかなーと思ったのでした。
IKEAで買った家具を2年で処分してしまった
転職前の有給休暇を利用して大体2年前に買ったIKEAの家具(ベッド、ワードローブ)を処分しました。
売ることも考えたけど、分解しなきゃいけないとか、そもそも値段つかないとかだったので、業者に頼んで持って行ってもらいました。
捨てたもの
買ったときのものが見つけられなかったので似たようなものを。値段はこれよりも安かったと思います。www.ikea.com
www.ikea.com
何で捨てたのか
色々ありますが、一番の理由は奥さんとの2人暮らし賃貸には少々サイズがデカ過ぎたことですかね。今後家族が増えた時のスペースが確保できないということで、今回処分しました。
2年で処分は本当にもったいないことしたなと思ってる。2年前住んでた家はクローゼットなかったので仕方なかった面もあるけど、当時新婚ということもあり少々舞い上がってたなーと反省してます。
IKEAの家具で後悔したこと。
家具自体は結構気に入っていたんですけどね。
お店でみるよりでかい
上にも書きましたがIKEAの家具はお店で見るとなんかちょうどいいサイズに思えますけど、実際に家で組み立てるとマジででかい。お店で見た時の1.5倍くらいに感じます。特にワードローブは背が高いので、部屋におくとかなり圧迫感ありました(処分したあと、この部屋こんなに広かったっけ？？となった)。幅とか奥行きは当然買うときに気にしてましたが、高さはあんまり考えてなかったなーと反省。
重い
日本の同じサイズの家具の2倍は言い過ぎかもしれないですけど、本当に重いです。IKEAは基本自分で組み立てですが、運送業者さんが持ってきた板を設置する部屋に持っていくのだけでも本当に大変だったのを覚えてます。組み立て手順自体は簡単なものですけど、マジで重いので一人暮らしの女性とか非力な男性で大型の家具かっちゃうとホント大変ですよ！
引っ越しのとき大変
IKEAの家具は引越し業者に嫌な顔されますねｗ重すぎるのでそのまま持っていくことができず、分解して再組み立てすることになるので。引越し業者によって対応分かれますが、以下のパターンでした。
- IKEAの家具は拒否される。別途指定の家具業者に頼んで、分解・組み立てが必要(+5万とかだった)。
- 引っ越し中に破損しても責任はとれないことに同意できれば、分解して持って行ってもらえる。組み立てもやってくれる。
自分は安く済ませたかったので、引越し業者に分解・組み立てまで全て頼みました。組立自体はしっかりやってくれましたが、釘とか使ってる箇所があるので強度は触って分かる程度に弱くなります。地震とかで壊れて重い板が倒れてきたりしたら怖いなーというのも今回処分した理由の１つだったり。(引越し業者も分解が二回目のIKEA家具だとかなり柔くなったと言ってました）
