ITをビジネスにしない楽しさ

ソフトウェア開発において
要件定義がうまくいけばほぼ失敗することは無いでしょう。
受益者が考えるベストプラクティスを聞きだし、
それを機能一覧に落とし込めれば終わりです。

後は想定した機能一覧をどれだけ精度よく具現化するかだけのお話です。
そこに技術の差がありプログラマーの腕の見せどころかもしれません。
しかし、それはどれだけこだわるかだけの話です。

実は、請負業務を中心がプログラマーは
「誰かのベストプラクティス」を「誰かが確立した技術の再利用」で
ソフトウェアをつくります。

以下のことをやるケースは稀です。

  • ベストプラクティスをつくる
  • 誰もやったことが無い新技術を確立する

少しそのあたりについてお話したいと思います。

ワードプレスの引っ越し屋さん – Twitter-Bot

バックアップファイルってなんか可哀そうなんですよね。
人知れず誕生して発生しない不測の事態に備えます。
数日経てば世代交代です。
誰からも参照されることなく上書きされて消えていきます。

不測の事態に活躍する子以外は
一体何の役割を背負ってこの子たちは生まれてきたのでしょう。
ただ毎日生まれて消えるだけ。なんと儚い。

と、そんな話はどうでも良くて
ただバックアップとして存在させるだけでは勿体ない。
というのが今回の蛇足案件。

バックアップファイルを使ったTwitterボットです。
Twitterボット自体は世の中に腐るほどあるので
なぜこんなバックアップファイルを使うという回りくどい方法で実装するのか?

理由は先に述べたとおりです。では、今回も雑に話を進めていきます。

ワードプレスの引っ越し屋さん – 蛇足モード

思いのほか簡単に引っ越しツールが
出来上がってしまったので完全に不完全燃焼です。
ここからは完全に蛇足モード。
相変わらずワードプレスの引っ越し屋さんアプリを弄っています。

ワードプレス引っ越しのために作ったツールですが、
引っ越しの過程で出来上がるバックアップファイルを眺めてると色々使えそう。

全記事が手に入るので、
今回は形態素解析を使って過去に作ったタグカテくんを実装していきます。

結論の出ない記事ですので読むだけ無駄だと思います。
最近そんなんばっか。

ワードプレスの引っ越し屋さん – 使い方

引っ越しは滞りなく完了しました。
手前味噌ですが思った以上に便利だったので
本ツール(ワードプレスの引っ越し屋さん)を使った引っ越し作業についてご説明します。

※AWSのBitnamiの環境でのみテストを実施しています。
今後、どの環境に対応できるか試してみます(予定は未定)。
(2021/10/02)

クラスとは何か

オブジェクト指向の概念であるクラス。
クラスとは何かと聞かれると最近の答えの流行りは設計図のようですね。
僕はあまりしっくり来ません。

設計図はクラス図のことで、UMLやSysMLの図の中の一つです。
少し大きめのソフトウェアを作る時、僕はクラス図を書いてクラス設計をします。

クラスが設計図ならクラス設計は設計図設計になってしまいます。
何かがおかしい。

僕はC言語からプログラマーの世界へ入ってるので、
オブジェクト指向否定派の一人でした。

オブジェクト指向の嬉しさが全くわからず調べてみても自動車やら動物やらの例ばかり。
で、何が嬉しいの?が全くわからない。
抽象化、多様性、ポリモーフィズム、カプセル化・・・だから何?

そんな僕がクラスの嬉しさについて少し語ってみようかと思います。
クラスの嬉しさは「再利用」と考えるのが良いのではないかと僕は考えます。

お文具さんとつながりたい – TwitterAPI+Cytoscape編

先日、TwitterAPIを操作できるTwitter Developer IDを取得しました。
簡単に言えば、Twitterと僕が作ったソフトでお話する方法がAPIです。

今回のTwitter APIを使ってフォロワーを辿っていきたいと思います。
ただ辿っていくのも面白くないので、僕が愛してやまないお文具さんを目指します。

一般に友達の友達はどう考えても他人ですが、
SNS界隈では友達の友達は友達という非常に息苦しい世界です。
しかし、今回はこの理論を採用し僕のフォロワーのフォロワーは僕のフォロワーという事にして話を進めます。
つまり、フォロワーを辿っていつかお文具さんにたどり着けばお文具さんは僕のフォロワー。
晴れて両想いという極めて気持ち悪い思考回路の取り組みです。

前段が長くなりましたが、要は
Twitter APIが使いたい
のです。

では、ご興味のある方のみお付き合いください。

DXの設計書㉕ – アジャイル方法論

僕がアジャイルに興味を持ったのは10年ほど前でした。
受注後、どんどん変わっていくお客様の要求に何とか対応できる方法が無いかを検討したのが最初です。

しかしながら予め成果物を決める請負契約とは全くマッチせず、
要求詰め放題プランになってしまいました。

今、転職し契約に縛られない働き方ができるようになりました。
改めてアジャイルについて考えてみます。
DXにおいてアジャイルは肝になると考えています。

ラプラスの悪魔 – 見積は難しい

僕はブラック・スワンの愛読者であり、
不確実性を予測することは不可能という立ち位置です。

見積の段階で全てのリスクを予測することは不可能ですし、
計画の段階でソフトウェア開発に必要な資料を完璧に作成することも不可能です。

ラプラスの悪魔。
例えば、テニスの壁打ちで壁から跳ね返ったボールがどこへ戻ってくるのかは予想がつきます。
その延長で、もし仮にすべての状態を解析できるだけのデータと能力があれば、
全ての未来を予測することは可能だというお話です。

もしもある瞬間における全ての物質の力学的状態と力を知ることができ、
かつもしもそれらのデータを解析できるだけの能力の知性が存在するとすれば、
この知性にとっては、不確実なことは何もなくなり、その目には未来も(過去同様に)全て見えているであろう。
『確率の解析的理論』1812年

ラプラスの悪魔 Wikipedia

そんなのムリに決まってんじゃん。

ソフトウェア開発プロセス – 自己流プロセス

ソフトウェアの開発プロセスは混とんとしています。
プロジェクトは基本的にプロジェクトマネージャーやプロジェクトリーダーの理論(持論)やクセで進みます。
中小企業規模のソフトウェアハウスで、きちんとプロセスモデルが定義されているところは少ないでしょう。

ある日突然リーダーやマネージャーに抜擢され、
特に教育を受けることもなく自己流のマネジメントをします。
プロセスすら固まっていないのでマネジメントがうまく行かなくても仕方ありません。
一人で開発する場合はフレキシブルに開発できますが、複数人で開発する場合はそうも行きません。

自信をなくし
「マネジメントしたくない。プログラマーとしてやっていきたい。」
そう考えるプログラマーやプロジェクトマネージャー・リーダーは多いです。
優秀なプログラマーからプロジェクトマネージャーになる人は特にそうですね。
知識不足だけで自分の可能性に線を引いてしまうのは、もったいない話です。

今回は少しプロジェクトマネジメントにおけるプロセスについて考えてみます。
どんなものがあるのか知っておくだけでも有意義です。

DXの設計書⑳ – クラウド?オンプレ?

定期的にお金が出ていくクラウドの仕組みが世の中に受け入れられ始めてきました。
また、社外にデータを置くことにも抵抗がなくなってきたように感じます。

クラウドサービスの形態はさまざまです。
端末やOS管理がいらないソフトウェアだけを借りる
Saas(Software as a Service)を対象にお話ししていきます。

クラウドを選ぶべきかオンプレでいくべきか