エンジニアの生産性を劇的に高める「開発支援ツール」の賢い使い方~JIRA、IntelliJ IDEAほか専門家座談会
開発環境は、職人にとっての仕事道具と同じ。どんな環境だと心地よく開発できるのか、生産性アップにはどんな使い方が有効なのかetc…は、常にエンジニアたちの議論の的になるものだ。
もはや恒例となっている「Emacs vs Vim」のエディター論争など、どんなツールを好むかは十人十色の意見があるが、今回は海外の有償ツールを日本で普及させる「開発支援の専門家」たちに集まってもらい、無償ツールにはない魅力を語ってもらった。
話は各ツールの導入メリットから、日本のソフトウエア開発の問題点まで及んだ。その一部始終をお伝えしよう。
EclipseやRedmineにはない「かゆいところに手が届く」ツール群
山本 わたしが日本の公式代理店として取り扱っているのは、JetBrainsというチェコの会社の製品群です。IDE(統合開発環境)といえばとりあえずEclipseを選択する方が多いですが、JetBrainsの『IntelliJ IDEA』はすごくよくできていて、最近評判を上げています。とにかく「空気を読んでくれるIDE」なんです。
山本 例えば、Eclipseにも文法やコード規約のチェック機能やリファクタリング機能はありますが、抽出したメソッドをほかの部分に適用するのは手動じゃないですか。『IntelliJ IDEA』なら、コードを解析してくれて、抽出したメソッドを適用できる箇所を検出し、「これらの箇所は抽出したメソッドを呼び出すようにしますか?」と提案してくれるんです。
共通化のために抽出したメソッドをほかから呼び出すように手動で書き換えなくて良いし、書き換え漏れも発生しません。ほかにもコードの非効率な箇所を検出、修正提案などしてくれるので、使っているとすごくスキルが高いエンジニアとペアプログラミングしているような感覚になります。
山本 そもそも、「気持ちよく開発ができるからEclipseを使っている」という人って、さほど多くないと思うんですよ。デフォルトでできることは非常に限られているので、結局は、自分で必要な機能を拡張しなければなりません。
大貫 たくさんのプラグインの中から必要なものを探し出す手間や、コンクリフトの対処に費やす時間というのは、開発コストそのものなんですよね。
山本 そうなんです。その点、『IntelliJ IDEA』のような有償ツールは、こうした不要なコストをかけることなく、導入直後から一通りの機能が誰でも使えるように作られている。これだけでも、導入するメリットがあると思いますね。
大貫 ええ。『JIRA』はオーストラリアの会社であるAtlassianの製品で、リックソフトはAtlassian製品のプロフェッショナルサービスを展開しています。バグトラッキングや課題管理を行う『JIRA』以外にも、開発者用Wikiの『Confluence』などが有名です。
Atlassianがちょっと違うのは、ユーザーが製品本体をカスタマイズしても構わないという立場を取っているので、ライセンスを買ったユーザーはソースコードも一緒に手に入れることができます。
大貫 ええ。Atlassianはもともと、オープンソースの塊のようなプロダクトだからというのが大きいでしょうね。その分、インストール時には自分でDBを用意しなければなりませんし、ライセンス購入者が自身で設定すべき点は少なくないのですが、それは、オープンソースに由来するカスタマイズ性の高さの裏返しだと思っています。
山本 確か、昔は自分でビルドしなきゃいけませんでしたよね(笑)。
大貫 そうでした(笑)。さすがに今ではインストーラも用意されるようになって、一発で入るようになっています。エンジニアであれば、「ここを少し変えて使いやすくしたい」っていう要望が多少なりともあるものですが、Atlassianは、そうしたカスタマイズ性を重視するエンジニアの皆さんが使いやすい形でプロダクトを提供しているわけです。
大貫 とりわけ数100~数千人単位で行うような大規模開発を進めていく際、『JIRA』と『Confluence』の組み合わせはとても威力を発揮します。『JIRA』はバグ、タスク、ソースコードなど大人数でもすぐにトラッキングできるような設計になっていますし、『Confluence』も情報共有用のWikiとしてすごく良くできている。
大貫 開発規模が大きくなればなるほど、現場ではいろんな開発用ツールが入り混じって使われ、逆に効率が悪くなったりするものです。『JIRA』や『Confluence』のような専門ツールを使うメリットは、この“カオス”によるストレスを軽減できる部分にあるんじゃないかと。
大貫 Atlassianは「Open Company」という標語を掲げているように、プロダクトだけでなく、開発情報についても非常にオープンです。例えば、報告されたバグや次期バージョンの新機能情報などはすぐに公開しますし、ユーザーが新機能に対して「投票」という形で意見を伝えることもできます。そのあたりも、オープンソースになじんでいるエンジニアに好まれている部分ではないでしょうか。
山本 そもそもエンジニアは、自分の使うツールをハックするのが好きな人種ですしね。
大貫 そうなんですよ。オープンスタンスな会社の製品は、エンジニアの信用を得やすいんですよ。
設計段階で使いこなすと後々楽になるUMLの専用ツール
河野 『Enterprise Architect』はUMLのモデリングツールでして、『IntelliJ IDEA』や『JIRA』のように開発の効率化を促進するツールではありません。コードを書く手前の設計段階を、UML(統一モデリング言語)という書式に則って標準化していくためのツールです。分かりやすく言うと、ソフトウエアの設計方針や構成を図解して、プロジェクト内で共有する際に利用するものになります。
河野 従来は、多機能コピー機のような複雑な製品などの開発で多く利用されてきましたが、最近ではそれらの製品に加え、医療や自動車、航空宇宙業界などの開発でも使われるケースが増えています。
河野 ISOのルール変更に伴って、モデルベースによる設計をメーカーが要求するようになったからです。先に挙げた業界は、どれも命にかかわるようなプロダクトを作っています。ですからソフトウエアに何か問題が生じた時に、どのような過程で開発されたのか、後からさかのぼれることが非常に重要になるんです。
河野 アジャイル的に「まずはプロトタイプを作ろう」というWebやモバイル系の開発よりも、官公庁や金融系のシステムなど、主にウォーターフォール型の開発手法が求められる分野でよく利用されています。また、開発拠点が世界各地に分散しているような巨大企業が、言葉の壁を越えて開発の意図や目的を共有するのに利用しているケースも多いですね。
山本 Webやモバイル系の開発でも、メンテナンス性を考えて、書き終えたコードをリバースしてUMLにすることもありますよね。
河野 ええ。そういった使い方もあります。
山本 UMLって、実際に活用しようと思ったら、やはり専用ツールを使わないとなかなか大変ですよね。無償のIDEツールにも、ちょっとしたクラス図やシーケンス図を作る機能はありますが、必ずしも使いやすいものではないですから。
有償ツール導入でよくある「投資対効果との戦い」をどうやるか
河野 今、実際に開発現場でプロジェクト管理に一番多く使われているのは、結局ExcelやPowerPointじゃないですか。わたしから見れば、それらを苦労して使いこなすくらいなら、『JIRA』のような専用の有償ツールを導入すれば早ければ2~3日で元が取れるんじゃないかと。
山本 とはいえ「導入のハードルが高い」というご指摘はもっともで、僕らが扱っているような有償ツールは導入までに2段階の障壁があると思うんです。
山本 最初はそもそも存在を知られていないために、なかなか触ってもらえないという障壁。そして、ようやく現場の人に良さを知ってもらっても、導入の決済権を持つ人たちの理解をなかなか得られないという障壁です。
大貫 確かに、企業で導入する際は、決裁権者を説得するまでが一苦労ですよね。
河野 わたしもよく「導入における費用対効果は?」などと質問されるのですが、UMLツールを導入すると「売り上げが30%向上します」なんてハッタリは言えません(笑)。その点でいつも苦労しています。
山本 現場の人は、開発の気持ちよさとか効率のよさを定性的に評価してくれますが、決裁権を持っている上の方は定量的な指標を欲しがりますよね。立場上、もっともな話なのではあるのですが。
大貫 『JIRA』の場合は1000円で始められるスターターライセンスがあるので、まずは現場の方が自腹で買って1年くらいかけてプロジェクトを回されて、実績を積み上げてから社内決裁を取り付けるようなやり方もあります。このパターンで購入される企業さまも少なくありません。
河野 うちの場合は、ライセンスを10本買っていただくと全国どこにでも無料出張セミナーに行くというのをやっています。もちろん、交通費やセミナー費用はこちら持ちで。
河野 目先の収支だけを見れば赤字です(笑)。ただ、このセミナーを通じて適切で効果が出る使い方を理解していただくと、その後のサポートに手が掛からなくなったり、隣の部署や別のチームからの発注が得やすくなったりする傾向があるので、継続してやっています。
山本 JetBrainsも、まずは気軽に使ってもらうために、通常のコマーシャルライセンスと同じ機能が使えるけど半額で利用できるパーソナルライセンスを用意しています。これは、「事情があって会社の稟議が通せないけれど、どうしても使いたい」という開発者に向けたライセンス。利用条件は、会社で経費精算しないことなんです(笑)。
山本 「うまく成果が見えて稟議が通るようになったらコマーシャルライセンスを導入してくださいね」と(笑)。そうすることで、参入障壁を少しでも低くしようとしているわけです。実際にパーソナルライセンスから初めてコマーシャルライセンスの導入に至った話は、こちらのslideshareに書いてあります。
大貫 確かにそういう面もあります。
山本 でも、業務に関係あるソフトであれば、ある程度現場の裁量でインストールしてもお咎めない会社も多いと思いますよ。
大貫 逆に、トップダウンで導入した開発ツールが現場にまったく根付かず、草の根的に使われていたオープンソースが事実上の標準ツールになるケースもありますよね。オープンソースツールが管理者のあずかり知らぬところで草の根的に広がってしまったがゆえに、重要なデータが乗り始めるようになってもバックアップすらされていなかった、という問題が発生したり。
山本 そうですね。だからこそ、デフォルトの状態からすぐに使える優れた有償ツールを使ったらいいのに、と思うんです。
一エンジニアとして使いやすいものを、多くの人に広めたい
山本 僕の場合、僕自身が『IntelliJ IDEA』やJetBrainsの製品を使っていて、ツールとしてすごく良いものだと感じたので。
大貫 わたしも、自分が使ってみて、「これはすごい」と。
河野 わたしもです。最初の動機って、そんなものですよね(笑)。
山本 JetBrainsは日本での知名度が低くて使っている開発者も少なかったので、じゃあ僕が普及役をやろうかなと。僕はまだ現役のエンジニアですし、一ユーザーとして良いと思ったものを広めたいなと思っています。
大貫 当社の場合は、かつては常駐型のSIを本業にしていたのですが、わたしが『Apache Geronimo』の翻訳プロジェクトにかかわっていた時、『Confluence』で文書管理をしていたのがAtlassianに触れるきっかけでした。
このプロジェクトで『Confluence』を1年半近く使ってみて、すごく良いツールだと感じて、正式なパートナーになり、会社もSI業から事業転換を図りました。
大貫 ええ。
河野 きっかけは、前職のシステム会社にいた時かかわった新規案件で、UMLを使おうとなったことでした。当時、UMLモデリングツールのデファクトスタンダードだったRationalの『Rose』の価格が高かったため、代替ツールを探していた時に出会ったのが『Enterprise Architect』で。
ただ、モノは良かったものの、わたしが使い始めた当時は日本語版もなく、マルチバイトにかかわるバグも多かったので、たびたび開発元のオーストラリアに問い合わせていたんですね。その時のレスポンスが良さや、気さくな感じが好印象で、Sparx Systemsとのかかわりを深めることになりましたね。
河野 やはり、こういう開発支援ツールをうまく使いこなせば、日本のソフトウエア産業をもっと元気にできるかもしれないという思いがあったからです。
大貫 わたしも似たような理由でしたね。
山本 日本は戦後、製造業で大きく経済成長を遂げましたよね。先進的で精度も良く、滅多なことでは壊れない家電や自動車が世界を席巻したわけですけれど、今の日本のソフトウエア産業にあの当時の輝きは感じられません。それって、がっちりと設計して完ぺきな仕組みを整えてから、大量生産に結び付けるような製造業型のビジネスが、ソフトウエアの世界では通用しにくいからだと思うんですよ。
大貫 確かに。それもあって、最近はアジャイル開発のような手法に注目が集まっていますが、そうすると大規模開発の時こそ、効率的に情報を管理できる支援ツールが重要になってきます。
山本 ええ。それに、多くのソフトウエア分野では、まず動くものを作って、後からバグを改善していくやり方が主流じゃないですか。まぁ人命にかかわる分野には当てはまりませんが、それ以外の分野では、有償でも「使える開発ツール」を積極的に活用してもらうことで、古い仕事の進め方から脱却できる。
今よりも失敗と改善のサイクルを高速で回していけるようになっていったら、もっと良くなると思うんですよ。
河野 わたしが思うに、日本人って、良い意味でも悪い意味でも「優秀」なんだと思うんです。だから、使いづらいツールを何とか使いこなしながら、それなりに良いモノが作れてしまっていた。
大貫 でも、今は開発サイクルの高速化が競合優位性に直結するような時代になっているじゃないですか。これまでのやり方では、限界を迎えてしまうと思っています。
日本企業はソフトウエア開発に対して、なかなか先行投資をしたがらない風潮がありますが、海外の企業ではむしろ積極的に先行投資をして、投資コストを最終的に回収すれば「良し」とする企業がほとんどです。日本がいつまでも現状にやり方に甘んじていては、なかなか世界的なプロダクトは開発できません。
山本 結局、開発者の本懐は、作るモノで価値を生むことですしね。
大貫 だからこそ、効率化すべきところを効率化し、割いた時間をプロダクトの向上に注ぎ込むべきだと思うんです。エンジニアが気持ちよく開発してこそ、クリエイティビティーが発揮されるというか。
河野 確かに。
大貫 複雑化する開発を支援してくれる優秀なツールは、いわば日本のソフトウエア産業を今よりもっと良くしていく土台となり得る。そのお手伝いは、けっこうやりがいのあるものだと思っています。
取材・文/武田敏則(グレタケ) 撮影/赤松洋太
RELATED関連記事
RANKING人気記事ランキング
米国優位が揺らぐ?ひろゆき「CPUの進化でGPU神話って崩壊しません?」【AI研究者・今井翔太が回答】
NEW!
表面的なテクニックより「基礎基本の重要性」に気付かされた一冊【Node.js 日本ユーザーグループ代表・古川陽介】
AWS認定資格10種類を一覧で解説! 難易度や費用、おすすめの学習方法も
正論モンスター化に要注意!ぎくしゃくしない「ミスの指摘」のコツ【澤円「コミュ力おばけ」への道】
社会で成功するゲーマーに、ひろゆきが聞く「現実世界を攻略できないゲーマーに足りないものって何すか?」
JOB BOARD編集部オススメ求人特集
タグ