プログラミングキャリアなしのメンバーばかりと自分のチームでObjectiveCからSwiftへ移行したことについての日記

弊グループアドベントカレンダーの記事ですが本日最終出社を迎えますshishiです。

www.adventar.org

前置き

  • これは日記です
  • 技術的な詳細の話はしない
  • 特にためになりそうなことは書いてない

経緯

4月に入社。入社がそもそも紹介で、とある仕事のために僕が必要ということで誘われて入社したものの入社したときにその仕事はなくなってしまっていた。さて何をしたものかと思っていたらやったことないObjectiveCからやったことないSwiftへの移行プロジェクトをすることになった。なお僕個人は別の1人プロジェクトもやっている状態。

メンバー

私自身はRubyPHPPerl、あとは趣味で雑多に色々とやってきたプログラマー。開発リードをすることに。

実はもともとタイトルのような大変な感じのプロジェクトではなく、プロジェクトの話が出た頃にはObjectiveC版をメンテナンスしていた数人と一緒にやるはずだった。しかし、いざ始めましょうかという段取りになると不思議な力でもともとメンテナンスしていた人達が全員別プロジェクト(地理的にも別、アドバイスを求めることも諸事情で難しい状態に)へ行くことに。残ったのは新卒(プログラミング経験あり)2人、プログラマーへキャリアチェンジしたばかりの1人(プログラミング経験無し)と私。全員ObjectiveCもSwiftも経験無しというなんともワイルドな感じになる。

プロジェクトを始めた後にさすがになんともならんということで僕を弊社に誘った張本人の1人(Java、Groovyプログラマー)と、その人と一緒に別の仕事をすることになっていたプログラマーへキャリアチェンジしたばかりのもう1人(プログラミング経験無し)を引きずり込み、自分のツテでObjectiveCもSwiftもできるフリーランスiOSアプリケーションプログラマを1人業務委託で連れてくることに成功し最終的なメンバー構成に。

プロジェクトでやりたかったこと

  • アプリケーション自体はビュー数も多くなく、自社サーバーに用意されたAPIを利用してほげほげな操作をする。詳細は不思議な力で書けない。
  • 今後のメンテナンスを考えたObjectiveCからSwiftへの移行。移行すること自体が第一の目的。
  • アプリケーションの画面デザインを全画面変更。ビューの構成要素自体はあまり変わらないが見た目的なものはほぼ変わる。
  • 予定期間は4ヶ月強

やってきたこと

プロジェクト開始前の私が入社してすぐぐらいはメンバー達にプログラミング基礎教育をしていた。言語としてはRubyを使い、数冊のRubyの本を輪読したり、Railsチュートリアルを2週したり。この輪読は色んな所で好評なので興味があったらまた会ったときにでも聞いてみて欲しい。なのでメンバーは大きくパラダイムが変わるのでない限り、なんとなく書いてあることは理解できるぐらいだったと思う。僕自身はSwiftのチュートリアルや入門書をいくつか済ませておいた。ObjectiveCについてはなんとなく読めればいいや以上の学習はしていない。 メンバーにはさらっと文法だけでも理解しといてね、と自習する時間をとってもらった。

言語移行に際して段階的にObjectiveCのコードにSwiftを混ぜていくか一気に作り直すかという方法があり、一気にやったほうが良いのではと思い友人数名に相談してみたところ、ほぼ一気にやったほうが良いという返事をもらったのでSwift新規プロジェクトを作り直すことに。

ObjectiveC版のコードはまさに秘伝のソース状態。やはりプログラマーとしては移行したついでに綺麗に直してやるぜぐらいは思っていたんだけども、これを直せるようメンバーを教育しながら移行していくことは無理だと判断。移行するという目的自体を第一に優先すべく、分からない部分はとりあえず動くという状態のままSwiftコードへとしていこうということにした。この当時は新デザイン案もまだまだ固まっていないことも合わせて、既存の画面デザインのままとにかくSwiftへとコードを移すことを優先した。この先何が間に合わなかったとしても第一の目的だけはという感じ。

この「とりあえず移行しよう」を優先したときに付け加えたことは2つあり、一つはStoryboardをビューごとに分割すること。これは人間が自分で内容を管理するものではなく、生成されたものを受け入れるしかないのが基本のXMLにも関わらずアプリケーション全体で一つの状態であったので、これからの移植、チームでのメンテナンスの際にさすがに看過できないデメリットになると判断したためによる。もうひとつはデーターベースアクセス、及びモデルとして定義されている部分についてユニットテストを書くこと。ほとんどのロジックはコントローラーに書かれており、ちゃんと分割されているわけではなかったので効果としてそれほどのものは得られないだろうということは予測できたが最低限自動的に誤りが見つけられるようにということと、後々テストを全体に整備できるようにするための教育含み。あとは多々ある言語の機能の違いをどうするかというのは早い段階で話し合って決めた。(letやvar, StringとNSStringなど)

移行する単位は画面ごととした。いろいろな画面で使われている共通メソッドみたいなものもあるが、担当した画面に関係のないものは一切無視して構わないことにした。区切りを分かりやすくしたかったこと、画面をつなげて動かすことを優先したかったこと、移行元に不要なコードが多く予想できたので切れるコードは早期に切りたかったことによる。割りと機械的にであればこの程度の学習量でも進まないことはないなと思った。とはいえ当たり前ながら機械的な移植では動作が変わってしまうことは多くあり、その際には仕様を維持できるように相談して実装していた。ついでに実装がまともに近づくことになったのでこのある程度考えるプロセスがあったのも結果的に見れば良かったのだと思う。

メンバーみんなでうんうん唸りながら数画面移植できてきたところで、上記の唯一まともにプロジェクトに必要な技量を持つプログラマーである友人が参加してくれたので、そこから開発が加速した。言語の文化、常識を聞いてメンバーの作業も早くなり、彼本人の作業もあって移植が進むようになった。まさに救世主状態。

移行作業中にはライブラリ管理をやり直したり、非推奨メソッドを代替してみたら動作が変わって大変なことになったりとそれはもうみんな困ったのだがそこはまたいずれ。

そのまま期間の大半を移植に当て、それっぽくアプリケーション全体を動かせるようになったところでコード行数を計測したときは不要なコードの多さと言語を替えたことによる圧縮効果が凄まじく、30%程度になっていたと思う。

単純にコードを移し替える上記の移植がだいたい終わったところで画面デザインの変更に取り掛かったのだけども、こちらのデザインの人もスマホアプリのデザイン初挑戦という方とうこともあり、テイストを崩さないように、かつ開発のやりやすいようにだいぶいろいろとデザインを一緒に試行錯誤させてもらった。

実際にその新デザインをStoryboardに当てていく際にはだいたいのメンバーがつらい移植を乗りこえてきただけあり、スムーズにデザインの変更を当てていくことができた。これは私自身が思っていたよりメンバーが成長したなと思った部分だった。デザインの移行が早かったこともあり、この時点で全体にUIテストを書くことができた。なおこのUIテストはそもそもテストフレームワーク自体がものすごく不安定で遅く、ここまでの開発で積もり積もったXcodeへの憎しみが倍増するきっかけとなった。

今回はありがたいことに外部からQA用人員を呼んで良かったので、だいたいデザインが当てられた頃から細かい動作検証をしてもらえた。開発者テストさえ上記のように十分ではなかったこともあり、このQAがなかったらどんなひどいアプリケーションができていたか…

メンバーへ思うこと

実際プログラミングを学習し始めるには既に動いているアプリケーションの一部を改修していき、小さいところからより広げていくのが一般的な気がしているけども、今回は会社の都合とはいえハードなことをメンバーに課すことになってしまったと思う。できた教育も十分ではなく、終始OJTできつかったと思うが、1人も抜ける人なくリリースできて良かったと思う。

教える時間が十分ではなかったので一つ一つの知識を教えても覚えられないと思い、できるだけ考え方を終始伝え、そこからどうすれば良いんじゃないかと教えた。我田引水すれば長期的には考え方が大事で知識は都度覚えていけば良いものであると思うので、それが今後役に立てば良いなあと思う。

これから

本当はもっと整理して書くつもりだったんだけど書いてるうちにいろいろ思い出して完全に日記になってしまった。まあこういう変なのがアドベントカレンダーに紛れててもいいかと思いそのままにする。

このブログは12/2に予約公開設定してある。公開する頃にはもうアプリケーションは僕の手を離れているはず。十分にやりきれないことはあったけどもメンバーの努力で制限の多い中最上のものになったと思う。移植を通して未経験ばかりだったメンバーは大きく成長したし、リファクタリングの順序や方針、Realmへの移行等々直すべきことの方針は共有してあるし、これから今までの苦労を次にメンテナンスする人達に被せないようにする作業を通してアプリケーションがずっと良くなっていくことと思う。

なお冒頭の通り私は12月で退職する運びとなっている。しばらくフリーランスとして過ごす予定です。近い将来タイムゾーンがずれるリモートワークでも良いという条件でお仕事あればぜひご連絡ください!

カンバンによるアジャイルプロジェクトマネジメントを読んだ

今すぐ実践!  カンバンによるアジャイルプロジェクトマネジメント

今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント

監訳者長沢さんより本書を頂いて読んだ。

最近にわかに「カンバン」という単語を久しぶりによく聞くようになったと思っていたら、立て続けにいくつかの本が出版されている。単純に以前に見える化を主な目的としていたプラクティスではなく、ワークフローになって帰ってきたらしい。

本書はたぶん大体の人が思うより薄く、目的や概念の解説があまりなく、主に実践について並べられた本である。1章のタイトルが「経営陣の同意を得る」というのもとても実践的であることを感じさせる。本当にそのままというわけにはいかないが、考え方としては普遍的なものだった。他にも開発チームとして組織でどう生きていくか、という視点からの章立て、内容が書かれており、共感しつつ読むことができる人も多いと思う。

本書のタイトルにもあるアジャイル開発という概念は少なくとも欧米においては多数的な開発思想であり、スクラムやらカンバンやら、アジャイル開発のための実践方法が模索されている。スクラムはしっかりしたフレームワークであるが、今までアジャイル開発という考え方になじまない人達には覚えるべき単語やプラクティスが多すぎてなじまないことがあるし、より覚えることやプラクティスを減らし、洗練させようとしてカンバンというワークフローになったのではないかと本書を読んで思った。

スクラムにしてもカンバンにしてもどんな実践方法でも、どこかの方法が全部そのまま他の組織にも適用できるなんてことはないと思っていて、多少は変形するものであると思うんだけど、本書の中で「分析」というフローと「開発」というフローに分かれていることはどうしても納得できなかった。WIP制限に引っかかった場合などに手伝いに行くなど柔軟に対応するということは記述されていたが、多角的な能力を持つ人達の前提があるなら、自分で分析し、自分で実装すべきだと思う。そんな間違いの入りやすい箇所を分断すべきではないと思った。

とはいえ、これは一つの会社での話であり、大元の考え方がズレていなければなんとでもしてよいものであるはずだし、メトリクスの取り方、計算方法などもシートごと公開されているのでいろいろな方法を計測して自分たちに合うものを採用できるようにしてくれている、カンバンに偽りのない本である。スクラムはやることが多すぎてイマイチという方や、カンバンって聞いたことあるけどどうやるのかって興味のある方は本書のターゲットではないかなと思う。

仕事は楽しいかね?を読んだ

仕事は楽しいかね?

仕事は楽しいかね?

本書は5、6年前には読んだことがあったが、転職を機に再読してみた。

超著名と言える知名度のあるビジネス系啓発書。過去に起業するも失敗して、現在も仕事に満足の行かないビジネスマンに対し著名なアドバイザーである老人がアドバイスをする体で話が進む。本の内容についてはいくらでも解説してくれるサイトはあるだろう。

この本を読んで再度確認したのは「計画は失敗すること」「試行することの大事さ」である。

なぜか毎回はかれもしない未来を正確に見積らせようとする愚についての例はあとを絶たないけど、なぜ「未来ははかれない」ということを学んでくれないかをいつも不思議に思っている。人がかなり正しく予想できるのはせいぜい数日以内のことであることは体験としても例を上げても分かることだと思うし、不確実性コーンという初期計画はそもそも大幅にずれるというデータだってあるというのになぜか最初からキッチリ計画したがる。KPIがどうこうとデータの大事さを訴える人達の中にもそういう人達は多くいる。こちらは信用できないということだろうか。

試行することの大事さはスクラムやリーンにも通じていると思う。小さく思考し、フィードバックを得て改善することを繰り返す。そしてこれはまた「計画は失敗すること」に通じている。大きな計画は失敗することを前提に、かなり正確に見積もれる数日の範囲で何度も計画し実行し続けるのである。スクラムやリーンという方法論にまで言及しなくても、失敗を経ていけば自然とこうするものではないかと思うんだけどこちらも楽しい例に出会うことはめったにない。多くの人は計画をたてることで管理した気になるんだろうなと思う。

つまり、この本が出版されて15年、僕の観測範囲ではあまり世の中は変わっていないっぽいということを確認してしまった。余談として、原題は本書とは全く違うのだけど、本書のタイトルはすごく良い釣りタイトルであると思う。

メタプログラミングRuby第2版を読んだ

メタプログラミングRuby 第2版

メタプログラミングRuby 第2版

本書はレビューに参加させていただき、本を頂いていたものなんだけども、1版やレビューで読んでいたこともあり、なかなかきっちり読み終えられていなかったものを会社の読書会にて読了した。なお、今もオンライン読書会にてさらに精読中。

本書の第1版はRubyを学び始めたころ、初めてのRubyプログラミング言語 Rubyに続いて読んだ記憶がある。確か当時は中級者向き的なことが書かれていて、大丈夫かなあなんて思っていたはずだ。

本書はタイトル通り、Rubyにおけるメタプログラミングを解説する本で、シンプルなものからRailsやいくつかのGemの場合まで、様々な場合について教えてくれる。Rubyプログラマの間ではとても有名な名著で、影響を受けた人はとても多いと思う。メタプログラミングというと難しいものや不思議なものにとらえられがちなものだけど、本書を通じて理解が深まり決して不思議なものでないというところまでたどりつけることと思う。

タイトルで敬遠する人がいるかもしれないけど、今では一通りRubyの文法、制御構造や良く使うメソッドなんかをさらったあとはこの本を読んでみるべきだと思っている。この本にはRubyを楽しいと思うための要素が詰まっていると思うからだ。プログラミング初学者はRubyはなんでもできるのだなあと柔軟性にただ感心するだろうし、他言語から来た人はRubyの柔軟さに良くも悪くも驚くと思う。けど、ここらへんこそがRubyなんだと思う。冒頭にあるMatzの「Rubyは君を信頼する」にグッと来た人も多いんじゃなかろうか。応えたくなるのが人情である。

また、本書は1版の時と異なり2版はオライリーから出版されているが、訳は変わらず信頼と実績の角さんなので、なんか訳が不自然で読みにくいということもない。Rubyを学ぶ万人にオススメしたい本である。

アルゴリズムとデータ構造を読んだ

アルゴリズムとデータ構造

アルゴリズムとデータ構造

アルゴリズムとデータ構造についておすすめの本を聞いてみたらおすすめされたので買って読んでみた本。 いわゆる名著ではあるがいかんせん古い。古典の部類。原著著者は超有名人である。

ニクラウス・ヴィルト - Wikipedia

アルゴリズムとデータ構造について振り返りたく読んでみたのだけど、とても古い。訳書(本書)の初版が1990年、原著は1975年!なお、本書は新訳らしく別の更に古い訳本があるらしい。 古くて何が困るかというと、サンプルコードはまあ擬似コード的にごまかして読むにしても、バブルソートが泡立ち分類と訳されるなど訳語のセンスにだいぶ乖離感があるのがつらかった。

言葉遣い的にもなんだか読みにくいなあと思ってしまい、途中で投げてしまいそうな危機感が出てきたので本の内容には疑問を持たず、とりあえず全部流して読むことにして通読した。本書をさらったことを土台にして、

アルゴリズムイントロダクション 第3版 第1巻: 基礎・ソート・データ構造・数学 (世界標準MIT教科書)

アルゴリズムイントロダクション 第3版 第1巻: 基礎・ソート・データ構造・数学 (世界標準MIT教科書)

なんかを読んで理解を深めていこうと思っている。

あまりちゃんと読めてないのでこうすごかったとも言いにくいんだけども、木構造とハッシュについてはすごくしっかり語られている印象を受けた。他で疑問に思ったときに参照すると理解が深まったりするかなあなんて思っている。他にもベーシックな配列等基本的なデータ構造、ソート、再帰などに触れられている。数学的な論拠を逐一示しながら進むので、数学好きな人は嬉しいのかもしれない。

考具を読んだ

考具 ―考えるための道具、持っていますか?

考具 ―考えるための道具、持っていますか?

いつもの技術書ではなく実用書というたぐいの本を読んだ。何かのきっかけで何年か前にもらったものだと思うが、ずっと本棚にしまわれたままのものだった。まあせっかくだしぐらいの勢いでざーっと読むことに。

本書は結構有名な本のようで、ググると結構な絶賛の記事も出てくる。奥付を見ると初版は2003年、実際読んでる本は2009年の29刷ということで結構な人気であったことは間違いなさそう。

内容としてはカラーバスなどのインプットするための方法やブレスト等のアウトプットの方法まで、色々なアイデア出しのための方法と道具について書かれている。現在から見るとだいたいが当たり前な方法に思えるのだけど、もしかするとこの本らがきっかけになって広まったのかもしれないなと思ったりした。だいたいが既知のものなので、目新しさという意味では面白くなかった。まあ私が技術職で特別にアイデアマンであることを求められてるわけでも、自身でなりたいと思っているわけでもないので真剣味が足りないという可能性はある。逆に言えば、アイデア出しの方法等についてまったく知らないという人にとってはきっと当時と変わらず良い書籍なのだろうと思う。

全然本の内容とは関係ないけども、こういう本は分かりやすく書かれていることはもちろんだけど、前提知識があまり必要とされていないので読書がものすごく早く進んだ。数時間もかかってないと思う。技術書読むのにはエネルギー使うもんだなあと比べて思ったりした。

ネットワークはなぜつながるのかを読んだ

ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

誕生日のプレゼントにいただいたネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識を読んだ。 かねてからよく言われる古典的な良い本であるが、LANとかの仕組みまでは知らないなあと思ってウィッシュリストへ入れておいたものだった。

いわゆるネットワークエンジニアではないところの多くのエンジニアの人たちだとそこまでローレベルな話を気にする人は少ないものだと思うので、そういうレベルからすると知らない話がたくさんあって、TCP/IPの仕組みをよく考えると知らない、なんて人は学ぶところが多くあると思う。

僕は昔々に情報セキュリティスペシャリストという資格をとったことがあるんだけれども、そこで勉強したことよりも通信の始まりから終わりまでのことが書かれており、最初に書いておいて通り、LAN以後のことはよく知らなかったので興味深く読ませてもらった。一方、OSI7階層モデルのなどの話は全然されない。あくまで本書の最初に書いてあるとおり、ウェブブラウザからリクエストが飛んで行ったらどうなるか、という話をされる。ウェブブラウザからLANを通りルータからプロバイダ、そしてインターネットへ…と流れていく通信を、各機器の役目や通信プロトコルの仕組みを通して順次説明されていく。

実際僕がプログラマとして本書で勉強したことが役立つかと言われると、既にある程度理解している立場からすれば万が一役立つことがあるかもしれないぐらいの感じではある。ただ一通りに通信の仕組みに触れられているので、何かで必要になった時に理解が早まるきっかけを持っておくという意味では浅く広く得た知識が役に立つかもしれない。しかし、きっとネットワークを扱う事自体を本職とする人たちからすればまるで足りないだろう。ただ、通信の仕組みがまるで想像できない人や、逆にエンジニアとの話をする上で共通の知識を身に着けたいという人は一読しても良いと思う。まるで仕事に関係がない人でもネットワークって不思議だなあって思ってる人は楽しく読めるかもしれない。