業務ソフトベンダーから「事業コンシェルジュ」への戦略的転換を図る弥生――改革を断行するCTO兼CIOが社内に浸透させるベンチャーマインド：CTOに問う（5）弥生編（2/2 ページ）

» 2015年07月01日 05時00分公開

[益田昇，聞き手：＠IT編集部]

CTOとCIOの役割をこなし、全方位でIT改革を

編集部　現在、開発本部長としてどのような役割を担っていらっしゃいますか？

安河内氏　システム開発部が担当する製品やサービスの開発・運用、情報システム部が担当する社内基幹システムの構築・運用に関して物事を決めること、決めたことを推進すること、決めた方向性を変えること、そして場合によっては止めることが仕事だと考えています。当然、他部門との調整も必要になりますし、最終的には社長の承認を得るのですが、基本的にはITに関わる全ての意思決定の権限が私に与えられています。

編集部　CTOとCIOの両方の役割を担っているわけですね。

安河内氏　情報システム部を統括するという意味では、当然CIOの役割も担っています。これまでは、システム開発部がリードする形で改革を推進してきましたが、今後は、カスタマーセンターの業務も含めて、全ての業務の棚卸しや整理を行いながら、ITによる改革を進めていきたいと考えています。

編集部　多くの役割を担い、仕事量が多くなっているのではありませんか？

安河内氏　システム開発部の改革が進み、さまざまな分野で着実にリーダーが育ってきていますので、今では全ての業務に口を出す必要もなくなってきています。実際に、開発本部長としての業務の負荷はずいぶん和らいできたと感じています。

「事業コンシェルジュ」を目指して

編集部　弥生の強みは何だとお考えですか？

安河内氏　私たちは、単なるパッケージ提供ベンダーではなく、「事業コンシェルジュ」になることを戦略的な目標として掲げています。それは、お客さまの業務の全てをサービスとして提供できるようになることを意味します。

　そうした戦略の一環として、優れたデスクトップ製品やクラウド製品を提供するだけではなく、弥生の製品を推奨する6000に上る会計事務所と協力して顧客をサポートする「プロフェッショナル・アドバイザー・プログラム（PAP）」や、きめ細やかなサポートを提供するカスタマーセンターが、他社を圧倒する強みであると確信しています。

編集部　弥生にとって、今の段階は、デスクトップ製品からクラウド製品へ移行する過渡期だと言っていいのでしょうか。

安河内氏　当社の場合、少なくとも現時点では、デスクトップ製品とクラウド製品の両方が車の両輪のごとくそれぞれが重要な役割を担っています。

　デスクトップ製品の方は、既存の企業顧客や会計事務所などの会計のプロ向けに、キーボードやテンキーを駆使した高い操作性を提供し、使いやすさを追求したものとなっています。こうした操作性は残念ながら今の時点ではWebアプリケーションでは実現できません。

　一方、クラウド製品の方は、主にこれまでExcelなどを使って会計処理をしていた個人事業主を中心とする新しい顧客層をターゲットにして、簡単かつ使いやすさを追求したものです。そのため、今やるべき処理をタイムリーに表示して、現在どこの処理をやっているのかを明確に把握できるような、一方通行で分かりやすいユーザーエクスペリエンス（以下、UX）を追求しています。

スタッフのほとんどがプロジェクトへ参加

編集部　製品開発の体制としては、プロダクトごとにプロジェクトを組まれているのですか？

安河内氏　基本的にはプロダクトごとにプロジェクト化を行っています。実際には、デスクトップ製品とクラウド製品の間でデータのやりとりを可能にしたり、顧客に好評だったUXを相互に取り入れたり、製品とサポートの連携を緊密にしたりするために、さまざまな部署のスタッフにプロジェクトと共通チームに参加してもらい、相互連携を図ってもらうようにしています。

　例えば、弥生のWebサイトやその中にある顧客専用のマイページの運用は、情報システム部が担当していますが、これらのシステムは、製品をサポートする上で重要な役割を担うようになってきています。これらのスタッフが、製品開発エンジニアと積極的にコミュニケーションを図れるように、プロジェクトに参加してもらっています。また、マーケティング部門や顧客サービス部門など、多くの部署のスタッフがプロジェクトに参加しています。

編集部　プロジェクトチームや共通チームには、どのようなリーダーがいるのですか。

安河内氏　プロジェクト全体を取り仕切るプロジェクトマネジャーの他、共通チームには、技術的な支援を取り仕切るテクニカルリーダー、品質監査の取りまとめを行うクオリティリーダーが選任されています。

編集部　エンジニアやスタッフの目標はどのように設定されるのですか？

安河内氏　期初には、個人の目標と同時に、自分が参加するプロジェクトでの目標、また共通チームでの目標を設定します。ただし、新入社員など、共通チームに参加していない場合は、個人とプロジェクトの2つの目標だけを設定します。

技術レベルに応じたトレーニングを実施

編集部　エンジニアのトレーニングについての考え方を教えてください。

安河内氏　日本企業の社員教育は、よく上司は人によって態度を変えてはいけないとか、できるだけ部下に任せた方がよいといった経験的な考え方で一律に行われているケースが多いと言われています。当社では、そうではなく、部下の技術レベルやメンタルレベルに合わせてトレーニングのアプローチを変えていく必要があると考えています。

編集部　実際にどのようなトレーニングを実施しているのですか？

安河内氏　当社の場合は、「SLII（シチュエーショナルリーダーシップ2）」と呼ばれるリーダーシップ手法を基にしたトレーニングを実施しています。このプログラムでは、部下の目標やタスク能力を評価して4つの開発レベル（D1～D4）に分類し、それに対応するリーダーシップスタイルに従って指示的あるいは支援的なサポートを行っています。

「SLII（シチュエーショナルリーダーシップ2）」モデル（事例紹介（弥生）－部下とのコミュニケーションを一変させたリーダー育成プログラムとは？ SLIIを基盤とするブランチャードプログラム導入の成果より引用）

　例えば、開発レベルが最も低いD1のエンジニアは、意欲は高いけれど、技術力が未熟なため、手取り足取り「指示型」で対応する必要があります。また、開発レベルが最も高いD4のエンジニアは意欲も技術力も高いため、指示も支援も必要とせず、「委任型」で任せておけばよいということです。もし、D1レベルの新入社員に対して「委任型」で対応したとすれば、つぶれてしまう可能性があります。

技術的負債の解消に向けリファクタリングを実施

編集部　技術的負債の解消に向け、どのような取り組みを行ったのですか？

安河内氏　7年前の改革以前には、複雑で特定の人にしか読めないソースコードが存在していました。また、製品によっては、UNIXでビルドされていて、Makefileが失われてしまったもの、場合によってはバイナリコードしか残っていないものもありました。

　そうした状況は何としても解消しなければならないということで皆が一致し、まずはソースコードの内容を皆が理解できるように、リファクタリングを行うことになりました。実際に、静的解析や動的解析のツールや複雑度を計測するツールなどを使って、どのように効率化できるのかを確認し、ソースコード改善しました。また、開発プロセスの標準化に取り組み、資料をきちんと作成することにしました。

　具体的なゴールとして最初に取り組んだのが、毎年行われる定例変更を最短の1日で終わらせることでした。改革以前は、ソースコードがハードコーディングされている箇所が多くあり、年度変更や法令変更だけの単純な定例変更に2カ月もの期間を要していたため、ほとんど新しい機能を追加できませんでした。定例変更を最短化することによって、「新しいものをやる」という方向に意識を転換できました。

編集部　技術的負債解消の取り組みは全て順調に進んだのでしょうか？

安河内氏　もちろん、プロジェクトの全てがうまくいったわけではなく、完全に火を吹いたプロジェクトもありました。その際には、システム開発のほぼ全員が年末年始出社しなければならない事態に陥りましたが、「プロセスを守らずに、小まめに資料を作らなければ、皆に迷惑を掛ける」ということを全員で共有できたと思います。

編集部　意識改革は現在でも継続しているのでしょうか？

安河内氏　7年前に改革を開始してから、多くの社員を採用しましたので、現在は改革を経験していない社員の方が多くなっています。そのため、リーダーの負荷も高まっており、改革を継続することがいかに難しい課題であるかを痛感しているところです。新たなリーダーを育てながら改革の継続を図っていきたいと考えています。

人の行動履歴から品質の状況を把握

編集部　品質を確認するために、ご自身がコードレビューをされることもあるのでしょうか。

安河内氏　私はもともと業務改善やプロジェクトマネジメントを得意としていますので、コードレビューまでは行っていません。ただ、障害の原因を突き詰めていくと、必ず人ならではの行動によるミスが浮かび上がってきますので、必ずしもコードを見なくても、品質の状態をある程度把握できます。

編集部　具体的には、どのようにして品質の状態を把握できるのでしょうか。

　例えば、当社の場合は、チケット駆動型の「Trac」というプロジェクト管理ツールを使って全てのタスクをチケットで管理をしていますが、チケットの更新履歴が20を超えると、そのタスクに問題が発生している可能性が高いことが分かります。

　また、ソース管理ツールとしてSVN（Subversion）を使っているのですが、SVNのコミット数が突出して多ければ品質が悪いことが分かります。

　なお、製品の品質保証（QA）については、専門のクオリティチームがきちんとKPIを設定して日々監視を行っていますし、ソースコードレベルの検証が必要な場合は、テクニカルリーダーが直接ソースコードを見るようにしています。こうした作業についても、コードの解析ツールを導入するなど、可能な限り自動化していきたいと考えています。

日本のエンジニアは自らをブランディングすべき

編集部　エンジニアを採用する際には、今でも直接面接されていますか？また採用の際に重視していることは何ですか？

安河内氏　はい。今でも面接しています。システム開発部の場合は、ものを作ること、生み出すことが仕事ですので、エンジニアに対しては、技術力だけではなく、モノ作り対してこだわりがあるかどうかを必ず見るようにしています。

編集部　情報システム部のスタッフにはどのようなスキルが求められるのでしょうか？

安河内氏　情報システム部が運用するシステムはほとんどが外注ですので、外注をハンドリングできるスキルを持った人材を必要としています。また、SE的なスキルを持った人材も採用しています。今後は、弥生ならではのシステムについては徐々に内製化していく方向も出ていますので、エンタープライズシステムの開発エンジニアも採用することになると思います。

編集部　日本のエンジニアの地位向上を図るにはどうずればよいとお考えですか？

　日本のエンジニアはただ技術力を身に付けるだけではなく、身に付けた技術力をどう使えば誰のためになるのかをもっと考える必要があると思います。そうすれば、コミュニケーションの量も増え、可能性も増えてくるのではないでしょうか。もしエンジニアが地位の向上を図りたいのであれば、もっと自分をブランディングしていくこと、つまり自分の売りをアピールする能力を身に付ける必要があると思います。

製品のWebアプリ化を模索し、基幹システムとの融合を図る

編集部　今後の技術的な展望を教えてください。

安河内氏　先ほど説明したように、今は、デスクトップ製品とクラウド製品を意識的に分けていますが、うまい具合に融合化を図っていければと考えています。デスクトップ製品自身は少なくとも向こう5年はなくならないと思いますし、無理にWeb化、SaaS化するつもりはありませんが、既存ユーザーの操作性を維持しながら、気が付いたらWebアプリケーションになっていたという展開はあるかもしれません。

編集部　情報システム部が担当する社内基幹システムの今後の展望について教えてください。

　現時点では、製品と社内システムとは、ほとんど結び付いていません。今後は、製品間の融合だけではなく、製品と社内基幹システムとの融合も図っていきたいと考えています。製品を裏側から支える基幹システムとしては、販売管理システムや顧客管理システム、カスタマーセンターのシステムがありますが、それらが全て融合の対象になります。

　具体的には、個々のユーザーに特化したUXやサポートメニューを提供したり、ユーザーとのコミュニケーションを電話だけではなく、メッセンジャーやチャットなどでも可能にしたり、カスタマーセンターへの問い合わせの際に、オペレーターの画面上にユーザーの情報を一括して表示させることなどができるようになればと思っています。

　昨年（2014年）には、カスタマーセンターのシステムにSalesforceの顧客管理システムを採用し、案件ごとのユーザー情報の確認や、ユーザーへの案内状況の確認といった案件管理を実現しています。ここに製品の履歴情報などをリンクさせることも今後の課題になるでしょう。

編集部　最後に、ご自身の今後の目標をお聞かせください。

安河内氏　製品間の融合、製品と社内システムとの融合というところまでは、ぜひやり遂げたいと考えています。その上で、未来を見据えながら、技術改革と人材育成の両面で、これまで確立してきたものを維持・継続することが今後の大きな目標になってきます。私はもともと、新しいものを生み出すことを得意としてきましたので、私にとって未知の領域に入ることになりますが、全力で取り組んでいきたいと思います。

　また、当社は昨年、オリックスグループの傘下に入りました。今後、グループ会社と協力して、どのようなシナジーを生み出すことができるのか、とても楽しみにしています。

「CTOに問う」バックナンバー