三上 光徳
最新記事 by 三上 光徳 (全て見る)
- 司法書士の営業・集客方法【まとめ】 - 2019年1月10日
- 司法書士のSNS活用戦略／FacebookやTwitterなど - 2019年1月10日
- 司法書士のセミナー戦略 - 2019年1月10日
こんにちは、三上です。
私の会社では、コンサルティングの他にシステム開発も行っています。
『システム開発』とかいうメニューを掲げていると、こんなことを言われたりします。
[voice icon=”https://m-associates.co.jp/wp-content/uploads/2016/09/shacho1.png” name=”どこぞの社長さま” type=”r line”]システム開発とかすごいですね～、私は全然苦手でして』
三上『私も苦手なほうです』
[voice icon=”https://m-associates.co.jp/wp-content/uploads/2016/09/shacho1.png” name=”どこぞの社長さま” type=”r line”]とか言いながらちゃちゃっと作っちゃうんでしょ、理系出身だしさ』三上『エクセルVBAの勉強の入り口で挫折しました』
今回は『システム』っていう言葉を聞いただけで拒否反応を起こしてしまうような人へ向けて、
実はあなもシステム開発の花形プレーヤーになれるかも！
ということをお伝えしたいと思います。
システムに苦手意識がある人が抱きがちな思い
①パソコンとかスマホとか苦手だし私には向いていない
まわりに一人や二人絶対いますよね、パソコン、スマホ大好きって言う人。
だけど、このような人達がシステムの『開発』ができるかっていうと、それは全く別問題です。
パソコン、スマホなどのIT製品に興味があって詳しい人というのは、あくまでその製品のユーザーとして詳しいのであって、システムを『作る』となるとまた別の話です。
もちろん、興味があるということは大きな出発点なのでとても大事なことではあります。
が、もっともっと大事なことがあります。
②プログラマーはみんな天才である
天才は言い過ぎかもしれませんが、確かに頭が良い人、論理的思考力が高い人が多いのは確かです。
が、あなたがプログラマーになる必要はありませんし、（年齢等の状況によりますが）なるのは相当大変です。
システム開発はプログラマーだけでは成り立ちませんし、むしろもっと大切な役割があります。
③システムってあのアルファベットの羅列みたいなのを理解しないといけないんでしょ
プログラミング言語は、C言語とかJavaとかRubyとか色々ありますが、プログラマーを目指す人を除いては理解する必要は全くありません。
また、プログラマーもすべてを理解して憶えているわけでもありません。
そんなことを憶える暇があったら、もっと理解しておくべきことがあります。
④テレビとかの配線も苦手なんだよね
家電の配線とシステム開発は別物です。
⑤あたし文系だし
プログラマーになるなら別ですが、直接的な関係はないです。
⑥あたし女だし
まったく関係ないです。
システム開発において重要なこと
すべては現場からはじまる
システムというと大きく分けて、
- パッケージソフトを購入する場合（あるいはプラスアルファでカスタマイズする場合）
- 各社毎に要望を聞いてそれを具体化する場合
があります。
パッケージソフトの利用
メリット
この場合、既に出来上がっているものを導入するので余計な時間がかかりません。
ビジネスにとって「時間」は非常に重要なファクターなのでこのメリットは非常に大きいです。
特に簡易なシステムだったり、至極単純な作業、あるいは極めて標準的で一般的な作業を実現したいのなら良い選択だと思います。
また、ある程度のユーザー数の利用が見込まれている、あるいは既に実績としてあるケースも多いので、そういう意味での安心感はあります。
デメリット
デメリットとすれば、そのパッケージソフトに自社の業務や業務の流れを合わせにいかないといけないので、自分たちの理想を実現することはできなくなります。
あるいは、理想を描こうという前向きな気持ちを削いでしまうかもしれません。
各社毎の要望をシステムとして具体化する
今回の記事のメインテーマはこちらです。
この作業において重要なのは、システムによって何を実現したいかです。
言い換えると現状の何に不満があるのかということです。
そして、その不満は現場の業務をよ～く理解している人だからこと感じることができるものであり、現場業務をよく理解している人こそ業務システム開発における花形プレーヤーなのです。
SE（エスイー）やプログラマーが知りたいのは現場の思い
システム開発とは、以下のような流れで行われます。
- クライアントが実現したい要望を聞き出す、あるいは明らかにする
- SEがそれを要件定義書（プログラマーへの設計指示書のようなイメージ）という形にまとめる
- プログラマーが要件定義書に従いプログラミングを行う
この３つの流れの中で特に重要なのは、1.の実現したいことを明らかにする工程です。
そしてそのためには、現場の思いが必要不可欠なのです。
いくら優秀なSEやプログラマーがいたとしても、作りたいモノがなければ何も始まらないのです。
現状に不満を持とう！
変なサブタイトルになってしまいましたが、理想のシステムを描く花形プレーヤーになるためには、現状に不満を持つことが非常に大切です。
とはいえ、
という感じの人も多いと思います。
そこで、不満を持つための具体的な手がかりを列挙してみたいと思います。
単純作業ばかりしている
コンピューターとは、“単純な作業を超高速で行うことができる機械”です。
そして、システムとはそのコンピュータの特性を生かして、ある特定の目的を遂行するためにデザインされた作品です。
つまり、単純作業に落とし込めるものがシステム開発の良いターゲットとなるのです。
例えば、
- ある数値とある数値が一致しているかどうかを確かめる作業
- ある数値を決まった場所に入力する、あるいはコピー＆ペーストする作業
- ある表を一定のルールに従って違った表に組み替える作業
などは、人間がやるとむしろミスをするが、システムがやるとミスをせず正確に行う典型例です。
普段の業務でこのような単純作業は意識してみると意外とあるものです。
同じような作業を2カ所で行うダブり作業
これもケースとしては結構あります。
コミュニケーションの極めて良好な組織であれば気付くかもしれませんが、人間の注意力が及ぶ範囲なんて思ったよりも小さいものです。
このようなケースは、システム開発の前に、全社的な視点での業務フローの改善の話となるケースが多いかもしれません。
また、各人、各部署で同じ性質の作業を行っているということであれば、システム開発という大げさな事ではないちょっとした改善ツールの作成が意外と効果が高かったりもします。
他社あるいは他部署の作業と比較してどうか
人は、他人と比較することで感情が動く生き物です。
転職経験がある人ならば、
みたいな経験が、１つや２つあることと思います。
システム開発に限ったことではありませんが、他社に勤めている友人、他部署の人などと意見交換（不満交換？）をしてみることは改善のための良い手がかりになる可能性が高いです。
いわゆる『壁打ちの相手』は積極的に確保しておくとよいでしょう。
SEやプログラマーに不満を伝えることから開発がスタート
SEというとかなり幅広い意味をもってしまいますが、ここでは「クライアントの要望をプログラマー向けに翻訳して伝える人」というようなニュアンスで言葉を使っています。
開発規模にもよりますが、SEとプログラマー両方の役割を兼ねることができる人も多いです。
社内にそのような存在がいればベストですが、システム系の部署は既に与えられている仕事があり、業務効率化や業務改善といったものにはなかなか関与できないケースが多いような気がします。
以下では、社内業務の効率化を目指したシステム開発を進める上で、意識しておくべき事項を列挙してみます。
なおここでは、既にやるべきことがガチガチに定まっているような開発ではなく、社内業務の効率化のような業務システム開発を想定して記載します。
システム以前に業務フローに改善の余地はないか
不満の解決法として、システム以前の業務フローの改善で済んでしまうこともよくあります。
また、システム開発による改善を真剣に考え出すと、紐づきで業務フローについても真剣に考えざるを得なくなるという面もあります。
やみくもにシステム開発に突っ込んでしまう前に、業務のフローを含めたトータルの仕組を見直す機会も非常に重要となります。
要件定義が固まらないかも
ここで言いたいのは、要件定義を進めていくうちに、よくも悪くもクライアント側の理解が深まってしまうということです。
SEが要件定義書を作成し、クライアントに提出したとしても、その段階ではクライアント側では明確にイメージできていないことが多いです。
システムに詳しくない人が要件定義書をみたところで、
くらいなものです。
このあたりはSEのコミュニケーション能力に負うところも大きいかと思いますが、それでもやはり限界があります。
そして、実際にシステムの試作版ができあがった段階で、
みたいなことになりがちです。
これは、なかなか回避するのが難しく起きがちな事象なので、事前に開発者側とクライアント側でこのような状況に陥ることを前提として話をしておくとよいでしょう。
小さく着手する
業務の効率化を目指した業務システムの開発では、まずは小さくはじめることがお勧めです。
『全社をあげての大規模な開発で、開発はかの有名なXXX株式会社が行います！』というようなケースは別です。
また、何度か仕事を発注したことがあり、既に信頼関係が出来上がっている会社に依頼する場合も別です。
しかし、例えば、
- 利用するシステム会社との取引は初めてである
- 理想とするシステムの全体像のイメージがまだ沸いてきていない
というような場合、業務改善を図りつつ理想のシステム像を描くというところから始める、という進め方が結果として効率的でかつ効果的な結果となる可能性が高いです。
まとめ
- 現場の業務を誰よりも理解しているあなたこそが、業務システム開発における花形プレーヤー
- 他社や他部署と比較して、業務に対する不満を感じよう
- 理想は変化するので、最初は小さく着手することがお勧め
