何に困ってますか?と聞くことが超上流と考える3流

ソフトウェア開発において
超上流工程というのは問題を提議し課題を明らかにしていきます。

一般にソフトウェア開発者とユーザーは会話が通じません。
そこでどちらの知識も持った人が間に入って一つのシステムを作り上げます。
いわゆる通訳ですね。

僕が過去にインド人と仕事をした際、
日本語と英語の壁があり間に通訳が入りました。
通訳と言ってもインド人か日本人かによって全く理解度が変わってきます。
日本人の通訳が入るとこっちサイドはわかりやすいのですがインド人との会話はあまり通じて無さそう。
インド人の通訳が入ると僕は日本語には聞こえるが理解できない言葉に悩まされます。
ソースコードでなら会話ができるという異様な状況。
システム屋とユーザーの間の通訳も同じです。

インド人ほどではありませんが
日本語ネイティブ同士でも開発者とユーザーはあまり言葉が噛み合いません。
そんな状態で超上流工程を進めていきます。楽しいですね。

やるべきことやりたいこと、そしてやれること

やるべきこととやりたいこととやれることを分けて考えなさい。
言われたことがある人もいます。
基本的には仕事に取り組む姿勢に対して使う言葉ですが
これが中々どうして難しいものです。

きちんと分けられていますか?
僕は分けられていません。

そもそもやるべきことや、やりたいことって、皆さん明確なのですか?

データベースとデータ – 引き分けか負けしかない世界

今回は、データベースとデータについて考えてみようと思います。
学術的な話ではないので、きちんと勉強したい人はしかるべきところへどうぞ。
データベースの嬉しさと大変さについて私の見解を語ります。

僕は生産管理系の業務アプリ開発が専門なのでそれなりにデータベースに触れてきました。
しかし、担当するジャンルによってはデータベースに一切触れません。
縁がなくあまり触れなかった人に、少しでも興味が沸く情報を提供できれば幸いです。

リモートワークの抱える8つの課題

在宅ワーク、リモートワーク、テレワーク・・・
呼び名は何でも良いのですが、
新型コロナの影響が良い方に出たものの一つにこのリモートワークの普及があります。

難色をしめす人達の主張を押しのけ爆発的に広がりました。
僕の会社も新型コロナ前は月に5回までという根拠のない上限でテレワークを許可していました。
きっと何か事情があったのでしょうね。

今は通勤を最低限にするようにと、国からも指示が出ています。

僕は大好きリモートワークですが、いくつか課題もあります。
ちまたではいくらでも転がっている内容ですが、周回遅れで述べていきたいと思います。

役に立ちたい気持ちと役に立ちたくない気持ちと

勢いで行先ボードアプリを作りました。
僕としてはアプリを作りたい欲求が満たせたので満足です。
しかし、社内に展開してちょこちょこ要望が増えてきました。
後悔しています。なぜ僕が対応しなければならない?

自分で言ってて何を言ってるかわかりません。
勝手につくって、勝手に現場に投入して、活用されたら文句を言う。
僕は何様なのでしょうか。

まぁ、そこは置いておきましょう。
もう少し使われないままで作り続けたかったのですが使われると責任が発生します。
どうしよう・・・。面倒くさい。

成功も失敗もわからないプロジェクト

僕がITベンダーに勤めていたころは
「XXX開発プロジェクト」や「XXX社向けXXXXプロジェクト」など後ろにプロジェクトと名の付く仕事が中心でした。
製造業に勤める今、ワーキンググループと呼び名の異なるプロジェクトが仕事の中心です。

プロジェクトとは、一回限りの繰り返しのない仕事である。
プロジェクトの定義はNASAやPMI(米国プロジェクトマネジメント協会)などで行われていますが、
いずれにも共通する要素をピックアップするとこのようになります。

- 有期性がある業務(期間が限定され、明確な開始と終了がある業務)
- 独自性がある業務(繰り返しのない1回限りの業務)
- 明確なプロジェクト目標の存在

しかしながら、今の方が圧倒的に成功確率が低いのです。
何故なのか考察してみます。個人的な意見です。

WindowsサービスアプリでAppData/Roamingにつくったファイルが見つからない

行先ボードアプリをサービス登録して実行させたのですが、
本来あると期待していた場所にファイルがない。
このアプリはAppDataのRoaming配下の行先ボード用フォルダにファイルを作成するハズだったのです。
PC内全てをファイル検索しても該当するファイル名がない。
ただ、サービスアプリは何故かファイルを認識してアプリに状態が反映されている。
不可解な現象。正直ホラーです。

僕はホラーが苦手です。
ちょっとこわくて泣きそうになりました。

ソフトウェアの「つくれば保守が増える問題」

なければ作ればいい。名言ですね。誰が言ったのでしょう。
リスクを考えたら何もつくれない。いやぁその通りです。
でも、後のことそろそろ考えませんか?

ソースコードを読むしかないと思わせるドキュメント。
意図の読み取れないコメントで構成されたソースコード。
ソースコードを読んでも全くわからない論理構造。

僕たちはどれだけ過去の遺産に苦しめられないといけないのでしょうか。
なぜ10年も20年も前の古い技術や古い思想のお守をさせられているのか。
もちろんユーザーの要求や環境が変化するからです。

今、僕は被害者ぶっていますが、自分のつくったソフトウェアに対する文句です。
僕のソフトウェアも10年選手が登場し始めました。

もうぶっちゃけます。
当時は丁寧に書いたつもりでしたが、今見るとソースコードもドキュメントもコメントも何を言ってるのかさっぱりわかりません。
毎日過去の自分に毒づいています。うへぇ。

とはいえ、自業自得と片付けるのはあまりに芸がない。
だって読みやすいドキュメントがあっても保守は辛いので。

ユーザーは神様か?

かの松下幸之助さんは言いました。
お客様は神様です。

我々プログラマ―は成果物を評価される立場にあります。
完成品を世に送り込んで、誰かに使ってもらいます。

僕にとってのお客様はユーザーです。
では、ユーザーは神様でしょうか?
ぶっちゃけ敵です。

エンジニアファーストの日本を!!

僕はエンジニアファーストな環境を作りたい。
我々何かを生み出す職業に不具合はつきものです。
評価する人は使って少しでもストレスを感じれば鬼の首を取ったように批判をしてきます。
僕らはバグを出した罪悪感と自己嫌悪に加え、評論家の人格攻撃に耐える必要があります。

僕らは弱い生き物で作ったものでしか自己表現ができません。
成果物の評価を常に気にしています。
否定の言葉一つで積み上げてきた自信が瓦礫と化します。
不具合を徹底的に批判していないで良い部分を褒めてあげればよいのに。
そんなことを思う今日この頃。ちょっと文章を書いていきます。