
今回は、SE出身の作家である、きたみりゅうじさんにお話をお伺いいたします。きたみさんは、フリーランスとして技術本やSE時代の体験を題材にした書籍を多数発行されており、多くの書店で売上ランク上位を記録しています。現在は5つのWebサイト、2雑誌で連載中。その面白おかしく感情表現豊かな独特な作品でSE以外の職業の人々にも幅広く知られています。取材会場は、千葉県の某駅近辺の寿司屋「銀蔵」です。テクニカルサポートとして、Webキャリアの前田道昂氏に同席をいただきました。
きたみりゅうじ 氏
1972年 大阪、寝屋川生まれ。もとは企業用システムの設計・開発、おまけに営業をなりわいとするなんでもありなプログラマ。あまりになんでもありで、ほとほと疲れ果てたので、他社に転職。その会社も半年であっさりつぶれ、移籍先でWindowsのパッケージソフト開発に従事するという流浪生活を送る。本業のかたわらWeb上で連載していた4コマまんがをきっかけとして書籍のイラストや執筆を手がけることとなり、現在はフリーのライター&イラストレーターとして活動中。遅筆ながらも自身のWebサイト上にて1コマ日記や4コマまんがを現在も連載中。
■オフィシャルサイト
「キタ印工房」 http://www.kitajirushi.jp/
■Web連載
「きたみりゅうじのブルルンバイク日記」 http://www.hobidas.com/blog/clubman/kitami/
「Dr.きたみりゅうじの"IT業界の勘違い"クリニック」
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s01300.jsp?p=010
「きたみりゅうじのエンジニア転職百景」 http://tenshoku.mynavi.jp/eng/kitami/
「SOHOの家づくり」 http://blog.smatch.jp/kitami/index.html
「シスタン」 http://blog.ascii-business.com/kitami/
![]() |
![]() |
![]() |
![]() |
![]() |
■連載@雑誌
「きたみりゅうじのCBブルルン生活」 http://www.clubman.jp/
「きたみりゅうじの聞かせて珍プレー」 http://gihyo.jp/magazine/wdpress
■著作
「SE・エンジニアの本当にあった怖い転職話 」毎日コミュニケーションズ
「シスタン 〜システム担当者を雑用係と呼ばないで〜 」 アスキー
「Dr.きたみりゅうじのSE業界ありがち勘違いクリニック」 講談社
「会社じゃ言えない SEのホンネ話」 幻冬舎
「パソコンマナーの掟 今さら人には聞けない「べからず!」集」 幻冬舎
「マンガ式IT塾 パケットのしくみ」 技術評論社
「SEのフシギな職場〜ダメ上司とダメ部下の陥りがちな罠28ヶ条〜」 幻冬舎
「改訂版 図解でよくわかる ネットワークの重要用語解説100 」技術評論社
「フリーランスを代表して申告と節税について教わってきました。」 日本実業出版社
「SEのフシギな生態〜失敗談から学ぶ成功のための30ヶ条〜」 幻冬舎
「新卒はツラいよ! 」幻冬舎
「フリーランスはじめてみましたが… 」技術評論社
「図解でよくわかる ネットワークの重要用語解説 」技術評論社
「WindowsXPネットワークスタートアップガイド 」技術評論社
「myShade3で描くカンタン3D 」ローカス
「こんなにできるDaisyArtミレニアムバージョン 」エムディエヌコーポレーション
「フリーランスのジタバタな舞台裏」幻冬舎
■監修
「ドット絵の教科書 」アスペクト
![]() |
きたみりゅうじ氏最新刊 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
![]() |
||
| Ruby大好きな方はこちらもどうぞ!! → | Webエンジニア武勇伝 第20回 高橋 征義 氏 | |
| Rails大好きな方はこちらもどうぞ!!→ | Webエンジニア武勇伝 第5回 増井 雄一郎 氏 | |
| これを読んだあなたに オススメの会社は→ |
![]() 株式会社ケイビーエムジェイ |
|
![]() |
||
ページ上部へ戻る










さっきまでの話だけだと、
この人すごくしっかりしている人という印象になっちゃうかもしれないんですけど、実はそんなことなくてだらっとしていたんですよ。遅刻常習犯だし、会社に入って少しはきっちりはしてはいたんですけど、納期さえ間に合えば、昼間だって何をしててもいいじゃんみたいな感覚でしたしね。サラリーマンとしての才能はなかったんですよ。誰が決めたかよく分らないルールに従うのは嫌でしたね。朝、遅刻して誰か困るかって、困らないですよね。でも会議に誰かが遅刻したら待ってないといけないので、困るんですよ。普通の社会人って逆なんで
すよね。会議にはだらだらっとしてなかなか集まらないけど、朝だけはちゃんと来るんですよね。それが本当に嫌で、自分だけ有給が減っていくのに、会議に遅刻した人は有給減らないっていうのは納得がいかなかったですね。
微妙なのは、1つくらいい
いかって許容しても、読んでる側は分からないんですよね。例えば、画を描くときにちょっと手を抜いたとしても分からないと思うんですよ。でも、分からないからといって、どんどん手を抜いたりしていくと、結構、分からないなりになんだか違うなって感じにはなってきちゃうので、どこかで歯止めをかけないといけないんですね。実際にイラストなんかでも最初の頃に比べると、ある部分では書き込む量を増やしているんですけど、ある部分では減らしていたりするんです。その減らす段階では、1度減らす画を描いてみて、それでどういう反応がくるか試して、「あ、分かんないもんだな」って思って、そうしてみたりとか。ちょっといやらしい話になりますけど、そうしていかないと回転させるためには、省力化させるところはしていかないといけないんですよ。ある意味、見えない部分のコストダウンですね。
まず、サラリーマンに戻ったらできなくなることってなんだろう?って考えました。まずは子供に会えなくなる。こんなに毎日、晩飯を家族と一緒に食うこともできなくなる。会社に通うと通勤時間もかかるので、1日の拘束時間は少なくとも14〜16時間になって、その間何もできないじゃないですか。じゃあ、その16時間をまるまる休みなく今の仕事にあてたら全然違うんじゃないかって思って、そこまで自分自身は頑張っていたっけって自問自答したらやってなかったんですよ。毎日16時間を書き下ろしにあてて、まわしていけば全然違う話じゃないのかなって感じたんですよ。勿論、実際はそんなことをしたからって、単純に書けるペースが倍増するわけじゃないんですけどね。でも少なくともそういうレベルでやってみたかって言われるとやってないんですよ。だったら、子供と会えなくなる選択をする前に、それを頑張ってやってみたらいいんじゃないかなと思って、そこから頑張りだしたんです。
業界によると思うんですけど、技術をとことん突き詰めていくことが必要なところに行く人は、もうその方面に突っ走るだけなのでお好きなようにと思いますが、そうじゃなくてお客さんありきでいかに便利なソリューションを作るとか、いかにチームとしてプロジェクトをうまくまわせることが求められる会社にいく人であれば、全部一緒だよって言いたいですね。文章書くのもプログラミングするのもお客さんの要求をまとめるのも全部必要なスキルだってことは同じだよっていうのが僕の思いなんですね。文章も最初に章立てがきちんとできないと支離滅裂なものになるんですよ。どういうテーマがあって、それをどういう章立てにして、どう伝えていくかっていうことを最初に整理しないと全体として筋が通らないものになってしまうんです。お客さんの要求も、まずテーマを見つけて、そのテーマに沿ってどういう順番でそれを提供するかという章立てを整えることで、お客さんもシステムのいい悪いを判断できるようになるし、お客さん自身の中ではっきりしていなかったものが、「あ、そいうのが欲しかったんですよ」みたいな話になったりしますよね。プログラムもやっぱり一緒で、作らなきゃいけないシステムがあれば、メインとしてまずテーマがあって、どういう機能をどういう順序で実装していかなきゃいけないとかってことを整理するのが大切なんですよね。今のオブジェクト指向系になると複雑になるんですけど、昔のやつだと、この機能を作りたいからこの機能ばっかり見て
いるとか、そうやっちゃうとそこだけでかくて大変なプログラムができたりとかするんですよ。テーマを作って、全体が流れていくときにどの行を抜き出してもその先っていうのが、同じくらいの大きさだったり複雑さだったり、そういうようにばらけさせることで、作業も分
担しやすいし、プログラムとしてまとまりがあると読みやすくなるんです。で、読みやすくなるので、C言語でいう一番上のメイン関数を呼び出してみると、それで1つの文章ができあがるんですよ。その文章が章立てになっていて、各章を見るとまたその中が章立てになってて
中身が分かる、それでそれ以上分けられないものが最後に残るって感じになるはずなんですよ。ですからどの仕事も、テーマを決めて、章立てにして、それをばらけさせるっていう意味では本当に同じだと思うんですよ。それができれば、何をやっても綺麗にまとまるんですよ
。綺麗だと見やすくて分かりやすいし、分かりやすいと、人の出入りも楽になるんです。例えば、思わぬバクがでて、ここで工数が遅れそうだから、一時的に人を増やして対応しようとしてもそういう造りであれば、すぐに対応できるんですよね。そういうことができるような
スキルを磨くためには、やはり相手が何を欲しているのかをどう読み取るかとか、どう伝えれば相手に分かりやすいかだとか、そういうことを日頃から考えていないと分かりやすいコードにはならないし、お客さんの要求をくみ上げられないですよね。プログラムが書ければい
いからって、それを見ない人っていますよね。そうじゃないんだよって思いますね。そこを磨くとなんでもできるんですよ。そういう人にプレゼンを作らせると、聞きやすくて見やすいプレゼンを作りますからね。そういう志向のない人にプレゼンを作らせるとやたらとアニメ
ーションばかりのプレゼンを作ってきますね。最初にそういう流れを整理する習慣をつけると、プログラミングの場合、気持ちの切り替えができるようになるんですよ。最初に整理してそこがもうぶれないって自信ができると、ここを抜き出してこの関数を組んでいる間はこれ
に集中していても絶対に他には影響を及ぼさないっていう自信が自分にできるんですよ。そうすると狭い範囲に集中できるので、全体が把握できて、ちゃんと目の行き届いた品質の高いコードが書けるんです。そういう品質の確保されたコードをくっつけていくと全体として当
然、品質の確保されたものが出来上がりますね。何も整理しないで書き始めちゃう人は、ここでいつグローバル変数を作ったんだっけみたいにコードを書き始めちゃって、そもそも今どんな変数を使える状態にあるんだっけってことも分からなくなって自分自身で把握しきれな
くなっちゃうんですよね。それでいろんなところで整合性がとれなくなって、最後の最後で動かないってときにはどこから手をつけていいか分からないですねってことになっちゃうんですよね。なので、最初に整理するっていうのは本当に大事ですね。



