第3回 選んだのは「内製回帰」の道――ひとり情シスの挑戦
湯本堅隆（GoTheDistance）
2009/12/18
■ 内製化の困難とやりがい
大前提として、内製化を正しく実行するためには、まず下記のポイントを網羅的に押さえなくてはなりません。なぜなら、そうしないと進化させるポイントを判断できず、目的を見失ってしまうからです。
すべてを変えることはできません。重点的にここを変えていかなければならない、というポイントを見いだすことが先決です。
- 自社のビジネスプロセスがどういう構造なのか
- 各業務をどのように回しているのか
- 業務と業務のつなぎ（発注→仕入など）はどのように橋渡しされているのか
とはいったものの、「自社のビジネスプロセスがどういう構造なのか」ということを知るのは、決して簡単ではありません。みんな、自分の負っている仕事をこなすだけで忙しいわけですから。筆者もそうでしたが、自分の部署だけに閉じていたら、会社のことは絶対に分かりません。
| エンジニアライフ コラムニスト募集中！ |
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
筆者がお勧めするのは、PMや営業など、顧客寄りの人たちがどうやって案件を受注しているのかを知ることです。やり方は簡単です。「その資料作り、手伝わせてもらえませんか？」といえばOKです。筆者は実際にそうしました。自社のビジネスプロセスに興味があるのなら、何らかの形で提案書作りにかかわってみてください。案件の立ち上げにかかわると、仕事の全体像が見えてきます。
もう1つは、雑務を注意深く見ることです。決裁の申し立てや月末処理など、他部署との協力で初めて行える仕事はたくさんあります。どんな立場の人がどういうかかわり方をしているのかを知るのもいいと思います。雑務は皆に等しく求められるものですから、裏方のスタッフがどうやって仕事を回しているのかを知るのもいいでしょう。
筆者が現在所属しているのは中小企業なので、筆者1人の力で全体を把握できます。しかし、中〜大規模な企業では、経営・情シス・現場がチームを組んで取り組む必要があります。何しろ、現在の筆者のように、社員が数人という小さな所帯であっても、自分の業務に追われると「このシステムに何を求めているのか」が見えなくなってしまうくらいですから。
ポイントが明確になったら、次に「実際に業務を体験してみる」ことが必要です。実際に体験してみると、以下のことが分かります。
- このシステムの機能が何をやっているのか
- 業務を損なっている不都合・問題は何なのか
- 本来はどういう機能を提供すべきだったのか
簡単にいえばフィットギャップ分析です。机上の空論ではなく、血が通うようになります。
筆者の場合は、社長の「これが困ってんだよなー」の一声で動き始め、機能改善を行います。「ひとり情シス」の場合、機能改善が引き起こす不具合はすべて自分に跳ね返ってきますので、大変スリリングです。「ちょっとスマートじゃないけど、取りあえず動くからいいや」ということを調子に乗ってやっていると、不具合があったときにプログラムで解決できず、自ら残業して手作業でリカバリする羽目になったりするので、注意が必要です。
また、ユーザーの「これが困ってんだよなー」の中身は多段構造になっていることがほとんどです。よって、「困ってんだよなー」をうのみにすると、「いったのと違うぞ」ということになりがちです。困ってることから分かるのは、要求と仕様がミスマッチである、ということだけです。本当に欲しかったものは、要求の奥に潜むニーズに隠れています。本当の要望を根気強く見つけ出すことが重要です。
内製して機能を作り込んでいくと、「あれもいるんじゃないか」「これはどうだろう」という具合に、良くも悪くも風呂敷が広がっていきます。筆者は「ひとり情シス」ですから、余計に広がります。正直、ここには戸惑いがあります。自分が使う機能を作るのは簡単なのですが、使ってもらえる機能を作るのは難しいのです。ユーザーと筆者とでは機能に対する感じ方やとらえ方がまったく違うからです。
As-IsとTo-Beが描ければ、後はそれを埋める機能を実装するだけです。基本的にこの繰り返しだと考えます。内製化の最大の障害は「結局どこを内製すれば会社の全体最適に貢献できるのか」というポイントを見定めるところにあると日々感じています。
■ 「ひとり情シス」になって得たもの
SIerでエンジニアとして働いていたころと、内製を推進するエンジニアになったいまとでは、意識の変化がありました。SIerでエンジニアをやっていてつらかったのは、「システムを使っているユーザーの顔が見えない」ことと、「設計から実装までの工程が分断されている」ことでした。内製化は、この両要因を可能な限り最小化できます。自分で自分が使う機能を実装するのですから、やっぱりそれは楽しいのです。「プログラムが書けて良かったな」と思える瞬間が多くなると思います。エンジニアとしては、それが一番幸せなことなのかもしれません。
「ひとり情シス」の場合は、自分が使いたい言語を使えばいいし、使いたいライブラリを導入できます。すべて自分のリスクになりますが、ソースコードが公開されていればどうにかなります。技術的制約はありません。求める答えが得られるなら、自分が正しいと思うやり方でやればいいだけです。
その代わり、「自分のスキル＝会社として実現できること」という図式になるため、外注する余裕がない会社においては、エンジニアは逃げ場がかなり狭くなります。
最近、最も戸惑いを感じているのは、「作ったシステムをちゃんとユーザーに使ってもらえているか」ということです。もともとデモ程度に作ったシステムに対して片手間で機能追加を施していったので、全体像がぼやけてしまっているのです。
現在はたたき台になるシステムがやっとできた状態です。これからどうにか進化を遂げるため、「できる」方法を探し続けてはトライ＆エラーを繰り返していかないといけません。それを思うと、げんなりすることもあります。雑務や会社としての業務も入ってくるので、なかなかスケジュールが思うように組めません。またげんなりします。筆者の時間は有限なのです。
ですが、「うおー、これができるようになったら相当、仕事が楽になるなー」とか、「これがちゃんとフォローできて情報分析できるようになると、もっともうかるだろうなー」とか、そういう楽しいアイデアが浮かんでくる時間が増えました。それがやりがいになっています。会社の成長を感じながら企画から実装まで自分で行っていくのは、とても楽しいです。
新しい気付きもありました。ずっと上ばかり見上げていると、「いまやるべきこと」と「いつか必要になること」を混同してしまって、良くないということです。
一気に全部やる必要はありません。段階を踏んで考えていけばいいのです。小さくても確実にできることを積み上げて、スピードを速くすること。間違えたとしてもリカバリするスピードが速ければ、どうにかなります。スピードに勝る問題解決はないなと感じています。
内製するのに進化をあきらめたら、何の役にも立ちません。
ソフトウェアに携わるプロとしての自分自身の進化で、会社の進化を促していく。そんな未来を筆者は夢見ています。
同時に、そのスピリッツを持続するということが、内製志向のエンジニアには最も大切なことだと思います。
| 筆者プロフィール | ||
|
 |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
