Category Archives: コミュニケーションパターン

要求は対話を通じて次第に明確化するもの

 ソフトウェア開発では、実際に動くようにする「実装」という作業が必要である。どのように実装するかは「要件定義」という記述を元にして検討され、その要件定義は顧客の「要求」を元に作られるというのが原則だ。本来は要求が先にあり、「〜をしたい」「〜を実現したい」という形式で記述できるものが基本である。「○秒以内で処理が完了する」と言った非機能要求も記述される。しかしながら、この要求による記述内容だけでは、その実現方法が多岐に渡る事になる。そこで、実装を円滑に進めるために「〜ができるようにする」という形式で記述できる要件を定義し、実装側は要件の実現に注力する。容易に分かるのはこうすれば実装の分業がやりやすいことだ。開発業務は元請けから下請けや複数の開発者に至る階層化された業務フローが一般的であり、要件定義は分業の基礎としてビジネス構造にもマッチする。この方法の是非はあるのだが、長年この流れをベースにやっているだけに、なかなか変えられれないというのが実情だとして、この枠内で開発における問題点を考える。

 うまく分業され開発が進むかと思うと、現実には顧客が望んでいたものと違ったものが開発されてしまうという問題がある。笑い話になりそうな、全く違うものができてしまうこともある。ちょっと意図的に強調した例として次のようなものがある(もちろん、かなり単純化している)。要求として「ポイントシステムを作りたい」として、要件としていくつか作られた項目の中に「ユーザー管理機能」というものがあるとして、その要件だけを知らされて実装したとしよう。すると、単に住所録みたいなものが出来上がり、管理番号がないとか、期限の管理はどうするのよ?みたいな実装が上がってくるかもしれない。もちろん、通常は自身が実装する要件以外も目を通すので、優秀なプログラマーたちの忖度機能が発動され、次第に顧客の要求に近づくということになる。なんだ、うまく行っているということではないのか?と思われるかもしれないが、うまくいく前提の1つとして、要求も要件も記述されている、つまりは文書化されているという前提がある。もちろん、100%文書化できるものではないのは確かだが、一定以上の割合の文書化がされていないとおそらく忖度ベースの開発は成り立たない。そして、経験上、一定以上の割合が満たされることはほとんどないと感じている。

 ソフトウェア開発の形態は実に様々あり、個別の事情も多いのだが、ここでは単純化して、顧客とコントラクターとデベロッパー(開発者)の3つの存在があるとして考えよう。下請け構造については「開発者」の一言で片付ける。ざっくりと言えば、SIerという人たちは「コントラクター」であるが、いわゆる「ゼネコン」の意味でのコントラクターであり、顧客から業務を請負、遂行する中心人物である。このような状況で開発をしている場合、開発者にとっては顧客の要求が極めてわかりにくいことが多々ある。好意的に見えればコントラクターが開発者にわかりやすいように解釈して作業に分割してくれている結果とも言えるのだが、コントラクターが顧客の要求を本当に理解しているのか疑問に持つような要件を投げてくることもある。たぶん、誰も悪意はない。それでも、比較的大きめの開発をしていると、要件に矛盾が目立つようになることが出てきて、疑問は急激に膨らむのである。要件は解釈がぶれる余地のない文章に一般的にはなっていることもあり、開発者は要件は書いてある通りに解釈できるものの要求が断片的にしか分からないと強く感じるようになる。コントラクターとの関係が悪くなると、責任の押し付け合いにもなる。

 何とかならないのだろうか? だからこそアジャイルなのだろうか? 手法に至る前にまず、問題の本質をどこに求めるかを特定したい。開発者が要件が分からないと感じる時、実はコントラクターも要件はよく分かっていないことが多い。開発者がコントラクターに問い合わせた場合、開き直って「私にもわかりません」と言われても困るのだが、もっと困るのは分かっているふりをすることで、顧客の要求と異なる回答をしてしまうこともある。実は、開発者と同じ程度にコントラクターも顧客の要求が分かっていないと考えるべきだ。そうなると、コントラクターがもっとしっかりすべきなのだろうか? それでは、よくある「営業 vs 実行部隊」の局面になってしまい責任の押し付け合いに等しく、ここから何か生み出されたことを見た事はない。開発者はコントラクターを責めてはいけない。その理由は、実際のところ、顧客自身が実はコントラクター以上に要求を理解していないからである。顧客に何か要求が明確にあるのかというとそうでもない事が普通にあるというのが現実だ。正直な顧客は「モヤモヤした話で恐縮ですが」と切り出して、構想を語る。不誠実な顧客は「お前らプロなのにそんなんことも分からないのか」と訝る。分からないから聞いているのである。私たちが超能力者でないことを説明する気力は普通は出ない。何れにしても、要求が文書化されているかと言えば、極めて限定的になってしまうのが通常である。

 そこで、顧客は要求を理解していないという前提に立つ必要がある。理解していないというのは色々な側面がある。何か構想はあるけど言語化されていない場合もあれば、上司に言われてシステム化の取りまとめをしており経営的な意味は全然説明されずに担当者になっているような場合もある。この点は掘り下げたいところだが、ここでは文書化あるいは言語化されていないという状況としてまとめておこう。このような状況は、次のように考えて見よう。顧客の頭の中はファンタジーであり、顧客の発する言葉はポエムなのである。ソフトウェア開発において、コントラクターはそのファンタジーを実現すべく奔走する人であり、開発者はポエムを開発言語に翻訳する人たちである。それじゃあやってられん!と言う前にこう考えよう。ソフトウェア開発者は、要するにスターウォーズのような素晴らしいSF作品を制作しているスタッフのような存在なのだと。若干無理やりかつ恣意的なポジティブ化ではあるが、ここで前を向かないとどうしようもないのである。

 ここであっさり「要求なんぞはないものだ、幻想だ」と言い切るのも無理がある。現在の多くの開発手法は要求が出発点にあるから。要求がないのではなく、開発者は要求を何らかの方法で明確化をする必要があるという前提に立ちたい。筆者は開発者として関わることがあるが、一人で全部行うコントラクター兼開発者の場合もある。後者の場合の問題点はかなり別のことが絡むので、ここでは顧客/コントラクター/開発者モデル場合だけに限定する。短絡的な考えとしては、開発者として関わっても、顧客と直接話をしたらなんとかなるのではないかとも考えた。だが、ビジネスライン的な意味で、普通はコントラクターは嫌がるのと、対顧客に対する原点的な意味での要求獲得は別の難しい問題があるので、開発者と顧客を会わせるというのはよほど限られた状況でしか成立しない。少なくとも、開発者が顧客対応可能なSE能力を持つような場合などである。ということで、顧客/コントラクター/開発者ラインを保って要求を明確化する方法はないかと試行錯誤をした結果、1つの方法がうまくやれば良い方向に行くのではないかという感触を得た。確証を得るほどの事例に当たった訳ではないが、提案はできる段階に来たと感じている。

 その方法は、コミュニケーションにおいて、要求の断片を話題に含めて、その要求あるいは会社が正しいかを検証することである。例えば、要件定義として「顧客管理番号は7桁である」と書かれているとしよう。これは少なくとも、「123」でいいのか、「0000123」のようにするか悩む定義である。単に「この要件は管理番号の頭を0で埋めるという意味でしょうか?」などと問い合わせるのが普通だと思われる。このコミュニケーションの中において、要求に近い文章を紛れ込ませる。例えば、「管理番号は、ポイントカードに印刷されるので、頭を0で埋める7桁なのでしょうか?」と聞いてみる。ここで「ポイントカードは印刷してお客様に渡したい」「ポイントカードには管理番号が印刷されていて、システム問い合わせで利用したい」と言った要求を言い換えて、質問に含ませている。このような問い合わせに対して、正解と言われるかもしれないが、違っているかもしれない。「管理番号はポイントカードには印刷しません。単にバックエンドのシステムが7桁で切られているから、それを気をつけて欲しいという意味です」のように答えが返るかもしれない。どっちにしても、ほんの少しだが、要求に近い情報が得られた。もちろん、それは小さな積み重ねだが、全くないより大きな進歩があるはずだ。なんとなくそうなのかなと思っていたことが明確になることも小さな進歩だろう。前記の例だと、「実は顧客情報はバックエンドのシステムにも入れられる」という新しい発見があったのかもしれない。仮にポイントカードに印刷するための0埋めだったとしたら、それをどこでやるのかという議論に発展するかもしれない。

 開発者からコントラクターに、要求が分からないから示して欲しいと言っても、コントラクターは開発者と同程度、下手をするとさらに下回るレベルでしか要求は理解していないと考えるべきだ。しかも、コントラクターはその点を意識しているかどうかも怪しい。無理やり文書化をお願いしたとしても、出てくるものには新しい情報はない。顧客に依頼するというのも同様だ。しかしながら、要件の中から要求を含めた、あるいは要求に至る内容を込めたコミュニケーションをすることで、不明瞭な要求群に対して逆算的に少しずつ隙間を埋めるような効果が期待できる。その結果、要求が次第に明確化し、気づいていない関連性が見えて来ることも期待できる。開発者にとって知る事も重要だが、コントラクターやさらには顧客に対しても気づく機会を作っていることも重要である。開発に関わる全ての人の意識を要求のさらなる明確化に向けるためのコミュニケーションが活発になることで、開発現場の様々な側面で要求が次第に固まるということを期待できるのではないかと考える。

 この手法で一番難しいのは作文である。コントラクターや顧客との関係上、どこまで言っていいのかなど、ドメインや個別の事情も絡む。要件に絡めるというのが1つの成立しやすい手法だが、普段の会話で投げてみるというのもあるかもしれない。しかしながら、同じようなことを何度も聞く、突拍子もない質問になってしまうといったようなことは避けたほうがいい。バカ者かと思われてしまうのは不利な状況を作りかねない。それでもうまい問いかけを繰り返し辛抱強く進め、成果物に対する着目点を顧客/コントラクター/開発者でなるべく多く共有できれば、より良い結果になることは十分に期待できる。

 実装する開発者が何人もいるような開発で、頼りになるように見える人は必ずいる。その人は、発言が多く、かつ、発言の中で、念の為にという意味合いで色々な角度で言葉を繰り出す発言が目立つ。そうしたやりとりが、開発の中で自身の実装部分に対しても非常に参考になったという経験もある。確認のために、条件を言い換えてみたり、その要件の目的をたずねてみると言った行動が、他の開発者の助けになるということもあった。そういう人はコミュニケーションスキルが高いという事で終わらせがちだが、スキルには細かなポイントがたくさんある。その1つが要求の明確化であり、それがコミュニケーションから可能ではないかということも、様々な人たちの行動や自身のプラクティスからの結論である。一方、この方法がうまく行かない事例として、コントラクターが開発者の発言を抱えてしまって顧客に流さないタイプの人である場合だ。コントラクターがしっかりしていればいいとも言えなくはないが、前記の通り、開発者が要求が分からないときは得てしてコントラクターも分かっていない。顧客に確認もしないというのは、単なる顧客に対するイエスマンかもしれないが、要求に対する問題意識がないのかもしれない。こういう現場では、とにかく時間がかかり、作業方針も立ちにくく、開発者の間で何かがぐるぐる回っているだけになる。このようにアンチパターンはある程度は見えている部分もあるが、まずはプラクティスとして問いたいと考える。

上から目線を評価する

「上から目線は言った側も言われた側も上から目線である」

「上から目線でものを言うんじゃない!」などと表現されるこの言い回しはもはや説明の必要がないくらい常套句となっています。下の立場の人から、上の立場のような言い方をされたときに、失礼だとか、お前に言われたくないよという意味で使われます。「上から目線の対処法」という記事が検索すると上位に来ます。確かに、認めてもらいたいがために上から目線になるというのは理解できますし、このページの対処法は確かにポジティブな対処法です。

役職や身分が決まっているならともかく、同等な相手で「上から目線」を感じるということは、言われて感じた側が「自分の方が上である」という認識をしているということでもあります。つまり、「低い位置で上から目線になっても、視野が極端に狭いだけじゃないのか」と感じることになるでしょう。

経過や大局を見ないで、その人が知っている範囲だけの知識で、大きな結論を出すような行為は、言われた側には狭い視野しかないのは一目瞭然だったりします。言われた側の方が、より広く多くの情報が分かっていることがやりとりで明確になれば、言われた側は自分が上であると判断し、相手を「上から目線」と思うわけです。

言う側も、言われる側も、そうなると所詮、自分の範疇が中心となりがちです。相手のことを知り、相手が何を考え、何を欲しているかを考慮するというコミュニケーションの原則もつい忘れがちです。上から目線でものを言わないようにしろと言うのは簡単ですが、上から目線でものを言われたとき、言った人の目線を水平にできるかどうかという点も、言われた側の器量が試されているのではないでしょうか。そして、自分の目線も水平にできるでしょうか?

怒る前に、そして怒ってもすぐに冷まし、そこから上から目線になる理由を探ることは、その人1人とのコミュニケーションだけでなく、重要なことを怠っていたことも分かるかもしれません。伝達されていない情報があったり、誤解されているということを探る機会になるのではないでしょうか。

手入力する文字や数字に関するメモ

追記:6とbも間違うぞという指摘があったので、修正します。

ユーザ名やパスワードは、時として「手で入力する」ことを必要とします。もちろん、コピペもあるんですが、手入力を必要にすることで、意図的にセキュリティレベルを高めることもあるかもしれません。そのとき、印刷状況によって、数字の「1」と「小文字のL」の見分けがつかなかったりということが発生します。もちろん、フォントの工夫と、アルファベットおよび数字などの使用している文字をサンプルとして印刷するということで対処する場合もあるかもしれません。

ここで、いっそのこと、間違えやすい文字列はもともと含めないでアカウントやパスワードを作るのがいいのではないかとも言えます。とはいえ、「間違いやすい」というのもちょっと曖昧な定義です。ご意見をいただければと思います。なお、ここでは記号類、全角文字は排除されているものとします。

数字+アルファベット大文字

  • 0 O(見栄えが似ている)
  • 1 I(見栄えが似ている)
  • Q 9(発音が似ている)

数字+アルファベット大文字小文字

  • 1 l i j(見栄えが似ている)
  • 6 b(見栄えが似ている)
  • 0 O o(見栄えが似ている)
  • Q 9 q(発音が似ている)
  • C c(見栄えが似ている)
  • K k(見栄えが似ている)
  • S s(見栄えが似ている)
  • V v(見栄えが似ている)
  • W w(見栄えが似ている)
  • X x(見栄えが似ている)
  • Z z(見栄えが似ている)

Zとzを間違えるかというと、微妙かもしれませんが、ありそうなことを排除することを考えています。フォントに寄っては、Zとzは区別しずらい、あるいは間違えやすいことはあるだろうということです。それでも、Tとtは区別はつくだろうとうことでリストには入れていません。

Qと9の区別は、日本語だけだろうということもあります。また、大文字と小文字の違いがある場合には発音だけでは判定できません。音声でコードを伝える必要がある場合は、アルファベットは大文字か小文字かのいずれかだけにしないといけないでしょう。どちらを使うかは、使用するシステムに依存すると思います。

上記のルールを適用して間違えやすい文字列を排除すると、使える文字列はこうなります。

数字+アルファベット大文字(30文字)

  •  2345678ABCDEFGHJKLMNPRSTUVWXYZ

数字+アルファベット大文字小文字(3735文字)

  •  234578ABDEFGHJLMNPRTUYadefghmnprtuy

以前、クーポンコードのようなものを考えたとき、その手入力が必要としたらどうなるかを考えました。その仕様がどうだったかはどうでもいいので、現状での記述に揃えます。ただ、ランダムに作るというよりも、生成した乱数をビットに分離すれば、変換はやりやすいと考えました。つまり、base64の原理です。4ビット16文字なら16進表現の方がいいでしょう。6ビット64文字にするには、上記のいずれのパターンも足りません。そこで、5ビット32文字で考えます。「数字+アルファベット大文字小文字」をもとに、さらに微妙に間違いが発生しないかと考えられる以下の53文字を排除するとします。

  • m n r(お互いにデザインが類似している)
  • u y (大文字のデザインにそこそこ近い)

こうして残ったのが以下の32文字、つまり5ビットです。5ビット分ずつ、以下の文字列に置き換えれば、乱数からそのエンコード表現ができあがり、手入力時に間違いやすい文字列が排除されているということになります。

数字+アルファベット大文字小文字(32文字)

  • 234578ABDEFGHJLMNPRTUYadefghprty

こんなことまで考えて、クーポンシステムを作ったのに、全然使われなかった…。まあ、それは仕方ないとして、別件でランダムパスワードの生成が必要になったので、思い出してブログにまとめました。

要注意キーワード:みたいな感じ

要注意キーワード: みたいな感じ

想定される問題:

  • 類似させたい個所と、異なる結果にしたい個所が、正しく伝わらない可能性がある。
  • 良かった点、悪かった点が何なのか明確にならない可能性がある。

用例:

  1. トップページはアマゾンみたいな感じでお願いします。
  2. この前やったプレゼン、プロみたいな感じだったね。
  3. 素人みたいな感じのデザインで、どうかな?

キーワードが発生する要因:

  • 例を示しつつも、その通りではないということをほのめかしている。
  • 的確な表現が見つからない。対象となるものを全体的に評価しているが、詳細な点についての意図や評価基準を持っていない。
  • ネガティブな用例においては、湾曲表現、あるいは、意味をやや薄めた言い方であり、受け取り様によってはなんとでも解釈できる言い方をすることで、あつれきや問題視を避けようとしている。

会話でよく使われる「みたいな感じ」は、話のきっかけとして、大枠と方向性を示すには非常に有効である。しかしながら、「○○みたいな感じ」というのが最終的な目標や要望であるとすると、○○の何を継承し、なにを変更するのかという点は不明確なままになる。そのため、この表現が出た場合、具体的なポイントとして、何を意図しているのかを詳細に問いただす必要がある。

===========

…とまあ、パターンを考えながら、パターンのパターンを探っている、みたいな感じでw

擬態音は崩壊の前兆である

以下のメッセージは、今年の1/15にFacebookに書き込んだ内容です。パターンの勉強の一貫として、「書いてみる」ということをちょっとやってみているのですが、いろいろな意見をいただきました。これも、記録としてこっちにも書いておきます。

================================

プロジェクト進行や計画ミーティング等でのパターン:

◎擬態音は崩壊の前兆である

  • 例1:この部分はささっと終わらせて
  • 例2:ボタンを押すと、ポーンと出てくるのがいいね
  • 例3:これでバーンと儲かりますよ!

 

決めごとの中に擬態音が混在すると、そのゴールは人に寄って異なる解釈となる場合が多い。つまり、具体的な方針には成り得ないことが多く、後から問題が発生する場合が多い。あるいは、具体的になにをすべきか分かっていない、あるいは検討されていない場合のその場しのぎで発せられる場合もあり、対処すらできない場合もある。

バリエーション1:濁音>半濁音>それ以外、の順に不吉な予感は高まる。
バリエーション2:関西弁の擬態音は、ほとんど省略可能として無視できる。

解決策:
擬態音の部分を具体化するか、非機能要件として定義できれば、崩壊を免れることができる。擬態音が発生した段階で、その擬態音を具体的な要件、あるいは形容詞などで置き換えることを試みる。置き換えができないものは、要件ではないと判断し、検討を重ねる。
また、擬態音を省略した場合、意味が通じるかについて判定する。つまり、コミュニュケーションの手段としてより強調したり、印象づけるために使われている擬態音については要件と分離できるため、無視することも可能である。しかしながら、無視できるかどうかについては、さらにコミュニケーションを深める必要がある。

消費税増税で忘れられていること

消費税が5%から8%、そして将来は10%になるという法案が政府によって進められています。現在、年間12兆円の消費税収入があるらしいのですが、いろいろな議論が巻き起こっているのも周知の通りです。その中でまったく議論が出てこないのが「免税業者」についての話です。

現在は、すべての取引(ただし非課税のものをのぞく)に消費税の徴収が義務とされているはずです。私は2005〜2008年は会社員だったのですが、その期間の前は、「あなたは免税業者ですか」と聞かれてから請求金額が決まるという会社が多かったことが思い出されます。免税業者なら5%付加しない金額で請求書を書き、その金額が払われてたのですが、会社員をやめてフリーになって改めて調べると、免税業者に対する支払いでも消費税を付加するのが必要という記述を税務署のサイトなんかで見つけました。世の中わかりやすくなったものです。会社員以前の消費税話もいろいろあるのですが、今現在の話をしましょう。

では、現在、免税業者になっている個人や法人はその付加された5%をどうしているかというと、単にその人や法人の収入になっています。免除されているので国に対して払う必要がなく、収入なわけです。つまり、借受消費税は単に収入としてあつかっていいことになっています。現在、免税業者としてメジャーなのは年間で1000万円以下の収入のある業者です。それから、会社設立してからの一定期間も免税業者です。零細企業の支援の側面もあるのかもしれませんが、比較的多いと思われるのが、サラリーマンをしながら副業でちょこっと儲けているような人も、その副業部分が免税業者扱いになっているのが多いのではないでしょうか。これは統計がないのでわかりませんが、会社員しながら1000万を超える売り上げがある人はかなりの強者であり、その方は副業でも課税業者になりますね。まあ、普通はそこまでかせげないでしょう。

2001年頃に、免税業者の基準が売り上げ3000万円から1000万円に引き下げられました。免税業者数は368万人から231万人になり、免税業者は全体の40%になるという数字が発表されています。それまでは消費税を払っていない業者の方が数で多いという結果だったのです。当時は「うちは株式会社ですから」みたいな理由で課税業者を名乗っていた人もいましたが、おかしな理屈であり、都市伝説としか言いようがなかったですね。まあ、それはいいでしょう。

私は、1000万円以下という免税業者という施策自体を再検討する必要があると考えます。税金の公平な負担という原則があるのなら、収入に関係なくルールに従って支払うべきです。消費税は、収益に正比例するきわめて公正な税金です。消費者にはあますところなく支払わせるのなら、業者も同様じゃないでしょうか。全業者の支払い義務があるとした上で、優遇措置を検討するべきです。

収入を500万円、そしてさらに中間の250万円を平均的な収益としたら、精算した支払い税額はその5%として12.5万円です。非課税業者が200万人としたら、2500億円となります。全体の税収12兆円の中でみれば少ないのですが、それでも2%程度の増収となります。もちろん、収入額の平均値はもっと少ないとも言えますが、でかくもなく、少なくもない規模ではないかと思います。ただ、徴収のための手間というか、経費が増えるとも言えるのですが、簡易的な計算方法を導入しつつ、オンライン化により、さほどの費用はかからないと思います。

大昔の3000万円のライン、1000万円のライン、いずれも「政治的な判断」とされていて、確固たる基準がありません。これを撤廃すると、必ず「零細企業を苦しめるのか」的な意見が出てきますが、苦しめているのではありません。本来、消費者が国に対して払ったと思っているお金を、自分のところにとどめないようにしましょうというだけのことです。本来の収入ではないものを「自分のもの」として扱うフィーリングが正しくありません。そして、少なくとも、サラリーマンの副収入、つまり生活の糧は本業の給料で得られている人にまで非課税を適用するという点は、過剰な優遇としか言いようがありません。

税の公平は絶対に守られていないといけないと思います。増税の話題で免税業者のことが出てこないことに、やっぱりどこか「選挙対策」が見え隠れしている気がします。