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

レインメーカー (35) 伽藍とバザール

»

◆アリマツ通信 2022.9.9
 新ユニット誕生(続報)
 RM ユニット誕生から一カ月、ユニットリーダーとなった朝比奈さんにお話を伺いました。以下はその抜粋です。

 ―― 一部で話題になっていますが、従来の<コールくん>やNARICS などのCRM システムとは、異なった方法で開発を進めていますね。
 別に奇をてらったわけではないんです。私は実業務としてのシステム開発経験が、ほとんどありません。思いがけず開発チームの指揮を執ることになりました。先人達のやり方をそのまま踏襲しても、おそらくうまくいかないだろうと考えました。そこで自分が最善と考える方法で進めることにしました。成功するか失敗するかは、まだわかりません。失敗したら、その責任は全て私にあります。
 ―― 未完成の状態でCC のSV さん、OP さんにテストを依頼しているのは手抜きではないか、という批判の声もあるようですが。
 多忙なCC のみなさんにお手数をおかけしているのは心苦しく思っています。単体テストをやらされているんじゃないか、と言われているのも承知しています。ただ業務を一番知っているのは、CC のみなさんです。その視点で過不足をチェックしていただくのが、最も信頼できるテストになる、と考えてのことです。
 ―― RM というユニット名の由来は秘密、とのことですが、こっそり教えていただけませんか(笑)
 真実を知るには代償がいるんですよ。
 ―― ?
 (笑)映画のセリフです。由来は秘密、ということで。

 インタビューの全文はこちらから。

 文 総務課 土井

 ◇ ◇ ◇ ◇ ◇

 田代は感嘆と嫉妬の入り交じった複雑な感情で、スクリーンを見つめた。
 プロジェクターから投影されているのは、10 月末に予定されているQQS 案件の業務B 用に開発されたWeb アプリケーションの画面だ。
 Python のフレームワークFlask、Bootstrap、Svelte という組み合わせで作成されたアプリケーションは、まず、ログインページからクールなデザインが目を惹きつけた。
 ログイン後に表示されるのは、対応待ちを表すカプセル型のアイコンだ。ページのあちこちにランダムに表示されるようになっている。OP がいずれかのカプセルをクリックすると、半分に割れる。中から無数のオレンジ色の粒子がページ全体に広がり、対応ページが表示される。
 確かに綺麗なUI だが、と田代は考えた。こんな細かいところに凝ってていいのか。他に工数をかけるべき箇所はいくらでもあるだろうに。田代はそう指摘しようとしたが、先に倉田が手を挙げた。
 「あの」スクリーンを見ていた倉田は首を傾げた。「これ、なんで、表示位置がバラバラなんですか? 同じ位置で表示させた方がわかりやすいと思うんですけどね」
 田代は腕を組んでイズミに目をやった。だが、イズミは顔色一つ変えず、近くに座っていたシオリに頷いた。QQS 案件の受電業務は昨年と同様に名古屋CC で行われるが、業務B は横浜CC が受け持つことになっている。シオリは臨時で参加することになっていて、そのため、新ユニットが設立されてすぐに仕様の打ち合わせに参加していた。
 「あー、それですね」シオリは立ち上がった。「私からお願いしたんです」
 「わざわざですか?」倉田は純粋に好奇心で訊いているようだ。「ゲーム感覚でOP さんたちを楽しませようとか?」
 「いえー、もっと現実的な理由です。以前、似たような業務をやったとき、やっぱり画面に出てる一覧から選択してOP が処理していくのがあったんですけどね。みんな一番上からクリックするから、エラーが頻発してたんです。エラーというか、このレコードはすでに他の人が処理中です、みたいなメッセージですね。表示位置が決まってるから、みんな、その位置にマウスを合わせて、カチカチずっと押したりして。そういうことがないように、表示位置を毎回変えてもらうように頼んでおいたんです」
 田代はスクリーンを見直した。数秒おきに、ページ上に表示されているカプセルの位置が変化している。
 「なるほど、そういうことでしたか。面白いですね」
 「確かに」シオリは笑った。「テストしたOP さんからは、単なる一覧より触ってて楽しい、って感想をもらってます」
 室内に控えめな笑い声が満ちた。それが収まるのを待ち、イズミが説明を続けるのを、田代は憮然としながら見た。
 対応ページには、QQS が提供するAPI から取得した情報が表示される。情報はユーザのスマートフォンにインストールされた専用アプリの内容によって異なる。現在のところ、6 種類、27 パターンが決定しているが、今後、さらに増える予定だ。単にパラメータによって表示を変化させればいい、という単純なものではなく、それぞれに異なるロジックが必要となる。
 横浜CC の三辻課長が手を挙げた。
 「アプリの方は、イベントの数日前まで改修入るみたいだけど、新しくパターン増えても問題ない?」
 「何とかします」イズミが短く応えた。
 「ひょっとしたら当日もあるかもしれないんだけどね」
 「10 月29 日と30 日は、RM ユニット全員出勤予定です」
 「ああ、そう」三辻は頷いた。「アイカワさんの方も?」
 「はい、了承をもらっています」
 イズミが会議室の一角に視線を送ると、そこに座っていたスーツ姿の男女4 人がそれぞれ頷いた。
 「なら安心ってことでいいのかな」三辻が感心したように言った。「まあ、見た限り、アプリの方の進捗もスケジュール通りのようだし。近藤くんの方も問題ないんだね?」
 「ええ」シオリが笑顔を見せた。「こっちの要望にも迅速にレスしてくれてるので」
 「ふーん。ま、最初、聞いたときはちょっと不安だったんだけど、一カ月とちょっとで、よくここまでやれたものだね」
 「私は何も」イズミが首を横に振った。「スキルのある人たちが集まってくれたおかげです」
 イズミの言葉がウソではないことを田代は知っている。実際、イズミは田代の知る限り、ほとんどコードを書いていないはずだ。
 当初、システム課の宇都の協力を得る、という話を聞いたとき、田代はとうとうイズミもやけになったのか、と考えたものだ。宇都が承諾するとは思えなかったし、たとえ承諾したとしても、プログラマでもない宇都が戦力になるとは考えにくい。コールセンター業務に関しての業務知識はあるだろうが、今回、イズミの新ユニットが手がけるのは受電業務ではないのだ。
 数日後、宇都と吉村が、新ユニットに兼務で参加するという人事通知が発表された。どうやって宇都を説得したのか、と田代は驚いたが、さらに驚いたのはアイカワのプログラマを参加させる、と聞いたときだ。どうせ宇都の伝手だろうが、それでもアイカワが無償でプログラマを派遣してくれるはずはない。
 田代が別件で用事があったついでに椋本副部長に訊いてみたところ、椋本は笑いながら言った。
 「ある意味ではNARICS のおかげだな」
 「は?」
 NARICS が新規業務で採用されることが続いているため、<コールくん>の改修依頼の数は大幅に減少している。そのため来年度からの年間保守料減額について、アイカワと協議を開始していた。
 「今年度については、すでに更新契約書を交わしていたから、減額はできないんだがね。社内からは実質的にアイカワの稼働工数は半分以下になっているんだから、何とかすべきではないのか、って声は上がってるんだ。それを材料にアイカワと交渉したんだが、相当に安い単価でプログラマを派遣してくれることにまとまった、というわけだ」
 「......一種の脅迫ではないんですか」
 「価格の適正化だよ」
 それでも田代は懐疑的だった。来年度からはともかく、今年度については今のままでも、例年より少ない作業量で、同じ利益が得られるのだ。そんな濡れ手に粟の状態を放棄するだろうか。
 ところがその予想に反して、アイカワはあっさりその条件を呑んだらしい。システム課の吉村に訊いてみると、吉村はオフレコですが、と前置きしてから話した。
 「アイカワでも<コールくん>の保守は、かなりお荷物になっていたみたいですね。機会があれば手を引きたい、というのが本音だったようで。あっちの久保寺さんは、ずっと<コールくん>担当だったから反対してるんですが」
 「だが<コールくん>はまだ何年かは、うちで使われるだろう」
 「でも新規案件がNARICS に移ってることで、先細りになるのは目に見えてます。だから今のうちに、新システムの方に唾つけとこうってハラなんじゃないですかね」
 勝ち馬に賭けたいってことか、と納得したものの、そんな動機で送り込まれるプログラマでまともな仕事ができるものか、と田代は言いたくなった。派遣では事前の面談もできないから、どんなポンコツでもとりあえず受け入れるしかない。そもそもアイカワの技術力など<コールくん>の保守を見ていれば、想像がつくではないか。
 田代の予想はまたしても外れた。派遣されてきたアイカワのプログラマ4 名は、いずれも20 代の若手ばかりだったが、高いモチベーションに輝いていた。以前に<コールくん>関係の打ち合わせで見た顔は一人もいない。その理由はイズミと話をして明らかになった。
 「Python?」田代は呆気にとられた。「Python で作るの?」
 「はい」イズミは答えた。「業務B のシステムはPython で作ります。Flask を考えています」
 「どうしてまた」
 「山下さんが、以前、やったことがあるそうなので」
 それだけの理由で、と問い返しそうになった田代だったが、自分も同じ理由でSeasar2 を選択したことを思い出して口をつぐんだ。
 「だけど」田代は別の疑問を口にした。「アイカワって、確か、Java ばっかりだったんじゃなかったか」
 「そのようですね。だからアイカワさんからの人たちは、Python の経験があるわけじゃないんです。それは条件に入れてないので」
 「え、Python の素人?」田代はまじまじとイズミを見つめた。「いったい、どういう条件でアイカワに依頼したんだ」
 「業務B の概要を伝え」イズミは笑いながら答えた。「言語はPython でやると伝えました。あと、できれば志願した人にしてほしい、とも」
 「......」
 そんな曖昧な条件で、どんな人材が集まったのやら、と皮肉な目で見ていたが、やがてその認識を改めなければならないことに気付かされた。アイカワのプログラマたちは、すでにテレワーク勤務に入っている山下、池松ノリコを交えて、活発に技術論を戦わせていて、数合わせの人員、という印象はくつがえされた。
 もっとも彼らがアリマツに出勤していたのは数日だった。一通りの情報共有が終わると、彼らはアイカワに戻っていった。残りの作業はZoom とSlack で行うらしい。
 さらに驚いたのは、業務B 用アプリケーション(名称はいまだに正式決定していなかった)の基本仕様とデータベース設計は、イズミが行うのではなく、メンバーからの提案を協議することで決定していく、という方針だった。DX 推進室の定例ミーティングの席でそれを聞いた田代は、さすがに黙っていられなくなった。
 「ほとんど社外の人間に、大事な仕様を決定させるって、ちょっと問題があるんじゃないのか。アプリの質はどうやって担保するんだ」
 「そのために」イズミは落ち着いて答えた。「テストの時間を多く取る予定です」
 「朝比奈さんと山下さんがテストをすることで、仕様の漏れなどを防ぐ、というわけか」
 「いえ」イズミは首を横に振った。「テストの大部分はCC の方にお願いしようと思っています。近藤さんには了承してもらっています」
 シオリがにっこり笑って手を振った。
 「しかし、リモートだけで、完全にコミュニケーションが取れるものなのか」
 「田代くん」椋本が言った。「君のやり方と違っているのが不安なのはわかるが、ここは朝比奈さんに任せてみようじゃないか」
 「はあ、まあいいですが」田代は不満を押し殺して答えた。「私はただ、業務が無事に稼働できるか心配なだけなので」
 本当に言いたいのは、リーダーでありながら、イズミはほとんど手を動かしていないではないか、ということだ。典型的なプレイングマネージャである田代は、コードを書かない、もしくは書けない人間を心から信頼することができない。
 その傾向はさらに続いた。イズミは再びシオリの友人である笠掛マリを呼び、フロント技術構築について助言を求めたのだ。その際に条件をつけた。
 「できる限り、最新の技術で。ただし、すぐに廃れてしまいそうなのはNG。一定の規模でメンテナンスが続いて、少なくとも今後5 年はメジャーな存在でいられるもので」
 マリは唸った挙げ句、Svelte というフレームワークを提案した。田代が聞いたこともないフレームワークだ。もっともマリはnode.js の環境を構築し、Svelte の開発手順をまとめたドキュメントを作成し、イズミを含めた新ユニットメンバー全員に6 時間の講習と実習をさせただけだった。
 並行してアプリケーション開発も進んでいた。データベースはNARICS と同じPostgreSQL でサーバも同じだったから、田代はときどき状況を確認してみた。最初の二週間ほどは、テーブル構成は毎日のように変化していた。DBA はイズミが行っていたが、田代からは、メンバーからの意見を無節操に反映しているようにしか見えなかった。
 また、ろくに動作もしない、紙芝居に毛が生えたような状態のアプリケーションを、テスト版として、CC に提供して早々にテストを開始したことに驚かされた。どうやらテストをしてもらうことだけが目的ではなく、仕様策定にCC の担当者を引きずり込むことが狙いだったようだ。いわゆるオンサイト顧客を狙っているのだろうが、指名されたSV やOP の不満の声は小さくなかった。
 どう考えても、これは失敗だ、と懸念を抱いたのは田代に限らなかっただろう。しかし、9 月に入ると状況に変化が見え始めたのだった。

 ◇ ◇ ◇ ◇ ◇

 デモが終わってDX 推進ユニットに戻ったとき、田代は倉田に感想を訊いてみた。
 「正直なところ」倉田は首を振った。「かなり完成度は高いですね。最初はどうなることかと思っていましたが。田代さんもそう思ったんじゃないですか?」
 田代は渋々頷いた。NARICS がマルチテナント型で、QQS 案件以外の個別ロジックを搭載しているのに対して、新アプリケーションはQQS 案件業務B に特化したシステムだ。だが、それを差し引いても、一つのアプリケーションとしての完成度が高いことは認めざるを得なかった。
 「あれは何というんでしょうね」定時が近いため、帰り支度をしながら倉田は感嘆したように言った。「アジャイル......いや、バザール方式ですかね」
 伽藍とバザールか。田代は、前世紀に読んだ論文を思い出した。
 「バザールというのは」田代は言った。「オープンソースの開発方法ではなかったでしたか」
 「そうですね。でも、参加者の意見を躊躇なく汲み上げることや、リーダーの優れた調整能力が必須である、など、RM ユニットで朝比奈さんがやってることは、バザール方式に似てます」
 「そもそも」田代は疑問を呈した。「こういう企業内システムで、バザール方式って有効なものでしょうかね。どうも自分には馴染みがない方式なので」
 「私だってそうです」倉田は頷いた。「もし私がリーダーの立場に置かれて、どちらかを選べと言われたら、迷わず田代さんと同じ方法を選択しますよ。少数でアプリケーション仕様やテーブル設計を行い、他のメンバーに指示してやらせる。これまで、そういうやり方ばかりでしたから」
 「オープンソースと企業内システムは異なりますからね」
 「でも、朝比奈さんには、そういう思い込みがない」倉田は時計を見ながらカバンを取り出した。「だから躊躇なく、自分が最善だと考える方法を進めています。システム開発の経験がないから、というだけではない。柔軟な思考を持っているからなんでしょうね。正直、私は興味津々なんですよ。朝比奈さんのやり方で、どこまでできるのか。実は田代さんもそうなんじゃないですか」
 田代が答えに詰まっている間に、倉田は「では定時ですので」と言い残して帰っていってしまった。

(続)

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

Comment(14)

コメント

匿名

バザールがサーバルに見えた

匿名

モデルは台湾の大臣がやったものでしょうけど。

匿名

バザールでござーる
しか思い浮かばない…

匿名

Svelteは良いものだ

匿名

機能(=品質)面はともかく、スケジュールや予算があらかじめ決まっているプロジェクトでバザール方式が機能するのかどうかは疑問だなぁ。それにバザール方式なら強力なリーダーシップが不要というわけじゃないと思う。何をいつまでにやるのか、現時点で何%できてて期限までに間に合うのか、使用可能な人員はこれだけ、となった時にトレードオフを決断しないといけないわけで、外注まで入っているときに合議だけでうまくまとまるのかは疑問(いくらモチベが高くても)。
あと、説明と保証を求められたときにイズミさんのやり方で桑原さんが納得いくような説明ができるとは思えない。DB設計が収束しなかったらどうするつもりだったのだろう。

イズミさんの施策で明確に良い点は最初からユーザを巻き込んでること+アジャイル開発体制を組んでることで、ユーザもモチベが高くてちゃんとテストやってくれてる点かな。

匿名D

バザール方式で収集がつかなくなるのは、
メンバーが完全に平等で、民主的(笑)な手続きにこだわった場合だと思う。
イズミ女史がどの程度の独裁ぶりを発揮したのかは書かれていないけれど、
「これでいく」「じゃ、ここまで」と表明して、
それを通せないようなボンクラじゃないでしょ。


それにしてもわからないのは、
田代氏の、経験が浅いことに対して警戒心が丸出しなところ。
ひとつの言語でなにか作ることができるのなら、
他の言語で同じようなことをやるの、そんなに難しくないでしょ。
そりゃ、ローカルな儀式は大なり小なりあるだろうけど。
逆に、経験豊富な言語だからって、
脳ミソを全く稼働させずにコードを書くなんて不可能だし。
これって、田代氏がコーディングを下に見ているってことにならない?


田代氏の男尊女卑の根は、以前の職場だけにとどまらないみたいだね。
リーダーぶりも、自分自身を相手に投影しようという欲求が強すぎると思う。
どなたかがすでに書いていたが、
このままじゃ某三浦マネージャーになりかねんぞ。

たむりん

どうしようもない田代だが、

「コードを書かない、もしくは書けない人間を心から信頼することができない。」

ここに関しては激しく同意。

匿名

長期運用が前提では無いからかなバザールモデルが上手くいく前提は。
ユーザ系でのウォーターフォールモデルのアンチテーゼという事だけど、
結局は派遣にならざるを得ない、どこもわざわざやりたいとは思わないから。
受発注の主体の利害関係を無視しているから。

台湾のモデルが上手くいったと「される」要因はアジャイルモデルのロールのユーザが技術者でかつ総責任者だったから。
逆にユーザシステムをリスクとってシステム作りたいとは誰も思わないと思います。

たむりん

どうしようもない田代だが、

「コードを書かない、もしくは書けない人間を心から信頼することができない。」

ここに関しては激しく同意。

匿名

そこだけ抜き出すと大多数の人間が信頼できないわけだが

夢乃

イズミさんがますます白川さんに似て見える・・・エースの白い魔女ならぬ、アリマツの暁の魔女の誕生も近い・・・
 
>svelte の開発手順をまとめた
ここだけ、Svelte の頭文字が小文字です。

匿名

案件としての規模が大きくなく現場の意見が汲み出せる状況であればバザール方式でもいいかも。
社内システムで使い切りなら尚更向いていると思うけれど。
エースでは無理だろうね。白川さんなら対極の方法で構築すると思うです。

リーベルG

夢乃さん、ありがとうございました。
「Svelte」ですね。

匿名

案件としての規模が大きくなく現場の意見が汲み出せる状況であればバザール方式でもいいかも。
社内システムで使い切りなら尚更向いていると思うけれど。
エースでは無理だろうね。白川さんなら対極の方法で構築すると思うです。

コメントを投稿する