アイロベックスメールマガジン　携帯版

「難しい」「大変だ」は、“ボケ”の言葉。

なんか、変なことを書きました。
大阪の人は、幼少の頃から、“ボケ”と“ツッコミ”の教育を、知らず知らずのうちに受けているというのは、本当でしょうか。
そういう意味では、頭の回転が速い人が多いような気がします。（気がするだけ・・・）

さて、システム開発をしていて、「これは！」と、頭の中で電球が輝くときがあるのですが、どんなときかというと、プログラマとの会話をしたときです。

前回もお話ししましたように、プログラマというのは、些細なことを、全て網羅して理解していないと気持ちが悪い、というような人たちです。

お客様やSEが、「そんなこと、どちらでもいいのではないか？」と思うようなことを、丁寧に、細かく考えて、プログラミングしてくれるのです。
褒めているのか、けなしてるのかといえば、褒めています。

しかし、そんな彼らも、ときに曖昧な発言をするときがあります。
「たぶん・・・」とか「・・・と思います」とか、「・・・・・・・」
黙ってしまうのもプログラマの特徴なのかもしれません。

こういうとき、SEはこれを“ボケ”だと思って、“ツッコミ”を入れることが要求されるのです。

「それって具体的にどういうこと？」
「どこに書いてあったの？」
「どういう検証をしたの？」
といった事実に落として、聞くことが必要になります。

一番注意すべき、プログラマの言葉は、
「大変なプログラムなんです」
「難しいんです」
といった言葉です。

言葉いじりをするつもりはありませんが、「難しい」って、どういう意味でしょうか？

彼らにとって、これらの言葉は
「仕様が100％理解できていない」
「どういうプログラミングをしたらいいのか、今は判断がつかない」
「プログラムで経験したことがない機能が含まれている」
といった意味なのです。

これをきちんと切り分けて、対策を練ってあげる必要があるのです。

「仕様が100％理解できていない」
この場合は、簡単です。
大きく、全体像をイメージとして分かりやすく話してあげること、これは前回、伝えたような内容です。
それから、細部においては、プログラマの視点に合った、図やデータ事例を見せてあげることが必要でしょう。

初心者の場合には、先輩プログラマを通して伝えてもらうことも必要かもしれません。

「どういうプログラミングをしたらいいのか、今は判断がつかない」
といった場合は、どのような選択肢が考えられるのかを、レビューする必要があります。
これも、SEと上級プログラマ、本人の3者で行うのがよいでしょう。

そして、
「プログラムで経験したことがない機能が含まれている」
これは、自社に経験者がいるのであれば、問題ありません。
経験者からサンプルを貰うこと、経験者を補助につけることが大事です。
こういった場合に、補助なしで、サンプルだけで仕事をさせるのは、リスクが大きくなります。

問題は、自社で経験者がいない場合です。
この場合は、一部機能だけを検証するプログラムを作らせる必要があります。
「やればできる」部分を徹底的に省いて、テストさせるのです。

そして、「難しい」という言葉、これを私は認めません。

プログラムで難しいロジックは不要なのです。

「難しい」は、「組合せが多様である」というように分解するのです。
そして、
「組合せパターンを網羅しての設計ができているか？」
はたまた、パターンではなく、
「方程式といったもので解決ができないのか」
を、考えるべきなのです。

プログラマの「大変だ」「難しい」は“ボケ”の言葉。
SEからの“ツッコミ”を待っている、アラームなのです。

最近は、「画面入力だけ作ってください」といった依頼も増えてきました。

これは、一つには、CSVや、テキストデータを作る仕組みさえ作っておけば、帳票やグラフは、データウェアハウスで、自由に作表した方が良いといった理由があります。

しかし、長年、システム作りをしてきた立場から考えると、「入力」だけのシステムというのは、やはり「何かが足りない」ような気がします。

24時間稼動のシステムも増えてきました。
そして、誰がいつ、どんな情報をインプットし、アウトプットしたのか、を管理する（操作ログ）仕組みも当たり前の時代になりました。

しかし、それがあるからといって、操作ログを頻繁に見るようなことは、現実的ではありません。
操作ログは、膨大な数に上ってしまうからです。

ログについては、いずれお話することとして、今回は「帳票の意味」について、掘り下げてみたいと思います。

システムで帳票を作成する意味は何でしょうか？

1）Excelや、データウェアハウスの扱いに慣れていない人でも作表できる。

2）レイアウトを定型にすることで、膨大な情報の集計から、企業として重要なポイントだけを切り取って表現することが可能となる。

3）情報の入力、チェック、作表、蓄積、消込みといった一連の流れの中で、ある一定のタイミングで情報が集計されることが保証される。

4）誰がいつ、どこで作表しても同じ結果が出る信頼性がある。

この中で重要な視点は、3と4だと思います。
特に、3の「一定のタイミング」ということ。
4の「時を選ばない」ということが、SEが成長する上で欠かせない知識です。

「一定のタイミング」が、どのタイミングなのかは、その帳票を見る人全員が、はっきりと分かっている必要があります。

例えば、国内だけで商品を販売している企業について考えてみましょう。

ここのお店は、ネット通販も行っていて、24時間、在庫の予約が可能であるとします。
しかし、出荷は、宅配業者にお願いしているので、毎日、夕方18時までには終了するとします。

売上を計上する基準というのは、業種・業務によって多少異なりますが、ここでは、最も一般的である「出荷基準」で売上計上している、という前提で考えます。

1日から末日までを集計した、「月間在庫管理表」を作成するとします。
末日を集計するタイミングは、いつが良いのでしょうか？

これが、全国の倉庫・支店で、18時までに出荷が全て終了し、その時点で、出荷入力が全て完了しているということであれば、末日の18時以降に帳票出力ができるはずです。

しかし、出荷入力は倉庫で行うが、最終的に売上承認や、訂正処理を本社で営業が行うということであれば、末日までの集計は、社内の業務ルールとして、翌月の3日、4日の営業終了時間までに、全ての伝票が入力されているということになります。

こういった場合、当然、業務ルールを守れない人や、突発的な業務事故が起こることもあるわけです。
その場合にどう対処するか、といったことも含めて、社内の運用ルールを決めてもらい、更に、システムでは、運用ルールが守られていることを保証する必要があるのです。

例えば、2月29日までの伝票を、3月4日の18時までに全て入力する約束をしたとします。
ここで、帳票を作成したという時点（締）が、システムには必要となるのです。
そして、その時点は全社一律であり、1秒でも遅れた入力や、修正については翌月の帳票に反映させる必要があるのです。

すでに動いている業務をシステム化するという仕事であれば、抽出条件、タイミング、合計の種類など、設計の大部分について、どういうものを作成すれば良いのか、ということを、お客様は、直ぐ答えてくださいます。

現在、役に立っている表、そして、こういうものがあれば便利なのになぁ、といった思いが蓄積してあるからです。

しかし、運用ルールについては、こちらから積極的にヒアリングしない限り、お客様から進んでお話しいただけることは、非常に少ないのです。

月末・期末・締日の慌ただしい中で、どのようにミスを防ぎ、全社的に整合性の取れたものを出力するかといったことは、ヒアリングの中から、SEも一緒に考えることが必要です。

業務ルールとあわせた運用ルール・仕組みを、お客様と確認しながら提供することが求められるのです。

「これはSEの仕事じゃない」と思ってしまえば、抜けてしまうことですが、あれも、これも、SEの仕事なのです。

帳票についていえば、その帳票が、システムの情報の中から「どんな条件」の情報を抜いて集計するものなのかといったことは、明確に提示する必要があります。
また、数多くの運用ミスを防ぐ為の仕組みも必要となります。

今回は、ちょっとカッコいいタイトルにしましたが、作業方法ではなくて、「判断基準」のお話です。

受託開発をしていて、一番、判断に悩む問題は、「どこまで丁寧に作るのか？」「どこはシンプルな作りで構わないのか？」ということだと思います。

理想像は、全ての機能において、「かゆいところに手が届く」ように作られていることなのでしょう。

こう考えている若手SEは、多いはずです。
これは現実問題としては、有り得ないことなのです。

しかしながら、実現する方法が全くないというわけではありません。

それは、どこの開発会社もやってきた、そして、現在もやっている方法ですが、元となるフレームワーク自体に徹底的に注力し、「良いもの」にして、使い回すという方法です。
部品として、再利用できるものを増やしておくのです。

この場合、「良いもの」とは、

・プログラムがシンプルである。
・操作性が良い。
・ミスが防げる。
・何かあったとき、直ぐに問題の箇所がわかる。

ということを指します。

フレームワークで実現できることだけであれば、何の問題もありません。
しかし、フレームワーク外として個別に作り込みを要求される機能は、必ず存在します。

そのとき、それを機能の重要さや、使用頻度に関係なく、一律に「丁寧に作るべきだ」と考えてしまうことは、生産性を低め、結果としてシステムの効果を下げてしまいます。

実際には、この判断基準をどう考えるか、というのが若手SEが成長する一つのステップなのかもしれません。

結局は、一定のコストと時間の中で、実現できることを絞り、選択しなければならないからです。

しかし、若手SEは、全ての機能に対して同じように「操作性が良いもの」「多機能なもの」を提供しようとします。

そのため、

「納品直前に理想のシステムが実現できないことがわかる」

「既に多くの工数費やしてしまって、後戻りできない状態でやっと気が付く」

といった状態に陥ります。

そこには、いろいろな理由があるでしょう。

「理想のプログラムは高機能で難易度が高く、ハイレベルの技術者が要求されるが結局、そこまで人員が手配できなかった」

「大抵において、プロジェクトには、予想外のトラブルや問題が起きるものなので、そちらに工数がかかってしまった」

など、など。

そして、志半ばで倒れてしまう。

であれば、各機能に対して、最初から徹底的に、優先順位付けしておけば、お客様にも迷惑がかからなかった。

ということがよくあるのです。

残念なことですが。

技術でも工数でも、必ずバッファを持つ、といったスケジュール管理も大事ですが、何に力を入れて、何をシンプルにするかといった、運用側のことを考えた「勘」がSEには要求されるのです。

わたしがいつも考えているのは、次の2点です。

1）その機能を入れ込むのに何時間かかるか？技術者の能力は合っているか？

2）その機能を入れることによって、節約できるお客様の時間はどれくらいか？

つまり、システム開発としてのROIを考えて判断するのです。

例えば、システムの初期稼動時にしか使わないような機能は、操作性や機能を重視する必要はありません。
それよりも、入力ミスをしてしまう可能性を無くすことに注力すべきです。

また、使用頻度の低い機能であれば、操作を忘れても、画面を見ればわかるように、メッセージを入れることに気を使います。

毎日、毎日、複数の人が頻繁に使う機能については、操作性を良くし、操作ミスに対してすぐにアラームが発生するように、そして、10秒でも、5秒でも節約して、作業ができることに注力します。

結局、そのシステムが稼働して、1年、2年というスパンで見た場合の「運用コスト」と「開発コスト」を比較して考えるのです。

つまり、システム開発は、トータルコストで考えるのです。

某国の役所の予算のように、そこに予算がある限り、人はそれを使ってしまうものなのでしょうか。

パーキンソンの法則とは、「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」ということです。

プロジェクト管理においては、プログラムの1本1本の工程が細かくスケジューリングされています。

余裕のないスケジュールが、ほとんどであるためか、一人ひとりの生産性というものに、差異があるためか、実際にはスケジューリングは、仕事を進めながら、何度もリ・スケジュールされていくことが通常です。

しかし、どんな場合でもスケジュールを提示するのには覚悟が必要です。

心優しいリーダーが、スケジュールを少しずつ緩やかに引いたときはどうでしょうか。

ほとんどのスタッフが、納期に間に合うように、ゆっくりと仕事を上げてくるに違いありません。

かといって、毎日のように、明らかにどんどんスケジュールが遅れていくような、見込みの無い計画であっていいはずもありません。

今までの経験値からだけで申し上げますと、1週間に1日以上は遅れない、そしてぴったり間に合ったりはしない、10％～15％増し程度のスケジュールが、理想といえます。

なぜ、ぴったり間に合ったりしないのか？それは、ぴったり間に合うために、スタッフが調整しているかもしれないからです。

チーム全員の息が合って、誰が何を何時間でしているのか、全員が分かっている場合には、こういうことは起こりません。

しかし、ちょっとプロジェクトが大きくなってしまったり、リーダーが他のことに気を取られて、スタッフを野放図にしてしまった場合に、ぴったり間に合っているということは、むしろ、余裕がありすぎたと思うべきなのです。

また、たとえ間に合わなかったスケジュールだとしても、月曜から木曜までは、予想通りの進捗だという報告だったのに、金曜になったら、いきなり「間に合いそうも無い」という報告に変わることも要注意です。

これこそ、夏休みの宿題の前倒しではなく、最後にやればいい方式の失敗といえるでしょう。

リーダーは各スタッフの主体性を重んじることも大事ですが、スケジュールについては、スタッフに任せてしまうことは、望ましくありません。

なぜなら、誰かが早く仕上がらない限り、遅れるスタッフが1人でもいれば、それは確実に、システム全体のコストや納期遅れ、品質の低下に繋がってくるからです。

リーダーがスタッフごとに「どんな場合に遅れて、どんな場合に予定より速く仕上がったのか」をヒアリングしながら、常に調整していくことも必要です。

そして、結局、遅れたスケジュールをチームとして取り戻すバッファが必要となるのです。

これは、人を増やすといったことだけが、スケジュール遅延をリカバりする方法だ、と信じている人たちには、プロジェクト管理の方法として、みなされないでしょう。

しかし、実際の話、差し迫った状況の中で、人を増やして解決するようなことは、非常に少ないのです。

だからといって増やさずに解決もしがたいのですけどね。