ソニービズネットワークス代表・小笠原康貴氏に聞く（２）
テレワーク時代の法人向けネットワークサービスのあり方
変化のスピードが速い時代に、ニーズにいち早く対応しサービスを届けるためにはどんな条件が必要か。働き方に関するルールや常識がどんどん変化していく時代に、総務をサポートするツールはどうあるべきか。「ハイブリッドな働き方」をキーワードに、クラウド時代のネットワークサービスのあり方について伺った。
小笠原 康貴（おがさわら・やすたか）
ソニービズネットワークス株式会社 代表取締役社長。1996年、日本電信電話（NTT）に入社し、技術開発や事業企画などに携わった後、2001年にソニーへ転職。同じく通信事業の技術開発を担い、「So-net」や「NURO 光」を手掛けるソニーネットワークコミュニケーションズにも籍を置く。2018年にはソニーネットワークコミュニケーションズの子会社であるソニービズネットワークスにも加わり、法人事業の拡大に注力。副社長を経て、2020年6月から現職。
目次
- 完璧を期すよりも欲しい機能を早く届ける方が重要
- 開発手法を変える前に文化を変えなければアジャイルにならない
- 次の変革期で日本が勝つためにAI普及に取り組む
- ハイブリッドな働き方が増えることで総務の仕事も大きく変わる
完璧を期すよりも欲しい機能を早く届ける方が重要
クラウド型の勤怠管理システム「AKASHI」をスタートする以前から、働き方に関するルールや常識がどんどん変化していくのを肌で感じていました。この変化のスピードに対応できるアーキテクチャをつくることを、AKASHIを始めるときから決めていました。
当時、お恥ずかしい話ですがシステムのバージョンアップは年に１回程度でした。そこで、AKASHIをリリースする際に、週に１回バージョンアップするぞと宣言したのです。
無料トライアルの人が「ここの機能はどうにかなりませんか」と問い合わせてきたときに、そういった問題が、無料期間が終わる前に直っていたらかっこいいじゃないですか。
それまで年１回しかバージョンアップしていなかったので、開発陣は「できない」「ありえない」と言っていたのですが、結果的にはできています。この5年間、週１回バージョンアップを継続してきています。QAに膨大な時間をかけて完璧に間違いないものをリリースしても多少のバグは出てきてしまいます。セキュリティなど重要な部分のQAには、時間をかけるなど、QAには、メリハリをしっかりした上で、運用で出てきたバグをすぐに修正するという修正速度の向上に考え方をシフトしました。
今、アジャイル開発は当たり前ですが、当時としては珍しかったと思います。とにかく週１回バージョンアップするということを先に決めてしまったというのが大きいですね。週１実装する優先順位を決めてバージョンアップを繰り返すと、仮に1年間で200個機能を増やす計画を立てても、1年経ってみると、実は半分ぐらいしか実装していなかったりします。残りの半分は状況の変化で必要でなくなるのですね。むしろ、その時々にニーズに対応することの方が重要です。それこそコロナ禍なんて、2019年には影も形もありませんでしたが、2020年春にはテレワーク機能の優先順位が突然上がったりするわけです。
開発期間を長くとりすぎると、その時々で本当に必要なものが無視されてしまいかねない恐れがあります。開発期間や周期を短くすることで、よりリアルタイムに最適な機能が実装できるようになりました。
長い期間で開発することに慣れてしまうと、コロナ禍のような問題が起きて短期間での開発が必要になっても、その開発速度から逸脱できないことが問題です。早い周期での開発に慣れている人たちは、時代が急激に変わった瞬間にやらなくてはならないと臨戦態勢に入れます。2020年の2月に新型コロナが流行しはじめたときに、テレワーク機能を入れようという話を開発の人間と立ち話でしたことがあって、３週間後には実装されて世の中に出ていました。なにかがあったときに動く速度が、普段練習をしているか、していないかで、ずいぶん違うと思います。こういうVUCAの時代には、そういったフットワークの軽さが重要になってくるでしょう。
開発手法を変える前に文化を変えなければアジャイルにならない
IT業界だからみんながアジャイルなわけではなくて、これは組織の文化を変えないとできないことです。開発手法を変える前に文化を変えなければうまくいきません。私自身が「１週間でやろう」「1カ月で開発しよう」と、意識して啓発してきた部分でもあります。
文化を変えるために、組織編成を変えたことも大きかったです。それまでタテ割りになっていた、営業、企画、開発を一つの組織に入れたのです。一つの課の中に全部入れてしまうことで、組織の壁をなくしていきました。とにかく同じ目的を共有している人たちを近くに置いて、速度を上げようということです。それまでは、うまくいかないのは営業のせいだ、開発のせいだ、と言っていたのですが、一つの組織にすることで、人のせいにできない雰囲気ができました。
組織がタテ割りだと、それぞれにKPIがあって、例えばそれは開発陣にとっては「実装の正確性」だったりするのですが、同じ組織にすることで、みんながサービス契約数をKPIとし、同じKPIを共有して同じ方向に向かって、同じ速度で取り組めるようになります。開発陣も「実装の正確性」は、KPIではなく、サービス契約数実現のための必要事項にかわりました。
今では開発のリーダーも営業と一緒にお客さんのところに行きますし、展示会の説明員を務めるようにもなるなど、ずいぶん変わってきていると思います。日常的なコミュニケーションの中でしか、文化は変わっていかないということを身をもって知りました。
また、自分たちが使うことも、ユーザーにどんどん使ってもらうことも重要です。ユーザーからの意見を吸い上げることで、自分たち自身を変革していくことの駆動力になっているなと感じます。
