2000年代に常識だった開発手法や業界構造が様変わりしている現在のSI業界で、30代、40代になっても「値崩れしないSE」であり続けるにはどうすればいいのか？ 人気ブログ『GoTheDistance』でおなじみのござ先輩とともに考えるこの企画。

前回のベテラン人事との対話で見えた「30代を過ぎても値崩れしないSE」4つの行動原則に続く後編は、長年にわたる開発経験をもとに、ITによるビジネス価値の向上に欠かせない要点を独自の視点で整理・体系化した「匠Method」の生みの親である萩本順三氏を迎え、これからSEがやっておきたい行動や思考を明らかにしていく。

株式会社匠BusinessPlace　代表取締役社長
萩本順三氏 (@haggy335)

2000年にオブジェクト指向技術の企業、豆蔵を立ち上げ、以降ITアーキテクト、メソドロジストとして活躍してきた大ベテラン。2009年7月、匠BusinessPlaceを設立。現在は、ビジネスとITの可視化を行うための要求開発をさらに洗練・拡張させた手法「匠Method」を開発。自らユーザー企業で実践している

有限会社エフ・ケーコーポレーションシステム　開発部　部長
湯本堅隆氏（ござ先輩） (@gothedistance)

2003年、新卒で大手SIerに入社後、Javaプログラマー→PM→コンサルタントとキャリアを積む。 その後、2009年4月に20人規模のインテリア用品の製造・卸企業である現在の会社へ転職。自社業務システムの開発・運用を行いながら、受託開発やITコンサルまでをこなす。2006年から始めたブログ『GoTheDistance』が有名

IT業界内での後進育成にも熱心な萩本氏との対話から見えたのは、対立する3つの際（きわ）の両端を意識的に行き来しながら、本質を把握する視野の広いエンジア像だった。

日々の仕事を通じて、これらの「際（きわ）」をどう行き来していくのか、2人の経験談を中心に話を聞いた。

新しい技術を「器用に覚え続ける人」ほど将来が不安!?

ござ先輩　聞くところによると、萩本さんがIT業界に入られたのは遅かったそうですね？

萩本　えぇ、そうなんです。27歳のころでした。

ござ先輩　それまでは何をされていたんですか？

萩本　ユーザー側で経理を担当していました。「エンジニアってカッコいいな」というあこがれがあったんですが、そもそもITがどんな風に人の役に立つのか、ちゃんと知りたいという気持ちがとても強かったので、エンジニアを志しました。

ござ先輩　なるほど。とはいえ、異業種から急にプログラマーばかりの環境に飛び込まれて、今のようなお立場になられるまでにはかなりのご苦労があったと思うのですが。

萩本　もともと目的を突き詰めて考えたり、原理原則を知りたがる方だったので、仕事の空き時間になると、与えられた保守・運用業務とは直接関係のないOSに関する技術書なんかを読み漁っていたんです。それが、周囲のエンジニアからしてみれば、ちょっと「外している」ように見えたんでしょうね。「アイツは何やってんだ？」、「使えない奴だ」って話が、よく出ていたようでした。

ござ先輩　それでも、少しずつ立場が逆転していった。彼らとは何が違ったんでしょうか？

萩本　不器用だったからだと思います。

ござ先輩　そのココロは？

萩本　時代が変われば、開発環境も使う言語も変わっていきます。器用な人って、そうした変化をうまくとらえて対応していきますが、大部分の人は表面的にしか理解していないものです。今作っているシステムはそもそも何の目的に使うものなのかとか、新技術が出てきたタイミングや時代背景、アンチテーゼとされる技術との位置関係を理解することって、あまり考えませんよね。

ござ先輩　そうかもしれません。

萩本　でも、僕はまず根本的なところを理解しなければ、人に対してシンプルに説明できないと思っているので、技術の歴史というか誕生の背景を、何とか彼らの器用さを上回るために必死に考えていました。今にして思うと、そういう不器用さが返ってよかったんだと思います。

「作ったシステムがゴミだと気付いた時が成長の第一歩」（ござ）

ござ先輩　そのお話には非常に共感できますね。僕なりの言葉でいうと、複雑な事象をシンプルに説明する力が、エンジニアにとって一番大切な力だと思うんですよ。

萩本　そうなんですよ！

ござ先輩　一般ユーザーに、技術を技術のまま、プログラムをプログラムのまま語っても、誰も理解してくれません。具体的かつシンプルな言葉で機能やメリットを説明できないということは、逆に言うとユーザーが何を求めているか、何を作るべきかも分からないということにもなります。

萩本　技術だけに目を奪われると、つい忘れがちな部分ですね。

ござ先輩　それと、ある種の「器用さ」が持つ危うさについても同感です。確かに、ある程度の経験を積めば、言葉の上澄みをすくうだけでもある程度のものは作れるでしょう。でも、「ある程度のシステム」では何の役に立たないことも多々あります。それは、ユーザーの業務に頭を突っ込まないと見えてきません。

萩本　ござ先輩も、過去にそういう体験をされたことがあるんですか？

ござ先輩　はい。以前、ある業務の担当者が不在の時、自分の作ったシステムで卸業務の代行をしたことがあったんですが、初めて自分のシステムがゴミだと気付きました（笑）。欲しい情報がすぐに出なかったんです。ショックでしたけど、その時に開発者として一歩成長できたような気がします。

理論派vs行動派、それぞれに待ち構える落とし穴と解消法

萩本　目の前の現実をどうとらえるかは、人によって大きく違いますよね。

ござ先輩　というと？

萩本　エンジニアのタイプを大きく分けると、行動派と理論派がいると思うんです。最新技術やお客さまの要望を徹底的に追いかけるのが行動派。彼らは、流行を取り入れるのは上手ですが、状況が変化するたびに話す内容が大きくブレるという落とし穴にハマりやすい。

ござ先輩　なるほど。

萩本　逆に、理論派は考えることが得意でも、腰が重くてなかなか立ち上がらないという落とし穴が待っています。僕はどちらかというと理論派の人です。ただ、自分の欠点もよく理解しているつもりなので、なるべくお客さんのところに伺って現場で考え、行動しているうちに「行動する中で理論を考える技」を身に付けたと思います。「走りながら考えろ」的な発想を持てるようになったというか。

ござ先輩　僕はどちらかというと行動派ですね。20代のころは、今よりもっと前のめりだったように思います。ソフトウエア開発って、「やってみなきゃ分からない」っていうところがあると思うんですが、作り手がその言葉に酔ってしまうと、無鉄砲さとアジャイルを混同してしまいがち。事前に考えれば分かることを、はしょっても良いという話ではありませんよね。

萩本　おっしゃるように、「ウォーターフォールかアジャイルか」なんて議論は、今でも揺れ動いているわけですしね。最近は経済状況的にも、計画自体に価値を見出しづらい状況ですから、「まずやってみよう」というアジャイル的発想は理解できます。でも、あらかじめ計画しておくことで、避けられるリスクもたくさんある。行動派は具象化に走りやすく、理論派は抽象化に走りやすいものなので、常にその両方を行ったり来たりすることが大事なんだと思いますね。

1. 1
2. 2
3. 3