比較的まっとうなプログラマを目指すために
俺俺ドキュメンテーション環境を整えた

Created: 2013-12-15
Modified: 2013-12-15
Written by Tatsuya Koyama

静的サイトジェネレータで tkDocs を作った

作ったソフトウェアのドキュメンテーションをまとめる環境や、 作業ログや勉強メモをガシガシ書いていく環境がほしかったので、 新たに tkDocs というサイトを作った。

なぜこれを作ろうと思い、何を使ってどのような手順で構築したのか。 tkDocs はドキュメンテーション環境なので、それも tkDocs 自身に記述 することにした。

自己完結的なシステム は強い。プログラミング言語のセルフホスティングなんかは好例だ。

これで何を書くのか

さて tkDocs に関して、Why と How は tkDocs の方に記述した。 では What は? 僕は新たに、ここに何を書こうとしているのだろう?

技術メモや勉強ノート

ひとつは技術メモや作業ログ、勉強したことのまとめ、出会ったエラーを解決したときの記録などだ。 これはまあ、律儀なプログラマなら誰でもやっていることだろう。 僕もやっていたが、それはローカルのテキストファイルや紙のノートに個人的に残しているだけだった。 この辺の編集・公開の手段としてはブログや wiki が一般的だけど、あまり僕の手には馴染まなかったんだ。

今回は自分にとって心地よいシステムが構築できたので、今後のメモはこちらに書いていくようにしよう。

自作ソフトのドキュメンテーション

もうひとつ。僕は概ねゲームのプログラムを書くことに人生の多くの時間を使っているが、 そうしていると自前のライブラリやフレームワークというものが出来上がってくる。 僕もそろそろいい年齢のエンジニアになってきたので、こいつをちゃんと 「人様に見せられる」レベルに整えて公開しておくようにするか、と思うようになってきた。

コードのリポジトリを GitHub で公開するだけならすぐにできるが、 より律儀に仕事をするなら設計思想や使い方も、ドキュメンテーションとしてまとめておきたい。 一口にドキュメントを書くと言っても、何のツールを使うのか、どう管理してどう公開するのか、 考えることは色々あった。 今回 tkDocs を作ったのは、ここに決着をつけたかったという理由が大きい。

自作のゲームフレームワークには、 krewFramework という名前をつけた。 完全に個人用で、まだコードもドキュメントも全然整っていない段階だが、 「公開状態である」という認識で開発することで品質を高めたいという戦略だ。

まっとうなプログラマを目指して

僕ももう社会人 4 年目のプログラマだ。 もはや新人ではない。雇われの身で働く以上、僕は「まっとうな」仕事をしなければならない。

信頼できるメンバーになる

キャッチーさを狙って真っ当などという言葉を使ったが、要は他のメンバーに 「こいつと一緒に仕事したいな」と思われるような人間でありたいということだ。 それはより良い作品を、自分が関わったと胸をはって言えるような状態で世に出すためにも必要なことだろう。

それに技術とセンスは、技術とセンスがある者のところに集まる。 重要なのは自分の持っているものをちゃんと人がわかるような状態にしておくということだ。 今回で言えば、コードやドキュメントを「いい感じの見た目で」公開することがそれに当たる。

よりオープンな思考を持つ

真っ当なプログラマは恐らく、ソフトウェアの世界に携わるほどに「他の人も楽させたい」という思考に至る。 仕事をしているときにドキュメントと書いたりコードを書いたりするのは当たり前だが、 せっかく労力を割くのに「これを自分たちだけで使っているのはもったいない」と思うようになるのだ。

僕の尊敬するプログラマの人が言っていたが、 結局のところプログラミングの本質でありプログラマの武器は、抽象化(汎化)なのだ。 問題解決力とは、経験を抽象化して応用できる能力のことなのだから。

  • 神は初めにゲームプログラマを作った
  • ゲームプログラマは最初にこう言った。「他のコードからも呼べるように、関数にしよう」
  • 次にこう言った。「他の状況でも使えるように、クラスにまとめよう」
  • 「他のゲームでも使えるように、ライブラリにまとめよう」
  • 「結局どのゲームでも似たような流れがある。フレームワークにしよう」

会社で働く場合にも似たような視点の移動が起こる。

  • 他の開発メンバーが楽できるように、ドキュメントやコードをまとめよう
  • 自分のチームに閉じる必要はない。他のチームにも使えるようにモジュールにまとめよう
  • 部門全体が使えるようにフレームワークレベルに整えよう
  • もはや会社に閉じる必要も無いんじゃないか。オープンソースで公開だ!

実際、こうした考え方はプログラマの力量を高める。言い方を変えれば、力量が無いと成し得ない。 目の前の問題だけを解決するプログラムを書くより、 似たような問題をひっくるめて解決するようなプログラムを書く方が、難しいからね。 まあ依存性を排除するというのはソフトウェア設計の王道のパターンだから、 「どこでも使える」を意識するのはいいことだと思う。

雇う側の気持ちを考えてみる

働いていると、採用に関連するような仕事を担うこともある。 採用する側の視点に立って逆に考えたのは、 自分自身は『こいつと一緒に仕事したい』と思ってもらえる人間なのかどうか、 ということだ。

その人の本当の実力というのは、しばらく一緒に仕事をしたり、じっくり話し込んだりすることで初めてわかるものだが、 優秀なエンジニアというのは得てして、すでに人目につくような成果物を上げているものだったりする。 (ゲームを作る人間なら、趣味で作った iOS アプリを App Store に出していたりとかね。) 採用関連の仕事に関わるとき、僕は自然とそうしたものをネットで検索しようとしていることに気がついた。 ゲームプログラマを目指す学生たちに就活のアドバイスを求められたときも、僕はこう言ったんだ。

  • 僕が面接官だったら、まず君の名前を GitHub で検索するかもね。

人に言うからには、自分も然るべき状態を目指さなくてはならない。

おわりに

ということで、僕は引き続き真っ当なプログラマを目指して、 ドキュメントを書いたりコードを書いたりしていこうと思う。 何をすべきで、何が正しいのか、たぶん多くのプログラマにはそれが分かっている。 重要なのは、それを「ちゃんとやる」ことだ。