キャリアの幅を広げたい。未経験だったコンサルティング領域へ挑戦

▲ 情報システムグループ多良雅也(左)と石川祐介(右)

KeepAliveに中途入社する以前は、Webデザインを手掛けていました。入社してからは培ってきたデザインスキルを生かしながら、UIを意識したサイト設計のスキルを磨きました。顧客のオムニチャネルサイトやコーポレイトサイト、ECサイト構築などで要件定義と基本設計を行うなど、リーダーとしてフロントエンド開発に携わりました。

そんな中でクライアントとの折衝やベンダ管理、プロジェクトマネジメントの経験を通じて、コミュニケーションスキルも身に着けられたと感じています。

入社から数年が経ち自信が深まったころ、さらにキャリアの幅を持たせたいという想いを抱くようになりました。KeepAliveのコアであるコンサルティングの領域に踏み込みたいと、大手不動産デベロッパーのコンサルティングプロジェクトへの参画を希望しました。そのプロジェクトは、タブレットを使った社内でも大規模なものでした。


プロジェクトに飛び込んだとき、今まで体験したことのない空気を感じました。一般のお客様を対象とした接客の最前線なだけに全員がスーツを着用し、折り目正しい行動を取っていました。それまでは私服でフレックスという自由な現場ばかりだったので、これまでの現場とは180度違う印象を受けました。

その上、コンサルタントとしてプロジェクトに参画するのは初めて。得意とするインターネットやWebに関係しない領域だったため、当初は自分がどのように役に立てるかイメージが湧かず、戸惑いがあったのも事実です。

カルチャーギャップと未経験の業務に試行錯誤。難しさを乗り越えて得た感覚

▲ 最初はカッチリした現場に戸惑いも

同プロジェクトは全体で200名ほどの規模で、たくさんの人が働きさまざまな役割をもっていました。

私が担当したのは、不動産のモデルルームで使用する接客用タブレットシステムの全国展開というミッションでした。具体的には、全国津々浦々のモデルルームに赴き現地の営業担当にシステムの使い方をレクチャーして、実際に業務が回るところを見届けるというものでした。

そもそもなぜタブレットシステムが導入されたかというと、販売センターの従来業務は、来場者からのアンケートも営業成績のグラフもすべて手書きというアナログな手法が主流だったからです。そのため、タブレットでの入力に変えてデータを集積し、商談管理システムと連動させ、再来率の分析や商談に生かしたいというのが導入の狙いでした。

しかし、いざ現場に入ったらレクチャーだけでは済みませんでした。まず、マニュアルとして使えそうなドキュメントは開発時の設計書のみで、ITリテラシーが高くない現場スタッフには難解すぎて使えないということが判明しました。

さらに現場の営業サイドからは、「こういう機能があったらいい」など、どんどん追加要望が入るので、その場でできない機能追加や改修は会社に持ち帰って開発チームに伝えるという役割も担いました。業務内容自体が難しかったことに加えて、カルチャーギャップにも悩みました。

顧客の年長者は、とくにアナログ的な従来の手法へのこだわりが強く、理解を得るのに苦労しました。また、モデルルームごとにやり方が統一されていない点にも戸惑いました。

これまでの現場では、「やるべきことをやる」のが正解だったのですが、ここでは「どうやったらユーザが楽になるのか」を考えながらやらないといけません。

ケースバイケースでまったく違うものをつくらなければいけない。今まではもののつくり方を覚えるだけで良かったのですが、ここではきめ細かな対応を求められました。その結果、残業が増えてしまいなかなか生産性が上がりませんでした。

しばらくして業務の標準化が完了し、つくるべきものも完成したのですが、細かすぎる対応や属人的な進め方に対する課題感が残りました。情報システムは、3~5人の少人数が対象の場合と、数百人が使う場合では話が違ってくると感じました。使ってもらう人が多いほど、そのような課題が増えるのではないかと思いました。

こうして、プロジェクトが終了して社内に戻った私に、2019年春「DevOps型情シスをつくれ」という新たなミッションが振られました。

そのとき、「営業支援プロジェクトで行ったマニュアル作成などの経験を生かせるのではないか」と思いました。さらに、最後まで課題と感じていたことを自分なりに解決してみたいという気持ちにもなりました。

DevOpsは再現性と持続性。データ共有・連結・連携を可能にする試み

▲ 作業はフリーアドレス&ペーパーレス

当時、社内にはDevOps型情シスに限らず、情シスと呼べるチームはなく、セキュリティや情報機器の管理などは一部のITリテラシーが高い社員によって最低限のレベルで行われているのみでした。しかも、それらに対するドキュメント類もなく、口頭での伝聞のみ。

たとえば、社員の入社・退社時の業務フローもドキュメント化・台帳化されていないような状態でした。プロジェクトにアサインされた後にアカウント発行がされていないこともありましたし、アカウント発行の権限を持つ人間さえも不明瞭という状態だったのです。

それまでは、20人程度の組織だったためそれでも回っていたのですが、中期経営計画に基づく人員の拡張に照らしたときに、ほぼすべてのしくみを刷新する必要があると考えました。

とはいえ、一気呵成にはできないので、まずは台帳やレギュレーションなどをドキュメントとして整備することからスタートしました。

また、再現性の担保と持続性の維持というDevOpsの考え方をベースにすれば、中間成果物となる台帳の更新が止まることは避けなければならないと思い、常に最新の情報を共有できるツールの導入が必須と考えました。

この考えに基づいて、紙運用を排除するために作成したドキュメント類のスプレッド化を進めた結果、常に最新データを共有・連結・連携することが容易に可能となりました。

続いて運用についてですが、ルールありきではなく、自動化の導入や機能を優先したフローの構築を心掛けました。

「手作業で繰り返し行われている・本来ならば自動化が可能な作業」のことを 「Toil」というのですが、この無駄をなくしたいなと思いました。そう思い立ち、業務スピードが落ちない社内ワークフローづくりを心掛けました。

今まで曖昧に行ってきた業務を明示的にルール化したので、メンバーにとっては窮屈に感じる部分があるかもしれません。しかし、業務の標準化によって「誰が何をやるのか」を明示した方が、やるべきことが明確になります。それによって業務効率が上がり、セキュリティに対する意識も高まると信じています。今後は、備品購入やアカウントの申請などもスプレッドシートを使って自動化していく計画です。

社員数100名規模へ。DevOps型情シスはその下支えになる

▲ 月に何度か経営に報告を行う

ブラッシュアップは継続中ですが、「DevOps型情シスをつくる」というミッションが成功したのは、思えばキャリアの幅を持たせたいという想いから参画したコンサルティングプロジェクトの経験があったからだと思います。

「ルールを押し付けるだけではみんな使ってくれない」「きめ細かな対応をすると時間がかかってしまう」そんな教育展開の難しさを教えてくれたのが、営業支援プロジェクトでした。

同プロジェクトで感じた課題感を自分ごとにできたことが、情シスをつくる取り組みでDevOpsを体現しようと思うきっかけになりました。

パラダイムシフトを受入れDevOpsエンジニアに進化―若手エンジニア1年の軌跡―」や「プラットフォーマーを目指して──DX推進に必要な力とは」 で紹介した通り、KeepAliveでは実案件での開発やコンサルティングにDevOpsを活用するべく日々研究に取り組み、ノウハウを蓄積中です。

「それなりの人員数が必要な間接職」というイメージの強い情シスですが、実際にはDevOps化が可能であり、少人数でも、ゼロベースからスタートし40人規模の会社の管理ができることが検証できました。

そして、2020年現在KeepAliveは社員を100名程度にまで増員するという中期経営計画の途上にあります。目標とする規模に近づけば近づくほど、今回完了した情シスのDevOps化はいっそう効果を発揮するでしょう。

当社の情シスの根幹を支える技術の大部分は、クラウドネイティブなものです。セキュリティの関係等でクラウドにアクセスできない大企業もありますが、今一度リスクと効果のバランスについて考え直してみるべきだと思います。

今回の整備結果は、まだ道の半ばです。常に最新のクラウド技術をキャッチアップし続けて、最終的には情シスの自律運転を実現したいと思います。それでは、また!