継続的デリバリー

「実践ソフトウェアエンジニアリング第9版」を1読目したのが先週。その後、一旦停止していた「継続的デリバリー」を読了。

「実践ソフトウェアエンジニアリング第9版」が教科書的であり、網羅的な書籍だとすれば、「継続的デリバリー」はソフトウェアと非ソフトウェアのプロダクトのコンテキストにおいて、工学の違いを熱く説き、私たちもこうあらねばと突き動かしてくれる書籍である。顧客から変更要求があった場合、1時間後には彼らに価値を提供したいという方向へ1歩前進させてくれる良書である。

実は、前回書いた「モジュラー性、凝集性、関心の分離」という言葉は、この「継続的デリバリー」に出てくる言葉で、私たちはそれらを頭では理解しつつも、言い訳ばかりして低品質のソフトウェアを作ることが多々ある。これらの弱気な心を打ち砕いてくれるという意味でも良書である。つまり「良書」は「良書」である。

ちなみに「実践ソフトウェアエンジニアリング第9版」は昨日から2読目に入った。こういう圧倒的な量の本は3読、4読くらいした後、実践して初めて自分の力となると信じている。継続は凡人に与えられた最強の武器だと私は常々考えている。

ソフトウェアエンジニアリング

やっと、1回目読了した。教える仕事を始めてから、しばらくご無沙汰になっていたソフトウェアエンジニアリングを改めて学び直した。IT企業にいたころは多忙を極め、まとまった時間をとることができず体系的に学んでいなかったので、改めて学んでみると多くの気づきがあった。多くのプロジェクトのマネージャやアーキテクトをこなしてきたが、エンジニアリングという観点から振り返ると至らないことが多々あったと反省するばかりである。

ここ10年で、いやここ1年で劇的に変わったことは生成AIの登場だが、中規模以上のプロジェクトとなると、複雑さの管理が必須となり、生成AIに頼ることができなくなる。ITエンジニアはプログラムを作ることがメインの仕事ではない。人の役に立つプロダクトの提供がその目的である。開発工程はプロジェクト全般から見ると10%程度とも言われている。簡単なコードや文書の作成などであれば生成AIがアシストしてくれるが、それ以上となると人間による管理がどうしても必要となってくる。

簡単なコードであれば、多くのサイトで学習している生成AIが簡単に答えを出すが、残念なことに少し複雑になると、コードのモジュラー性、凝集度、関心の分離などを考慮したプログラムの作成は全くこなすことができない。

人間にとっての複雑さとは何かをAIが理解するのはまだまだ先の話である。

少し話がそれたが、IT技術者なら是非知っておきたい分野である。対象者はIT技術経験5年以上くらいだろう。

独学

趣味や仕事に関係なく、何かを習得したいとき、お金をかけたくなければ独学しか選択肢がない場合も多い。いまはユーチューブはじめ映像関連の情報、技術系のサイト、ブログなどがあふれているが、全体像を知りたい場合や個々の技術どうしの関連性知るには、書籍の方が向いていると個人的には思っている。

もちろん、今ではChat GPTなども登場し大いに役立っているが、まだまだ間違えた答えが多い。私は本を読むときに分からない言葉が出てきたりすると、Chat GPTにその言葉の意味・定義と他の言葉同士の関連性を質問すると精度よく答えてくれる。ただし、やはり全体像がまだぼけているし、ある程度以上になると精度も落ちる。

また、独学は最初の数ページまでは新しい世界に触れたことで胸躍る高揚があるが、それ以上になってくるとだんだん理解が追い付かなくなり、苦痛になったりもする。それでも私はそれを習得することに価値があると思うと最後まで何回も読み通し理解できることが多い。それは人より少しだけ継続する力があるからだと思う。

とは言え、私も挫けるときは挫ける。そんな時助けてくれたのが、読書猿さんの「独学大全」である。読書猿さんは「アイデア大全」などで知っていたので、発売後すぐに飛びついた。

その本のいくつかは私も実践していただけに非常に共鳴できる部分が多い。それでも55のテクニックは決して思いつくものではない。まさに圧巻と言える。多くの生徒さんに紹介している。継続力を先天的に持ち合わせている人はおそらく稀であると感じている。努力して勝ち取るものだが、習慣化するまでの工夫が必要である。そのテクニックを知らないのはもったいない。「独学大全」は超お薦めの書籍である。

予習

プログラムに限らず、誰かに教わるときは予習は必須である。独学の場合は反復練習が重要になるが、時間もそれなりにかかる。理解するまで、「あっ、そういうこと！」と脳の回路がつながるまでの時間が長い。

しかし、その分野を熟知している人から教わるときは、一番重要なのは予習である。何が書いてあるかさっぱり分からなくても、分からない言葉、分からないコードは分かるようになる。その状態で授業に臨むと自ずと質問が飛び出てくる。そうすると分からないコードがすぐに理解できるかというと、そう簡単ではない。しかし、不思議なことに分からないことの輪郭がよくわかるようになってくるのである。それは理解の前兆だと思った方がいい。多くの人は分からないことがさらに分からなくなったと嘆くのだが、輪郭がはっきりしてくるというのは、問題が見えてくるということであり、それに対する思考がフル回転する準備ができたということである。

私の経験だと、COBOLという非常に古い言語から、その当時は生まれたばかりのJavaを勉強し、理解までに数年を要した。しかし、いざ業務となると全体像が全くつかめない。客先に常駐しての仕事だったが、まだ、Strutsというフレームワークさえ生まれていない時に、初めてフレームワークと出会った。何日も何日も理解しようとするのだけれど、まったく、本当に全く理解できないのである。この数年間の私のJavaの勉強とは何だったのかと考え直すほど打ちのめされた。

しかし、その会社は非常にオープンで社員ではなくとも勉強会に参加を許してくれた。5つの勉強会すべてに参加し、すべてが素晴らしかった。今まで理解できなかったことが話題となっていたため、私は質問攻めした。質問がとめどなく出てくるのである。

結局5つの勉強会のうち4つの勉強会を追い出されたが、そのころには完全にそのフレームワークを理解した。それも手に取るように理解したのである。その後、いろんなプロジェクトに参加したが、私は勉強会を開催し、後進の技術者に惜しむことなく教えた。特によく質問してくれた人には勉強会以外でも質問に答えた。

予習していないと授業の時に頭がパニックになるのは不思議でもなんでもなく、誰だってそうなる。パニックは授業の前に経験し、授業はそのパニックを解決するためのの場だと私は考えている。

アルゴリズム

「プログラムを習得するにはとにかく暗記ですか？」と質問される生徒さんが多い。暗記ではないが、繰り返しコーディングすることで構文に馴染むことは大切である。繰り返しのメリットはコードを読んだ時には意識していなかった箇所がクッキリ形をなって現れてくることだ。また、構文をしっかり習得することで、アイデアをコードに置き換えるという本来のプログラミングに専念できるようになる。

しかし、プログラミングの本質はアイデアを形にすることなので、定型的なものの繰り返しではその能力を磨くことができない。アイデア・考えを形にするには、モニターとにらめっこしても解決できないことが多い。意外と思われるかもしれないが、紙のノートにアイデア書き出し、どうすればそれを実現できるかの試行錯誤は非常に重要となる。コードは1次元である。アイデアはおそらく4次元以上である。モニターとにらめっこし、コードを書き、デバッガーでデバックするだけでは難しい問題を解けない。どのようにして解くかの戦略を立て、実現可能な候補を挙げていく。すべての候補を考慮しても実現可能と感じられない場合は、戦略の練り直しである。また候補を挙げ...の繰り返しである。手書きのノートは自分の思考過程を追うには最適だと思う。デジタルでは思考過程を残そうとすると凝ったグラフや表を作ることになり、本質から遠ざかってしまう。

では、どのような訓練をすれば、そのような力がつくのか？それは自分の思いついたアプリであったり、業務ロジックであったりする。ただし、そのような状況にない場合は、アルゴリズムを解くのをおススメする。アルゴリズムはパターンを暗記するのが目的ではない。アルゴリズムを学ぶ目的は、解決すべきゴールを処理速度やメモリ要件を満たし実現するかを考え抜くためにある。他人のコードをコピーするだけであれば、それは時間の浪費である。考え抜くことに価値がある。1つの問題を解くのに1週間かかることもざらにある。行き詰ることも多々ある。それでもその経験が財産になることは確かである。その積み重ねの上にアイデアを素早く形にする素養が出来てくる。

アルゴリズムの本はたくさんあるが、私的にはロバート・スウェジックの本が好きなのだが、最初に取り組むには少し難易度が高い。日本語の参考書で入手しやすいものであれば、柴田望洋先生の本は練習問題もついておりおススメである。写真はC言語であるが、JavaやPython版もあるので、言語は問わない。特に練習問題を解くと力が自ずとついてくるので辛抱強く取り組むのが大切。

Laravelで大規模システム開発

Laravelは今やPHPのフレームワークとしてはダントツに人気がある。学習コストが少なくて済むのも魅力だと思う。

しかし、ミドルウェア・カスタムバリデーション・クエリビルダ・認証と認可あたりになってくると途端に難しくなってくる。

そのようなトピックまで紹介している参考書が見つからず苦労していたが、ついに出た。「PHPフレームワークLaravel Webアプリケーション開発」。

オブジェクト指向の基礎ができていないとわかりづらいが、オブジェクト指向を知っていると思わずなるほどという記述が多く出てくる。バージョン5.5の時もいい本だと思ったが、今回もそれに負けないくらいいい本になっている。中級者以上にはおススメ。オブジェクト指向が苦手という方はまずオブジェクト指向の理解から。PHPはオブジェクト指向を知らなくとも、ある程度できるのが大きな魅力なのだが、やはりさらに深く理解し、フレームワークを使いこなしたいのであればオブジェクト指向はPHPでも避けては通れなくなりつつある。食わず嫌いを乗り越えオブジェクト指向に取り組むと、さらにその先に広い世界が待っているはず。(当教室はPHPでもオブジェクト指向を勉強したいという方にもキチンと対応)

また、MVCフレームワークだけでなく、柔軟なアーキテクチャの紹介もまた素晴らしい。ADR(Action Domain Responder)の話が出てきたり、Javaなどでは当たり前のレイヤードアーキテクチャの説明もわかりやすい。このあたりは上級者にならないとピンと来ないかもしれないが、ある程度以上の規模のシステムを組む場合は知っていなくてはいけないトピックである。PHPは大規模システムには向いていないという人が多いが、Laravelの成熟度を見ると、大規模システムにも使えそうだいうのが私の感想である。

TypeScript

JavaScriptの進化速度が速く、着いていくのも手一杯だという人も多い。私も教えてて大変疲れることが多い。

ある程度JavaScript、Java、C#を知っている人であれば、TypeScriptやDartの方がおすすめかもしれない。昨日少しだけ、TypeScriptを使ってみたが、型を指定できるのはやはり魅力的だ。Pythonを作ったグイド・ヴァンロッサム氏はBDFL(優しい終身の独裁者)から引退されたが、その最後のころにPythonを動的型付言語にしたことを悔やんでいたというニュースも流れた。Pythonにも型アノテーションはあるが、やはりJavaやC#のような静的型付け言語には程遠い。

システムの規模が小さいうちは動的型付言語の方がサクサクつくれるが、大規模になると途端に型がないことがデメリットになってしまう。そういう意味だと今までJavaやC#で作られたサーバサイドのシステムとTypeScriptとDartなどは相性がいいのではと考えている。

しばらく、遊んでみて、使えそうであればコースに組み込みたいと考えている。

自然言語解析

2019年は統計学から始め、TensorFlowやKerasを使った画像認識や文字認識などにチャレンジし、大いに楽しんだ。世間のAIに対する過剰な期待などはまったく持っていないが、使い方次第では面白いこともできそうだということだけは確認できた。

そこで今年2020年は自然言語解析にチャレンジしようとしている。ただ深く知ろうとすれば言語学や言語哲学まで踏み込まないといけない。ふーむ、迷ってしまう。非常に面白い世界なのだが、それ故に膨大な時間が必要となるのだ。まずは写真の本で探りを入れ、様子見するとしよう。第1章だけしか読んでいないが、いい感じの導入部である。海外にはいい書籍が多い。

勉強のコツ

プログラミングは理屈でもあり、慣れでもある。一番いいのは理屈を理解して慣れること。しかし、理屈の部分は普段慣れない考え方が出てくるため拒絶反応も起こしがちである。

無理に理解せず、いつかは理解できるというスタンスでも構わない。ただ、実際にコードを打ち込み試行錯誤はどっちにしろ必要である。Aを削除してみたり、Bを追加したり、いじくりまわしている間にうっすら概念が入ってくる。

ある程度理解できるように感じてきたら、とにかく何度も繰り返すこと、これ以外の近道はない。学問に王道はない。サンプルを打ち込んでおしまいという勉強では上達は難しい。

有言実行

去年の春頃に卒業された生徒さんから、「ドイツで働いています」と連絡があった。授業中、将来はドイツに住みたいとその生徒さんからは頻繁に聞かされていたが、こんなにも早く実現するとは予想していなかった。

住むだけでなく、しっかり働けるようになるためにプログラミングを勉強したいとの要望で授業をすることになったのはよく記憶している。しかし、それはなんとなくの夢なのかなと思っていたが、予定通りというか、それ以上のスピードなので驚いているし、感動している。

私も日々の忙しさにかまけて、自分の目標を見失いがちだが、私も夢に向かって一歩一歩進めていかなければと、おしりを叩かれたような気がする。嬉しい報告だった。感謝。感謝。

OS自作!

3月に卒業した生徒さんから近況があった。研修も終盤に差し掛かっており、今はOSの自作に取り組んでいるという。同期のほとんどは大学で情報処理を学んでいるようで遅れをとっているが、なんとか食らいついているようだ。

最初は同期との差を意識するが、10年経てば、誤差の範囲でしかない。こればかりは10年経たないと実感が湧かないのでしょうがないが、今は周りを気にせず、基礎体力作りに没頭してほしい。

オブジェクト指向については授業でしっかりと教えたので、周りと比較すると理解が進んでいるようだ。

どのような業務に就くのかは聞いていないが、与えられた業務を積極的にこなし、10年後には会社を背負うくらいになってくれたらと願っている。

Djangoチャレンジ中

ASP.NET Core、Spring Bootに続き、ようやくDjangoに着手出来た。

ルーティングはASP.NET CoreやLaravelなどのように、ファイルに集中して記述するタイプ。ただ、Djangoの場合、プロジェクトにアプリケーションを追加していくことによってプロジェクトを組み立てていくので、アプリケーションにもルーティング用のファイルが置けるようになっている。Spring Bootのようにアノテーションによるルーティングはないようだ。私の好みはどちらかというとファイルにまとめて記述できるタイプの方だ。その方が全体としての動きが俯瞰しやすいと思う。

Djangoにもテンプレートは存在し、DTL(Django Template Language)を使うことができる。テンプレートの継承やフィルターなどは他のテンプレートと大きな差異は感じられない。

また、コマンドラインベースの作り方も、今のフレームワークらしさを感じる。メニューから辿っていくよりも、コマンドをたたいて、枠組みを作る方が私には合っている。GUIのメニューベースの作り方は初学者には向いているが、慣れてくるとコマンドの方が圧倒的に生産性は高くなる

マイグレーション機能もシンプルで使いやすそうに見える。マイグレーションも最近のフレームワークにはなくてはならないものになっている。

O/Rマッパーは今はあって当たり前なので特筆すべきところはない。今のところ、Djangoだけの素晴らしい機能というのを発見できていないが、フレームワークとしての機能としては十分だと判断している。

Spring Bootチャレンジ中

Spring Framework自体は随分前に触ったことがある。DI(Dependency Injection:依存性注入)の仕方が素晴らしく感銘した記憶がある。

記憶があいまいだが、Java EEのDIはSpring Frameworkを参考に作られたと思う。その当時の私はJava EEを使って多くのシステムを作っていたわけだが、Spring FrameworkのDIは素晴らしいと感じた。

Java EEでもDIが使えるようになってからは、Spring Frameworkから遠ざかっていたが、ある生徒さんとSpring Bootを勉強することになった。

私が知っているSpring Frameworkはシンプルで分かりやすい作りであったが、久しぶりに見たSpring Frameworkは肥大化し、お世辞にも扱いやすいものではなかった。Java EEの肥大化を思わせるものがあった。

おそらく、そのように感じているのは私だけではないはずだ。その証拠がSpring Bootの出現だと思う。内臓アプリケーションサーバを持ち、Ruby on Railsのように「構成より規約」に従うスタイルも、今のシステムづくりとマッチする。

PHPのLaravel、ASP.NET Coreもほぼ同じような感覚で作ることができる。正式にコース化していないが、いずれコースを開講したいと考えている。

LINQ再び

久しぶりにLINQを使っているが、改めてその簡潔さと、他のデータソースと同様の記述ができることに改めて感心している。

試しに、リストを3つ用意し、join句またはJoinメソッドで連結する練習をしたが、実に素晴らしい。特にjoin句はほぼSQLライクに使用できる。

group by句またはGroupByメソッドも2つ以上のプロパティを使いこなす練習をした。JoinとGroupByを自由に扱えるようになると、一挙に世界が広がるように感じられる。

5、6年ぶりに触ったLINQ、改めてC#のアーキテクチャ設計能力に圧倒された。

誤解してた

ASP.NET framworkとASP.NET coreの多くはクラスを共有しあっていると勘違いしてた。「プログラミング ASP.NET Core」を読んで、ASP.NET Coreは一から作り直されたものだと知った。

ということで、今までのいろんな誤解が解けてすっきりした。知らないというのは時として大きな誤解を生むことを再認識。また一歩前進！

WebAssemblyって気になるね

JavaScriptも面白い言語に成長しているが、やはり速度的に限界がある。JavaScriptがなくなるわけではないが、今後は、パフォーマンスを必要とする部分はWebAssemblyに置き換わっていくだろう。

C/C++、Rust、GoなどがWebAssemblyを吐き出すことができるようになっている。RustやGo言語界隈もにぎわっている。C/C++は相変わらず人気があるが、RustやGoも目が離せなくなってきている。

今すぐという訳にはいかないが、RustやGoのどちらかをコースに含めたいと考えている。この業界、いつまで経っても刺激があっていいよね。

多態性・デザインパターンつまみ食い

前回のつぶやきで触れたコンソールベースのネットショップアプリだが、多態性とは何か、疎結合とは何か、データソースやアプリの形態に依存しない作りにするには？など、今までは簡単なサンプルコードでしか経験していないものを、このアプリでは本格的に経験し理解できる仕組みになっている。

Blackjackなどのゲーム作りも面白いが、上記のような概念を使いづらいと感じている。特にデザインパターンを導入することでうまく整理できるものがあることを、少しだけだが実感してもらっている。

このアプリに真面目に取り組んだ生徒さんは一気にオブジェクト指向に目覚める。地味だがいい訓練なのである。参考書を100回読んでも理解できないものがすっと頭にはいる瞬間である。

アハ体験？

Javaの中級コースでコンソールベースのネットショップアプリを作るが、今まで勉強してきたオブジェクト指向とまったくかけ離れたコードを書く生徒さんがほとんどである。COBOLやBASICの世界に戻ったようなコードである。

しかし、これでいいと思っている。とにかく課題を形にしてみる。最初は要求したものが出来ればいいのだ。そこから徐々にヒントを出してゆく。そうすると参考書に出てきたオブジェクト指向の概念と結びつくようで、一種のアハ体験をしてもらっている。

徐々に改良を加えてゆくと最初とは見違えるようなコードに変化してゆく。まるで錬金術である。

基礎をしっかり押さえた生徒さんほど、この課題で一気にオブジェクト指向の考え方が身に着くのである。教えている私の方も感動を覚える瞬間である。「オブジェクト指向おもしれーっ」と叫んだ生徒さんの時は痛快だった。

とにかく、やり抜く！

プログラミングをはじめとしたIT技術は確かに習得は大変だが、継続してやり抜く力が必要である。頭を動かし、手を動かし、体を動かし、目を動かし、耳を動かす。たまには味覚も動かす。五感をフル動員できるようになることが大切である。これは決して比喩ではない。人間の脳はそれだけで駆動するのではないと思っている。脳の周りのものを動かして駆動すると日ごろから考えている。

いくら優秀な者でも、本を読むだけでは無理である。本を読んだら実践する。サンプルコードを打ち込む。意味を考える。サンプルコードをいじくり倒す。サンプルコードが原形を留めないくらいになるのがちょうどいい。モニタだけ眺めてもだめで、たまには紙に書き、ホワイトボードで頭を整理し、人と議論する。キーボードをすごい勢いで叩き、問題を解決するのはテレビや映画の話である。キーボードを叩くのがIT屋の仕事ではない。IT屋は自分のアイデアを形にしたり、お客様の要望を的確に捉え、より良い提案を行った後に、それを実現するためにコミットするのがその仕事である。

じっと待っていても理解することはできない。能動的な思考が必要である。学生のように解答が用意されているわけでもなく、自らゴールを決め、厳しいテストに耐えるものを作り上げてゆく。誰かのせいにしている暇はない。継続し、やり抜くこと。それだけのことである。

毎日、長時間教室で授業をしているため、たまに外に出たくなる。とは言っても遠出はできないので、近場をドライブすることが多い。

糸島をグルっと回った後、今宿のキャンプ場に寄ってみた。天気も上々、気温は30度超えているはずなのだが、木陰に入ると海から吹き上げてくる風が心地よく、しばらく腰を下ろして寛いだ。

本格的な夏に向けて、剪定する作業員の方がいるだけで、この綺麗な木々がもったいなく感じた。土日ともなると親子連れでいっぱいなのだろうが、まだ夏休みでもないので平日は非常に静かだ。

山登りもしたかったが、作業員の方曰く、低い山だが急な斜面も多いとのことで、途中の鉢伏観音まで行き引き返した。不覚にも途中道に迷ってしまった。標高も低く、キャンプ場から聞こえる芝刈り機の音を頼りに無事降りることが出来た。

Pythonのフレームワーク。2005年に登場したフレームワークである。その頃から機械学習の芽が出始めたと記憶している。そう思えば、結構年季の入ったフレームワークになってきたと思われる。

私自身、最初に触ったのは2008年、海外旅行のついでに参考書を買って遊んでいたのだが、激務中だったこともあり、その後すっかり忘れてしまっていた。

ある生徒さんがWebアプリを作りたいというので、思い出した次第である。どんなフレームワークだったかも全く記憶にない。機械学習ブームということもあり、Pythonを習いたいという生徒さんが増えてきたが、ついにWebアプリもPythonという生徒さんが出てきて少々慌てているところもあるが、楽しみがまた一つ増えたと思っている。

JavaとPythonのWebフレームワークコースを追加予定。JavaはSpring Bootを、PythonはFlaskも考えられたが、技術情報の豊富さからDjangoを選択。

Javaのフレームワークについては私も2000年当時関わっており、そのフレームワークを使用したプロジェクトは大成功したが、フレームワーク自体はその直後にオープンソースとして登場したStrutsにあっという間に負けてしまった。

そういう苦い経験もあるが、生産性を考えるとフレームワークの授業も必要か考え、9月ころにSpring Bootを、今年の冬頃にDjangoを開講予定。どうぞお楽しみに！

粘る。諦める。休む。また、粘る。諦める。休む。また、粘る。難しいことにチャンレジするときはこのようなものである。最初から1発で問題を解決できるのは天才だけで、天才以外は1歩ずつ進めることである。粘り勝ちはよくあることで、すぐに諦めるのはもったいないと思っている。