募集職種

社長が1対1で面接する。所要時間は約1時間。

3次面接後2〜3日以内に内定の旨を伝える。その後、社長と人事部長が同席して処遇や期待を説明する。

【通過率：約7割】

漆原：
　（あいさつを交わしたあと）【Point1】早速ですが、清水さんの職務経歴を説明してください。

清水：
　私は、新卒入社した○○○（大手SI会社）に来月で丸四年勤めることになります。最初のプロジェクトは人事給与システムの開発でした。Javaでのプログラミング、結合テスト、導入までを担当し、下流工程を学びました。
　次が社内向けの開発標準策定プロジェクトです。これは、エンジニアリングの各フェーズでどんなタスクを行うかの定義付けをし、標準化を図るのが目的です。【Point2】経験のないフェーズのインプットとアウトプットを定義付けする作業もありましたが、私なりの「教科書」をもてた意義がありました。
　3番目が、通信回線の料金見積もりツールの開発でした。Webアプリケーションです。このプロジェクトで初めてサブリーダーになり、協力会社の社員3人を付けてもらって、マネジメントのさわりを勉強できたように思います。

　4番目が業務改善コンサルでした。お客さんは通信キャリアで、タイプの異なる回線商品を組み合わせて提供する際に、部署間の連携が必要でした。そのためのシステムを、業務改善と併せて提言しました。その後、システム開発へと発展したので、私は引き続き要件定義まで担当しました。
　このプロジェクトの経験はとてもためになりました。各担当者のデスクのそばで事細かにヒアリングもし、お客さんが現実に必要としているものを把握してまとめるという作業を体験できたからです。
（このあと、コスト面の理由から立ち消えになった5番目のプロジェクトについて説明する）

清水：
　そして、6番目が直近のプロジェクトで、電話局内サーバ設置業務支援システムの開発です。これはサーバ設置申し込みワークフローでした。私はチームリーダーとして入り、お客さんと仕様の調整をしながら進捗管理、テスト仕様の策定、障害管理などを行いました。
　この仕事ではリーダー経験も積めましたが、それよりデスマーチの体験が大きかったです。【Point3】われわれが苦労すれど、お客さんから怒号が飛び、仕様はつぎはぎになっていく。このシステムは最終的にお客さんにとって良いものなのか、本当に使われるのかと疑問を抱くほどでした。

　最大の原因はRFP（提案依頼書）自体に問題があり、RFPの範囲内でシステムを作る立場の私には、根本的な解決を図る道がなかったのです。【Point4】これがITコンサルへの転身を図る動機となり、転職活動をしています。

漆原：
【Point5】そういう経歴を積んできて、自分が最も得意だと思えることは何ですか？

清水：
　技術を深くいくというよりは、人を取りまとめて何かを作るという経験のほうが多かったですから、得意なものを挙げるとすればリーダー業務だと思います。

漆原：
　【Point6】システムの内容も立場も異なる仕事をいろいろ体験してきた中で、これは大変だったとか、やったなと思えるプロジェクトはどれですか？

清水：
　そういう意味では2つあります。ひとつは通信キャリアの業務改善コンサルティングです。お客さんは業務上の不都合や不効率を既に知っているんですね。知っていながら解決策を見いだせずにいる。その中へ第三者のわれわれが入って変えていくには、われわれが改善の核になり、核の周りに改善の層を広げていく必要がある。そういうことを実地で理解できたのは感銘深いことでした。
　もうひとつ記憶に残るプロジェクトは、直近のワークフローの設計・開発です。デスマーチの中で、それまでのシステムの作り方を疑問視するきっかけになりました。

漆原：
　【Point7】1つ目の業務改善という仕事は初体験だし、お客さんの期待値も高かったはず。どんなところが大変でしたか？

清水：
　初めてとはいえ、取り組めば徐々に改善の方向性は見えてきます。具体的なものにもなっていきます。しかし、それがだれにでも好ましいとは限りません。人によってメリットとデメリットが異なります。そのあたりを立場の違う人たちに納得してもらったうえで、受け入れてもらうという作業がいちばん大変でした。

漆原：
　　2つ目のデスマーチの仕事のほうは、どんな方法を取ればよかったと考えますか？

清水：
　そのプロジェクトに私が入ったのは火消し役としてでした。論理設計の途中くらいからで、私は必死で作業を進めました。その中で気付いたのは、お客さんの信用を当初から得ていないということでした。引き継いだドキュメントの内容にもそれが如実で、誠実な対応に欠けていると思えました。最初に信頼関係を築き上げておけば、あそこまでのデスマーチにはならなかったろうと思います。

漆原：
　プロジェクトを遂行していて、どんなときにうれしさや充足感を感じますか？

清水：
　【Point8】これが完成したら、お客さんは本当に喜ぶだろう、楽になるだろうと思えるシステムを作っているときに最も充足感を覚えますし、システム完成後に、お客さんから「とても楽になった」「便利でいい」といった評価が伝えられてきたときが最もうれしいです。

漆原：
　【Point9】技術面について伺います。電話局内サーバ設置業務支援システムのプロジェクトでは、SQLサーバを使ったデータベースの要件定義もしたのですね。開発規模はどれくらいですか？

清水：
　300人月程度です。

漆原：
　データベースのエンティティの数はどのくらいですか？

清水：
　30〜40です。

漆原：
　データベースを設計するとき、どこに最も気をつけましたか？

清水：
　基本的には、データが分散したり冗長化したりしないようにすることです。ただし、実際にSQLでデータを取得する際に、多数のテーブルをジョインしなければならないのは性能的にツラいので、性能と設計との兼ね合いを図りました。

漆原：
　根幹となる論理データはどんなものでしたか？　3つほど挙げてみてください。

清水：
　具体的な名称でいうと、回線リソース調査申し込みテーブル、回線リソース設置申し込みテーブル、開通工事申し込みテーブルです。

漆原：
　【Point10】ITコンサルタントを目指して転職したいということですが、動機の部分をもう少し詳しく聞かせてください。それと、なぜ弊社を志望するのかも。

清水：
　SI会社の立場でシステムを作る場合、RFPの枠内に収まるものという前提があります。RFP自体にズレがあったり、必要な機能がもれていても、SI会社は「残念でしたね」というスタンス。さらには、「言った」「言わない」の水掛け論で敵対関係になってしまうことすらあります。
　これでは皆が不幸です。ならば、本当にお客さんの立場に立ってRFPを策定するところから仕事に入っていきたい。そうすることで、皆がハッピーなシステム構築をしていきたい。これが転職の動機です。

　では、なぜ御社なのかです。コンサルティング段階でも誠実にお客さんの立場に立たなければ同じことで、パワーポイントで提案書を作り、あとは知らぬと逃げてしまうコンサルティングファームもあるようです。しかし、御社は最後までお客さんを支え切るスタイルです。私の望む働き方ができると思い、応募させていただきました。

漆原：
　弊社の具体的な仕事のイメージはできていますか？

清水：
　はい。業務プロセス改善や業務支援システムの開発などが中心と想像しています。お客さんと一緒に課題を考え、解決に至るまでお客さんとともに歩んでいくというイメージです。

漆原：
　【Point11】弊社の仕事上で期待していることは何ですか？

清水：
　お客さんとの信頼関係をしっかり築いて仕事ができること。プロジェクトを通じて人間的にも技術スキル的にも成長していくこと。大きくこの2点を考えています。

漆原：
　【Point12】弊社の仕事は非常に現場重視で、泥臭い面が多々あります。お客さんの経営と現場の板ばさみになりそうになったり、火消し役で投入される案件もあります。やればやるほど難しくなるプロジェクトのほうが多いくらいです。それでも、イメージに合っていますか？

清水：
　きれいな働き方をしたくて御社を望んでいるのではありません。私のイメージと大きな違いはないはずです。
（このあと、漆原氏は5年先と10年先の目標について尋ねてから、清水さんに逆質問を促した。清水さんは、大企業とベンチャー企業の違いについて漆原氏の考え方を尋ねた）

　入社のいちばんの決め手は、面接時に社長から聞いた「ベンチャー企業は自社または業界にとって必要なことなら、リスクをとってでも挑む。それが当社の姿勢だ」という言葉でした。共感できたんです。元気な会社だと思いました。また、選考の速さにも好感をもちました。1次面接から内定までが、わずか1週間。これなら経営上の意思決定も速いだろうし、それほどまでに私を気に入ってくれたのかと心底うれしかったんです。