業務改善Tips｜Q&Aとアドバイス実例集

弊社の業務改善で、ベースになる作業進行と考え方

• 想定
• 問題点の収集
• 想定の修正
• 問題点の収集
• 改善案の立案
• フィジビリケーション（導入実験）

想定がなければ、問題の本質に近づくのに時間がかかってしまいます。
想定が間違っていれば、壁打ちが進むきっかけになります。

問題点の収集では、クライアントの要望や困っている点を実際にヒアリングします。
実際に業務を数日ないし数時間拝見し、改善点を洗い出していく作業も行います。

想定の修正では、想定した問題点がそうであったかなかったかを、事実から判断し修正します。
また既存の問題に対し、本当にそうなのか？何故そうでなければいけないか？という問いかけを何度も繰り返すことで、問題が見えてきます。

問題の本質が見えてきたなら、再度問題点の収集を致します。
具体的な課題を見つけ、問題を細分化し、クリティカルパスを見つけます。

改善案の立案では、様々な提案をします。
例えば、
既存のシステムを全く変えないで、スタッフの意識を変える。
現行システムを全廃して、新システムへ移行。
など、振り幅の大きいプランを提示しつつ、現場作業の効率化は徐々に進めるなど、硬軟織り交ぜた提案を心がけます。

新しい仕組みの導入に関しては、急激な変化には抵抗感が生まれます。
そこに人がいて、既存のやり方に親しんでいるからです。
簡単な業務から順に、新しい仕組みに移行していくことで、作業理解が進み、業務改善に至ります。

新規事業におけるアドバイス例

税金関連

税関連の問題を解決したい意向が、みなさんございます。
やり始める前にアテはあった方がいいという形で、IT以外の相談で一緒にヒアリングを受けるのが税金の話です。
弊社からもご紹介は可能です。
税理士と会計士は違い、個々に得意分野も違いますが、弊社は税理士さんをおすすめします。

IT業務改善でのアドバイス例

表作成

なんらかの分析をされていて、その流れが表になっているものをよく見ます。

分析のフローチャートだとして、そういうのは、左から右、下から上に、逆さに読んでも、意味が通じるはずです。
悪い表は、逆から読むと意味が通じないです。

表題に書いてある重要なキーワードが、分析表に一度も出てきません。
勿体ないです。
表内で大事な伝えたいことやキーワードは、資料内で表記を統一し、積極的に使ったほうがいいです。まとめと省略と手抜きは違うと思います。

納品物の検収コスト

多くの場合、発注側が納品物を検収するという観点が抜けています。
エラーチェックのコストも見込んでください。
どなたがそれをやるのか担当者を任命するところからです。

開発したツールの寿命

制作ツールが、安定して動作し続ける期間は、想像以上に短いです。
減価償却に年数が決まっていることからも、目安になるかと思います。

iPhone用アプリを例にすると、iOSはバージョンのアップデートが頻繁に行われます。
せっかく作ったアプリも、新バージョンでは動かなくなるかもしれないです。

アプリを発注し完成してやったバンザイですが、そこから戦いは始まります。
運用保守の観点と、会計経理における減価償却も考えると、ツールの寿命が決まってくるでしょう。

これは開発が一度終わっても、継続して開発は発生するということになります。
作って終わりは趣味の範囲の話なら許されますが、会社経営となるとそうはいかないはずです。

開発会社の実態

手離れのいい仕事を好む傾向があります。
これはITでも、技術者を都度アサインすることが多いためです。
ずっとその人がそこにいるわけではないから、ある期間で絶対に作り切る必要があります。

そして中抜き構造が、人と人とのつながりを分断することにもつながります。
「間に人が入りすぎて、意思疎通にズレが生じる」ため、案件の対応期間が長いとズレが大きくなり、クライアントもイライラ、技術者もイライラ、中抜きしている人間もイライラとなります。
手離れの良い案件が好まれる理由です。

弊社は基本的に代表が一人で応対し、プロジェクトに他の技術者の参加を仰ぐことがあっても、中抜きをしません。
中抜きをすることで、本来支払われるべき報酬額の減額が起こり、作業社の作業精度に影響が出ます。

見積もり時の請求額が立派でも、会社の体制や信頼には関係ありません。
判断するべきは、どう対応するかという姿勢なのです。

長くお付き合いをしたいなら、会社選定を考える必要があります。
有名だから安心ではありません。