成長が止まらない、torchの期待のエース、たっくんの活躍を心待ちにしていた、150,000,000人のたっくんファンの皆様、ご無沙汰しております。Yas（うつぼ）です、こんにちは。

冷静と情熱の狭間

さて、テストリリースを無事に終えた。たっくんでした。意気揚々と湯治に向かい存分にリフレッシュして帰ってきたようです。さて、頭も気持ちもリセットして、第2ラウンドの始まり！なのですが……。

開発者と利用者の感覚の違いに少し悩むことになります。

開発者という肩書を持ったことがある方なら、この感覚には同意できるかもしれません。自分の作った機能を客観視するのが難しいというか、多角的にものを見るのが難しいというか。偏執的になってしまうというか。どうしても色眼鏡をかけて見てしまうというものです。

フィードバックにお願い！

torchの良いところは、アプリをリリースすると触ってくれる人がいるという環境です。今回も色々な方がテストしてくださいました。

本当に有難い限りなんですが、フィードバックの内容によっては、たっくんにとって理解し難いものもあったでしょう。僕は、ここに関しては自分の針路を定める必要が常にあると思っています。このバグはすぐにやるべき、後回しでもOKみたいなトリアージを現場ではよくすると思います。これが出来るようになるためには、直してみるという経験値が蓄積されないといけないはずです。

なので、torchの中では（いや、たっくんには）、

「全部、修正だよ。全部！」

という風に言ってたりします。修正をすると自分のコードの構造体を冷静に見つめる機会にもなります。コードを眺めていると、色々な感情が沸き起こってきます。喜怒哀楽、それこそその全てが降りかかってきたりします。その感情こそが次のリファクタリングやらのモチベーションだと僕は考えています。なので、不条理でもとりあえず突っ込んでみるというのは、自身の経験の幅をかなり広げてくれることなので、愚痴も言わずに取り組んでいる、たっくんは本当に偉いとお父さんは思うわけです。

リファクタリングするってよー！

バグを直すタイミングで、テストさえ、きちんと書けば必要だと思う部分は書きなおしてもいいよと。テストを書けばというのがポイントですが、これやらないと再現性がなくなっちゃうので。ここはサボらずにやるという約束で、リファクタリングしていいよ！という事になりました。

実際は、

テスト書く　→　バグ直す　→　リファクタリングする　→　テスト通す

という工程を踏んでいるので、壮大な遠回りはしている感覚はあるのですが。これも経験です。

Yasとリファクタリング

個人的にリファクタリングはするべきだと思っています。工程に組み込まにゃいかん！とかいう宗教論争に巻き込まれたくないので、あまり詳しくは言及しませんが。リファクタリングをしないのは、寝間着で外出するみたいな感覚が僕にはあります。裸で出社するでも良いですけど……。要するにダサいんですよね。パターンやらアルゴリズム的に完璧で無駄なく美しい……というのも好きですけど、そういう格好良さではなくて、拡張性が乏しいとか、共通化できるところをほったらかしにしておくことで後からの巻き戻しや揺り戻しの工数が膨れ上がるのが耐えられない。というのがビジネス的な言い分ですけど、個人的にはもっと低レベルで、僕がコピペするのが大の苦手でコピペで量産すると絶対に失敗するから無理！ってのが実はあります。（実はこれ多いんじゃないかなーと思っている）

メンテナンスリリース

要するにBugを修正しましたというリリースのことです。綺麗にお化粧しなおして、コードもダイエットして無事、メンテナンス・リリースも迎えることが出来ました。が、コードを書く以外にも重要な事があるよね？っていう話を、たっくんにしました。それは、ドキュメントです。

ドキュメント、忌み嫌われしもの

開発者にドキュメントを書こうぜ！といって、はい分かりました！！とニコニコで受けてくれる人には、ほぼ皆無なんじゃないでしょうか……。中には文章を作るのが大好きで、ドキュメントを書くのが楽しい！って人もいましたが、それはそれで稀有だと思っています。

要するに、嫌われ者なわけです。ドキュメント。たくさん書いても読まれないし、無いと怒られるし、動画にしようと思うとそれはそれで面倒だし。

書きたくない理由なんて、500,000,000個は出てくるもの。それがドキュメントですよね。

僕も、仕事じゃないなら書きたくないと思っている派なので、ご多分には漏れていないです。

それでも、ドキュメントって大事だぜ！

どうやって使うの？
何が良くなったの？
何が追加されたの？

当たり前の疑問に答えるのが、ドキュメントなので。Change Logを作るという形で、たっくんはドキュメントに向き合うことになります。

開発案件は１チケットの形で表現されており、チケットの中の必要項目をすべて記入して、証跡としてのビデオくっつけとけばChange Logとして機能すべきだ。この理想をたっくんに伝え、考えてもらいました。

そんなこと言われても！？みたいな話を僕は平気でふるので、それに返答ができるたっくんは本当に優秀だなと思います。もしくは、僕に対する傾向と対策が大分と出来てきたのかもしれませんね。

Trelloでいきましょう

Trelloで良さそうじゃないですか？ここ上手に使えませんか？

毎度おなじみのたっくんの神質問がやってまいります。本当に、天才だと思いました。おじさん世代だと、TracとかRedmineとか言いがちですね……。でも、この類のツールは星の数ほどあるのでなんでも良いとは思っています。プロジェクトで果たすべき要件がそろっていればいいので。

そういう意味では、タスクの管理にも使えてそれをそのまま公開してしまうというのは一石二鳥でよいなぁと思ったので、その意見を全面採用して、もう１つ公開用のボードを作り、そこにChangeLogを公開するようにしてみました。移動もサクッとできるし、これ、実は結構らくちんだなと気に入っています。

さぁ、次は機能設計してみるか！

たっくんも、保守・運用のイロハのイぐらいは学べたので、今度は工程的には上流と呼ばれる工程にチャレンジです。

ＤＡＯが活動するために必要な機能群の設計をしてほしい

という無茶ぶりが、次のたっくんのミッションです。とりあえず、僕とか、てんてんにはヒアリングしてね！って話はしているので、何を聞いてくるのかは楽しみです。さぁ、どうなることやら、また次回に期待ですね！

アプリ開発をするエンジニアになりませんか？

エンジニアになる最短の道のりは、分かっている人に教えてもらいながら作る方式が最適です。Makunouchi DAOでは、アプリを実際に創っていきながらエンジニアとして生きていくための心構えや、必要な技能を伝えています。教えることはしません、伝えるだけです。それに基づいて調べて、自分でやってみて、Yas（うつぼ）がフィードバックをします。このフィードバックに基づいて、また調べるというサイクルがエンジニアを育てる上で一番大事だと思っています。近道はありません、3か月で1人前にもなりません。1年かけてじっくりと育ってください。学び直ししたい、挫折したけどチャレンジしたい方は、こちらからご参加ください。1年間のメンバーシップとなっています。

法人様、企業様からのエンジニアの新人研修の依頼も承っております。それ以外にも、お話を聞いてみたい方、torchのTwtitterをフォローして、DMを送ってください。詳しくお話させていただきます。