ここ最近の軽めの話・買ったものなど
ネタがないのでいくつかのトピックに分けて最近の話を軽めに。
社内ワーキンググループ
組織的な技術力向上をテーマに、全社的にみると結構な数の社内ワーキンググループが立ち上がった。 自分もワーキンググループに参加しつつ、またそれぞれのグループの活動を推進していく立場なので、両方をうまくやっていきたい。ワーキンググループによっては対外的な発表も計画されているそうなので楽しみにしている。
自分がメンバーとして入っているワーキンググループはプロジェクトの生産性や品質向上がテーマ。 具体的に何をしていくかはメンバーでブレストしてこれから決めていくところだが、生産性を向上させるツールや技術を実際に使ってみてレポートしたり、 社内でよく使うツールのショートカットや隠れた便利機能といった、ちょっとしたTipsを集めて展開するといったような感じになるだろうと思っている。 個人的にはTDDを広めたい。とりあえず年度末までに2〜3つ(テーマ決定→調査・情報収集→展開を１ヶ月のサイクルで回す)はアウトプットすることを目標にして進めていくつもり。またミーティングではファシリテーター役をすることがめっぽう多いので、こういった"場を回す"スキルも向上させていきたい。
制御系からWeb系になるかも
今現在の自分はいわゆる制御系の業務についているが、もしかするとWeb系に変わるかもしれないということになりそうである(まだ可能性の段階だが)。 はっきりいってそうなった経緯についてはあまりよくわかっていない(汗)。まあエンジニアとしての幅が広がるならいいかと割と楽観的に考えている。 ただ本格的に入る前に準備はしっかりしておきたい。というものの、まだまだ未確定状態なのでなんとも言えない(話自体がなくなるかもしれない)。何から始めればいいものか。暫くは悶々としそうな気もするが広く浅く情報を仕入れていこうと考えている。ひとまずHTML/CSS/JavaScriptくらい共通で必要だと思うので学習しておく。
最近買ったもの
AmazonのブラックフライデーセールでEchoShow8、アウトドアワゴンなどを買った。
Echoは国内初代の第二世代のものを持っていたが、リビングから書斎への呼びかけや画面のあるEchoデバイスを使ってみたかったので買ってみた。セットアップは電源につなぐだけで完了(めちゃかんたん)。Wi-Fiの設定が必要かと思ったが、複数のAmazonデバイスを所有しているからかデフォルトですでに家のWi-Fiと接続できていた。
まだセットアップして間もないので使用感はこれから段々わかってくると思うが、今のところはまずまず。Echoそのものは音声主体のデバイスなので、画面はおまけのような感じ。UIもそこまで洗練されておらず、動画を見たりするならタブレットの方が断然使い勝手がよい。また写真を撮ったりもできるものの、画質が良いわけでもない。あとAmazon Music UnlimitedのEchoプランを別の端末に移すにはカスタマーサービスに問い合わせる必要があるらしいのが面倒そう。いいところを一つも語っていないが、画面があるのはやっぱりいいと思います(小並)。レシピ動画もサクッと見ることができるので、キッチン周りに置くと活躍できそう。インテリアとしてもなかなかオシャレ。
アウトドアワゴンは未開封。出かける際に荷物が多くなりがち＋子供がまだ小さく歩きたがらないことが多いので、これに乗せておけば少しは楽ができるかも…と思って買うことに。コロナ禍で外出自体が難しくなりつつあるが、早く使ってみたいものである。
やる気アップ、モチベーションコントロールなど
なんかやる気が出ない
ここのところ若干バーンアウト気味になっているように感じる。多忙だった時期が続いていたことに加え、今後の環境についてドラスティックな変化が起こりそう(しかも自分で何とかできそうにない)なこともあってどうも学習その他諸々に身が入らない。いろいろ考えていても仕方がないので暫くはゆっくりしようと思っていはいるものの、とはいえこのままの状態を引きずっていたくない。ということでやる気をアップさせる方法がないかなと思っている。
ググる
やる気アップやモチベーションコントロールなどでググってみると、大体次のような感じだった。
とにかく休む
休む、規則正しい生活をする、部屋の整理をするなど。身体的に疲弊している状態を元に戻すことでやる気を戻す。
目標を整理する
別のことをする、目標を思い出す、やりたいことを見つけるなど。先の状況を整理し見直すことでいわゆるやる気スイッチをONにする。
原因を断ち切る
そもそもやる気がなくなった原因を解消する。
組み合わせてやる気を戻す
調べて文字にするとなんだか至極当然のような気もするが、暫くはゆっくりしつつ少し先の自分を考えながら過ごしてみようと思う。
それはそれとして
下期に入るとともに、自分が所属している組織的な技術力向上を目標とする社内グループの活動方針も若干変更になった。テーマごとに複数のグループを作って活動することが主な取り組みになる。少し心配なのは、グループの構成や活動テーマなどが半ばトップダウン気味に決まっていることで、枠だけ作っても継続が難しいのではと危惧している。やらされ感があるとなかなか上手く進めることができない。グループを推進していく役割の自分としては、メンバー全員が楽しくやりがいを持って自然に活動できることを理想として、(活動が)止まらないようにしたい。
モチベーションが高まる仕掛け
目的目標をしっかり定める、活動を通じて得られるものを意識する、その場が楽しいと思えるような雰囲気づくり、適切なフィードバックなど、これまた文字にすると当然のような気がするが、当たり前のことを当たり前にすることが難しい。以前に学んだラーニングパターンや人を動かすに書かれていたことを思い出しつつ楽しく成長できる場づくりを行なっていきたい。
とあるプロジェクトにヘルプで入ったときのふりかえり
とあるプロジェクトがトラブルに巻き込まれ、マネジメントの役割でヘルプに入ることになった。そのためここ２ヶ月ほどはバタバタしていたが、漸く終わった(落ち着いた)のでゆるくふりかえっていく。
基本情報
- ヘルプメンバー含めて10人ちょっと(半数以上がヘルプメンバー)
- 作業場所はバラバラ
- 不具合改修メイン
- 期日が決まっている
準備など
まずはじめにRedmineで専用のプロジェクトを作り、急造(期間としては2日くらい)で開発プロセス・導入手順・進捗管理方法などをまとめた。テンプレートは社内にあったので内容を埋めるプラスアルファで済んだのは良かった。イチから考えていると結構時間がかかるので、こういうテンプレートがあると立ち上がりが段違いに感じた。また並行してヘルプメンバーの選定と調整、キックオフのための段取りをした。 幸いだったのはヘルプに入ってもらえる人全員に快諾をもらえたこと。断られると次の手に困る状況だったので助かった。それから専用のチャットグループを作ってコミュニケーション手段やルートを確立した。
ヘルプメンバーがなるべく速やかに立ち上がれるように、開発用の環境も事前に可能なところまでは構築してVMで配布できるようにしたり、wikiにドメイン系のナレッジを書き込んだりしておいた。
感じたことなど
良かった点
色々なプロジェクトからヘルプに入ってもらったので、面識はあるが普段あまり接点のない人たちとの間で交流することができた。イメージ通りの人や意外な一面を見せる人など、作業を通じて色々な面を知ることができたのは良かった。他にも普段のプロジェクトとは異なる作業内容から刺激を受けた人もいたのではないかと思う。当初はどうなるのかと不安があったが、なんとかやりきったという達成感が大きい。
進捗状況の見える化には消化チケット数によるバーンダウンチャートを使用した。先の予測を立てたり状況を報告したりするのが行いやすかった。実績に基づいていると大体これくらいで進捗しそうだなというのが感覚としてわかる。開始直後や度々ペースが悪い時期があったが、早い段階で気づくことができリカバリーもできた。
気にしていたこと
開始序盤はコミュニケーション周りには注意を払っていた。チームとしても急造だったので、やりとりにはなるべく入るようにしてコミュニケーションが止まらないようにしていた。
改善点など
チームビルディングが不十分だった。チームとして未熟な状態なので、テキストメインのコミュニケーションだと認識を合わせるのが難しいときもあった。もっと積極的にZoomを使うなどしてもよかったかもしれない。また期間中は負荷が高い状態が続いた。計画時点では考慮していたものの、やはり実際に動き出すと目標を達成するために負荷をかけざるを得なかった。そのため工数的にも実績が予定をかなりオーバーすることになった。QCDでいうところのQとDを優先していたのでいたしかたない点ではあるのだが、できることならもう少し楽にやりたかった。それでもなんとかやりとげることができたのでメンバーには感謝しかない。
あと作業中に別件でチケットが増えたり客先レビューのフィードバック対応など、いくつか予測できなかった点があった。事前に知ることができていればもう少しやりようがあったかもしれない。
事前の察知が重要
今回の件についてはヘルプに入る時点でこうなることがある程度予想できたので、対応内容の改善というよりもどうやったら初めから負け戦状態に陥らないか、もっと早い段階で気づくことはできなかったのかを考える必要がある。個人的には普段から状況を把握できるような仕組みづくりが重要だと考えている。一応社内に定型的な報告の仕組みはあるがあまり活用できていない。そういうのも大事だが、もっとゆるい感じで、雑談でもそういった話ができるような雰囲気にしていければと思っている。
クネビンフレームワークで問題を分類する
SCRUMMASTER THE BOOKを読んでいると、３章だったか４章だったかでクネビンフレームワークというものが出てきた。問題や状況を分類しどういったアプローチをとるかを決めるのに有効なツールだ。今年は特に社内の技術力向上について考える機会が多く、またどういった問題や課題を抱えているか・それらについてどういった改善案・解決策を取ればよいかで頭を悩ませることが多かった(今もその最中)。クネビンフレームワークはこれを解決するのにとても有用なのでは、と考えちょっとまとめてみることにした。
クネビンフレームワークとは
1999年にデイブ・スノーデンが提唱したもの。問題を自明(Simple)、煩雑(Complicated)、複合(Complex)、混沌(Chaos)、無秩序(Disorder)の5つの領域に分類する。
Cynefin framework - Wikipedia より引用
単純・自明(Simple)
単純な問題。因果関係や構造が明確になっており、解決策が自明である。ベストプラクティスの世界。問題を認識・分類し、ベストプラクティスに示された解決策を適用する。
煩雑(Complicated)
分類や因果関係・構造を明確化するために分析が必要。専門家に解決策を依頼する。グッドプラクティスの世界。SCRUMMASTER THE BOOKによるとウォーターフォールであるとのこと。
複合(Complex)
因果関係が複雑で事前に判断するのが難しい。分析も失敗する。やってみないとわからない状態。アジャイルやスクラムの世界。
混沌(Chaos)
完全に予測不可能でコントロールできない。子どものパーティのような状態。考えられるプラクティスを場当たり的にとにかくやってみる世界。
無秩序(Disorder)
状況を分類する方法がわからず、直面する問題に解決策がない。
まとめ
いままで問題や課題に対しては分析ありきで、とにかく現状分析してみて解決案を考えるという方法が主体だったのでアプローチの方法についてはあまり意識してこなかった。クネビンフレームワークを知ることで、どの領域の問題なのかを考えられるようになり、領域ごとのアプローチを取れるようになる。またそのアプローチが間違っていたとしても、結果から次のアプローチが取りやすくなるのではないかと考える。今後はこれを意識してどういったアプローチをとるべきなのかを考えてみようと思う。
『ここアジャ』記念対談イベントに参加した
『ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織の作り方』という書籍の発売に伴い、著者による記念対談が開催されていたので参加した。
著者は『〇〇の問題地図』シリーズの沢渡あまねさんと、『カイゼン・ジャーニー』の新井剛さん。どちらの方の書籍もウチの社内の本棚にある。 はじめに書籍や書籍に登場する人物の紹介があったのだが、仕事中に参加していたため、ちょうど電話がかかってきてこのあたりを聞き逃してしまった。残念。
トークテーマは下記の通り。個人的には4つ目のテーマが気になっていた。
これからの開発や組織のカタチとは？
オープン＆ハイブリッド。昔は組織の中に答えがあったが、今は不確実性に向き合う時代。
組織の中に答えはない。そのため様々なことを経験・チャレンジして自分の中に引き出しをたくさん作ることが大切になってくる。そうすることで幅広く応用が効くようになる。
「何から始めたらいい？」現場を変えるヒント
おやつ神社の紹介。おやつを置いて立ち寄れる場所。そこに人が集まることで雑談が生まれ、コミュニケーションが活性化していく。そういえば昔、HappyBoxなるお菓子箱が社内にあったなあと思い出した。あれも同じような目的だったと思う。最近コミュニケーション関連で課題感があったので、今こそあってもいいのかもと感じた。
コミュニケーション関係で印象に残ったのは、コミュニケーションは手を変え品を変え景色を変えという話。分かってはいるものの偏りがちになっている。特にチャットに。あまりチャットの文化に慣れていない人もいて、そういう人は割と見逃しがちなので、「チャットに書いてますよ」ではなく、手段を変えた方が良い場合もある。また目的に応じて使い分けたほうが効率的に伝えられる。
感想など
ウォーターフォールもアジャイルも互いに良いところがあり、1か0かで考えるのではなく状況に応じて使い分けるほうがよいという話から、無理矢理型にはめず柔軟な意思決定ができるようになれればと思った。そのためにも自分の中に引き出しをたくさん持っておきたい。
今回著者のお二人のお話を聞いたのは初めてだったが、話し方がすごく柔らかく優しい印象を持った。人の良さみたいなものがZoom越しでも出ていて、やはり話し方は重要だと感じざるを得なかった。自分は人前だと結構早口でバタバタと話すので、話し方伝え方をもっと改善したい。
色々と気づきを与えてもらえたこのイベント、参加してよかった。ありがとうございました。実はまだ書籍を読めていないので、今読んでいるものが終わったら読んでみようと思う。
まとめもありました
CleanAgileを読んで基本に立ち戻る
Clean Agileを読んだので内容や感じたことなどをまとめる。
序文にもあるが、概要としてはアジャイル開発とはなんなのか、その歴史・アジャイルのプラクティスなどがアンクルボブの視点で解説されたものである。アジャイルに関する書籍は幾多にも及ぶが、誕生の瞬間の話がここまで詳細に書かれているものは少ないのではないかと思う(自分の知る限りではない)。どういう経緯でスノーバードの会議が開かれたのか、興味のある方には特におすすめできる。
目次
気づいたことや感想など
ウォーターフォール
とある論文で紹介された、後にウォーターフォール呼ばれるプロセスだが認知のされ方が意外だった。もともとはその論文の後半で論破する予定であったが、図が論文の目立つところにあって、この図だけでその内容を推測する人が多く出てしまって著者の意図とは違う方向で認知されたというもの。この件が以降の30年間を支配したのだから、読んでいてゾッとしてしまった。
サークルオブライフ
XPのプラクティスを描いた3つのリングを持つ図。外側のリングにあるプラクティスは(当時の)スクラムプロセスに相当するというもの。不勉強なものでこの図については知らなかった。XP本は10年くらい前に読んだっきりだったので、プラクティスについてはざっとは知っている程度でしかなかった。当時の本には載ってなかった気がする(たぶん)。
XPについてはアンクルボブがとても推すので、改めて興味が湧き読んでみたいと思った。調べてみるとXP本の第二版も出ているみたい。
プロフェッショナルであること
今はあらゆるところにソフトウェアがある時代で、ソフトウェアが世界を支配しているといっても過言ではない。そのような世界でプログラマーが十分な品質を担保しているかと言うとどうか。ちょっとしたバグのせいで世界が大惨事になることもありうる。そのためプロフェッショナリズムがプログラマーには求められている。自分が誰で、何をするためにここにいて、何ができるのかをしっかりと認識することが重要だと思う。
ソフトウェアクラフトマンシップ
プロとしてのソフトウェア開発の水準を引き上げ、アジャイルの本来の目的を再構築するために、新しいムーブメントとして「ソフトウェアクラフトマンシップ」というマニフェストが2008年11月に生み出されたとのこと。当時の自分は社会人になって数年目くらいだったが、この流れは知らなかった。日本語でググった感じだと、10年くらい前の記事がいくつか見当たるくらいで、日本ではそこまで大きなものにはならなかったのだと思える(単に自分が知らなかっただけかもしれないが)。内容としてはアジャイルマニフェストをベースに、それだけではなくプロであるべきというマインドを促進させるようなものになっていて、個人的には忘れずに持っていたい気質であると感じた。
- 動くソフトウェアだけでなく、精巧に作られたソフトウェアも
- 変化への対応だけでなく、着実な価値の付加も
- 個人との対話だけでなく、専門家のコミュニティも
- 顧客との協調だけでなく、生産的なパートナーシップも
上記はClean Agileからの抜粋だが、原典はこちら。
Manifesto for Software Craftsmanship
動画も
訳者のお二人と平鍋さんによる、アンクルボブへのインタビュー動画もある。
こちらもとても良い内容(語彙)なので、必見。
An interview with Uncle Bob on "Clean Agile" - Celebration to the Japanese Editionagile-douga.tv
Python学習メモ：ジェネレータ・デコレータ
ジェネレータ
ジェネレータはリストやタプルのように、for文で使用できるイテラブルなオブジェクト。リストやタプルは要素数に応じてメモリ使用量も増えるが、ジェネレータは次の要素が求められるたびに新たな要素を生成して返すためメモリ使用量を節約できる。
ジェネレータ関数
内部でyield式を使っている関数をジェネレータ関数という。ジェネレータ関数の戻り値は、ジェネレータイテレータと呼ばれるイテレータ。
このイテレータは特殊メソッド__next__()が呼ばれるたびに関数内の処理が次のyield式まで進む。呼び出し元にyield式に渡した値を返すと、そのときの状態を保持したままその行で処理を中断する。再度特殊メソッドが呼ばれると次の行から処理が再開され、関数を抜けると自動でStopIterationが送出される。
def gen_function(n): print(‘start’) while n: print(f’yield: {n}’) yield n n -= 1 gen = gen_function(2) next(gen)
上の処理でnext(gen)が呼ばれるたびにnの値がデクリメントされる。
ジェネレータ式
リストやタプルなどのイテラブルなオブジェクトがある場合は、内包表記を使ってジェネレータを作成できる。リスト内包表記と同じ構文で[]の代わりに()を使う。
x = [1, 2, 3, 4, 5] gen = (i**2 for i in x) list(gen) # [1, 4, 9, 16, 25]
ジェネレータを使用する際の注意点
関数len()には使用できない。また巨大なジェネレータや無限に返すジェネレータをリストやタプルに渡すとメモリを圧迫したり無限ループになったりするので注意。
ジェネレータのユースケース
値を無限に返したいときや大きなデータを扱いたいときに有効。大量のテキストデータや画像ファイルを扱う際に、行単位やファイル単位でデータを取り出す逐次処理をするとパフォーマンス向上が期待できる。
デコレータ
デコレータは関数やクラスの前後に処理を追加できる機能。関数やクラスの前後に@で始まる文字列を記述すると使用できる。関数の引数チェックや実行時間計測などの用途でよく利用される。
デコレータの実体
関数デコレータの実体は、引数に関数を一つ受け取る呼び出し可能オブジェクト。プログラムの実行中には、関数デコレータが戻り値で返した新しい関数が元の関数名に紐づけられる。
処理時間の計測
処理時間を計測するデコレータの例は以下の通り。詳細はPython実践入門参照。
from functools import wraps import time def elapsed_time(f): @wraps(f) def wrapper(*args, **kwargs): start = time.time() v = f(*args, **kwargs) print(f’{f.__name__}: {time.time() - start}”) return v return wrapper
functors.wraps()を使うことで、実際に実行される関数の名前やDocstringをもとの関数のものに置き換えることができる。これをしないと、デコレータ内のラッパーの関数名がラッパーのものになり、デバッグ時などで不便。
デコレータelapsed_timeの使用例は以下の通り。
@elapsed_time def func(n): return sum(i for i in range(n)) # 0〜n-1までの総和を返す print(f’{func(10000)=:,}’)
