ソフトウェア開発は今日も大変 No.2
第1章 納期は早々に決まり、仕様はいつまでも決まらない
その２ そして仕様は遅々として決まらない
開発はスタートしてしまうが、仕様はいまだ決定していない。決めてもらえるように頼んではいるが、いつまでも決まる様子はなく時間だけが過ぎていく。
待てる限りは待つが、仕方ないと手を付けられるものから手を付ける。派生開発においては、従来のままの部分も多いが、ハードの変更などで手を入れなければならないものは多い。
こちらが焦れて待っているのは伝わらないのか、遂に手を入れられる部分は尽きてしまう。
そしてまた決めてくれと伝えるしかないのだ。
さて、特に組み込み開発では、ありふれた状況なのかもしれないが、時間がお金だと考えられない現場だと、こういうことはあるようです。
どんな人でも決まっていないものは作れないのが真理です。
ここで、決めてもらえないから仕方ないという思想にはまり、組織に絶望して辞めるか、諦念の中で惰性で仕事をしていくかとなることは多いように思えます。
しかし、人を動かすには、それなりにコミュニケーション能力が必要になります。この部分では開発力が高い人でも苦労することが多いようです。
人と人との間、組織間、いろいろな問題がありますが、これも問題解決の一つなのだと思っています。さりとてどうするかとなると、人によっても組織によっても解決策は異なります。
ただひとつ分かっているのは、誰にも守りたい正義があるのです。
それに対する共感なくして味方になることはあり得ません。これが問題解決の第一歩だと考えています。
ソフトウェア開発は今日も大変 No.１
ソフトウェア開発は今日も大変
第1章 納期は早々に決まり、仕様はいつまでも決まらない
その１ とりあえず納期は決まっている
次の開発が始まるのは、延々と遅れた前回の開発の余波が収まるまで待ってくれることもなく、スタートから遅れているかのような悲壮感をそこはかとなく漂わせ、ソフトウェア開発者の諦念の気持ちの中でこれといったイベントがあるわけでもなく、ただ何となく、それは始まるのだろう。
ソフトウェア開発者は思う、納期はもう決まっているのに、仕様の詳細はまだ決まっていない。これはいつもの繰り返し。昨日まで何度も繰り返された日常である。正しい開発プロセス、ウォーターフォール、そんな綺麗ごとはできない。できないが、何かを変えることもできない。そうして日常に埋もれていく。
さて、仕様より先に納期が決まる。見積もった結果、納期が策定される訳ではなく、まず納期が指定される。これは悪いことなのかといえば、必ずしも悪いことではない。レッドオーシャンを生き抜く企業にとって、競争相手より先に商品をだすことは、とても大事なことなのだと思う。これ自体はおそらく多くの企業で普通に行われていることなのだろうと考えられます。
先に納期を決めることは一概に悪とは言えない。
例えば、開発期間でおつりが来るくらい先の納期が指定されていれば、誰も不平不満は言わないはずで、短い時にだけ、そういう話になるからです。
とは言え、余裕がある開発とかしたことはないのですが、納期が先に決まること自体に功罪の罪の部分を負わせるのはちょっと違うかなと思うのです。
商業的に営利団体がロードマップを持つことは当然の事と考えるのは自然であり、それを目の敵にするのは、ちょっと違うのだろうなあと感じているわけです。
では何が悪いのか、少しずつ追いながら考えていきたいと思うのです。
No.258 ふとした機会を得て
・講演をしてくれと言われて
還暦を過ぎて再雇用で働く身の上の自分に、こんな依頼があるとは思ってもいなかったのだが、社会貢献できる機会を頂けたのだからと、ボランティアとして受けることにしました。
なぜ要求でくろうするのかを語ってほしいというので、沖縄まで行くことになったのでした。
・いろいろな人がいて
沖縄訪問も初めてのことでしたが、意外なほど寒いという経験をすることになったりしましたが、なんとか、数名の前とはいえ、無事に役割を全うできたと思います。
感想についてもその後頂きましたが、リップサービスの部分もあるかとは思いますが、概ね高評価を頂けたようでした。
そこで面白いと思ったのは、受講後の感想でそれぞれの人の着目のポイントが話の部分で違ったという点でした。やはり、その結果は非常に面白いです。
・正解のない場所と自覚する
要求でありがちなのは、正解を要求者が持っていると暗黙で思い込んでいることです。確かにその部分については確固たる要求があっても全体を微に細に渡り完全な形で持っているなどということはないのです。なのに、正解があると思ってすり合わせに行ってしまう・・・それが悲劇を生むきっかけになっているかもしれません。
正解は関係者全員で作り上げる。それがステークホルダーも自分も救う道ではないかと思っている次第です。
No.257 ソフトウェアテストで
・外国人との差異
知識としてメンタリティが違うということが分かっていても、実体験としてそれを学ぶケースは多くはないでしょう。
外国人の開発者にこちらがテスターとして不具合を指摘して直してもらうのは、そのメンタリティの違いを乗り越える必要があるのです。
基本的な性格のようなもので、日本人の文化とは決定的に違うのが取り組み方です。
・コンテクスト
日本人は背景情報が似通っているので、言葉にしなくても伝わる部分が多く、腹芸とか察するとか、言外の部分のコミュニケーションが成立しますが、外国人との間ではこれは絶対に望めません。
ローコンテクストの文化では、言わなきゃわからんだろうということがベースなので、伝えないことはやらなくていいことになります。これが結構厳しいです。
・異文化コミュニケーションを
結局、日本文化を背負うなら、とことん相手を理解する方向に行くしかありません。背景情報が違うので、全部書く、全部伝えるが当たり前なら、どれだけ面倒でも書くしかありません。濁すとか、フィーリングで伝えるというのは相手の理解の外のものです。
とにかく、伝える側に伝える責任があるのはワールドスタンダードで明白なので、常識を理性で封じ込めて仕事をするような感覚でやるしかないでしょうね。
No.256 育った環境
・常識とは刷り込みのようなもの
その環境における普通が、一般的なものと違っても、その世界しか知らないものにはそれ以上のことはできないものです。
北朝鮮の体制が維持されるのも、そういう側面があるのだと思います。
だから、まともとは言えないプロセスが日常化している環境に身を置くのは、周囲から見れば不幸ですが、本人には普通であり、日常に過ぎないともいえるのでしょう。
・一度壊れてしまうと
正しいプロセスが機能せず壊れてしまうと、その組織は、正しいところに自力で戻ることはできなくなります。その理由は、必要なスキルが失われてしまうからです。こうなると、異常であってもその中で生きていくことしかできなくなります。
そして、経営層がちゃんとやれと言っても、スキルがないのでそれをすることはできなくなります。これはエンジニアの敗北ではありません。
・経営者に結果以外のものに向き合う覚悟があるか
これは、本来問題がエスカレーションされていけば、解決義務がある経営層が正しいものを無視して結果だけを安易に求めてしまうことがあるからです。下の人間はやめるか、あきらめるかの2択なので、どちらでもいいのです。
エンジニアリングが、目先の売り上げに敗北したとは考えたくない筆者の思い込みなのかもしれませんが、正すには痛みを伴う改革が必要なのは事実だと思っています。
No.255 組織か自分か
・組織のために
組織は組織のために、人を使います。しかし、人にとってのベストな環境といえるかどうかは別物です。
仕様変更、プロセスを無視する例外の強要、それらはすべて組織のためにの一言で成立する世界といえます。
・自分のために
組織を優先すると、個人が成長しても評価が上がらない可能性があります。どんなに素晴らしい仕様書を書くことができても、後回しにすることが決まり、形だけあることが望まれれば、中身は評価されることはありません。これで努力をやめた人は外では通用せず、飼い殺しになる恐れもあります。
・客観的な目で
結局、自分の価値観に従って生きていくしかないのでしょうが、願わくば世間で通用するソフトウェアエンジニアになっていただきたいと思うのです。自分が存在している組織がどのような場所かで、成長できるかどうかがかなり変わりますが、組織に望まれずスキルを伸ばすこともかなわず、埋もれていくのは悲しいことだと思います。
強くなるとともに強く在ってほしいと切に願います。
No.254 例外の価値
・仕様書は後回しで
これを認めた結果、仕様書をチェックする人間は不要になります。そして書く人間もチェックされなくなるので、そのスキルは育ちません。
例外を認めるということはその組織の価値を貶めています。
・リリースは早くなるのか
例外を認めて仕様書を後回しにした結果、品質の低下分の抑えが効かなくなります。その結果、品質は落ちていくことになります。定量的に管理しようにも基準を失った状態では、人依存でしかそれは回らない状態になります。
・そしてもう書けない
それを単にソフトウェア開発者の問題にしてしまったら、安易に書けということが経営者はできてしまいます。しかし、長い間で失われたスキルは組織内にないので、何を書かなければならないのかもわからなくなります。
おそらく、二度とそのスキルが組織内に定着することはないでしょう。
