ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

イノウーの憂鬱 (52) ディベート

»

 夏目 (微笑みながら)私はうちの会社に開発部門......具体的に言うならばシステム開発室は不要だと考えています。理由の一つは、社内の業務システムなど、クラウドサービスが多数存在している現在では、いくらでも選択肢があるからです。わざわざ自社で開発部門を持つ必要性は低い、と言えるのではないでしょうか。

 伊牟田 (鼻で笑って)夏目さんは、うちの会社には、長年に渡って確立されてきた業務フローがあることをお忘れのようだ。パートナーマネジメント業務だけをとってみても、そのノウハウは非常にユニークなもので、一般の業務システムでは対応は困難、いや、ほとんど不可能だと言えます。ダリオスが維持されてきたのは、それなりの理由があるんですよ。

 夏目 ユニークだと言っているのはパートナーマネジメントの人だけでしょう。現に同業他社では、Salesforce など外部のシステムを採用しているところもあります。伊牟田さんも、それはご存じでしょう。

 伊牟田 もちろん、知っていますよ。自社に開発部門を置けるほど余裕がない、うちより格下の企業ばかりだ。そんな会社と比較しても意味がないでしょう。

 夏目 しかしシステム開発室は、これまでのところ目立った実績を上げていませんね。

 伊牟田 実績がないとは事実に反して......

 夏目 失礼、検温フォームや、PC 申請フォーム、それからエースシステムとのデータ連携のm2A の他に、目立った実績がない、と言い直しましょう。

 伊牟田 ダリオスの改修をお忘れです。それとも意図的に外したんですかね。夏目さんが指揮した改修案が、結局のところ、大竹さんに見向きもされなかったから。

 夏目 私が言いたいのは、ダリオスの改修も含めたシステム開発室の実績と謳われているものが、社内の開発部門でなければ成し得なかったとはいえない、ということです。外部サービスでも代替がきくものばかりです。

 伊牟田 m2A はうちとエースシステムとのデータ連携システムですよ。外部のサービスに、そんなものがあるとは思えませんね。

 夏目 (呆れたように嘆息して)わかりませんか。システム開発室をベンダー、あるいはSES で置き換えても成立しますね。

 伊牟田 当初、開発にはベンダーに入ってもらいました。結果は失敗でした。

 夏目 (含み笑いしながら)あなたが、選定したベンダーが失敗したんですよ。より優秀なベンダーだったら、結果はまた違っていたのではないですか。

 伊牟田 そんな仮定の話をしても意味がないでしょう。当時の状況を考えると、スケジュールと予算の関係で、どんなに優秀なベンダーであっても、システム開発室ほどの成果を出すことはできなかったと思われますね。

 夏目 逆の言い方をするなら、スケジュールと予算に余裕があるなら、外注で十分ということになります。

 伊牟田 (嘲笑するように)夏目さんは広報だからわからんのでしょうが、スケジュールと予算に余裕がある開発なんて、ありえんのですよ。スケジュールは必ず遅延するものだし、工数は必ず予算を超えます。それがシステム開発というものです。

 夏目 (ニヤリと笑って)私が社内の開発部門を不要だと考える二つめの理由がそこです。無限に工数をかけていいのであれば、誰だって素晴らしいシステムを作成できるでしょう。ですが、制限があるのが現実です。外注であれば契約書の金額以上を支払う必要がない。仮に工数が、見積をはみ出したところで、それは外注先の問題ですね。ところが内製であれば、社員には規程に則った時間外労働手当を支払う必要がある。つまりコスト削減は、内製で行う理由にはならない。それどころか場合によっては、外注よりもはるかにコストがかかるケースだってありうる。

 伊牟田 そんなことは管理者が適正に工数管理を行えばすむことだ。

 夏目 (ボソッと)そんなことできるわけないっしょ。

 伊牟田 (訝しげに)失礼、今、何と?

 夏目 (落ち着いて)適正な工数管理などできますか、と訊いたんです。

 伊牟田 もちろん......

 夏目 (首を左右に振って)できるはずがないんですよ。管理者になる人間は、プログラマではなく、プログラミングの知識もないんですから。彼、または彼女が、一日の就業時間を有効に使ったとどうしてわかるんですか。

 伊牟田 日報でも書かせればいい。

 夏目 (不意に視線を動かして)イノウーくん。

 不意に呼びかけられたぼくは、反射的に姿勢を正した。夏目課長は構わず訊いた。

 夏目 昨日、君がやった作業を具体的に教えてくれますか。

 ぼくは昨日の記憶をたどった。午前中はダリオスの改修、午後はダリオス改修の続きを行った後、JINKYU の改修について人事課と打ち合わせ、その後はエースシステムから依頼されているm2A のデータレイアウト変更の仕様を確認していた。合間にはジョイントベンチャーについて斉木室長とチャットし、マリともダリオスのフロント部分とWeb API の連携仕様についてチャットを断続的に行っていた。ぼくはそれらを夏目課長に話した。

 夏目 ダリオスの改修についてですけどね、その作業を行ったというエビデンスはあるんですか? いえ、答えなくても大丈夫です。そんなエビデンスがないことぐらいはわかっています。

 伊牟田 (退屈そうに)失礼ですが、それが何を意味しているのか説明していただけますかね。

 夏目 伊牟田さん、今、イノウーくんが話した内容が日報として上がってきたとして、あなたはその真偽をどう判断するんですか。

 伊牟田 それは......

 夏目 ダリオスの改修作業を行っていた、とイノウーくんが報告したとしますね。その時間、ネットで動画を見ていたとしても、わからないのではありませんか? ましてや今はテレワークですよ。

 伊牟田 ソースファイルの日付やサイズをチェックすればいいでしょう。

 夏目 現実的にそんなことができますか? できませんね。ソースファイルの更新日付やサイズを変えることなんて簡単です。実際にイノウーくんがダリオス改修をやっていた、あるいはやっていなかったと証明することは不可能です。改修版ダリオスの内部に詳しく、コードを読める人間が、ソースを見ながら変更部分をイノウーくんからヒアリングし、前日の履歴と比較してチェックする。そこまでしなければ、作業が行われたという証明はできません。つまり、私でも伊牟田さんでも、イノウーくんが昨日、真面目に仕事をしていた、ということを証明することはできないんですよ。

 伊牟田 (せわしなく左右を見ながら)それはそうかもしれんが......

 夏目 もちろん、それはシステム開発室だけに言えることではありません。顧客やベンダーに外出した社員が、途中でスタバで一服する、私用の買い物をする、ネカフェで仮眠する、これらはいずれも厳密に言えば社員規程違反です。実際に同様の行為が行われているだろうことは、管理者なら誰でもわかっています。わかっていながら、黙認しています。一つは全社員の就業時間中の行動をビッグブラザーのようにチェックすることなど不可能だから。一つは設定した期間内、予算内で成果を出せば問題がないからです。

 伊牟田 システム開発室だって同じではないですか。別にダリオスの改修に無限の工数を使っていいと言われているわけではない。

 夏目 同じではないんですよ。たとえばパートナーマネジメントであれば、A という案件をB という社員が担当するとして、どれぐらいのコスト、どれぐらいの日数を必要とするか、どれぐらいのマージンを見込めばいいのか、ということが自身の経験や、社員B のスキル、過去の同種の案件を参考に予想がつくでしょう。また、長年にわたって蓄積、改良されてきた業務フローによって、仮に誰かが不正を行ったとしても、容易に発覚する仕組みになっています。ところが社内の開発については、うちの会社の既存のノウハウが適用できない。うちが開発業務から手を引いて長い年月が経過しているので、どれぐらいが適正値なのか、ということがわからないからです。これが何を意味するのかおわかりでしょうか。イノウーくんが、ダリオスの改修を完了するには、あと1 年という時間を必要とする、と主張したとしても、社内にはその妥当性をチェックできる人間がいない、ということです。イノウーくんがその1 年の間、一日に30 分だけ仕事をして、残りの時間は遊んでいたとしても、です。

 伊牟田 (冗談めかして)イノウーはそんなことしないよ。

 夏目 (頷いて)ええ、イノウーくんがそんな人間でないことはわかっています。ですが、この問題の本質は、うちの会社における開発部門の仕事は、どうしても属人化せざるを得ない、という点にあります。プログラマの報告をそのまま信じるしかないんです。これがベンダーであれば、プログラミングに特化した業務フローがあるでしょうし、上長もプログラマかプログラミング経験者であることが多いでしょうからチェックもできます。テスト部門があればダブルチェックもできます。うちの会社の場合、その全てをイノウーくんがやっている状態です。そうですね、斉木くん。

 斉木 (無言で頷く)

 夏目 業務の属人化が不正への第一歩であることは言うまでもありません。それでなくても少人数、つまり実質的にイノウーくん一人に基幹システムの保守が集中するのは健全でないことは、おわかりだと思います。イノウーくんが病気やケガで長期離脱するか、この会社に嫌気が差して転職されたら、大混乱に陥ります。

 伊牟田 それなら人数を増やせばいい。プログラマ同士で相互に業務をチェックさせれば全て解決だ。

 夏目 本質的な解決にはなりません。第一にプログラマにはスキルの差があり、互いの作業内容を理解できるとは限りません。第二に一人か二人の増員では、イノウーくんのコピーができるだけで、属人化された業務の数を増やすだけに終わるでしょう。第三にプログラマ同士で結託して、当たり障りのない進捗を報告を上げてくる可能性を否定できません。

 伊牟田 やれやれ。夏目さんはプログラマなど信用できん、とそう言いたいわけですか。

 夏目 私が言いたいのは、プログラミングというのは、あまりにも専門性が高いので、プログラマを適切に管理するには、同様に専門会社でなければならない、ということです。うちはIT 企業ではありますが、プログラマを管理する仕組みがない。

 伊牟田 ベンダーコントロールのノウハウはありますよ。

 夏目 似て非なるものです。ベンダーコントロールとは、究極、一文に集約できます。「納期と品質を守れ」です。それができるのは、うちの会社がベンダーに対して上の立場から物を言えるからです。一方で、同じ会社の社員であるシステム開発室に対しては、そういうわけにはいきません。相手は下請けではないからです。

 伊牟田 (しばらくの間沈黙)

 斉木 伊牟田さん、ご意見があればどうぞ。それとも、出し尽くしましたか? であれば、このディベートはここまで、ということになりますが......

 伊牟田 もちろん続けるともさ。まずは夏目さんのご意見を拝聴していたんだ。次は俺の番、ってことだ。

 斉木 なるほど、ではどうぞ。続けてください。

 (続)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術や製品の優位性などを主張するものではありません。

Comment(13)

コメント

匿名

うちは開発する会社なのに
何を勘違いしてるのか
プログラミングを下流の仕事
とか思ってるから上の人間はみんな
プログラムのレビューできないんだよな…
コメントだけ見て設計書とあってるかしか確認しない…>

匿名

業務中に読んでます

匿名

うちのとこは設計通りに動けばどうでもいいと思ってるらしく可読性とか性能は全くレビュー対象とならない


社内に一定の技術力をもつメリットはベンダーの言いなりにならなくて済むこととシステムの更新やら導入やらの際に円滑に行えることじゃなかろうか
たしか初期の方は明らかに実作業より遥かに多い金をベンダーに払っていたような

匿名

面白いねこのディベート。
イムタ氏の味方をしたくなっちゃうじゃないか。

匿名

おっ、意外に伊牟田氏がまともなこと言ってる。
そして両者に一目置かれるイノウー…

ゆう

社内向けのシステムに限定すれば、
夏目課長に意見におおむね賛成です。
 
社内向けはSalesforceやERP等で済ませ、
どうしようもない部分のみアドオンでよいと思います。
(それも極力避けるべきですが)
 
現行業務フローとのGAPはどうしても出ますが、
独自の業務フローは、非効率やムダの温床だったことも多かったので、、。
個人の経験ですが。

匿名

パートナーマネジメントのノウハウを確立することが正ならば、
社内開発の工数見積を出すためのノウハウを確立するのも正なのでは。
後者が専門性が高すぎるというのも、じゃあ前者は簡単なんだ?っておもってしまうし。

でも夏目さんの説得ポイントはそういうんじゃないんだろうな。
社内システムの独自性自体が競争力になるとか?絶対言わなそう。がんばれ伊牟田

匿名

もしかしてこれ、伊牟田さんに必要性の再認識をさせるだけの儀式なのでは?

なんなんし

〉もしかしてこれ、伊牟田さんに必要性の再認識をさせるだけの儀式なのでは

もしかしなくても
そういう流れでしょうね

なんなんし

ついでに自分の中のわだかまりも解消
って意味もあるんでしょうけど

匿名D

夏目女史は、会社が開発部門を持つことについて
相応の考察をされているようですね。
会社に開発部門が必要、というよりも、
会社にない、イノウーの属人スキルに焦点があたっているように見えます。


そもそも、現状の下請けに丸投げするがごとく外注するだけでは、
パートナーマネジメント以前に、
無用な案件を踏むのを回避することはできない。
Webアプリで特権IDの管理だの、
開発管理プロセス規定で10数年前の官製ガイドのコピペだの。
それらを回避するには、
夏目女史の指摘の通り、開発者としてのスキルが必要です。


次回ではそのへんがあぶり出されるのかな。

z化まぞく

正しく管理できない一因に「知識不足」があるなら、管理者もイチから勉強したらいいよね

…あれ?

匿名

夏目さん男性じゃないかな

コメントを投稿する