Est. 2004
構想から実装、そして運用まで。組織の課題を、分断せずに考える。
Design Before Technology
組織にとって最適なシステム構成を考える
次期システム更改プロジェクトの担当に任命された。
任されたことは素直にうれしかったし、期待されていることも分かっていた。ただ、この最初の判断がこの先を左右することぐらいは分かっていたから、勢いで決めるわけにはいかない。
現場の話を聞くべきか。製品を比較するべきか。ベンダーに相談するべきか。考えるほど、最初の一歩が決まらない。
ヒントを求めて、情報を集め始めた。AIにも聞き、比較記事を読み、セミナーにも足を運んだ。それでも増えていくのは技術の話ばかりで、違和感だけが残る。
「……本当に、最初に考えることってそれなのか。」
情報が足りないから、判断できないわけではありません。判断するための土台が、まだ見えていないだけかもしれません。
クラウドにもオンプレミスにも、OSSにも商用製品にも、それぞれの利点と役割があります。けれど、どれが一般的に優れているかを比べても、その組織にとって何が適切かは決まりません。何を実現したいのか、誰が使い、誰が運用するのか——その条件が整理されて初めて、技術の違いは意味を持ち始めます。
現場へ話を聞けば、営業には営業の、経理には経理の、情報システム部門には情報システム部門の理屈がある。どれも間違ってはいない。でも、その正しさをどう一つの方向へまとめればいいのか、見当がつかない。
ベンダーに提案を依頼すれば具体的になるかもしれない——そう思いかけて、手が止まる。この状態で提案書を並べても、何を基準に比較すればいいのか。価格か、性能か、将来性か。基準が決まらないまま比較しても、結局は印象や勘で選ぶことになる。判断材料は増えるのに、判断基準だけが見えてこない。
プロジェクトの初期段階には、さまざまな立場から情報が集まります。利用部門は業務上の課題を、情報システム部門は運用と継続性を、経営は投資と成果を、ベンダーは自社の解決策を、それぞれの視点で差し出します。
現場から集まる声は、どれも実際の課題です。だからといって、すべてを反映することが正しい判断とは限りません。何を採用し、何を採用しないのか。その線を引くための基準がなければ、声を集めるほど、かえって決められなくなります。
困って前任者へ相談すると、返ってきたのは一言だった。
「まずはアーキテクチャから考えよう。」
なるほど、とは思った。でもその直後、また別の疑問が浮かぶ。
「……っていうか、アーキテクチャって何なんだよ。」
ネットワーク構成のことなのか、クラウドの話なのか、それとも業務や運用まで含めた話なのか。言葉は知っているのに、自分が何を決めなければならないのかが分からない。
それでも、プロジェクトはいつか動き出す。設計が終わり、ベンダーも決まり、開発チームが動き始めてから、前提が違っていたと気付いたら——その時、自分は止められるのだろうか。多くの人が動き、予算も承認された後で「このまま進めるべきではない」と言えるだろうか。ここまで進めたという事実が優先され、止めるに止められなくなる。そんな未来を想像しただけで、背中に冷たいものが走った。
ベンダーに聞けば製品の話に、現場に聞けば部署の事情になる。プロジェクト全体を同じ高さから見て、一緒に考えてくれる相手はいない。最後に判断するのは自分なのだと思うと、急に一人になったような気がした。
Architectureという言葉は、技術構成やシステム構成を指して使われることがあります。しかし、N.H.Rが設計するのは、それだけではありません。
プロジェクトは技術だけで成り立っているわけではない。業務、組織、運用体制、人員、予算、既存環境、将来計画——これらは互いに影響し合う一つの構造です。運用する人員が限られていれば、優れた技術も維持できません。拡張性を重視すればコストは増え、利便性を高めればセキュリティとの新たな判断が要ります。
だから、技術を選ぶ前に、まず判断の基準を設計します。組織として何を実現したいのか。何を優先し、何を受け入れるのか。その判断を誰が、どのような根拠で行うのか——それが見えて初めて、無数にあった技術の選択肢は自然に絞られていきます。導入しないという判断も、既存を残すという判断も、この構造の中で意味を持ちます。
ただし、構造を整えること自体が目的ではありません。その先で組織が今より良い状態へ変わっていくこと。N.H.Rが考えるArchitectureとは、技術を選ぶための枠組みではなく、組織をより良い状態に変化させるための枠組みです。
Experience Changes the Questions
組織にとって本当に解くべき課題を見極める
部長に呼ばれた。
「今検討しているプロジェクトにコンサルティング会社を入れるべきかどうか、一度整理してほしい。必要だと思うなら、その理由も含めて役員会へ提案したい。」
コンサルティング会社か……。
仕事をしていれば名前を聞くことはあるし、大きなプロジェクトでは当たり前のように関わっていることも知っている。でも、自分で依頼したことは一度もないし、「何をしてくれる会社なのか」と聞かれたら、正直、自信を持って説明できる気がしなかった。
それなのに今回は、「導入すべきか、それとも必要ないのか」を理由も含めて整理しなければならない。
プロジェクトの初期段階では、このような迷いは決して珍しいものではありません。
情報が足りないから判断できないわけではありません。むしろ、情報は集めようと思えばいくらでも集まります。問題は、その情報を何と比べ、何を基準に判断すればいいのかが、まだ決まっていないことです。
コンサルティング会社を比較する。ベンダーを比較する。製品やサービスを比較する。その前に、本来整理しなければならないものがあります。「今回のプロジェクトで、外部へ何を期待するのか。」そこが曖昧なままでは、どれだけ情報を集めても、判断の材料は増えません。
まずは何社かホームページを開いてみた。
ホームページには実績や導入事例が並び、代表者やコンサルタントの経歴も紹介されている。まぁ、当たり前だけど、ネガティブなことが書いてある会社なんてあるはずない。
何社か見比べてみたけれど、「企業変革を支援します。」「DXを推進します。」「課題を整理します。」書き方は違っても、どこも似たようなことが書かれている。
何度か読み返してみたけれど、それらしいことしか書いていない。実績があることは分かった。立派な経歴が並んでいることも分かった。
多くの企業は、この段階から比較を始めます。
しかし、本当に比較するべきなのは、会社の知名度や実績だけではありません。その会社は、自分たちが解決したい課題に対して、どのような役割を担ってくれるのか。プロジェクト全体の中で、どこまでを任せ、どこからを自分たちが担うのか。その役割が見えなければ、実績も経歴も、判断材料にはなりません。
でも、それだけで「このプロジェクトにはコンサルティング会社を入れるべきです」とも、「必要ありません」とも判断できる気がしない。
「導入した方がいい」と言われれば、そんな気もする。「必要ない」と言われれば、それも間違っていない気がする。
部長に、何て答えればいいんだろう。
私たちが考えるConsultingとは、答えを代わりに出すことではありません。発注元企業の視点でプロジェクト全体を見渡し、意思決定できる状態をつくることです。
どんなプロジェクトにも、それぞれの事情があります。組織の文化も違えば、予算も違う。求められるスピードも、目指すゴールも同じではありません。だから私たちは、最初から「こうあるべき」という前提を持ってプロジェクトへ入ることはありません。
最初に考えるのは、「このプロジェクトにとって、本当に必要なことは何か。」その問いに向き合い続けることが、私たちの役割だと考えています。
Ideas Become Reality
組織にとって本当に必要な解決を、現実のものにする
役員会で承認が下りた。
ようやくここまで来た。
何度も現場へ足を運び、ヒアリングを重ねながら資料を書き直してきた。長年「いつかやらなければ」と言われ続けてきたシステム更改が、ようやく動き始める。ここから忙しくなることは分かっていたけれど、不思議と不安はなかった。これでやっと、現場が抱えていた課題を解決できる。そう思っていた。
プロジェクトが始まった頃は、誰もが同じ方向を見ています。
「この業務をもっと効率化したい。」「長年の課題を解決したい。」「新しい仕組みで組織を変えたい。」
そんな目的から始まったプロジェクトも、要件定義、設計、開発や構築へと進むにつれて、画面や機能、スケジュールやコストについて考える時間が増えていきます。
それは、構想を現実のものにしていくために必要な、ごく自然な変化です。
要件定義が進む中、現場の担当者から声を掛けられた。
「報告があります。ひとつ確認漏れがあったことが分かりました。」
嫌な予感はしたが、最初は大した話じゃないと思った。
でも、その要件一つでシステム全体の構成を見直さなければならないと分かった瞬間、頭の中が真っ白になった。
担当者は何度も「申し訳ありません。」と頭を下げていた。
正直、腹が立たなかったと言えば嘘になる。役員会も終わっている。もう少し早く気付いてくれていれば、こんなことにはならなかったかもしれない。
ただ、すべて今さらの話だった。
多くの人が関わり、多くの時間とコストを投じる以上、プロジェクトを予定どおり進めることは重要です。
一方で、プロジェクトが進むほど、「何を解決したかったのか」よりも、「何を作るのか」に意識が向きやすくなります。
システムを完成させることと、組織が抱えていた課題を解決することは、必ずしも同じではありません。
だからこそ、予定や計画を守ることと同時に、その計画が何を実現するためのものだったのかを見失わないことも、実装に向き合ううえで大切だと私たちは考えています。
もちろん、仕様変更はできる。
でも、役員会で承認された予算も、この計画を前提に動き始めたスケジュールも、そのままというわけにはいかない。ここで前提を見直すということは、ベンダーとの契約も含めて、プロジェクト全体をもう一度説明し直すことを意味していた。
「ここまで進んだのだから引き返せない。」
その言葉だけが、頭の中を何度もよぎる。
目の前には要件定義書と、その横には役員会へ提出した資料が静かに置かれている。
実装は、もう目の前だった。
私たちは、Implementationを単にシステムを構築する工程とは考えていません。
Architectureで考えた構造を。Consultingで導き出した判断を。そして、組織が本当に必要としていた解決を、責任を持って形にすること。
そのためには、経営の視点、予算やスケジュール、プロジェクト全体の流れ、構築やその先の運用までを切り離さず、一つのプロジェクトとして見渡しながら、組織が抱える課題を解決するという当初の目的を、最後まで見失わないことが重要になります。
新しい技術を導入することも、AIを活用することも、既存の仕組みを活かすことも、それ自体が目的ではありません。どれも、必要な解決を現実のものにするための選択肢です。
私たちが責任を持つのは、技術でも、製品でもありません。
組織にとって本当に必要だった解決を、現実のものにすること。
それが、私たちの考えるImplementationです。
Operations Drive the Organization
組織の未来は、日々の運用の中から生まれる
月次報告の時期が、また来た。
毎月使っている報告書を開き、いつものように実績を埋めていく。ここまでは、いつもと変わらない。
ただ、今回は一つだけ、いつもとは違う欄を埋めなければならなかった。
前回の報告会で、上司が資料をめくりながら言った。
「これ、毎月ちゃんと報告してもらってるんだけどさ。結局、運用が良くなってるのかどうかが分からないんだよね。問い合わせが何件あって、障害が何件あって、それに全部対応しました。それは分かる。でも、それだけだと毎月同じじゃない?」
言っていることは分かる。自分でも、毎月似たような報告をしているとは思っていた。
「何か改善の目標を置けないかな。できれば数字で。次回までに考えてみてよ。」
数字で、というのが厄介だった。
改善案を一つ書くだけなら、何かしら考えることはできる。でも数値目標として出せば、次からはその数字を自分たちが追うことになる。適当な数字を置いて、あとで自分たちの首を絞めるのは御免だった。
正直、面倒だった。
日々の運用では、利用者からの問い合わせに対応し、必要な作業を行い、その日に起きたことへ一つずつ対処しているうちに、また次の業務が始まります。目の前の課題を解決することが優先され、その場では最善だった対応も、次の業務が始まれば過去の出来事として埋もれていきます。
その一方で、日々処理されていく問い合わせや障害、対応の履歴には、組織がこれまで経験してきたことが残されています。
運用とは、組織が積み重ねてきた経験や実績を最も多く持っている場所でもあります。
今日も問い合わせは入っているし、午後には定例の打ち合わせもある。今の運用が破綻しているわけでもない。それでも責任者である以上、言われたことを放っておくわけにはいかない。
仕方なく、過去の実績を開いた。
数字はある。むしろ、いくらでもある。
問題は、そのうちのどれを目標にすれば「改善した」と言えるのかだった。
問い合わせ件数なら分かりやすいかもしれない。そう思って履歴を開いてみると、同じ分類の中にもいろいろな内容が混じっている。これを一つの数字として見ていいのか分からなくなった。
ならば別の数字はどうだろう。
そうやって見始めると、今度はその数字の中身が気になる。中身を見ると別のことが引っ掛かる。何か一つ、根拠を持って説明できる数字が欲しいだけなのに、見れば見るほど簡単には決められなくなっていった。
途中で部下から声を掛けられた。
問い合わせの内容を聞いて、以前にも似たケースがあったことを思い出す。
「それなら、○○さんに聞いてみて。たぶん分かるから。」
部下が席へ戻り、自分も報告書へ戻った。
そこで、ふと手が止まった。
なぜ自分は、○○さんなら分かると知っているんだろう。
以前にも同じようなことがあったからだ。では、そのときの対応はどこに残っているのか。手順書を開いてみても、実際の判断に必要なところまでは書かれていない。履歴を探せば何かは出てくるが、すぐに必要な情報へたどり着けるわけでもない。
だったら、きちんと残せばいいのか。
そう思って既存のナレッジを見ると、今度はほとんど使われていないものが目に入った。
「……そういう話でもないのか。」
日々の業務の中で一つひとつ処理されてきた出来事も、あらためて振り返ると、それまでとは違った姿を見せることがあります。
目の前の業務を回し続ける中で、その一つひとつを立ち止まって振り返ることは簡単ではありません。その場で必要な判断をし、問題を解決し、次の業務へ進む。それを繰り返すことで、組織の運用は支えられています。
けれど、そこで積み重ねられてきたものまで、過去の出来事として終わらせてしまうのは、もったいないと私たちは考えています。
繰り返されている問い合わせ、対応に時間が掛かった理由、その場で下された判断、誰かの経験によって解決されてきたこと。それぞれをあらためて見ていくと、その組織がどこで迷い、何を知り、どのように仕事をしてきたのかが見えてきます。
報告書に並ぶ数字だけでは見えなかったものが、そこにはあります。
日々の運用に積み重ねられているのは、処理された出来事の記録だけではありません。
その組織が、これまでどのように仕事をしてきたのかという実績そのものです。
一つ決めて終わらせたいだけだった。
なのに、一つ見れば別のものが気になる。その理由を確認すれば、また別のものを見ることになる。問い合わせ、対応の記録、手順書、ナレッジ。気になるところはいくつも見つかったのに、肝心の数値目標は何一つ決まっていない。
そろそろ決めなければならない。
何でもいいわけではない。でも、このまま調べ続けたところで答えが出るのかも分からない。
だったら、どこかで割り切って一つ選ぶしかないのか。
そう考えると、今度はその数字を来月の報告で説明している自分の姿が浮かんだ。なぜこの数字なのか。この数字が良くなれば、何が良くなったと言えるのか。
説明できる気がしなかった。
最初は、何か数字を一つ決めれば済む話だと思っていた。
今は、その一つを決めることの方が怖くなっている。
報告書へ目を戻した。
実績の欄は、いつもどおり埋まっている。これまでなら、もう完成していたはずだった。
その横に追加した「数値目標」の欄だけが空いている。
調べる前より、材料は増えていた。
それでも、その空欄に何を入れればいいのか……答えが見つからない。
日々の運用に蓄積された情報を整理し、異なる事実を重ねていくことで、これまで見えていなかった課題や改善の可能性が見えてくることがあります。
しかし、そこで見つかったものが、そのまま一つの解決策に結びつくとは限りません。
新しい技術を使うことが必要な場合もあれば、業務フローを見直すことや、既存の運用を整理することが最も合理的な答えになる場合もあります。
重要なのは、手段ではありません。
組織を正しく理解し、本当に必要としている改善を見極め、それを現実の運用として実現することです。
私たちは、Operationsを日々の業務を維持するためだけの活動とは考えていません。
組織に積み重ねられた経験や実績を整理し、改善につなげ、新しい価値を生み出すこと。
それが、私たちの考えるOperationsです。